+1
v
On Wed, Apr 19, 2017 at 9:19 AM, John C Klensin <klensin@xxxxxxx> 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
<paul.hoffman@xxxxxxxx> 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