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.hoff...@vpnc.org> > Date: November 15, 2010 21:44:24 GMT+02:00 > To: <ts...@ietf.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
