ietf-smtp
[Top] [All Lists]

IESG approval status of rfc2821bis

2008-06-05 09:12:00

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