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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf