Questions about draft-lear-iana-no-more-well-known-ports-00.txt

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