[Top] [All Lists]

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

2007-04-10 11:47:53

Tony Hansen wrote:
Getting back to this draft.

I'm a bit confused by I-D.klensin-smtp-code-registry, this isn't an
intentionally competing draft, or is it ?

IANA is directed to create the registry Mail Enhanced Status
Codes.  In the terms of [5], values of Enhanced Status Codes
must be registered with IANA under the IETF Consensus method.

Published RFC is IMO simpler, they can link to a RFC in the
That *IS* the IETF Consensus method; see the definition in RFC

IMO it's very different:  "Published RFC" allows informative and
experimental RFCs submitted independently (direct to RFC editor).

That may be your opinion but the facts are otherwise. 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].

So, 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.

The name may not be the best and may in fact be counterintuitive to some, but
it is what it is.

IETF consensus is IMO something based on an IETF Last Call.  It's
not necessarily published as RFC.  Generally it's an "IETF last
called RFC".  If the IESG could decree "IETF consensus" without
Last Call it would be another reason why 2234bis should replace
2234 a.s.a.p.

Actually, the IESG can declare consensus through means other than a last call,
but that's really beside the point.

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-
             CONSIDERATIONS]) New values are assigned only through RFCs
             that have been shepherded through the IESG as AD-Sponsored
             IETF (or WG) Documents [RFC3932,RFC3978]. The intention is
             that the document and proposed assignment will be reviewed
             by the IESG and appropriate IETF WGs (or experts, if
             suitable working groups no longer exist) to ensure that the
             proposed assignment will not negatively impact
             interoperability or otherwise extend IETF protocols in an
             inappropriate or damaging manner.

             To ensure adequate community review, such documents are
             shepherded through the IESG as AD-sponsored documents with
             an IETF Last Call.

             Examples: SMTP extensions [SMTP-EXT], BGP Subsequent
             Address Family Identifiers [BGP4-EXT].

The significant change is that this new text makes it clear the document has to
a sherparded draft that goes through last call. 

There is an issue of what to do with the values X.7.8 through
X.7.13.  These were all defined in a draft that has since
expired (draft-newman-auth-resp-00.txt), but have been used in
other documents such as draft-siemborski-rfc2554bis.

2554bis-09 was approved some days ago, I see 2.7.0, 4.7.0, 5.7.0,

These are all obviously previously defined.

5.7.8, 5.7.9, 5.7.11, 4,7.12, 5.7.12, and x.5.6.

All of these have are consistently defined in 2554bis and in Tony's draft. 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.

| must be registered with IANA under the IETF Consensus method.
| (Specifically, new assignments are made via RFCs approved by
| the IESG.)

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. You're
getting hung up on what the term "IETF Consensus" seems to you to mean rather
than what it is defined to mean.

Please add the sources to your enumeration (e.g. RFC 2554bis)...

| X.7.14 Trust relationship required  The submission server requires
|    a configured trust relationship with a third-party server in
|    order to access the message content.  This value replaces the
|    prior use of X.7.8 for this error condition.
| X.7.15 Authentication credentials invalid  Authentication failed
|    due to invalid or insufficient authentication credentials.
|    This value replaces the prioruse of X.7.8 for this error
|    condition.

...or in these cases the source [RFC XXXX], i.e. your draft.

| 5.1.  Normative References

Please add 2554bis here.

A citation seems fine to me.


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