Dear IESG,
From the discussion just prior to the recent appeal by John Klensin, it
was clear that the guidance regarding example domain names in IETF
documents provided in the ID-Checklist needed to be updated. This point
was emphasized further during the discussion of the Klensin appeal.
Proposed text is now available. Many thanks to Bert Wijnen for continuing
to edit the document.
The IESG solicits comments on this proposed update. The IESG plans to
make a decision on this proposed text on 2008-07-17. Please send
substantive comments to the ietf@xxxxxxxx mailing lists by 2008-07-16.
Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either
case, please retain the beginning of the Subject line to allow automated
sorting.
I agree with moving the 2606 check to "SHOULD".
It is often helpful to provide guidance about when SHOULDs might not be
appropriate, when we have at least some experience where this is the case.
Were I to propose text, I think we have some experience that's popped up
during the appeal discussion, as follows:
Addresses used in examples SHOULD use fully qualified domain names instead
of literal IP addresses, and SHOULD use example fqdn's such as
foo.example.com instead of real-world fqdn's. See [RFC2606] (Eastlake, D.
and A. Panitz, "Reserved Top Level DNS Names," June 1999.) for example
domain names that can be used.
The use of reserved example FQDNs, IP addresses or network prefixes may not
be appropriate in all cases, including these (which have come up in
practice):
o If an example describes a complex network topology, it could be
appropriate to use a variety of names, IP addresses or prefixes that are
easily disambiguated, so that the reader might follow the example more
easily.
o If a standards-track document that does not use example names is
advancing, it could be appropriate to minimize text changes as the document
advances (the names used in the document have already been published, so the
question should be whether there is additional damage that would result from
the second publication on the standards track).
Thanks,
Spencer
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf