Re: IESG approval status of rfc2821bis
In general, I think the IESG should have broad discretion to object to
any technical shortcoming of a document - certainly anything that would
make a protocol less robust is grounds for a DISCUSS. Editorial
shortcomings are a grayer area, but I still think the IESG should have
broad discretion - for instance any ambiguity that could reasonably lead
to an interoperability failure is grounds for a DISCUSS.
But I think IESG's goals for standards-track documents should center
around technical soundness and the likelihood of such documents being
interpreted consistently by different readers.
So I don't think IESG should be constrained to issuing DISCUSS votes
only when there's a consensus-based rule already in place. At the same
time I think that DISCUSS votes should always be justified in terms of
making the resulting protocol (or its implementations) more robust or
more likely to interoperate. Any counterarguments should probably be
made based on the same values.
Applying this value to the "goodness" of the example domains in rfc
2821bis I generally find that the domain names chosen for examples should
(a) be syntactically valid domains for DNS, SMTP, and RFC822;
(b) not be confusing. this might imply, for instance, using only
recognizable TLDs and not coining new ones).
(c) avoid conflicts with existing or future domain names - because this
could cause disruption for some parties and thus harm the robustness of
their operations. (I remember being told, long ago, that a significant
portion of the traffic to nic.ddn.mil was ICMP echo requests because
"ping nic.ddn.mil" was a widely published test for determining whether
you were "on the net".)
Restricting the examples to the names in section 3 of RFC 2606 is a
well-established way to accomplish these. But if these goals can also
be met in a different way, that should also suffice.
(However, I would recommend _against_ the use of TLDs in section 2 of
RFC 2606 when not talking specifically about new TLDs - because I think
they could be confusing. Some readers might not recognize foo.test as a
I also think that any unnecessary changes between RFC 2821 and RFC
2821bis will make the task of identifying those changes more difficult
than it needs to be. This might conceivably harm robustness or
interoperability. There's a lot of value in consistency, even for
something as trivial as this.
Finally I remember that when writing RFC 1891, I coined a large number
of new domain names (Pure-Heart.ORG, Big-Bucks.COM, Ivory.EDU,
Bombs.AF.MIL, Tax-ME.GOV, Boondoggle.GOV), simply because I needed lots
of examples and I wanted the reader to be able to clearly distinguish
between the different cases. I don't think the examples would have been
as readable had I constrained myself to use the names available in RFC
2606. I was also trying to pick names that would be easy for readers
to remember so that the examples would be more accessible. (it's a lot
easier to distinguish Pure-Heart.ORG from Ivory.EDU than it is to
distinguish A.EXAMPLE.COM from B.EXAMPLE.ORG)
(Though when revising RFC 1891 (to become RFC 3461) I found it necessary
to change Pure-Heart.ORG and Big-Bucks.COM because those domains had
since been registered.)
Bottom line: IMHO, RFC 2606 is fine for documents that only need a small
number of example domains, but not adequate for documents than need more
than 2 or 3 different example domains. I also think there's
considerable value in maintaining as much consistency as possible
between versions of a specification. I don't think IESG is overstepping
its authority by DISCUSSing this point, but I do think that on balance
they'd be harming robustness and interoperability by blocking the
document until such a change were made.
As for whether to appeal, I'd apply the same values - which would result
in better robustness and interoperabilty? Getting the document out
sooner by changing it to use RFC 2606 domain names, or waiting for the
appeal to complete before publishing the document?
I do think it's worth another round trip to IESG to say "here's why we
think it would be better to use the existing examples." As to whether
it's worth the time to ask IAB the same thing - maybe, but only if it
can be done quickly. At least this particular issue is fairly simple.
But I don't think it's a process issue, but rather a clarity issue and a
matter of editorial judgment.
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
now have an explicit note in hand that says "I await a revised
document or an appeal", so we are now at a choice point. I'm
inclined toward an appeal or other push-back action but am not
the only one who would be affected by a further delay with this
document, so want to explain the situation as I see it.
There has been fairly extensive correspondence on this subject.
I've tried to summarize the situation from my point of view
below in as short a form as possible. Lisa and Tony have, I
believe, seen all of it and may have a different take on what is
going on. If either does, I hope they will say something.
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.
There are three IESG position statements that might bear on the
issue. Quoting from one of the earlier notes...
(1) The "Guidelines to Authors of Internet Drafts"
(http://www.ietf.org/ietf/1id-guidelines.html) does not
mention the issue of examples at all.
(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".
(3) The DISCUSS Criteria document
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
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".
My position in general is that
(i) The IESG does not get to invent rules that are then
used to block progression of a document without
consulting the community.
(ii) Given the pressure on authors --especially WG
Chairs and document editors-- to simply go along with AD
demands and preferences, reasonable or not, in order to
get documents published rather than permanently stalled,
I do not believe that "the IESG has been doing this for
years" constitutes evidence that the community has
approved of the IESG's doing so.
(iii) Even if one were to concede that the IESG has the
authority to make this a requirement (which I do not),
it is abusive --an example of a completely unnecessary
very late review "gotcha" surprise-- for the IESG to
impose this rule without documenting it in any of the
criteria statement documents identified above. I have
suggested in a few of my notes that, if the IESG wants
to impose rules like this, it should move to revise one
of more of those documents (presumably the I-D
Checklist) to specify the requirement and see if the
community accepts that additional rule once it is
written down. Of course, they could also initiate an
update to 2606 that changes "can be used" into "MUST be
used unless the IESG grants a waiver". There has been
no response to either of those suggestions.
(iv) Since this blocking DISCUSS is inconsistent with
the IESG's published statements about conditions for
such actions (in the absence of a mandate from a
consensus document, it appears to be an "editorial
preference") and there seems to be no practical way to
un-block it, it is a case in which, excerpting from RFC
2026, Section 6.5.3, "the procedures themselves ... are
... inadequate or insufficient to the protection of the
rights of all parties in a fair and open Internet
Standards Process". Of course, that would be irrelevant
if the IESG were to reverse itself and unblock this
document during the appeal process.
I note that none of those three issues is specific to 2821bis.
They are really about how the IESG manages and expresses its
authority and discretion. There is one more general issue,
which is what changes it is reasonable to demand to a document
being progressed from one maturity level to the next. 2026 is
not specific about this, but I believe that its language
combines with a presumed general belief that we should put as
few unnecessary stumbling blocks in the path of advancing
documents to argue that late-review/ late-surprise requirements
for cosmetic changes are inappropriate.
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
I believe that there are four possible ways forward, at least
ones that I wouldn't find very offensive (I'm open to other
(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
(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.
(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
(4) Either instead of (3) or in addition to it, people could
conclude that the behavior and argument that the IESG can and
should do this because it thinks it can and has been doing so,
despite any documentation or evidence of consensus, is
sufficiently abusive that the AD in question should be singled
out as an illustrative example and recalled. I will not
initiate such an action, partially because I believe it would be
justified only if an AD continued to resist after losing an
appeal (remember that the IAB cannot require the IESG to take a
particular standards action) but, if someone else decided to do
so, I would probably feel obligated to sign a well-designed
What is your pleasure?