On Wed Jun 18 12:28:10 2008, Dave Cridland wrote:
> Therefore, to cover this particular case, such a blanket policy
> would have to be stated such that even vague recommendations in
> BCPs
I received a private comment which appeared to suggest I'm being
unclear here. So let me clarify:
The BCP, RFC 2606, as a whole is not a vague recommendation, and I
certainly didn't say that - the BCP states that the domains are
reserved, and, by its status as a BCP, it therefore reserves them.
(Donald Eastlake said elsewhere in the thread that the reason it's a
BCP at all was because the reservation of the domains needed the kind
of solid consensus that BCP status provides).
What is very much a vague recommendation is whether these domains
should be used.
The document says:
Depending on the nature of
the test or example, it might be best for it to be referencing a
TLD
permanently reserved for such purposes.
Yes, folks, that's "might be best" - hardly the eleventh commandment,
here.
And:
".example" is recommended for use in documentation or as
examples.
Note that both these, the latter of which is by far the strongest
recommendation in the document, refer to the rarely used ".example"
TLD.
On the subject of the more traditionally used second-level domains,
it says only this:
The Internet Assigned Numbers Authority (IANA) also currently has
the
following second level domain names reserved which can be used as
examples.
So to summarize, if the IESG were saying that this phrasing forms a
policy that all technical specifications MUST only use the domains
from RFC 2606 - not that it is, but if it were, it would seem odd
that the outcome would be that the IESG would recommend the second
level domains in Section 3, rather than the TLD which seems to have
been more strongly recommended in the consensus backed document that
the IESG would be citing.
But that's not the point here, really - there is no such documented
policy, and the policy we don't have is quite clearly not specified
in the BCP that doesn't define it. At best, the BCP which does not
define the policy we don't have suggests a different policy we don't
have either would be a better policy to have, yet this alternate
policy is not, as far as I can tell, what the community would
generally want - so it's actually quite lucky that neither policy the
BCP doesn't define actually exists.
I hope that's clearer now.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf