John C Klensin wrote:
Neither 2606, nor the "Guidelines", nor even "IDNits" require
"SHOULD preferably" and "preferably" are, I believe obviously,
statements of preference, not firm requirements.
(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
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
The one issue that _is_ specific to 2821bis (and 2821) is that
DRUMS explicitly considered the question of what to do about the
Two points are missing:
1) Undue cost for making a *bis revision
2) Protecting the installed base.
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.