Consensus Call Tranche 1 Results
Vint Cerf
vint at google.com
Sun Oct 12 12:32:43 CEST 2008
Tranche 1 - Document Format
Analysis:
There were 12 votes for and 10 votes against the proposed consensus,
thus there is not a consensus on the proposed format and content of
the Rationale document.
In reading through the comments below, the common theme is
approximately: "move normative material from Rationale"
into either Protocol or into a separate document. "
A possible compromise might be to leave material in Rationale
for expository purposes (but NOT for normative purposes)
and to incorporate the normative material AS NORMATIVE
into Protocol, for example.
It appears that much of the material considered normative is
definitional and could reasonably fit into the Protocol document
structure.
As chair, I ask the editor of Rationale (John Klensin) to review
the comments above and below and, to the best of his ability,
attempt to compose a revision of Rationale (and Protocol, if
the Normative material found in Rationale can be reasonably
accommodated there.) Of course, WG members are free to suggest
alternative treatments that attempt to resolve the varied
comments found below, taken from the poll responses to the
Document format question.
Vint Cerf
====================================================
Rationale document should be an informational document that explains
- background of IDNA2008
- IDNA2008 design concept / philosophy
- IDNA2008 documents structure
- IDNA2008 requirements
and so on. If it is intended to be "informational", it should be
just "informational".
Normative materials should be described in other documents such as
protocol document that evolve through standard track. We should
avoid such cases that no recommendations in rationale document such
as local mapping are implemented in applications and lost backward
compatibility with IDNA2003. In order to assure this, standard track
documents should have all relevant normative materials.
=====================================================
Rationale:
- While John has shown in -03 that there are some differences
between him and Mark in terms of what should be normative and
what not, I don't think these will take that long to hash out
(as far as I have checked, I lean somewhat more towards John's
assessment than Mark's, but still somewhat in between).
- The parts of the Rationale document that I have read give me
the impression that it's far from ready, for ANY purpose.
The main problems are:
1) It's written in present or future tense, like "here's
what we are going to do, and why", in many places,
which means it has to be re-written to actually be
readable after publication. While such a rewrite might
slightly lower its value for current readers, the
earlier this is done, the better.
2) While the document makes several successful attempts
at clarifying some of the rationale behind some of
the design and some of the changes between 2003 and 2008,
each of the pieces is written with some assumptions about
previous knowledge, and these assumptions differ widely,
and aren't built up step by step or made explicit.
I would personally not recommend anybody to read this
document unless I'd be sure the person is so much into
IDNA and related issues already that s/he can take a
critical approach to the document (being able to
identify its strengths and weaknesses) or I'd be sure
I'd be able to babysit the reader to correct wrong
assumptions.
======================================================
I agree with the Rationale document necessity, but it should not
contain normative material and shuld be an informational document.
- The normative material should be removed from Rationale and
extracted to a separate document (for example Terms and Concepts)
even if this lengthens the WG's target dates for an unknown period of
time. Note that there may be controversy about what material is
normative and what is not; that is a separate consensus issue and may
also take an unknown period of time to resolve (R.2)
The normative material should be a separate document or merged to
protocol document.
=====================================================
I'm implementing an application. Both rational and specification
could be useful (not to me, not for "in applications" but in theory,
you know how theory and practice are).
I'm implementing a registry, and I've seen this implemented both in
pure punycode and in utf8. Both rational and specification could be
useful ... again, in theory.
When I think of ccTLD registries, the CDNC and JET participants of
2002 and the present, in particular, which isn't the whole universe
by any means, they have "... the technical savvy to implement (and
understand) the protocol as such ..."
So Yes, in theory, but for archaic reasons only the mandatory to
implement statements have my personal interest, and "... is behind
its original schedule. It should be noted that ..." is noted, but not
particularly useful, even wearing that neither application nor
zonefile implementor hat.
======================================================
I believe that both "policy people" and "coder people" need the
definitions.
I believe that both "policy people" and "coder people" need to read
Rationale.
Therefore, I do not see a value to a separate "definitions" document
- it adds to the clutter.
======================================================
I have no formal issue with keeping normative parts outside the protocol
document. It is not my preferred solution, it makes reading more
challenging, especially for implementers, but I could live with it, even
if reluctantly. So this is a YES strictly on the matter of document
organization.
I am however with many other here in requiring the rationale document to
identify normative and non normative parts as soon as possible. This is
standard practice in most standard documents. We can't really make
progress until we decide what is normative or not in it.
========================================================
(1.a) The Rationale document should be retained to support implementors
whose work requires that they understand the reasoning behind certain
design choices.
Even if I think this is true,
(1.b) While there has been debate about whether or not the content of
the
Rationale document should contain normative material, it seems
expedient to
agree on the content of Rationale for Proposed Standard without
attempting
to separate it into multiple parts.
I don't think this is true. I cannot see any reason why a rationale
document ought to become a normative part of a specification. In
another context, I am fighting to fix historical documents which
conflated the informative and normative roles, and which did so in an
environment of much greater homogeneity than we find among the network
operator community today.
As an aside, I agree that there are two audiences for these documents.
We can call them, loosely, the "registry implementers" and the
"protocol implementers". The latter are the strictly technical people
who will have to implement the protocol as such. The former are,
often, technical managers who do not have or need the technical savvy
to implement (or maybe understand) the protocol as such, but who have
to make intelligent and informed choices about the policies related to
the protocol. It seems to me that these two audiences have enough
different about them that we need to address them differently. A
protocol implementer rarely cares why: "what" is the correct question
here, or we'll never get interoperation. Policy decisions, however,
need to be informed more by why than by what.
the WG's target dates for an unknown period of time. Note that there
may
be controversy about what material is normative and what is not; that
is a
separate consensus issue and may also take an unknown period of time to
resolve (R.2)
I agree strongly with others in the thread, who have argued that if
there is such controversy, then there is no way the documents are
ready to go anywhere. If we who are interested in this topic cannot
agree on what is normative, I can't see how interoperation is ever
going to happen. If you can't state something plainly, it's not a
protocol for machines. So to the extent these things aren't yet
plain, we don't have protocol documents yet.
===================================================
Speaking as implementer, it is difficult to implement technology that is
not clearly specified, and even more so when it is unclear what is
intended to be normative and what is not. Having normative language
spread over several documents is unfortunate, but if there is a clear
separation (like in IDNA2003), the costs are manageable. Having
normative language in a rationale document does not seem like a good
idea to me.
I would agree that definitions needs to be normative. However, that is
not a reason to make the entire idnabis-rationale document normative.
It is easy to reproduce the necessary definitions in the other document.
The alternative is:
- The normative material should be removed from Rationale and
extracted to a separate document (for example Terms and Concepts)
This sounds better from a technical point of view to me.
even if this lengthens the WG's target dates for an unknown period of
time. Note that there may be controversy about what material is
normative and what is not; that is a separate consensus issue and may
also take an unknown period of time to resolve (R.2)
If there are controversies around what is normative and what is not,
that suggests to me that the documents aren't ready to move forward
anyway.
====================================================
COMMENTS: IDNA200X assumes the implementation of policy-level
constraints that are not articulated in the protocol, itself. It is
therefore imperative that the document suite attaching to the
protocol revision contains an encapsulated exposition of all the
detail that needs to be understood by DNS zone administrators, if the
expectations being placed on them are successfully to be met. It is
patently unrealistic to expect the focus of these administrators'
interest and understanding invariably to be congruent with that of
software developers. It is therefore inappropriate to require that
the necessary information be gleaned from documents deliberately and
exclusively framed for the technically oriented segment of the
target community.
=====================================================
As I have said before, I can live with the extra document
solution implied by the alternative outlined below. However,
I am very concerned about two things:
(1) Especially given the speed at which the WG is
moving, it may take us a long time to get consensus
about what is and is not "normative". One specific
example is the description of differences between
IDNA2003 and IDNA2003, which I believe must not be
considered normative unless we want to risk much greater
trouble.
(2) I fear that, if we move the material that people
consider critical out of the Rationale document with the
intention of getting the other documents out sooner, it
may be equivalent to a decision to kill the Rationale
document. For reasons that have been discussed at
length on the list, I believe the explanatory material
in the Rationale document is as important to our work as
the protocol-implementer material in the other documents.
==================================================
If we were writing a specification for implementers only, we
would write exactly the specification I think you are describing
-- a purely normative technical document (or set of documents)
that contain no explanatory material at all (not even examples)
because there is always a risk that the explanatory material
would contradict the base material and thereby create confusion
and inconsistent implementations. If documents were translated,
the odds of apparent contradictions would actually increase. In
addition to removing the normative material (whatever that
means; see below) from Rationale, we would also remove
explanatory material from Protocol and Tables. For example, we
would eliminate the textual explanations about the intent of
each of the contextual rules and leave only the semi-formal
definitions.
We would also eliminate the [rest of the] Rationale document
(and any other explanatory material) entirely, because someone
might read those materials instead of the specification and
implement from it, with very high odds of getting some detail
wrong and creating interoperability problems.
If I correctly understand the proposal Paul Hoffman made several
times, that is precisely the model he was suggesting, with full
awareness of its consequences -- no explanatory material at all,
just the steps that an implementer was to follow and the minimum
amount of material needed to make those steps clear.
The problem with that approach lies precisely with the types of
user communities you are most concerned about. In my
experience, they will not read a technical protocol document,
regardless of the human language in which it is more or less
written (or to which it is translated). The leadership of ICANN
and the ccNSO (and that of the GAC and gNSO) are at least as
problematic. Despite many efforts, we have had little success
in getting them to understand how IDNs work and far less success
in getting them to read any specific technical document
(specifically including RFC 3490, 3491, 3492, and 3454). We
hear a lot of discussions among those groups in which terms like
"stringprep" or "punycode" are tossed around, but, when we
question the speakers, it is clear that they have not looked at
those documents but are relying on their impressions (sometimes
very vague and third-hand) about what is in them and what the
terms mean. Even RFC 4690 --which you like but several
participants in the WG do not-- is, at least in my experience,
read very little in that community... read even less than it is
cited, which is not often.
The current document organization recognizes the difficulties
with their reading and understanding a technical document and
tries to present, in what we have been calling Rationale
(remember that most of the content is explanations and
definitions, not "rationale" as such), the definitions,
explanations, and information that they need to make sensible
decisions about registration policy, permitted internationalized
naming relationships, etc. I believe, as a group, they are as
important an audience as the protocol implementers. If I
correctly understand much of what you have been saying for the
last few years, you do too.
I think the alternative scenario, in practice, is likely to look
like this:
(i) We try to pull all of the normative material out of
the Rationale document. That is going to require
reaching consensus on what that material actually is.
For example, Mark has suggested that the "how IDNA2008
is different from IDNA2003" material is normative. I
suggest it is not and should not be treated as such,
both because it is not needed to implement IDNA2008 and
because there is a possibility that an implementation of
IDNA2008 derived by looking at differences from IDNA2003
would be slightly different from one derived from
looking at the technical specification alone. One way
or another, we would need to take the time to resolve
that, and possibly other, differences in opinion about
what is and is not normative. Unless we figured out how
to do so much more quickly than the WG has been working,
I believe that would push us into 2009, with no
possibility of stabilizing the other documents until
that is done.
(ii) We then get the other documents out to Proposed
Standard and the already-slow-moving WG becomes
impossible to mobilize to do the work necessary to
produce a consensus Rationale document.
(iii) Sooner or later, someone (maybe me (but no
promises), maybe Cary, Patrik, Tina or someone else)
produces an IDNA2008 explanation document as a personal
piece, with no real opportunity for review by the group.
That --rather than anything from the IETF-- becomes the
document that ICANN and the various policy types
actually read and refer to (if, indeed, they read
anything).
If those folks decide they need to make decisions before
that document appears, they decide on the basis of what
they think IDNA2008 says, or should say, or might say,
or would say if the DNS worked the way they think it
does. To all intents and purposes, that does put them
in charge of at least some pieces of the Internet
technology because IETF was unwilling or unable to
explain the technology to them in a way that they could
understand and in a timely fashion.
That, presumably, is not your desired outcome.
==================================================
The definitions in Rationale are really crucial to the other
documents. Moreover, I really think it is not much of a problem to
take the definitions out of Rationale; I already sent out a note
detailing which sections would come out.
The problem I see is that Rationale still has so many problematic and
contentious sections still that we will just end up wrangling over it
forever. And because of those problems, I see that foresee that we
will not get interoperable implementations, because the normative
implications will be unsure. I believe the shortest path to success
will be to
pull the normative definitions out of Rationale,
include them in Protocol or a separate document,
and push those documents out (bidi, tables, protocol/definitions)
A second phase will be to fix the text of Rationale be purely
informative and clean up problems in it, but the other documents
don't have to wait on Rationale.
==========================================================
The note below says that "the" alternative is to move the normative
material out of Rationale into a second document". But look closely
at the statement:
"...even if this lengthens the WG's target dates for an unknown
period of time. Note that there may be controversy about what
material is normative and what is not; that is a separate consensus
issue and may also take an unknown period of time to resolve ..."
These are *precisely* the reasons why this measure should fail. If
there is controversy in *this* group about what is normative or not,
it means that the document as a whole is badly written, and will be
impossible for ordinary readers to understand what is normative or
not. Moreover, the "even if this lengthens the target dates" is a
misleading. I believe it will take much longer to iron out the many
problems in Rationale if it has normative content than if it is
purely informative -- in the latter case, the problems in the text
are not as important.
If we were really concerned with (a) the timing, and (b) having a
rigorous document, the better alternative would be to move the
normative definitions into Protocol (or a separate document), and
then put Rationale on its own track, not tied to the release schedule
of the other parts.
======================================================
The normative part must be kept as short, comprehensive and clear as
possible. So it can be clearly translated and understood out of any
local specific which might disagree with parts of the rationale.
ICANN considers that implementing something this year after eight
wasted years is a key JPA related issue. IMHO, their best political
mistake would be to implement something not considering RFC 4690 and
users. ICANN/ccNSO is not in charge of the Internet technology.
========================================================
NOTE NEW BUSINESS ADDRESS AND PHONE
Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081012/9744e6a9/attachment-0001.htm
More information about the Idna-update
mailing list