I'm really glad to see this draft in LC at long last and it is a great improvement to the current situation - thank you to all the people that put work into this. I have two significant problems with it that I think should be resolved before being published Big Issues 1: I don't like mandating one port for secure and not secure versions of a protocol I don't think this reflects IETF consensus given the number of protocols that deliberately choses to use two ports. I also don't think that it is a good idea in all cases. I believe the decision should be left to the people designing the protocol if they want one port or two. Let me give some examples Imagine a client server protocol that runs over UDP and uses DTLS for security. The server will simultaneously serve requests over both DTLS and UDP. When the server receives a packet, it needs to be able to demux if it is a UDP packet or a DTLS packet. The obvious demux code point is the port. Yes, one might be able to reinvent a concept of a stream along with a 5 tuple and something like STARTTLS but this has many other problems. It means the client needs to use a different SRC port for each different "session" to the same server. This uses up NAT ports and complicates NAT traversal. It also adds additional latency to set up a small session. People just aren't going to do it. The other approach is demux based on the first byte inside the UDP packet. The CoAP protocol being developed in the CORE WG has taken that approach. The CORE WG proposed to the TLS chairs that over half the remaining code space for the TLS code point in the first byte be assigned to CoAP. The TLS chai rs, more or less told the CORE guys to get stuffed (politely of course). Two ports is the obvious answer. Lets consider another example. As the draft mentions, firewalls help apply policy, and catch configuration errors. Take an organization (like my house) that has a policy of no email over unencrypted protocols. It's really easy to set up a firewall policy that allows the encrypted ports and blocks the non encrypted ports that are typically used for email and does not require the firewall to do DPI. No doubt my daughter could figure out to circumvent this and sent unencrypted email via an VPN tunneled over DNS or ICMP or something but thats not the point - the point is to catch accidental misconfiguration, like the type that happen during software upgrades. You can agree or disagree about using firewalls this way but the fact remains, lots of people do use firewalls this way. I strongly urge this draft not to take on mandating one port - leave the decision with the designers of the protocol. If draft does mandate one port, you will end up with a port registered for protocol foo and a port for a proprietary protocol with no description called foo-secure. As I mentioned before, I also do not believe there is IETF consensus for one port. Big Issue #2: The draft has close to no review advice for the expert reviewer. I have been involved with several port registrations and they all left me grumpy and irritated and very frustrated at the expert review process. I'm sure the expert reviewer involved felt the same way and I know others have had similar experiences. We need concrete actionable advice for when the review says yes or no. This draft provides no guidance on what the expert review would approve or deny. If all they are doing is checking the requirements of this draft have been satisfied, then I am fine with that but the draft needs to say that something like any denial by an expert review should include which MUST in this draft was not complied with. I would like the draft to say that when IANA sends a response from an expert review to the applicant, the name of the reviewer (and perhaps email address) should be included. Lets take some specific points of never ending confusion about what is "good enough" to say yes. The reference to the doc describing the protocol. Is this a one line description? Is it a overview of the high level way this works, deals with congestion, security etc? Is it a full protocol specification. I have no idea. I also have no idea on what grounds the expert reviews can say no based on this. What protocols use Anycast. Does STUN? Does ping? what about DNS? Who knows - who cares. I do not believe discussion of if a protocol uses anycast or not has much relevance to deciding to allocate a port. Next lets talk about the whole topic of what is or is not appropriate for dynamic range. Let's take web browsing for example. You start with a URL like www.example.com but the protocol could have required a port like www.example.com:55123 in the URL and only used dynamic ports. Is http a protocol that should be forced into the dynamic range? Clearly the answer is no but if not http, then what protocol should? This draft offers no advice to the expert reviewer on what to do. Next lets consider a protocol like FTP data transport - first FTP does some signaling and it can pass the ports to be used for the data transport connection so you might think the dynamic range is fine for the transport part - but policy on firewalls has resulted in people wanting to have a well known port for that FTP uses for the data connection. Most FTP now supports PASV and things like that to meet this well known port requirement. You need to do this to make NAT port forwarding work. I think this draft need specific actionable advice on what grounds the expert review can say No. Obviously violating any of the MUST in this draft is fine reason to say no - but beyond that it is just too vague. Next we come to the issue of if a new protocols is allowed or not. Cisco developed a new protocol - the retransmission and flow control part of it was stollen from another protocol that is an RFC. I viewed this as a good thing as it ensured that we did not reinvent something new that was broken. The IANA expert review felt that we should not make a new protocol and should instead extend the old one and would not approve the port. Eventually sanity prevailed and the port was allocated but it worth noting that when the port was approved, the product had already shipped and the port was fixed. Had IANA not allocated the port, Cisco would have just kept using the port anyways. I'll note most other vendors feel about the same way - if they need to build a product that needs a port, they will take a port, or more than one, if one is not allocated. This does not make me happy but I think we need to be realistic about what our grounds are for saying no and the probable result of say ing no. Along these lines, I have no idea what review guidelines the expert would use to decide if something was OK to be in the System port range instead of User. What would be an appropriate argument for System instead of User? Along these lines, I think the draft should contain an example registration for a protocol in the port range where the description of the protocol is not a reference to a document but is provided in this example - using an existing protocol such as HTTP might make it easier for everyone to read. Similarly be nice to have example for something in the System range. Anyways, my meta point is the draft need to give enough advice to the expert review that they know what to do. Of course the expert applies human intelligence but the review and applicants have to be on the same page about what is expected here. Small Issue #3: I object to anonymous review The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several emails with an expert reviewer relayed via IANA where the conversation was going no where - once I knew the name of the reviewer, the whole conversation changed and stuff quickly came back to the realm of sane. I'm not willing to forward these emails to the list as that would just not be kind to anyone but I am happy to forward them to the IESG if they think looking at them is really critical. On Jan 18, 2011, at 14:26 , The IESG wrote: > > The IESG has received a request from the Transport Area Working Group WG > (tsvwg) to consider the following document: > - 'Internet Assigned Numbers Authority (IANA) Procedures for the > Management of the Service Name and Transport Protocol Port Number > Registry' > <draft-ietf-tsvwg-iana-ports-09.txt> as a BCP > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2011-02-01. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf