--On Thursday, 10 July, 2008 08:50 -0700 Bob Braden
<braden@xxxxxxx> wrote:
>
>
> *>
> *> John C Klensin wrote:
> *>
> *> > (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.
> John,
>
> This contradicts Section 2.1 of RFDC 1123, which says an
> application SHOULD support literal addresses (and of course
> DNS support is a MUST) -- Section 6.1.1.)
Yes. Independent of the text in 1123, several others have
pointed out that as strong a rule as I suggested, worded that
way, would be a bad idea. Several notes in this thread have
pointed that out, offered specific examples, and proposed text
that was better than mine.
Of course, there has never been a requirement that a
specification exhibit every one of its capabilities in examples.
The examples should be chosen should, IMO, represent likely
common practice rather than obscure features. Sometimes that
will point to the use of IP addresses (see a note from Ted
Hardie for an example) but often it will suggest DNS names
instead.
However, since IPv6 came over the horizon, there _have_ been a
number of statements made that prefer domain names over literal
addresses for reasons that were not relevant when 1123 was
written. I think those arguments are strong enough that asking
an editor who chooses to use examples with address literals in
it to explain that choice is entirely in order.
Again, the goal of my proposal is to move the rationale for
decisions to use anything but 2606 names into the document flow
for consideration during discussions of the document and Last
Call, with the IESG interpreting community consensus (as with
everything else). The alternative, it appears, is a guessing
game about IESG intentions and flexibility post-last-call and an
invitation to private negotiations between the IESG and authors.
We generally claim those are a bad idea even if we don't always
act consistently with that claim.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf