On 5 Dec 2018, at 16:37, John C Klensin wrote:
But, with two qualifications, that is all that has ever been
proposed. Those are:
(1) Because the root of the problems in this topic area is (or
appears to be) that the IETF community doesn't know nearly as
much about the topic as it would in a more ideal world and
because i18n work spans traditional and current Areas, I hope
the advice would be public rather than delivered in secret to
the AD and I would hope that the group would make an extra
effort to explain its reasoning in ways that the community (not
just the ADs) could understand and learn from. I would hope
that the group members would want to do those things and that
the relevant AD(s) would insist on them. (I don't think you
intended advice delivered in secret and kept that way, but your
suggestion could be read that way). I think that is consistent
with your interpretation of "educating..." but can be see how
that could be interpreted differently, just as my initial
suggestion was.
it has been « by design » that Stringprep [RFC3454] and its
replacement Precis[RFC8264] that there will be « requests » on how
to do « the precis profile for my protocol » from the community.
This happened for Stringprep quite a lot after the release of
Stringprep. With Precis, we updated many of those to use Precis instead,
but when the precis working group was closed, there was still many
profiles-to-update left and obviously others will come.
Therefore, for Precis at least, there will be some
community—i18ndirectorate exchanges similar to yang doctors.
Marc.
(2) Not unlike our "Doctors" model (and consistent with the very
informal consultations about some LAMPS documents which I
believe were successful), I'd expect WGs and
document-developers, including those in other Areas, to want to
consult this group for advice and even help with text in
documents. I'd hope that could be handled informally,
directly, and efficiently, with a focus on getting quality work
done. I think it would be very unfortunate if the same sort of
procedure-lawyering that has gotten involved in this thread
would turn those efforts into requirements for a process that
would go something like:
(OtherWG (or AD in other Area)): Dear ART ADs, would you
please ask the Directorate to review XYZ and help with text.
(ART AD to OtherWG): Sure
(ART AD to Directorate): Please see this request from
OtherWG, deal with it, and tell me.
(Directorate to ART AD (because they are expected to advise
that AD and no one else): ART AD, we think ABCDE
(ART AT to Other WG): Directorate says "we think ABCDE"
Possibly followed by additional iterations of this waste of the
time of ADs and Directorate members, especially if specific text
were asked for and/or suggested.
I think that would be seriously dumb and hope my example shows
that and why. But it would be consistent with efforts to draw
narrow lines around supposed principles such as "the only thing
a directorate is allowed to do is to advise ADs in that area).
best,
john
--On Tuesday, December 4, 2018 19:21 -0500 Vint Cerf
<[email protected]> wrote:
suggestion:
set up the advisory group and allow it to offer advice to the
appropriate AD.
This same advisory group can reasonably share its findings
more generally, thereby "educating...." the rest of the
community. No power to block should either explicitly or
implicitly be inferred by the creation of the advisory body.
_______________________________________________
IDNA-UPDATE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idna-update
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
