[Top] [All Lists]

Re: Conflicting Enhanced Status Codes between RFC 4468 and draft-siemborski-rfc2554bis

2007-04-10 19:59:53

RFC 2434 is very clear about this. It says:
   IETF Consensus - New values are assigned through the IETF
   consensus process. Specifically, new assignments are made via
   RFCs approved by the IESG. Typically, the IESG will seek
   input on prospective assignments from appropriate persons
   (e.g., a relevant Working Group if one exists).
   Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
   Family Identifiers [BGP4-EXT].

"RFCs approved by the IESG".  My proposal "published RFC" doesn't
exclude *_other_* RFCs.
OK, so your concern is that non-IETF RFCs be allowed to use the registry, Not
only do I not share your ocncern, I think allowing such usage is a really
bad idea.

Mind you, I'm not saying no protocol parameters will ever fit this set of
criteria. A parameter space that's plentiful, used by multiple protocols
including experimental ones, has no intrinsic security issues, where overlaps
or conflicts aren't an overwhelming concern, but for which it is important to
have each addigned value publicly documented, would be one where "published
RFC" criteria make sense.

Enhanced status codes, OTOH, are only used by a single protocol - SMTP - that's
incredibly widely deployed. Interoperability and security considerations are of
paramount importance here. It is therefore essential that any codes that are
defined be carefully and completely reviewed for conflicts and clarity and
there can easily be serious security considerations attached to their
definition and use. While I think the chances are excellent that the IESG
would, upon reviewing any independent submission that defined such codes
improperly, tell the RFC Editor that the document is in conflict with the
IETF's ongoing work on SMTP, that therefore it should not be published, and
that the RFC Editor would agree, I don't want to take even a small risk.

as Tony has already pointed out, "IETF Concensus" is the name
for the process where registrations are made by publishing an
RFC. The term "published RFC" is not one that RFC 2434 defines.

ACK, it's defined in 2234bis.
2234 is the old ABNF spec so I assume you meant 2434bis. Even so, the term
"published RFC" is not one of the "well known IANA policy definitions" in

If 2434bis gets published first, this statement should be
revised accordingly.
Yes, the 2234bis term is "IETF review", and it clearly requires
And which RFC 2434bis also states is the replacement name for
"IETF consensus":
    IETF Review - (Formerly called "IETF Consensus" in [IANA-

And one paragraph above that you see the different definition for
"RFC required" also allowing non-IETF-RFCs:

| RFC Required - RFC publication (either as IETF Submission or as an
|     RFC Editor submission [RFC3932]) suffices. Unless otherwise
|     specified, any type of RFC is sufficient (e.g.,
|     Informational, Experimental, Standards Track, BCP, etc.)

The section with these (and more) definitions claims to enumerate
"Well-Known IANA Policy Definitions", it's no new invention.  Maybe
you intentionally want to exclude _other_ RFCs, and then we disagree
about what we want, not about the terminology, and also not about
the 2234 / 2234bis source of the terminology.

Is there a compelling reason to exclude independent RFCs ?

Yes, I think there are fairly compelling reasons to exclude them. I also think
that erring on the side of caution is preferable to making a hash of the
enhanced status code space.

If Tony's draft moves forward and is approved before 2554bis is
published 2554bis will need to be revised to use the proper
registration templates. But this can easily be done with an RFC
Editor note.

An RFC editor note in the approval of Tony's draft intended to edit
another approved RFC already waiting for its number in the editor
queue ?  That would beat the "RFC editor note" stunts I've seen so
far (okay, only two).

Actually this sort of thing is quite common, especially when there are
publication delays. In fact there's example of an almost identical set of
changes taking place in the Sieve WG right now - various Sieve drafts that have
normative references to 3028bis have been approved and are waiting for 3028bis
to make it through the process. However, in the meantime 3028bis has been
revised to create an IANA registry for Sieve extensions, along with a specific
template to use for these registrations. All of the approved Sieve drafts -
five at last count - are expected to be revised to include the new template.

The IESG has approved RFCs without Last Call and without IETF
consensus, for examples see RFCs 4405, 4406, 4407, and 4408.
(4408 doesn't invent a status code, but it has a 3464 reference)
None of which has anything to do with what's being proposed here.

It has, in theory one of these RFCs could have tried to register a
new reply code.  Under Tony's rules that might be not allowed.  The
EAI drafts will be experimental, they might introduce new reply
codes, and there might be no Last Call / IETF consensus about it.

EAI is a WG, with all that implies - it's documents are going to be IETF
documents, not independent submissions to the RFC Editor.

You're getting hung up on what the term "IETF Consensus" seems to
you to mean rather than what it is defined to mean.

Apparently 2343bis agrees with my interpretation, it offers an "RFC
required" different from "IETF review (formerly IETF consensus)".
Please add 2554bis here.
A citation seems fine to me.

Stating the source of a citation can't hurt.  I think Tony's I-D can
just update 2554bis like it updates 4468 (depending on the outcome
of the race condition with an "RFC editor note" strategy).

As I said, the correct course of action depends critically on whether or not
2554bis is published before this document makes it through the process.


<Prev in Thread] Current Thread [Next in Thread>