ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
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.
Don't try to confuse me, it could be a waste oif time... :-)
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.
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.
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])
[...]
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 ?
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).
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.
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).
Frank