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 user ports. Joe On Jan 31, 2011, at 9:25 AM, Joe Touch <touch@xxxxxxx> wrote: > > > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf