Eliot,
I haven't made up my mind whether I think this is a good idea or
not, but I two have two questions about issues that interact
with this draft that are not covered in it.
(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?
(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?
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf