Hi John,
At 08:52 05-06-2008, John C Klensin wrote:
We have reached an impasse with the IESG about how to proceed
with 2821bis. The problem is an outstanding DISCUSS about
changing all of the examples that do not use RFC 2606 (e.g.,
"example.com" and friends) names to use that convention, with
the possible exception of those that point to ISI or USC. I
I saw that DISCUSS. A long time back, I sent you comments about the
draft together with suggested changes to the examples to have them
conform to RFC 2606. Your arguments against my suggestions were
valid in my opinion. I'm not going to post the arguments as it was
in a private email.
Neither 2606, nor the "Guidelines", nor even "IDNits" require
those names. 2606 (the only consensus document on the subject)
says things like "can be used" and does not even express an
explicit preference for them.
[snip]
> (2) The I-D Checklist (IDnits,
> http://www.ietf.org/ID-Checklist.html), Section 6, says
>
> "Addresses used in examples SHOULD preferably use
> fully qualified domain names instead of literal IP
> addresses, and preferably use example fqdn's such as
> foo.example.com instead of real-world fqdn's."
>
> "SHOULD preferably" and "preferably" are, I believe obviously,
> statements of preference, not firm requirements. That is
> especially true of the second one, which doesn't even contain
> the word "SHOULD".
Unless you have a good reason not to, it is preferable to use domain
names as mentioned in RFC 2606. Now, if we want to treat that as a
firm requirement, then I could argue that even the ISI or USC domain
names should be changed so as to conform with RFC 2606. 2821bis lays
down a lot of rules. It however gives us some leeway under local
considerations instead of setting everything in stone. That applies
to the above as well.
> (3) The DISCUSS Criteria document
> (http://www.ietf.org/IESG/STATEMENTS/discuss-criteria.html)
> does not list the use of non-2026 names as an item on the
> list of criteria in Section 3.1. Indeed, it explicitly
> discourages DISCUSSion for "Pedantic corrections to
> non-normative text" and "Stylistic issues of any kind" in
> section 3.2.
The AD holding the DISCUSS (you can easily find out from the
tracker, but I believe this is about principles rather than
personalities and am generally happy with that AD's performance)
has indicated that he doesn't like these names and considers
their use "rude" and that the IESG has been enforcing the use of
2606 names as a firm rule for "at least five years".
Under which DISCUSS Criteria (Section 3.1) does this rule fall?
The one issue that _is_ specific to 2821bis (and 2821) is that
DRUMS explicitly considered the question of what to do about the
821 examples. In fairness, I don't know how much the WG was
influenced by my personal preferences, but the conclusion was to
eliminate the references to .ARPA (because they were distracting
and clearly impossible given the current role of that domain)
but otherwise to preserve Jon Postel's examples (not just the
ones that used USC or ISI domains) to the extent possible.
DRUMS reached consensus on what became 2821 and the IESG signed
off on it. So this DISCUSS within the IESG now effectively
overrides, not only discussions and conclusions on this mailing
list, but the presumably-informed discussions of the original
WG. And, for better or worse, another few months of delay in
getting 2821bis published probably makes less difference than
would be the case for a new Proposed Standard for which people
are anxious to deploy conforming implementations, so I'm feeling
less pressure to "just go along" than the typical WG editor
might.
As 2821 was approved by the IESG two years after the publication of
RFC 2606, then why is this an issue now?
I believe that there are four possible ways forward, at least
ones that I wouldn't find very offensive (I'm open to other
ideas):
(1) I have offered the AD in question the option of changing the
DISCUSS to a Comment, thereby dropping the implicit assertion
that the IESG (or, even worse, one AD) has the right to
_require_ this type of change at this point in the process. I
have indicated informally that, if that change were made, I
would "probably" change the examples. While I haven't said it
explicitly to the AD or IESG, the only condition on the changes
would be my checking with this list to see if anyone strongly
and persuasively objected. In either this case or the next
one, I would rewrite the Acknowledgments to explicitly point to
Jon's role and examples and clear the text with this list (in
retrospect, that may be what we should have done for 2821).
The option of making the DISCUSS -> Comment change has been
declined (at least I have gotten no response to it in any of the
discussions).
(2) People can convince me that the principles I see here aren't
very important and we should just give in, make the changes, and
get the document published. To me, that is equivalent to
agreeing that it is ok for the IESG to have essentially-secret
rules, developed without community consensus and undocumented in
any description for I-D requirements, and then impose those
rules using permanent blocking DISCUSS positions after Last
Call. I believe that agreement would be bad news, but perhaps
I'm being naive and the relevant horse is sufficiently out of
the barn that it is time to acknowledge that, e.g., selection to
the IESG is equivalent to anointment as a member of a group with
imperial powers and divine right.
Principles are important. If we follow that line alone, then we have
to agree that it is reasonable to follow RFC 2606 when writing an I-D.
I appreciate your stand on this as a matter of principle. However,
as the editor, you serve at the pleasure of the "WG". The question
is whether the "WG" believes that examples in the 2821bis that went
through the Last Call should be preserved as such.
Changing the examples overrides a DRUMS WG decision. During the
discussions on 2821bis, several points were rejected based on the
argument that we should not revisit DRUMS decisions. 2821bis
received extensive review and also went through an IETF-wide Last
Call where such RFC 2606 nits are generally picked up. Unless I am
mistaken, the question was not raised. I assume that there was
community consensus on keeping the examples as they are now.
(3) I can launch an appeal, following the outline above and
asking for two specific remedies: (i) approval of this document
as-is and (ii) a firm requirement that no AD issue a blocking
DISCUSS on any editorial or other non-technical subject unless
the requirement is clearly documented in a BCP or formal
position statement that is subject to appeal at the time of
publication and that is published prior to the document's
entering Last Call. This is the default option unless people
persuade me otherwise, presumably that we should fall back to
(2).
I favor option (3).
Regards,
-sm