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

[Lars Eggert <[e-mail]>]

Hi

On 2011-1-27, at 2:12, Cullen Jennings wrote:
> 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

Paul Hoffman raised this issue as well (email from Nov 4 to this list.)

There was some discussion that lead to Paul suggesting specific edit to this document. (Which are not reflected in -09; us editors may have dropped the ball here). I'm attaching Paul's proposed changes below, could you check if you'd agree with them?

> Big Issue #2: The draft has close to no review advice for the expert reviewer.

Joe Touch (who leads the expert review team for ports) is working on a separate document (draft-touch-tsvwg-port-use). The first version of that draft was issued on the same day as the -09 version of iana-ports, which is why we don't refer to it. 

Does draft-touch-tsvwg-port-use have the content you are looking for? If so, we should refer to it. (We should probably refer to it anyway, in a "you may also want to read this" kind-of way.)

> 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.

I can see your point, and I personally have no problem with disclosing the reviewer identity. What do others think?

Lars

PS: Paul's proposed changes re item #1:

Begin forwarded message:
> From: Paul Hoffman <[e-mail]>
> Date: November 15, 2010 21:44:24 GMT+02:00
> To: <[e-mail]>
> Subject: Proposed resolution for security issues with 	draft-ietf-tsvwg-iana-ports-08
> 
> As this list and the TLS has seen, there is a wide variety of views on how to deal with fallback-to-insecure in protocols. I believe that the security community has no consensus on what this means, much less how to do it. My earlier proposal (continue to allow registration of two ports) was popular with some, unpopular with others; similarly, so was "force all protocols to use one port".
> 
> Therefore, I retract my proposal to allow two-port registrations for fallback-to-insecure. However, I still recommend some changes to the text to reflect the view that STARTTLS is not the only way to have such a feature on one port.
> 
> This will be an interesting IETF Last Call discussion.
> 
> I propose the following changes to draft-ietf-tsvwg-iana-ports:
> 
> Section 7.2 current:
> o  IANA will allocate only one assigned port number for all versions
>   of a service (e.g., running the service with or without a security
>   mechanism, or for updated variants of a service)
> 
> Section 7.2 current:
[in the line above s/current/proposed/, I think]
> o  IANA will normally allocate only one assigned port number for all versions
>   of a service (e.g., running the service with or without a security
>   mechanism, or for updated variants of a service). This policy can
>   be overridden by the expert reviewer.
> 
> Section 7.2 current:
>   Further,
>   previous separation of protocol variants based on security
>   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
>   not recommended for new protocols, because all new protocols should
>   be security-capable and capable of negotiating the use of security
>   in-band.
> 
> Section 7.2 proposed:
>   Further,
>   previous separation of protocol variants based on security
>   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
>   not recommended for new protocols, because all new protocols should
>   be security-capable.
> 
> --Paul Hoffman, Director
> --VPN Consortium