[Top] [All Lists]

Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 07:06:34
Cullen Jennings skrev 2011-01-30 05:56:

I read the draft to say that there would only be one port allocated - I took 
strive to mean that Joe would deny my port requests for two ports. If the 
intention is actually for the draft to say that it strives for one port but 
allows assignment of two where the that is what the protocol design desire, 
then I have no problem. Perhaps we just need to clarify what "strive" means. 
This definition of "strive" leads into exactly my other complain that this 
draft provides no guidance on what the expert will or will not approve. 

We probably need to adjust text like 

o  IANA strives to encourage the deployment of secure protocols, and
     so strives to avoid separate assignments for non-secure variants


 The use of separate
  service name or port number assignments for secure and insecure
  variants of the same service is to be avoided in order to discourage
  the deployment of insecure services.


 Services are expected to include support for security, either as
  default or dynamically negotiated in-band.

In band negotiation of security is applicable for some cases, but it adds 
latency, bandwidth, and complicated multiplexing in non session based 
transports. I think this is a bad idea in many cases. I also view separation 
even for stream based protocols as something that helps management and 
debugging as well as policy. 

Well, the high level goal is to preserve a limited resource. We can't do
that without making the preference clear. But I think you have forgotten
to consider those statements trying to make clear that this is up to

The review criterias can be expected to change overtime. They are also
hard to codify. Especially for this case, how do we measure
architectural uncleanness, implementation issues, and performance impact
to make a rule that judges if one or more port is allowed?

We clearly can't, this will be up to human judgment.

I also think it is important that we separate the basic registry rules
from the review guidelines, as they will change. Thus this is a separate
document. One that we should make clear is going to exist.

And as pointed out in other parts of this discussion there are several
ways of challenging the reviewers recommendation resulting in an IANA
decision. First of all is the appeal process. Secondly, is to take it
through the IETF approval process where IETF makes the decision, not IANA.

As I see it, we either leave these high level goals in this document, or
we remove the completely and put everything in a separate document.

I rather leave them in, because I don't seem them changing. Only be
acted up in varying ways over the coming years.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: 
Ietf mailing list

<Prev in Thread] Current Thread [Next in Thread>