ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 11:26:42


On 1/31/2011 9:16 AM, Joe Touch wrote:
Lars,

On 1/31/2011 7:06 AM, Lars Eggert wrote:
Hi,

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
document says:

A key element of the procedural streamlining specified in this
document is to establish identical assignment procedures for all IETF
transport protocols.

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.

Joe

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
document.

Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

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