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
registry.
That *IS* the IETF Consensus method; see the definition in RFC
2434.
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
an IETF RFC.
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.
Ned