Re: Call for review of proposed update to ID-Checklist

[Ted Hardie <[e-mail]>]

At 2:03 PM -0700 7/9/08, John C Klensin wrote:

>I propose
>the following as alternative text:

A nit with this:


>        "6.  Addresses used in I-Ds SHOULD use fully qualified
>        domain names (FQDNs) instead of literal IP addresses.
>        Working Groups or authors seeing exemptions from that
>        rule MUST supply the rationale for IP address use with
>        inline comments (e.g., "Editor's note:" or "Note in
>        Draft:" that can be evaluated by the IESG and the
>        community along with the rest of the document.  Domain
>        names  in pseudo-code, actual code segments, sample data
>        structures and templates, specifically including MIB
>        definitions and examples that could reasonably be
>        expected to be partially or entirely copied into code,
>        MUST be drawn from the list reserved for documentary use
>        in BCP32 (RFC 2606 or its successors).

I believe that this must say "Example domains in pseudo-code, actual
code segments, sample data structures and templates, specifically
including MIB definitions and examples that could reasonably be
expected to be partially or entirely copied into code,
MUST be drawn from the list reserved for documentary use
in BCP32 (RFC 2606 or its successors). "  Without that, it might
be read to force things like the domains in XML namespaces
to fit this rule.  Those are, after all, things that might be partially
or entirely copied into code.



> It is generally
>        desirable for domain names used in other I-D discussion
>        contexts to be drawn from BCP32 as well, if only as an
>        act of politeness toward those who might be using the
>        domains for other purposes at the time of publication or
>        subsequently.   Working groups or editors who are
>        convinced that different names are required MUST be
>        prepared to explain and justify their choices and SHOULD
>        do so with explicit inline comments such as those
>        described above."
>
>Now, that is somewhat longer and more complicated, but it would
>seem to satisfy the criteria that have been discussed on the
>IETF list, not just since the ID-Checklist update draft was
>posted, but over the last six weeks or so.  In particular:
>
>        (i) I believe that there actually is consensus that use
>        of non-2606 names in places where they are likely to be
>        copied into production code (even if only by the lazy or
>        careless) is likely to be harmful as well as a terrible
>        idea.

See above.  There are places where it will be required. 


>        (ii) There is, at best, much less consensus that use of
>        non-2606 names in narrative or illustrative examples is
>        likely to be harmful.  There may be consensus that it is
>        impolite (or, to quote some recent IESG comments,
>        "rude") but that is, IMO, a rather different matter.
>
>        (iii) The IETF has indicated enough times that domain
>        names, not literal addresses, should be used in both
>        protocols and documents that doing anything else should
>        reasonably require clear and strong justification.

I'm not sure that this is a reasonable statement of the consensus,
even of the weak consensus.  I think we normally like to have
examples cover common cases; if literals are common in the
actual protocol use, forcing the examples to use FQDNs is
unhelpful.  We could use FQDNs in SDP examples, to take one
common case, but the reality is that these usually use IP
addresses.  The relevant ABNF is:

 unicast-address =     IP4-address / IP6-address / FQDN / extn-addr

from RFC 4566, so FQDNs could clearly be used in SDP examples.
But doing so is no favor to the actual implementors that might
read the docs.

>        (iv) If someone wants to use non-2606 names, it is
>        entirely reasonable to expect them to explain why and to
>        do so in public.  If that drives editors and WGs to take
>        the path of least resistance and use the 2606 names, I
>        think it should be fine with all of us.
>
>FWIW, please note the philosophical similarity between the above
>and RFC 4897.  In both cases, we move away from incentives for
>elaborate procedures and private negotiations between the IESG
>and authors (and the consequent late-stage guessing about what
>is likely to happen).  Instead, we get the issues and
>justifications up front as part of document processing or in the
>document itself so that the community can address them as part
>of Last Call.  The IESG can then make decisions based on
>evidence of community consensus (or community indifference, as
>the case may be).
>
>I think that is supposed to be what we all want around here,
>isn't it?

I certainly share your goals: avoiding elaborate procedures and private
negotiations between the IESG and the authors.  I remain concerned,
though, that this formulation still looks like "justify yourself to the IESG"
rather than "satisfy the relevant community you know what you're doing,
and the IESG will approve unless the larger community objects".  But
that is a much larger issue.

				regards,
					Ted

>    john
>
>
>
>
>_______________________________________________
>Ietf mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf