John C Klensin wrote: > Eliot, > > I haven't made up my mind whether I think this is a good idea or > not I'm not sure all the ideas in the document are a good idea either! > (1) At present, the IESG reviews and approves applications for > well-known ports. If the IESG does not believe a particular > protocol proposal is "worthy" (my terminology, not theirs), then > a low-numbered port is not assigned although the author is free > to go to IANA for a higher-numbered one. Would the effect, and > intention, of deprecating the distinction between "well known" > and other ports be to take the IESG entirely out of the approval > loop for port assignments except as described in the first two > paragraphs of section 2? > Yes, the distinction between well known ports and just assigned ports is outdated. The overarching theme of the document is that the IANA should be treated as a group of adults and that they should use some discretion with oversight only where needed. > (2) Your charging plan ties a potential charge to port requests > originating outside the IETF process for which there is no > corresponding RFC. However, there have been cases in which IANA > has assigned a port number, the requester has submitted a > document for RFC publication, but the RFC Editor has not found > the description of the associated protocol to be of sufficient > interest to the community to be worth publishing. It seems to > me that this creates an uncomfortable situation which could be > resolved by: > > (i) Requiring that the RFC Editor publish, on request, > any protocol description for which IANA assigns a port > number of for which it has assigned a port number in the > past. or > > (ii) Permits that charge only for ports and protocols > for which no documentation has been submitted to the RFC > Editor for publication. or > > (iii) Creates a two-track process for assignment of port > numbers that are not based on IETF-approved protocols. > In one, the RFC Editor approves a specification document > and then requests that the port assignment be made, > while, in the other, requesters go to IANA directly but > agree to pay any fees necessary. Of course, our > normal procedures and conventions would presumably > require an appeals procedure if the RFC Editor turned > something down. That would raise all sorts of other > issues that might not make either the community or the > RFC Editor very happy (see > draft-klensin-rfc-independent-01.txt) > > So, what did you have in mind? > What I have in mind is that the protocol be documented in some normative way, not necessarily via the RFC Editor. But your observations are astute and deserve further consideration in the next revision. Eliot _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf