Consensus Call Tranche 1 (Document Organization)

[John C Klensin]

--On Tuesday, 07 October, 2008 01:41 +0200 JFC Morfin
<jefsey at jefsey.com> wrote:

> At 22:54 06/10/2008, Vint Cerf wrote:
>> DUE DATE: October 10, 2008 (ET)
>> 
>> Place your reply here: [YES or NO]
> 
> NO.
> 
> Comment:
> 
> 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.

Jefsey,

With the understanding, as usual, that I will do whatever Vint
concludes represents consensus tells me too, I think your
conclusion is at variance with positions you have expressed
about your own users and readership.

Try to think about it this way...

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.

     john