Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned N

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 <paul(_dot_)hoffman(_at_)vpnc(_dot_)org>
> Date: November 15, 2010 21:44:24 GMT+02:00
> To: <tsvwg(_at_)ietf(_dot_)org>
> 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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf