Fwiw please see sec 8.1 of our doc which states which procedures of RFC 5226
are specified for each range, and already allows IESG approval as a path for
On Jan 31, 2011, at 9:25 AM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
On 1/31/2011 9:16 AM, Joe Touch wrote:
On 1/31/2011 7:06 AM, Lars Eggert wrote:
On 2011-1-31, at 16:51, Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request
for an IETF-approved protocol that needs two ports without recourse.
I don't follow. Assignments through IETF-stream documents do not go
through expert review.
Then this should be made *much* clearer in the document. In fact, the
A key element of the procedural streamlining specified in this
document is to establish identical assignment procedures for all IETF
I assumed that "all" meant "all", not "all except those through
IETF-stream documents"; others might have read it the same way I did.
The sentence you quote isn't related to the issue we're discussing. It
is intended to say "a goal is that the procedures to get ports and
service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it
would be clearer by explicitly naming these protocols in the document.)
But I see the point you're raising. The document should somewhere say
that "Expert Review" is the procedure used for assignment requests
made directly to IANA, whereas for documents on the IETF Stream, "IETF
Consensus" is sufficient to make the assignment. In other words, no
expert review doesn't really need to happen for those, since IETF
Review and IESG Approval are at least equivalent.
RFC2434 already gives IANA these options.
As does RFC 5226 - its update (there is no substantive change between the two
in this regard, FWIW).
Perhaps - at best - we should include a ref to that.
And 5226 is already clearly cited.
No further action should be required.
However, this document is not focused at changing what RFC2434 says, and
the above statement, IMO, does.
That's another can of worms, and should be reserved for a different
Ietf mailing list