ietf-smtp
[Top] [All Lists]

Re: IESG approval status of rfc2821bis

2008-06-05 11:54:07

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 RFC[2]822;
(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 domain name.)

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.

Keith


John C Klensin wrote:
Hi.

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
(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".

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
might.

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.

(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).

(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
petition.

What is your pleasure?

     john