ietf-smtp
[Top] [All Lists]

Re: IESG approval status of rfc2821bis

2008-06-05 11:07:24



John C Klensin wrote:
Neither 2606, nor the "Guidelines", nor even "IDNits" require
those names.
...
"SHOULD preferably" and "preferably" are, I believe obviously,
statements of preference, not firm requirements.
...
(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.


A nicely compelling bit of background. But then, it *is* from John...

And I really am quite loathe to suggest that John's typically lengthy and
typically thorough analysis is incomplete, but this time, I must:


My position in general is that

        (i) The IESG does not get to invent rules that are then
...
        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.
...
        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.
...
        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".
...
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.


Two points are missing:

   1) Undue cost for making a *bis revision

   2) Protecting the installed base.

Seriously.

Imagine hiring a licensed electrician to add a new outlet to a room in your house and having them tell you that making this small change means that you also are required to bring the entire house up to conformance with all health and safety building codes that have been added since the house was built, thirty years ago. This include making all earthquake, insulation and electrical modifications to meet current building requirement.

The basis for the cited Discuss has exactly this sort of logic and implication.

When revising a document, the cost of the revision should be commensurate with the community need for the changes. RFC2821bis is a very small effort to make minimal changes to a successful document. It is simply not reasonable to start imposing more recent requirements -- assuming they really are valid requirements -- absent a compelling demonstration of damage that will accrue without the change.

RFC2821 has extremely broad use by industry. When designing changes to a successful protocol, we are careful to make changes in a way that protect the installed base of technology. We look for ways to make small, incremental changes so that what worked before works now. The same criterion should be applied to the specification document, itself: There is a large installed base of people who are familiar with RFC2821. The revised document should remain as familiar in style and details as possible. Changes imposed on the trained population of technicians should only be for fixing compelling problems.

That is, after all, why this is a *bis, rather than a brand new effort.

The examples don't qualify as having a compelling need to be changed.


(3)  I can launch an appeal, following the outline above and
asking for two specific remedies:

I think your assessment of the facts and the implications are exactly correct.

I think that alternative 3 should, indeed, be the default path.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net