Re: Last Call: <draft-freytag-lager-variant-rules-05.txt> (Variant Rules) to Informational RFC

[Vint Cerf <[e-mail]>]

+1
v


On Wed, Apr 19, 2017 at 9:19 AM, John C Klensin <[e-mail]> wrote:

> Paul and IESG,
>
> While I think the clarifications in this draft are a
> considerable improvement, your response to Vint captures the
> concern about this document all along.  To explain, I'm going to
> need to review some history, so apologies for probable length.
>
> The whole topic of DNS "variant rules" has been controversial
> among those who know about them and care from the beginning.
> They are much less so in the context of the root zone for which,
> the special names issues aside, ICANN has clear responsibility
> (and can make whatever rules they like, including the one to
> allow thousands of names, as long as IETF Standards are not
> violated -- and even the latter seems to be under threat), than
> for zones deeper in the tree and whether such rules are used
> there in a voluntary or involuntary.
>
> I note that, at the time ICANN first started allowing and
> encouraging IANA publication/ registrations of the characters
> that particular TLDs would allow in their zones, the ICANN Board
> (with support from me and the IAB), created that registry
> directly rather than requiring that the IETF establish the
> registry and rules for its maintenance.  The idea was to try to
> help preserve and reinforce the separation implied by the above.
>
> We've also seen some history of documents being adopted (a
> deliberately vague term) in the IETF then being used to argue in
> ICANN processes that the IETF action means that ICANN has to
> implement then.  That approach goes back to at least the CRISP
> effort (RFC 3707).   That it has been unsuccessful in many cases
> is beside the point.  That some of the efforts in the IETF have
> been strongly influenced by ICANN staff members who might (or
> might not) have planned to influence ICANN policy development
> processes in ways that they could not do directly may or may not
> also be an issue (and you, and other ICANN staff, may reasonably
> interpret all of those data differently than I do).
>
> So the IETF created a WG, LAGER, to do the core work on which
> this I-D was based, ultimately cumulating in RFC 7940.  I note
> that, in recent years, we've had trouble getting enough traction
> to do meaningful work on any internationalization (i18n) issues
> -- IMO, EAI and PRECIS barely had enough active participation to
> justify a claim of meaningful WG consensus by the time their
> work wound down and other than a BOF (LUCID) that, IMO, never
> engaged with the key topics, the IETF has not been able to
> engage on the "non-decomposable character" issue despite a
> request from the IAB that it do so.   I imagine that many
> people, even some of the i18n experts looked at the lAGER
> charter and said "if people want to get together and write some
> data representation rules around something that is basically an
> ICANN problem, I don't need to worry about it".   I also
> imagine, reinforced by the few comments during IETF Last Call on
> what became 7940, that the Last Call reaction was similar.
> However, in that case, there _was_ a WG, the IESG reached the
> conclusion that the WG had sufficient membership and
> participation to be meaningful, and the community generally
> assumes that WG conclusions should stand as IETF ones if there
> is no meaningful and substantive dissent during Last Call.
>
> Then the IESG, in its wisdom and for reasons not announced to
> the IETF other than "concluded work" (such announcements are
> rarely made and I wouldn't propose to change it) closed down the
> WG.
>
> Then this document appears as an individual submission.   There
> has been little evidence of wide review, especially by those
> with significant history of IDN involvement in the IETF.
> Perhaps that is in part because it shares the limited scope
> issues with LAGER and RFC 7940, requires a thorough
> understanding of that document and what it does and does not do,
> and, noting that the IAB just shut down its I19n Program after a
> long period of inactivity, there seems to be even less ability
> to get IETF traction on i18n issues than there was a few years
> ago.
>
> As I understand it, this document provides and explains a system
> to assist in developing and describing rules that might then be
> documented according to 7940.  Even with the latest revision, it
> makes some assumptions that some of us (including, given his
> comment, I assume Vint) question in an IETF context (even if
> they represent ICANN consensus and are reasonable there because
> the scope, conditions, and support arrangements are different).
> At least in principle, the IESG could have reopened LAGER,
> gotten review there, and then pushed this through as a document
> from the same WG that was responsible for 7940.  They didn't.
>
> But your conclusion was (out of context, but complete below)
>
> > There is no IDNA Working Group any more, so there is no way to
> > say that it was not endorsed by this WG. The document is,
> > however, intending to be an IETF consensus document.
>
> Right.  There is no way to say that LAGER did not endorse it (or
> would not have endorsed it had it still existed).   Likewise for
> IDNABIS.  AFAIK, DNSOP and for that matter and, despite it (and
> 7940 (to pick a random example) LISP didn't consider it either.
> Since 7940 (last paragraph of introduction) and this document
> even more strongly claim that their data structures, mechanisms,
> and principles can be used for non-DNS identifier labels,
> perhaps the latter should have looked at it.  But none of them
> did although, by your logic as I read it, there is no way to
> assume that they would not have endorsed it had they looked and
> therefore their assent must be assumed.
>
> For a claim of IETF consensus on an individual submission,
> especially one that is the slightest bit controversial (as this
> clearly is, even if one believes the controversy is about
> process, not substantive content), I think there has to be clear
> evidence of adequate and competent review of document content
> and relationship to other work to make that consensus claim
> meaningful.  I don't think that has been demonstrated; YMMD.
>
> I also think that, if a document comes out of a WG and then one
> of its authors produces a individual document that suggests an
> extension, interpretation, or supplemental tools, we need to be
> extra-careful about that document and IETF consensus claims.
> YMMD about that too.
>
> Your response to Vint about what can be done about this was:
>
> > It says "Informational" right at the top of the document, and
> > that's the best we can do for the RFC Series.
>
> But that is not "the best we can do".   The IESG can say
> "insufficient evidence of IETF consensus" and drop the document.
> I don't recommend that, but it is possible that others would
> disagree.  The document can be handed off to the Independent
> Submission Editor with recommendation for publication with the
> usual clear statement from that Stream about there being no
> consensus assessment.   Noting that all of the documents that
> started the "variant" epidemic (RFCs 3743, 4290, and, as a key
> example at least, 4713) were published in the Independent Stream
> and that didn't prevent them from getting community attention,
> there is probably little argument for the IETF Stream unless
> there is either clear evidence of consensus or if this document
> is really expected to be treated as a Standards Track supplement
> to 7940 independent of its official status.   Or, in principle,
> the IESG could attach a note indicating that the document is
> published as a convenience and there is little or no evidence of
> informed IETF consensus about it.
>
> For me, it is precisely the claim that the document represents
> IETF consensus, or the now-demonstrated high likelihood that
> claim will be made, that is the problem here.   That claim is,
> at best, not demonstrated to be true and, for a document that I
> believe lies very close to the boundaries of IETF scope and
> relationship to ICANN, I think we need to be extra careful about
> it when it is not demonstrably true (and not just because a
> series of current and closed WGs haven't commented on, much less
> endorsed, it).
>
>    best,
>      john
>
>
>   ---------------------------
>
> For the information of the IESG and community, Paul forwarded
> the Last Call announcement to the idna-update mailing list.
> Vint responded there (but not to the IETF list or, AFAIK, to the
> IESG) and Paul responded to him (but, again, not to the IETF
> list or AFAIK, the IESG).  Paul's response to Vint and, IIR, the
> substantive part of Vint's message appear below.
>
>
> --On Tuesday, April 18, 2017 09:38 -0700 Paul Hoffman
> <[e-mail]> wrote:
>
> > On 18 Apr 2017, at 7:04, Vint Cerf wrote:
> >
> >> if this is published, I hope it is made clear that this is
> >> not a  standards
> >> recommendation endorsed by the IDNA working group.
> >
> > It says "Informational" right at the top of the document, and
> > that's the best we can do for the RFC Series.
> >
> > There is no IDNA Working Group any more, so there is no way to
> > say that it was not endorsed by this WG. The document is,
> > however, intending to be an IETF consensus document.
> >
> > --Paul Hoffman
>
>


-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190