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
+1 /Markku On Mon, 28 Mar 2011, Michelle Cotton wrote: +1 Michelle On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
+1. On 3/28/11 3:52 PM, Michelle Cotton wrote: +1 Michelle On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Alexey Melnikov wrote: Peter Saint-Andre wrote: Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: Paul's text is much better than mine. That was what I trying to get at. Agreed, I will add this as an RFC Editor's note. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it is using two ports. After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 3/28/11 2:14 PM, Alexey Melnikov wrote: Alexey Melnikov wrote: Peter Saint-Andre wrote: Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: Paul's text is much better than mine. That was what I trying to get at. Agreed, I will add this as an RFC Editor's note. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it is using two ports. After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. As someone who was involved in formulating the two-sentence text and who raised concerns about removing the second sentence within the IESG, I'd like to publicly affirm that I find this resolution acceptable. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
As one of the authors, I'm fine with this change too. Joe On 3/28/2011 5:46 AM, Lars Eggert wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Joe Touch skrev 2011-03-28 15:33: As one of the authors, I'm fine with this change too. Me too, Magnus Westerlund ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
+1 Michelle On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote: As one of the authors/editors, I am fine with this change. Thanks! On 2011-3-28, at 14:14, Alexey Melnikov wrote: After discussing this new text with IESG and some participants of the TSVWG, it became clear that while there is clear agreement for adding the first sentence quoted above (There is no IETF consensus...), there is no clear cut consensus for adding the second sentence (Therefore, an expert reviewer should not reject a proposal). After even further discussions with proponents of this text, with editors, IANA, etc., the proposal is to strike the second sentence, i.e. only the following sentence is going to be added to the document: There is no IETF consensus on when it is appropriate to use a second port for an insecure version of protocol. The IESG is already alerted when there are problems with IANA registrations, so the requirement being removed is not needed. If people have problems with this change, please send your objections by 4pm Prague time on Wednesday, March 30th, as I would like to approve the document before my IESG term ends. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Peter Saint-Andre wrote: Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: Paul's text is much better than mine. That was what I trying to get at. Agreed, I will add this as an RFC Editor's note. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it is using two ports. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Cullen, there's a lot of history with port registrations. As you're probably aware in the past, there was a procedure for experts to sign an NDA before reviewing port requests. It's my understanding that is no longer done. However, it does suggest there's strong desire for proprietary protocol support. So, there's lots of complexity specific to this registry here that I don't know about. However, the general idea of having experts reviews on a public list, or even soliciting comments on a public list is well supported. There's specific discussion of this in RFC 5226. We've done it successfully in a number of cases. So, there's reason to believe that things in this space could be effective for IANA registries. I think soliciting public comments on port requests would be bad; I think your proposal of having the request/response be published would be as far as we should go for this registry at this time. So, I don't have the background to say this would be a good fit for the port registry, but to the extent that my background supports something like this I can support your idea. It's worked elsewhere at lesat. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
I propose some text for the draft near the bottom of this email On Feb 2, 2011, at 2:16 AM, Magnus Westerlund wrote: Cullen Jennings skrev 2011-02-01 18:19: So to summarize what you are saying, ports are allocated based on an arbitrary view of the expert review. When this person will say yes or no too can't be described and will change over time. If that's how it works, there is not even any grounds for appeal of any given decision. You can't even use precedence as an argument. My view was the IESG has been trying to move to having much more concrete advice for registries that required expert review. If you agree that is about the right summary, then I'm pretty sure I can find plenty of other people that would agree with me that this is not OK. I'm not a fan of the WG could not get consensus on if we should allow A or not so we are just going to let the expert review do whatever they want. If the IETF could not come to consensus on if X or Y were reasons to deny a registration, then I don't think the expert review should be able to deny a registration due to X or Y. Cullen, Apparently you like to twist what I am saying in most negative way and without considering the checks that are in place. Sorry Magnus ... I really did not mean to twist your words. I know you are very straight up about this type of stuff. I suggested some text bellow. - I think general guidelines can and should be developed. But other than high level goals this isn't the document. Here Joe has the start of a document. But I do think that in long term this guidance may change. - There is an appeal process where the IESG and then IAB gets to sanity check the arguments that the reviewer + IANA has given towards the appealing requestor. I understand that but we both know appeals are a painful tool to use and we would like to avoid it where possible - they waste an incredible amount of time for everyone involved and particularly the IESG. - One can take a assignment request through the IETF process I'm not as focused on drafts in IETF process but even in theses cases, WGs will look to this BCP for guidance on what would be acceptable behavior. So even if this draft might not legally block a WG from doing something, the WG will still be influenced by the goals this draft strives for. That is a good thing - BCP advice that applies to non IETF work should guide IETF process work too. I hope that we can get consensus on the guidelines, because I think that would give the reviewers a lot of comfort being able to rely on that consensus. Cullen, what are your suggestion for how to improve the document? For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. The reason I think this needs to be in the draft is very simple. In my mind there are clear and compelling cases for two ports - many of them involving DTLS and real time protocols that actually care about number of round trips. Joe Touch has already said he would reject an example use case that I think should be accepted. I think this is much easier to resolve this issue now than with an appeal. The CORE WG, which I co-chair, needs clear advice now on what direction would be acceptable and is not particular interested in waiting for a year or two for the drafts to be done, appealed, and then redesigned. Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it using two ports. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Paul's text is much better than mine. That was what I trying to get at. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it using two ports. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: Paul's text is much better than mine. That was what I trying to get at. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it using two ports. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
I've been thinking more about this thread and my concerns about this draft. I was originally looking for the draft to have advice for the expert review team that gave them guidance on what the IETF thought was all right to approve or not approve. It's become clear that this draft does not have that advice and is not likely to get it in the very short term. This BCP will empower the expert reviewer to reject or approve just about any request. Appeals are not the best way to balance putting that power because they are incredibly corrosive and time consuming to everyone involved. I think this thread somewhat suggests an alternative approach for a check and balance. What do people think of the idea of: for all ports requests, the request and the expert reviewer reposes including reason for accepting or rejecting them need to be posted to a public email list. This seems like a simple way to help mitigate this issue and it will help educate people writing a port request to know what types of issues they need to address and what would be appropriate or not. Pros cons of this idea? On Feb 8, 2011, at 1:41 PM, Christian Huitema wrote: I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against shade is sunlight. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Hi Paul (and Cullen), Paul Hoffman wrote: On 1/29/11 9:34 PM, Joe Touch wrote: On 1/29/2011 8:54 PM, Cullen Jennings wrote: On Jan 27, 2011, at 17:10 , Joe Touch wrote: ... AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. As per my other note: RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments. The term Expert Review is defined in RFC 2434. Neither document binds IANA to use the advice of a reviewer. Further, there is no single reviewer - we have a team, consulting each other on occasion, and all decisions are seen by multiple reviewers. However, none of that is worth codifying. If IANA or the IESG doesn't like how we serve them, they can replace us - at any time, for any reason, and there is an appeals process for decisions of the expert team: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Now that this has been made clear to me, I am *much* more worried about the wording in the current draft. The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. As Cullen and others have pointed out, there are sometimes very good technical reasons for a particular protocol to need to have two ports. The document should be amended to say that protocols with IETF consensus should get as many ports as it needs, regardless of what IANA or the expert reviewer thinks. This makes it the responsibility of the IETF consensus process to follow the guidelines in this document. I think the document (-10) was amended as requested, but can you please double check? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Paul Hoffman wrote: On 1/31/11 12:23 AM, Lars Eggert wrote: On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. Then this should be made *much* clearer in the document. I believe this was clarified in -10. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that all meant all, not all except those through IETF-stream documents; others might have read it the same way I did. Further, the wording throughout the template description in 8.1 makes it sound like that the restrictions in this document apply to everything that needs a template, which clearly includes IETF-stream documents. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Hi folks, Sam Hartman wrote (and others suggest): I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Chris Benson. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against shade is sunlight. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Feb 8, 2011, at 9:41 PM, Christian Huitema wrote: I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against shade is sunlight. +1 Bob -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Regardless, we're already moving forward to make the identities public (not sure if it's happening, or already happened). Regardless, though, again, this is out of scope for this doc to address in detail, IMO. Joe On 2/7/2011 1:24 PM, Chris Benson wrote: Hi folks, Sam Hartman wrote (and others suggest): I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Chris Benson. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Cullen Jennings skrev 2011-02-01 18:19: So to summarize what you are saying, ports are allocated based on an arbitrary view of the expert review. When this person will say yes or no too can't be described and will change over time. If that's how it works, there is not even any grounds for appeal of any given decision. You can't even use precedence as an argument. My view was the IESG has been trying to move to having much more concrete advice for registries that required expert review. If you agree that is about the right summary, then I'm pretty sure I can find plenty of other people that would agree with me that this is not OK. I'm not a fan of the WG could not get consensus on if we should allow A or not so we are just going to let the expert review do whatever they want. If the IETF could not come to consensus on if X or Y were reasons to deny a registration, then I don't think the expert review should be able to deny a registration due to X or Y. Cullen, Apparently you like to twist what I am saying in most negative way and without considering the checks that are in place. - I think general guidelines can and should be developed. But other than high level goals this isn't the document. Here Joe has the start of a document. But I do think that in long term this guidance may change. - There is an appeal process where the IESG and then IAB gets to sanity check the arguments that the reviewer + IANA has given towards the appealing requestor. - One can take a assignment request through the IETF process I hope that we can get consensus on the guidelines, because I think that would give the reviewers a lot of comfort being able to rely on that consensus. Cullen, what are your suggestion for how to improve the document? Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Cullen Jennings skrev 2011-01-31 18:44: Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. Well, frankly I don't know. I think it is something that can be avoided going forward in many use cases, but not all. Simply by thinking of this issue in the design phase. In addition there is clearly other solutions there other considerations, like NAT traversal has said, yes multiplexing is a must, thus live with even higher complexity costs. The issue I have a problem with is that is we say on general basis that due to negotiation of security protocols we are allowed to use different ports for negotiation or simply usage of it. Then why is that different from different versions of the protocol, or feature support. What is the difference for a security protocol compared to these other issues? What I am worried here is that we will see an increased port consumption rather than a decreased one. At the current run rate I think the estimate is 50 years+ before run out. That is something that I am reasonably comfortable, but if the consumption rate increases four times, then I am suddenly not comfortable. So I am pretty certain that we need to aim at lowering the consumption rather than raising it. As I see it there are only one way of doing it. - State clearly that you really need to do everything reasonable so that your application is only for one port. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. And from that perspective I don't think security is special in anyway. It is only one of several things that could potentially require additional registered ports. Yes security is important, but as previously discussed it doesn't appear that the actual level of security provided is different if you are forced to use one port or two. It might affect the ease of implementation and deployment of security, which is another aspect of impact. Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
+1 to everything Magnus says here. THis is exactly how I view the multiple port issue. I will also add that at least part of this fuss seems to be concern about how human oversight is needed but what if the overseer misbehaves issue. Speaking as someone who has been doing IANA reviews for well over a decade, it is absolutely the case that a reviwer's actions can screw up a registry. But the solution to this problem is not to overconstrain the review process - we've tried that approach and found it causes more problems than it solves - but rather to have proper checks and balances in the process itself. I believe the current specified process - once you understand the details, which unfortunately are a bit difficult to track through all the various specifications - is sufficient to deal with this. Ned Cullen Jennings skrev 2011-01-31 18:44: Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. Well, frankly I don't know. I think it is something that can be avoided going forward in many use cases, but not all. Simply by thinking of this issue in the design phase. In addition there is clearly other solutions there other considerations, like NAT traversal has said, yes multiplexing is a must, thus live with even higher complexity costs. The issue I have a problem with is that is we say on general basis that due to negotiation of security protocols we are allowed to use different ports for negotiation or simply usage of it. Then why is that different from different versions of the protocol, or feature support. What is the difference for a security protocol compared to these other issues? What I am worried here is that we will see an increased port consumption rather than a decreased one. At the current run rate I think the estimate is 50 years+ before run out. That is something that I am reasonably comfortable, but if the consumption rate increases four times, then I am suddenly not comfortable. So I am pretty certain that we need to aim at lowering the consumption rather than raising it. As I see it there are only one way of doing it. - State clearly that you really need to do everything reasonable so that your application is only for one port. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. And from that perspective I don't think security is special in anyway. It is only one of several things that could potentially require additional registered ports. Yes security is important, but as previously discussed it doesn't appear that the actual level of security provided is different if you are forced to use one port or two. It might affect the ease of implementation and deployment of security, which is another aspect of impact. Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Tue, Feb 1, 2011 at 8:38 AM, ned+i...@mauve.mrochek.com wrote: +1 to everything Magnus says here. THis is exactly how I view the multiple port issue. I'll respond to this separately. I will also add that at least part of this fuss seems to be concern about how human oversight is needed but what if the overseer misbehaves issue. Speaking as someone who has been doing IANA reviews for well over a decade, it is absolutely the case that a reviwer's actions can screw up a registry. But the solution to this problem is not to overconstrain the review process - we've tried that approach and found it causes more problems than it solves - but rather to have proper checks and balances in the process itself. I believe the current specified process - once you understand the details, which unfortunately are a bit difficult to track through all the various specifications - is sufficient to deal with this. Others may have that concern but it's not my concern. My concern is rather that the reviewer get the correct guidance, and in this case that guidance appears to be that he ought to be pushing back on protocols which desire to use one port for the insecure version and one port for the secure version, and I'm not really that comfortable with that. -Ekr Ned Cullen Jennings skrev 2011-01-31 18:44: Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. Well, frankly I don't know. I think it is something that can be avoided going forward in many use cases, but not all. Simply by thinking of this issue in the design phase. In addition there is clearly other solutions there other considerations, like NAT traversal has said, yes multiplexing is a must, thus live with even higher complexity costs. The issue I have a problem with is that is we say on general basis that due to negotiation of security protocols we are allowed to use different ports for negotiation or simply usage of it. Then why is that different from different versions of the protocol, or feature support. What is the difference for a security protocol compared to these other issues? What I am worried here is that we will see an increased port consumption rather than a decreased one. At the current run rate I think the estimate is 50 years+ before run out. That is something that I am reasonably comfortable, but if the consumption rate increases four times, then I am suddenly not comfortable. So I am pretty certain that we need to aim at lowering the consumption rather than raising it. As I see it there are only one way of doing it. - State clearly that you really need to do everything reasonable so that your application is only for one port. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. And from that perspective I don't think security is special in anyway. It is only one of several things that could potentially require additional registered ports. Yes security is important, but as previously discussed it doesn't appear that the actual level of security provided is different if you are forced to use one port or two. It might affect the ease of implementation and deployment of security, which is another aspect of impact. Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2/1/11 2:14 AM, Magnus Westerlund wrote: Cullen Jennings skrev 2011-01-31 18:44: Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. Well, frankly I don't know. I think it is something that can be avoided going forward in many use cases, but not all. Simply by thinking of this issue in the design phase. In addition there is clearly other solutions there other considerations, like NAT traversal has said, yes multiplexing is a must, thus live with even higher complexity costs. The issue I have a problem with is that is we say on general basis that due to negotiation of security protocols we are allowed to use different ports for negotiation or simply usage of it. Then why is that different from different versions of the protocol, or feature support. What is the difference for a security protocol compared to these other issues? As has been said many times before: downgrade attacks and essentially different transport. Each of those has very serious consequences, the first for the security of the communication, the second for the design of the underlying protocol. What I am worried here is that we will see an increased port consumption rather than a decreased one. At the current run rate I think the estimate is 50 years+ before run out. That is something that I am reasonably comfortable, but if the consumption rate increases four times, then I am suddenly not comfortable. So I am pretty certain that we need to aim at lowering the consumption rather than raising it. No one is suggesting raising the consumption rate. As I see it there are only one way of doing it. - State clearly that you really need to do everything reasonable so that your application is only for one port. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. At least one other way was proposed in the TSVWG, but did not get anywhere. And from that perspective I don't think security is special in anyway. It is only one of several things that could potentially require additional registered ports. Yes security is important, but as previously discussed it doesn't appear that the actual level of security provided is different if you are forced to use one port or two. It might affect the ease of implementation and deployment of security, which is another aspect of impact. Some people say it doesn't appear that the actual level of security provided is different if you are forced to use one port or two and others disagree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
So to summarize what you are saying, ports are allocated based on an arbitrary view of the expert review. When this person will say yes or no too can't be described and will change over time. If that's how it works, there is not even any grounds for appeal of any given decision. You can't even use precedence as an argument. My view was the IESG has been trying to move to having much more concrete advice for registries that required expert review. If you agree that is about the right summary, then I'm pretty sure I can find plenty of other people that would agree with me that this is not OK. I'm not a fan of the WG could not get consensus on if we should allow A or not so we are just going to let the expert review do whatever they want. If the IETF could not come to consensus on if X or Y were reasons to deny a registration, then I don't think the expert review should be able to deny a registration due to X or Y. On Jan 31, 2011, at 8:06 , Magnus Westerlund wrote: 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 and 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. and 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 review. 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? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
inline On Feb 1, 2011, at 5:14 , Magnus Westerlund wrote: Cullen Jennings skrev 2011-01-31 18:44: Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. Well, frankly I don't know. I think it is something that can be avoided going forward in many use cases, but not all. Simply by thinking of this issue in the design phase. In addition there is clearly other solutions there other considerations, like NAT traversal has said, yes multiplexing is a must, thus live with even higher complexity costs. The issue I have a problem with is that is we say on general basis that due to negotiation of security protocols we are allowed to use different ports for negotiation or simply usage of it. Then why is that different from different versions of the protocol, or feature support. What is the difference for a security protocol compared to these other issues? I've provided reason why I think this is needed for security in previous email on this thread. I'm not arguing you need more ports for versions or feature support - I don't think you do. What I am worried here is that we will see an increased port consumption rather than a decreased one. At the current run rate I think the estimate is 50 years+ before run out. That is something that I am reasonably comfortable, but if the consumption rate increases four times, then I am suddenly not comfortable. So I am pretty certain that we need to aim at lowering the consumption rather than raising it. I'm far more worried about people just using ports without registering them than I am about running out. Keep in mind the allocation policy is more or less anyone can get one port for just about anything so if we are really worried about running out, we would change that. Most protocols will not need or request two ports. As I see it there are only one way of doing it. - State clearly that you really need to do everything reasonable so that your application is only for one port. Reasonable here is the problem. I don't want the expert review to tell me a second port for security is not reasonable for cases where latency is a relevant. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. Again - I want to be able to register ports for proprietary protocols without disclosing the details of the proprietary algorithm And from that perspective I don't think security is special in anyway. It is only one of several things that could potentially require additional registered ports. Yes security is important, but as previously discussed it doesn't appear that the actual level of security provided is different if you are forced to use one port or two. It might affect the ease of implementation and deployment of security, which is another aspect of impact. It's not just an ease of anything - it's the real time performance of the resulting system that is an issue. Cheers 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: magnus.westerl...@ericsson.com -- Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
To clarify some of this discussion, providing some context that might be useful: 1) the current doc already explicitly states the procedures for assignment in each range of ports (see Sec 8.1.1). 2) Sec 8.1.1 *already* states that IESG approval through IETF process is a valid path for assignment, distinct from Expert Review. Since that appears to be a point of confusion, I'll quote it directly: o Ports in the User Ports range (1024-49151) are available for assignment through IANA, and MAY be used as service identifiers upon successful assignment. Because assigning a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. This documentation will be input to the Expert Review procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the assignment. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the IETF ^^ Review or IESG Approval procedures [RFC5226], which is how most ^^ assignments for IETF protocols are handled. ^^^ o Ports in the System Ports range (0-1023) are also available for assignment through IANA. Because the System Ports range is both the smallest and the most densely allocated, the requirements for new assignments are more strict than those for the User Ports range, and will only be granted under the IETF Review or IESG ^ Approval procedures [RFC5226]. A request for a System Port ^ number MUST document *both* why using a port number from the Dynamic Ports range is unsuitable *and* why using a port number from the User Ports range is unsuitable for that application. 3) section 7 has NOTHING TO DO with the procedures this document updates. That section has plenty of words to avoid any such impression. And no, we don't need to define strives, IMO - since NOTHING IN THAT SECTION IS BINDING. Again, since this is a persistent cause of confusion, I quote from that section: This section summarizes the current principles by which IANA handles the Service Name and Transport Protocol Port Number Registry and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA has flexibility beyond these principles when handling ^^ assignment requests; other factors may come into play, and exceptions ^ ** may be made to best serve the needs of the Internet. *** If you need more explicit words, the term non-binding can be added. --- There's a doc I drafted in TSVWG which is a more appropriate venue to discuss this issue (draft-touch-tsvwg-port-use0. I encourage those interested in these issues to continue discussion on that list, not on this general list. For this document, if this section is causing confusion, it should be removed, since it is already included in this other doc and can be vetted there. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2/1/2011 9:19 AM, Cullen Jennings wrote: So to summarize what you are saying, ports are allocated based on an arbitrary view of the expert review. When this person will say yes or no too can't be described and will change over time. See my other post. Section 8.1.1 already states that there are other means besides expert review. If that's how it works, there is not even any grounds for appeal of any given decision. The grounds are disagree with the advice of the Expert Review. The IESG can overturn those decisions on that basis alone. They can - and have - held up decisions that have come from community consensus as well. I.e., this is no different from other appeals process. It is based on the strength of the argument. From your earlier post: I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, ** that will not meet the latency goals of the protocol. Joe does not agree. The burden of proof, especially when asking for multiple ports, ought to be on the applicant. very little evidence is the issue, and if that didn't convince me, then there's an appeals process listed in RFC 5226 which you could have used to take that very little evidence to convince the IESG to overturn the decision. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch to...@isi.edu wrote: To clarify some of this discussion, providing some context that might be useful: 1) the current doc already explicitly states the procedures for assignment in each range of ports (see Sec 8.1.1). 2) Sec 8.1.1 *already* states that IESG approval through IETF process is a valid path for assignment, distinct from Expert Review. Since that appears to be a point of confusion, I'll quote it directly: o Ports in the User Ports range (1024-49151) are available for assignment through IANA, and MAY be used as service identifiers upon successful assignment. Because assigning a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. This documentation will be input to the Expert Review procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the assignment. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the IETF ^^ Review or IESG Approval procedures [RFC5226], which is how most ^^ assignments for IETF protocols are handled. ^^^ For the purposes of clarification, then, this document has no impact whatsoever on ports assigned through the IESG process? I.e., if my WG submits a proposed standard document to the IESG and it asks for two ports, I'm not going to get pushback based on the claim that this document imposes a presumption that that's wrong? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2/1/2011 10:00 AM, Eric Rescorla wrote: On Tue, Feb 1, 2011 at 9:39 AM, Joe Touchto...@isi.edu wrote: To clarify some of this discussion, providing some context that might be useful: 1) the current doc already explicitly states the procedures for assignment in each range of ports (see Sec 8.1.1). 2) Sec 8.1.1 *already* states that IESG approval through IETF process is a valid path for assignment, distinct from Expert Review. Since that appears to be a point of confusion, I'll quote it directly: o Ports in the User Ports range (1024-49151) are available for assignment through IANA, and MAY be used as service identifiers upon successful assignment. Because assigning a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. This documentation will be input to the Expert Review procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the assignment. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the IETF ^^ Review or IESG Approval procedures [RFC5226], which is how most ^^ assignments for IETF protocols are handled. ^^^ For the purposes of clarification, then, this document has no impact whatsoever on ports assigned through the IESG process? I.e., if my WG submits a proposed standard document to the IESG and it asks for two ports, I'm not going to get pushback based on the claim that this document imposes a presumption that that's wrong? The ONLY impact is in the format of information required for an assignment. (i.e., yes, if you're asking that there's no change to the process, that's correct) However, IANA can still pushback, and can use whatever advice it sees fit to do so, during IESG review. You can get that pushback now. This document doesn't change that AT ALL. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Tue, Feb 1, 2011 at 10:26 AM, Joe Touch to...@isi.edu wrote: On 2/1/2011 10:00 AM, Eric Rescorla wrote: On Tue, Feb 1, 2011 at 9:39 AM, Joe Touchto...@isi.edu wrote: To clarify some of this discussion, providing some context that might be useful: 1) the current doc already explicitly states the procedures for assignment in each range of ports (see Sec 8.1.1). 2) Sec 8.1.1 *already* states that IESG approval through IETF process is a valid path for assignment, distinct from Expert Review. Since that appears to be a point of confusion, I'll quote it directly: o Ports in the User Ports range (1024-49151) are available for assignment through IANA, and MAY be used as service identifiers upon successful assignment. Because assigning a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. This documentation will be input to the Expert Review procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the assignment. The submitted documentation MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Ports in the User Ports range may also be assigned under the IETF ^^ Review or IESG Approval procedures [RFC5226], which is how most ^^ assignments for IETF protocols are handled. ^^^ For the purposes of clarification, then, this document has no impact whatsoever on ports assigned through the IESG process? I.e., if my WG submits a proposed standard document to the IESG and it asks for two ports, I'm not going to get pushback based on the claim that this document imposes a presumption that that's wrong? The ONLY impact is in the format of information required for an assignment. (i.e., yes, if you're asking that there's no change to the process, that's correct) However, IANA can still pushback, and can use whatever advice it sees fit to do so, during IESG review. You can get that pushback now. This document doesn't change that AT ALL. I'm sorry, but I'm still not clear. This document has an affirmative statement against the use of multiple ports for TLS. AFAIK that statement is not part of present written policy. Is that correct? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2/1/2011 10:29 AM, Eric Rescorla wrote: ... I'm sorry, but I'm still not clear. This document has an affirmative statement against the use of multiple ports for TLS. I'm sorry, but it does not. I states a goal, and a preference, and has plenty of wiggle room as I've repeatedly quoted, and will quote again here: This section summarizes the current principles by which IANA handles the Service Name and Transport Protocol Port Number Registry and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA has flexibility beyond these principles when handling assignment requests; other factors may come into play, and exceptions may be made to best serve the needs of the Internet. AFAIK that statement is not part of present written policy. Is that correct? See the word above principles. That isn't policy. IANA isn't bound by it (see the last sentence). The Expert Review team is not bound by any written policy - RFC 5226 does not require that we have one, and we don't. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
I'll add my +1 to Ned's comments in a slightly different way. As someone who is a reviewer, I think we all owe a big debt to Joe Touch and Pearl Liang for guiding applicants and reviewers through the process (even if the applicants don't know it). Eliot On 2/1/11 5:38 PM, Ned Freed wrote: +1 to everything Magnus says here. THis is exactly how I view the multiple port issue. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Joe == Joe Touch to...@isi.edu writes: Joe On 1/27/2011 12:52 AM, Lars Eggert wrote: Joe ... 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? Joe AFAICT, the experts team reports to IANA. We make Joe recommendations to them. They are the ones who have the Joe conversation with the applicant. They can take our advice or Joe not - that's their decision. Joe, the IESG had a fair amount of negative experience with this style of review just before I joined; this type of review was just about out of the process leading to blocking objections when I joined as an AD. I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2/1/2011 11:14 AM, Sam Hartman wrote: ... Joe, the IESG had a fair amount of negative experience with this style of review just before I joined; this type of review was just about out of the process leading to blocking objections when I joined as an AD. I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. Such reviews occur elsewhere in the IETF as well; it's not a requirement that every review include a list of all consulted parties. This is no different. IANA is the one making the decision of how to use the advice they receive. I.e., please explain where in RFC 5226 that the process of Expert Review is expected to be a dialogue. I.e., the dialogue is with IANA, not the reviewer. The point isn't that reviewers MUST be anonymous; many of them do engage in direct conversation with the applicant. However, we try to avoid that because we want IANA involved in all conversation, and we want IANA to approve that conversation as it goes along. So, ultimately, the discussion is really, IMO, with IANA, not the reviewer per se, which is why the identity of the reviewer is irrelevant. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Joe == Joe Touch to...@isi.edu writes: Joe On 2/1/2011 11:14 AM, Sam Hartman wrote: Joe ... Joe, the IESG had a fair amount of negative experience with this style of review just before I joined; this type of review was just about out of the process leading to blocking objections when I joined as an AD. I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. Joe Such reviews occur elsewhere in the IETF as well; it's not a Joe requirement that every review include a list of all consulted Joe parties. This is no different. IANA is the one making the Joe decision of how to use the advice they receive. Joe, RFC 5226 disagrees with you fairly significantly. I draw your attention in particular to section 3.2, and particularly call our attention to several points made there: * The designated expert is responsible for initiating and coordinating the review. * Designated experts are expected to be able to defend their *decisions* to the IETf community * The process is not intended to be secretive * Experts make a single clear recommendation to IANA * In cases of deadlock IESG may be pulled in to resolve disputes * When IANA receives conflicting advice, chair of pool of experts gives clear *instructions* to IANA. On page 10, the expert review criteria requires approval of a designated expert. I submit based on the above that the experts rather than IANA are making the decision; the expert has the responsibility of justifying and defending their decision. Moreover anonymous expert reviews violate two BCP requirements: they tend to a secretive process and they do not facilitate the expert defending their decision to the IETF community. Having read RFc 5226 my objection to anonymous expert reviews is much stronger than when I first read Cullen's message. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2/1/2011 12:12 PM, Sam Hartman wrote: Joe == Joe Touchto...@isi.edu writes: Joe On 2/1/2011 11:14 AM, Sam Hartman wrote: Joe ... Joe, the IESG had a fair amount of negative experience with this style of review just before I joined; this type of review was just about out of the process leading to blocking objections when I joined as an AD. I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. Joe Such reviews occur elsewhere in the IETF as well; it's not a Joe requirement that every review include a list of all consulted Joe parties. This is no different. IANA is the one making the Joe decision of how to use the advice they receive. Joe, RFC 5226 disagrees with you fairly significantly. I draw your attention in particular to section 3.2, and particularly call our attention to several points made there: * The designated expert is responsible for initiating and coordinating the review. * Designated experts are expected to be able to defend their *decisions* to the IETf community * The process is not intended to be secretive * Experts make a single clear recommendation to IANA * In cases of deadlock IESG may be pulled in to resolve disputes * When IANA receives conflicting advice, chair of pool of experts gives clear *instructions* to IANA. On page 10, the expert review criteria requires approval of a designated expert. I submit based on the above that the experts rather than IANA are making the decision; the expert has the responsibility of justifying and defending their decision. Moreover anonymous expert reviews violate two BCP requirements: they tend to a secretive process and they do not facilitate the expert defending their decision to the IETF community. Having read RFc 5226 my objection to anonymous expert reviews is much stronger than when I first read Cullen's message. Well, based on the above, the Expert Team has a lot more power than I originally thought. I agree that, given that power, making the reviewer known makes sense. I will let you know that I will recommend to IANA that they should include a warning that any communication regarding an application made outside of the process (e.g., with IANA in the loop) will likely result in an application being rejected on a violation of the above open process. That should avoid my concerns about the team being deluged out-of-band ;-) Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Tue, Feb 1, 2011 at 2:14 AM, Magnus Westerlund magnus.westerl...@ericsson.com wrote: Cullen Jennings skrev 2011-01-31 18:44: Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. Well, frankly I don't know. I think it is something that can be avoided going forward in many use cases, but not all. Simply by thinking of this issue in the design phase. In addition there is clearly other solutions there other considerations, like NAT traversal has said, yes multiplexing is a must, thus live with even higher complexity costs. The issue I have a problem with is that is we say on general basis that due to negotiation of security protocols we are allowed to use different ports for negotiation or simply usage of it. Then why is that different from different versions of the protocol, or feature support. What is the difference for a security protocol compared to these other issues? What I am worried here is that we will see an increased port consumption rather than a decreased one. At the current run rate I think the estimate is 50 years+ before run out. That is something that I am reasonably comfortable, but if the consumption rate increases four times, then I am suddenly not comfortable. So I am pretty certain that we need to aim at lowering the consumption rather than raising it. As I see it there are only one way of doing it. - State clearly that you really need to do everything reasonable so that your application is only for one port. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. And from that perspective I don't think security is special in anyway. It is only one of several things that could potentially require additional registered ports. Yes security is important, but as previously discussed it doesn't appear that the actual level of security provided is different if you are forced to use one port or two. It might affect the ease of implementation and deployment of security, which is another aspect of impact. Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. And I've never witnessed IANA rejecting requests coming through the IETF. But even if they did, there is an appeals procedure. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
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 and 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. and 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 review. 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. Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/31/11 12:23 AM, Lars Eggert wrote: On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. Then this should be made *much* clearer in the document. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that all meant all, not all except those through IETF-stream documents; others might have read it the same way I did. Further, the wording throughout the template description in 8.1 makes it sound like that the restrictions in this document apply to everything that needs a template, which clearly includes IETF-stream documents. And I've never witnessed IANA rejecting requests coming through the IETF. This document is about new restrictions for the future, not what has happened in the past. But even if they did, there is an appeals procedure. That is slim comfort to a WG that has designed a protocol that has good design reasons for needing two ports and, at the last minute is told that they either have to re-design from scratch or go through an appeals process to justify their design to IANA. It's fine that they have to justify it to the IESG (well, fine to me; other greybeards seem to not like that so much these days), but there should be no way that IANA can say you cannot get ports assigned because this new RFC says that you designed your protocol wrong. If what you say above about Assignments through IETF-stream documents do not go through expert review. is true, it should be plainly stated in the introduction to the document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Hi, On 2011-1-31, at 16:51, Paul Hoffman wrote: On 1/31/11 12:23 AM, Lars Eggert wrote: On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. Then this should be made *much* clearer in the document. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that all meant all, not all except those through IETF-stream documents; others might have read it the same way I did. The sentence you quote isn't related to the issue we're discussing. It is intended to say a goal is that the procedures to get ports and service names are the same for UDP, TCP, DCCP and SCTP. (Maybe it would be clearer by explicitly naming these protocols in the document.) But I see the point you're raising. The document should somewhere say that Expert Review is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. Did I get that right? But even if they did, there is an appeals procedure. That is slim comfort to a WG that has designed a protocol that has good design reasons for needing two ports and, at the last minute is told that they either have to re-design from scratch or go through an appeals process to justify their design to IANA. It's fine that they have to justify it to the IESG (well, fine to me; other greybeards seem to not like that so much these days), but there should be no way that IANA can say you cannot get ports assigned because this new RFC says that you designed your protocol wrong. If what you say above about Assignments through IETF-stream documents do not go through expert review. is true, it should be plainly stated in the introduction to the document. Right. I think the change I outlined above would address this. Thanks! Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/31/11 7:06 AM, Lars Eggert wrote: But I see the point you're raising. The document should somewhere say that Expert Review is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. Did I get that right? Yes, that would greatly reduce the concern about where and when (and how often!) the review would happen. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Jan 31, 2011, at 8:14 , Paul Hoffman wrote: On 1/31/11 7:06 AM, Lars Eggert wrote: But I see the point you're raising. The document should somewhere say that Expert Review is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. Did I get that right? Yes, that would greatly reduce the concern about where and when (and how often!) the review would happen. Hmm ... I don't agree that solves the issue. Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. I'm sure that some people believe the draft, by using the word strives, actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that strives means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/31/11 5:13 PM, Cullen Jennings wrote: Hmm ... I don't agree that solves the issue. Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. Who, ultimately, is the steward of this precious resource? If it is not the IANA and it is not the IETF, then who? To say that it is everyone's responsibility is to avoid responsibility entirely. Who gets to say which standards organizations are stewards and which are not? I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. This is a VERY VERY dangerous approach you propose, Cullen. It is akin to saying, you can think about security later, because we'll have to give you a port for it later. We don't want to be saying that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
So IANA has a huge amount of technical expertise and takes maintaing the registries very seriously. I've seen them catch technical mistakes that made all the way through WG and IESG review. I've got huge respect for technical competence of IANA and in particular Michelle. So I'm not questions that but I don't recall seeing them override an expert on a technical issue. I'd be happy to hear of examples but lets consider the example I am actually concerned about here. I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, that will not meet the latency goals of the protocol. Joe does not agree. So Michelle, in that case, would you be willing to override Joe? I'm sure you would be willing to help facilitate any conversations, bring in other people such as ADs that can help etc. I was sort of working on the assumption that you would not override Joe in this case and the the only path forward would be an appeal to Lars but perhaps that is just a bad assumption on my part. Appeals are really the worst way possible to resolve things. I have a hard time imagining that IANA would want to engage in a technical discussion to resolve this and instead relies on the expert reviewer. I'll note that the expert review may report to IANA but they are selected by and replaced by the IESG. The important point here is that I really don't care if it is Joe or IANA that is saying no - I think this document should be clear that this BCP can not be used as grounds for rejecting the request for a second port for security. On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/31/11 8:13 AM, Cullen Jennings wrote: Hmm ... I don't agree that solves the issue. Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. Because IANA is responsible for maintaining the usefulness of the registry. Part of that is don't hand out ports unnecessarily, and part of that is hand out ports without hassle to those who are trusted to ask for them wisely. If 3GPP can show it belongs in the latter category, great. Until then, the only body that is there is IETF consensus plus maybe IESG pressure. I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. I'm sure that some people believe the draft, by using the word strives, actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that strives means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this. Fully agree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Cullen Jennings skrev 2011-01-31 17:13: Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. I am not certain I understand what your issue is here. Is it that they can come to different conclusions, and that IETF can decided to override the expert review team? I think that is the logical conclusion, as the IETF's decision will have gone through a consensus process. One which the expert can provide their view into this. I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. My reading of the WG last call consensus is that nobody is disagreeing with the goal of trying minimize the port consumption. My interpretation is that we do need to state that goal in the document. And the only way of achieving this is to try to minimize the consumption by each protocol that requires a registration. That includes trying to get all multiplexing into that single socket, or at least use it for agreeing on dynamic range port for this protocol. I'm sure that some people believe the draft, by using the word strives, actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that strives means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this. It is a high level goal to minimize the port space consumption. I do believe there is strong consensus for this. And I believe that the only way of ensuring that this goal is meet is to take a pretty hard stance against frivolous use of ports. Thus, I still think there is clear grounds for rejecting requests for multiple ports based on not sufficiently motivating why it is impossible to not use one port. I do agree that these guidelines should be documented, and that is the plans as far as I know. Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Cullen, We do have some technical expertise within the IANA staff, however our expertise is more aligned with the process of creating and maintaining registries. Part of that includes relying on the experts that the IESG designates to make the decisions for requests that utilize the Expert Review policy in RFC 5226. In the past, if there is strong disagreement from an expert and the requester disagrees, we have brought the Transport Area Directors into the communications to see if all parties can come to an agreement. In almost all cases, this is where a final decision is made. If that set of folks can not come to a conclusion, we then would default to going to the IESG. With all requests, if there is any uncertainty as to what decision should be made, we go to the IESG for guidance. We do rely on the technical expertise of the appointed experts for all registries, but we ALWAYS have the possibility to seek guidance form the IESG. I don't believe we have ever had an official appeals with ports (Knocking on wood really hard!). Does that help? --Michelle On 1/31/11 8:33 AM, Cullen Jennings flu...@cisco.com wrote: So IANA has a huge amount of technical expertise and takes maintaing the registries very seriously. I've seen them catch technical mistakes that made all the way through WG and IESG review. I've got huge respect for technical competence of IANA and in particular Michelle. So I'm not questions that but I don't recall seeing them override an expert on a technical issue. I'd be happy to hear of examples but lets consider the example I am actually concerned about here. I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, that will not meet the latency goals of the protocol. Joe does not agree. So Michelle, in that case, would you be willing to override Joe? I'm sure you would be willing to help facilitate any conversations, bring in other people such as ADs that can help etc. I was sort of working on the assumption that you would not override Joe in this case and the the only path forward would be an appeal to Lars but perhaps that is just a bad assumption on my part. Appeals are really the worst way possible to resolve things. I have a hard time imagining that IANA would want to engage in a technical discussion to resolve this and instead relies on the expert reviewer. I'll note that the expert review may report to IANA but they are selected by and replaced by the IESG. The important point here is that I really don't care if it is Joe or IANA that is saying no - I think this document should be clear that this BCP can not be used as grounds for rejecting the request for a second port for security. On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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, On 1/31/2011 7:06 AM, Lars Eggert wrote: Hi, On 2011-1-31, at 16:51, Paul Hoffman wrote: On 1/31/11 12:23 AM, Lars Eggert wrote: On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. Then this should be made *much* clearer in the document. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that all meant all, not all except those through IETF-stream documents; others might have read it the same way I did. The sentence you quote isn't related to the issue we're discussing. It is intended to say a goal is that the procedures to get ports and service names are the same for UDP, TCP, DCCP and SCTP. (Maybe it would be clearer by explicitly naming these protocols in the document.) But I see the point you're raising. The document should somewhere say that Expert Review is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. RFC2434 already gives IANA these options. Perhaps - at best - we should include a ref to that. However, this document is not focused at changing what RFC2434 says, and the above statement, IMO, does. That's another can of worms, and should be reserved for a different document. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
The procedures that are specified - for ALL assignments - are the PROCEDURES - the word itself is used specifically in the heading of section 8. That does not refer to the principles - again for which there are more than sufficient wiggle words, and which already cite existing RFCs that have provisions that already limit the role of Expert Review and allow for appeals. Again - this document is NOT focused on those principles. IANA - and more specifically its review team - is NOT required to publish any such principles (as per RFC 5226). If they continue to be a source of contention, then section 7 should be removed. Joe On 1/31/2011 6:51 AM, Paul Hoffman wrote: On 1/31/11 12:23 AM, Lars Eggert wrote: On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. Then this should be made *much* clearer in the document. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that all meant all, not all except those through IETF-stream documents; others might have read it the same way I did. Further, the wording throughout the template description in 8.1 makes it sound like that the restrictions in this document apply to everything that needs a template, which clearly includes IETF-stream documents. And I've never witnessed IANA rejecting requests coming through the IETF. This document is about new restrictions for the future, not what has happened in the past. But even if they did, there is an appeals procedure. That is slim comfort to a WG that has designed a protocol that has good design reasons for needing two ports and, at the last minute is told that they either have to re-design from scratch or go through an appeals process to justify their design to IANA. It's fine that they have to justify it to the IESG (well, fine to me; other greybeards seem to not like that so much these days), but there should be no way that IANA can say you cannot get ports assigned because this new RFC says that you designed your protocol wrong. If what you say above about Assignments through IETF-stream documents do not go through expert review. is true, it should be plainly stated in the introduction to the document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/31/2011 9:16 AM, Joe Touch wrote: Lars, On 1/31/2011 7:06 AM, Lars Eggert wrote: Hi, On 2011-1-31, at 16:51, Paul Hoffman wrote: On 1/31/11 12:23 AM, Lars Eggert wrote: On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. Then this should be made *much* clearer in the document. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that all meant all, not all except those through IETF-stream documents; others might have read it the same way I did. The sentence you quote isn't related to the issue we're discussing. It is intended to say a goal is that the procedures to get ports and service names are the same for UDP, TCP, DCCP and SCTP. (Maybe it would be clearer by explicitly naming these protocols in the document.) But I see the point you're raising. The document should somewhere say that Expert Review is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. RFC2434 already gives IANA these options. As does RFC 5226 - its update (there is no substantive change between the two in this regard, FWIW). Perhaps - at best - we should include a ref to that. And 5226 is already clearly cited. No further action should be required. Joe However, this document is not focused at changing what RFC2434 says, and the above statement, IMO, does. That's another can of worms, and should be reserved for a different document. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Thanks - yes that makes it clear and I like the way IANA handles all of this. On Jan 31, 2011, at 9:55 , Michelle Cotton wrote: Cullen, We do have some technical expertise within the IANA staff, however our expertise is more aligned with the process of creating and maintaining registries. Part of that includes relying on the experts that the IESG designates to make the decisions for requests that utilize the Expert Review policy in RFC 5226. In the past, if there is strong disagreement from an expert and the requester disagrees, we have brought the Transport Area Directors into the communications to see if all parties can come to an agreement. In almost all cases, this is where a final decision is made. If that set of folks can not come to a conclusion, we then would default to going to the IESG. With all requests, if there is any uncertainty as to what decision should be made, we go to the IESG for guidance. We do rely on the technical expertise of the appointed experts for all registries, but we ALWAYS have the possibility to seek guidance form the IESG. I don't believe we have ever had an official appeals with ports (Knocking on wood really hard!). Does that help? --Michelle On 1/31/11 8:33 AM, Cullen Jennings flu...@cisco.com wrote: So IANA has a huge amount of technical expertise and takes maintaing the registries very seriously. I've seen them catch technical mistakes that made all the way through WG and IESG review. I've got huge respect for technical competence of IANA and in particular Michelle. So I'm not questions that but I don't recall seeing them override an expert on a technical issue. I'd be happy to hear of examples but lets consider the example I am actually concerned about here. I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, that will not meet the latency goals of the protocol. Joe does not agree. So Michelle, in that case, would you be willing to override Joe? I'm sure you would be willing to help facilitate any conversations, bring in other people such as ADs that can help etc. I was sort of working on the assumption that you would not override Joe in this case and the the only path forward would be an appeal to Lars but perhaps that is just a bad assumption on my part. Appeals are really the worst way possible to resolve things. I have a hard time imagining that IANA would want to engage in a technical discussion to resolve this and instead relies on the expert reviewer. I'll note that the expert review may report to IANA but they are selected by and replaced by the IESG. The important point here is that I really don't care if it is Joe or IANA that is saying no - I think this document should be clear that this BCP can not be used as grounds for rejecting the request for a second port for security. On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf
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
On Jan 31, 2011, at 9:41 , Magnus Westerlund wrote: Cullen Jennings skrev 2011-01-31 17:13: Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. I am not certain I understand what your issue is here. Is it that they can come to different conclusions, and that IETF can decided to override the expert review team? I think that is the logical conclusion, as the IETF's decision will have gone through a consensus process. One which the expert can provide their view into this. I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. My reading of the WG last call consensus is that nobody is disagreeing with the goal of trying minimize the port consumption. My interpretation is that we do need to state that goal in the document. And the only way of achieving this is to try to minimize the consumption by each protocol that requires a registration. That includes trying to get all multiplexing into that single socket, or at least use it for agreeing on dynamic range port for this protocol. I'm sure that some people believe the draft, by using the word strives, actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that strives means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this. It is a high level goal to minimize the port space consumption. I do believe there is strong consensus for this. And I believe that the only way of ensuring that this goal is meet is to take a pretty hard stance against frivolous use of ports. Thus, I still think there is clear grounds for rejecting requests for multiple ports based on not sufficiently motivating why it is impossible to not use one port. I do agree that these guidelines should be documented, and that is the plans as far as I know. Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
So first, we already have a BCP that says more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that - security. It's probably impacts design work in working groups more than any other BCP. It has IETF consensus. The IESG holds protocols to this. Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy. Please do enlighten me. And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design. On Jan 31, 2011, at 9:27 , Eliot Lear wrote: On 1/31/11 5:13 PM, Cullen Jennings wrote: Hmm ... I don't agree that solves the issue. Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. Who, ultimately, is the steward of this precious resource? If it is not the IANA and it is not the IETF, then who? To say that it is everyone's responsibility is to avoid responsibility entirely. Who gets to say which standards organizations are stewards and which are not? I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. This is a VERY VERY dangerous approach you propose, Cullen. It is akin to saying, you can think about security later, because we'll have to give you a port for it later. We don't want to be saying that. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/31/11 6:51 PM, Cullen Jennings wrote: So first, we already have a BCP that says more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that - security. It's probably impacts design work in working groups more than any other BCP. It has IETF consensus. The IESG holds protocols to this. But this isn't only about IETF process. You just asked about why the IETF is special and why 3GPP shouldn't be treated on equal footing. Well, then what about ITU, ISO, W3C, and Joe's Standards Body? Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy. Please do enlighten me. The vast majority of the requests I see have 0 security built in until I ask the question. A few come back with a plan. Take away that lever and I don't even get to ask the question. And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design. I missed a step there? CoAP? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Fwiw please see sec 8.1 of our doc which states which procedures of RFC 5226 are specified for each range, and already allows IESG approval as a path for user ports. Joe On Jan 31, 2011, at 9:25 AM, Joe Touch to...@isi.edu wrote: On 1/31/2011 9:16 AM, Joe Touch wrote: Lars, On 1/31/2011 7:06 AM, Lars Eggert wrote: Hi, On 2011-1-31, at 16:51, Paul Hoffman wrote: On 1/31/11 12:23 AM, Lars Eggert wrote: On 2011-1-30, at 17:12, Paul Hoffman wrote: The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go through expert review. Then this should be made *much* clearer in the document. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that all meant all, not all except those through IETF-stream documents; others might have read it the same way I did. The sentence you quote isn't related to the issue we're discussing. It is intended to say a goal is that the procedures to get ports and service names are the same for UDP, TCP, DCCP and SCTP. (Maybe it would be clearer by explicitly naming these protocols in the document.) But I see the point you're raising. The document should somewhere say that Expert Review is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. RFC2434 already gives IANA these options. As does RFC 5226 - its update (there is no substantive change between the two in this regard, FWIW). Perhaps - at best - we should include a ref to that. And 5226 is already clearly cited. No further action should be required. Joe However, this document is not focused at changing what RFC2434 says, and the above statement, IMO, does. That's another can of worms, and should be reserved for a different document. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Mon, Jan 31, 2011 at 11:41 AM, Eric Rescorla e...@skype.net wrote: So first, we already have a BCP that says more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that - security. It's probably impacts design work in working groups more than any other BCP. It has IETF consensus. The IESG holds protocols to this. Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy. Please do enlighten me. I don't think it does. At a high level, there are three ways in which insecure and secure versions (by which I mostly mean channel security mechanisms such as TLS) of the same protocol can coexist: 1. They can operate on totally different transport parameters (e.g., ports) 2. They can be demuxable by some indicator that's simply sent by one side and accepted or rejected by the other side. (E.g., If the first byte is 20 this is TLS, else it's not) 3. It can be negotiated as in STARTTLS In the first two of these, the client knows which version it wants (secure or insecure) and there is no chance for the server to indicate otherwise other than failing the connection. In the third, the sides negotiate. So, I think the first question is which general design you wish to have. Each of these have their merits: negotiation designs are more complicated but allow for opportunistic security. Unfortunately, they also allow for downgrade attack, as the experience with STARTTLS for SMTP shows. By contrast, non-negotiation designs are easier to implement and provide for referential integrity but not for opportunistic security. IMO there is a place for both, though I generally tend towards non-negotiated designs, in part out of a feeling that the world would be better if people used encryption all the time. Clearly, if you're going to do a negotiation design you want a single port. If you're going to do a non-negotiated design, then I don't see a huge amount of value in using a single port. It's true that there is a port consumption issue, but OTOH ports are there for protocol demuxing and this is clearly another protocol. It's simply a lot easier to have your TLS stack just start its thing rather than try to autodetect whether you have TLS or some other protocol. So I would generally push back on the claim that non-negotiated designs should have to have demuxing in information in the dataflow rather than use the port. And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design. I don't consider this an acceptable design and I've already told the CoAP authors and chairs so. Speaking as chair, if the CoAP authors/chairs wish to pursue this avenue they should bring it to the TLS WG, which AFAIK they have not done. -Ekr On Jan 31, 2011, at 9:27 , Eliot Lear wrote: On 1/31/11 5:13 PM, Cullen Jennings wrote: Hmm ... I don't agree that solves the issue. Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. Who, ultimately, is the steward of this precious resource? If it is not the IANA and it is not the IETF, then who? To say that it is everyone's responsibility is to avoid responsibility entirely. Who gets to say which standards organizations are stewards and which are not? I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. This is a VERY VERY dangerous approach you propose, Cullen. It is akin to saying, you can think about security later, because we'll have to give you a port for it later. We don't want to be saying that. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Eric, Clearly, if you're going to do a negotiation design you want a single port. If you're going to do a non-negotiated design, then I don't see a huge amount of value in using a single port. It's true that there is a port consumption issue, but OTOH ports are there for protocol demuxing and this is clearly another protocol. Another way to look at this is that it's the same protocol running atop a security layer. Same protocol engine, perhaps in a slightly different security context in terms of what is authorized. And there's good reason to look at it this way. Aside from the leverage it gives reviewers as I discussed previously, there's also the minor matter of port consumption, which won't be so minor if we run short. And don't think that can't happen. Additional ports are being approved for reasons that are clearly architecture limitations. I'm not even sure this is an acceptable excuse. For one, if we look at some of the examples that have been mooted, I doubt that an additional port would have solved the downgrade problem. The case I have in mind is indeed SMTP. The conditions that allow for the downgrade attack have more to do with the realities of certificate management than STARTTLS. As I wrote in a different context there is also the draft that Paul has written for HASTLS, which allows a server to express a policy without having to require a port. While some of us have some questions about some of the choices Paul made in the design, on the whole I think everyone agrees it's a good idea. It may not, however, solve the entire problem, because we now are forced to answer the question as to how host policy should be conveyed. It's simply a lot easier to have your TLS stack just start its thing rather than try to autodetect whether you have TLS or some other protocol. Maybe so (wasn't so hard for me), but there now is a whole lot of free code out there that does just this. So I would generally push back on the claim that non-negotiated designs should have to have demuxing in information in the dataflow rather than use the port. There is a cost that extends beyond the protocol. That has to be taken into account. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Mon, Jan 31, 2011 at 2:11 PM, Eliot Lear l...@cisco.com wrote: Eric, Clearly, if you're going to do a negotiation design you want a single port. If you're going to do a non-negotiated design, then I don't see a huge amount of value in using a single port. It's true that there is a port consumption issue, but OTOH ports are there for protocol demuxing and this is clearly another protocol. Another way to look at this is that it's the same protocol running atop a security layer. Same protocol engine, perhaps in a slightly different security context in terms of what is authorized. And there's good reason to look at it this way. Aside from the leverage it gives reviewers as I discussed previously, there's also the minor matter of port consumption, which won't be so minor if we run short. And don't think that can't happen. Additional ports are being approved for reasons that are clearly architecture limitations. I'm not even sure this is an acceptable excuse. Really? What fraction of the port space has been consumed? For one, if we look at some of the examples that have been mooted, I doubt that an additional port would have solved the downgrade problem. The case I have in mind is indeed SMTP. The conditions that allow for the downgrade attack have more to do with the realities of certificate management than STARTTLS. I didn't say it did, if you reread my message. What I said was that not negotiating addresses downgrade. As I wrote in a different context there is also the draft that Paul has written for HASTLS, which allows a server to express a policy without having to require a port. While some of us have some questions about some of the choices Paul made in the design, on the whole I think everyone agrees it's a good idea. Well, I'm not sure I see the relevance of this. The question is how the server supports both secure and insecure variants at once. It's simply a lot easier to have your TLS stack just start its thing rather than try to autodetect whether you have TLS or some other protocol. Maybe so (wasn't so hard for me), Well, I have no idea what protocol you're thinking of, but all of the upward negotiation protocols have a significantly more complicated state machine than does HTTPS. but there now is a whole lot of free code out there that does just this. And it's generally all protocol specific, so we have this problem with every new protocol. So I would generally push back on the claim that non-negotiated designs should have to have demuxing in information in the dataflow rather than use the port. There is a cost that extends beyond the protocol. That has to be taken into account. Of course. Which is why I'm not saying that you should ALWAYS do a separate port. But I don't agree there is consensus that it's bad either. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/29/11 9:34 PM, Joe Touch wrote: On 1/29/2011 8:54 PM, Cullen Jennings wrote: On Jan 27, 2011, at 17:10 , Joe Touch wrote: ... AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. As per my other note: RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments. The term Expert Review is defined in RFC 2434. Neither document binds IANA to use the advice of a reviewer. Further, there is no single reviewer - we have a team, consulting each other on occasion, and all decisions are seen by multiple reviewers. However, none of that is worth codifying. If IANA or the IESG doesn't like how we serve them, they can replace us - at any time, for any reason, and there is an appeals process for decisions of the expert team: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Now that this has been made clear to me, I am *much* more worried about the wording in the current draft. The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. As Cullen and others have pointed out, there are sometimes very good technical reasons for a particular protocol to need to have two ports. The document should be amended to say that protocols with IETF consensus should get as many ports as it needs, regardless of what IANA or the expert reviewer thinks. This makes it the responsibility of the IETF consensus process to follow the guidelines in this document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Paul (et al.), See below. Note that IANA can't just make its own decisions either and ignore IETF process *AND* expert review. I wasn't trying to imply that, but it appears to have been inferred from my claim that neither document binds IANA to the advice of a reviewer. IANA is bound by the OR of basic IETF process and Expert Review. The former can override the latter (or vice versa), but there is an appeal process - through the IETF - as well. If you have issue with these processes, then RFC 2434 and RFC 2780 are your targets, not this doc. Joe On 1/30/2011 7:12 AM, Paul Hoffman wrote: On 1/29/11 9:34 PM, Joe Touch wrote: ... As per my other note: RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments. The term Expert Review is defined in RFC 2434. Neither document binds IANA to use the advice of a reviewer. Further, there is no single reviewer - we have a team, consulting each other on occasion, and all decisions are seen by multiple reviewers. However, none of that is worth codifying. If IANA or the IESG doesn't like how we serve them, they can replace us - at any time, for any reason, and there is an appeals process for decisions of the expert team: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Now that this has been made clear to me, I am *much* more worried about the wording in the current draft. The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. Repeating myself: a) this document is NOT proscribing IANA processes for expert review of port requests b) RFC 2790 describes MANY ways IANA decides how to allocate ports: Values in this namespace are assigned following a Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action. Note the word *OR* above. Expert review doesn't override IETF process here. The document should be amended to say that protocols with IETF consensus should get as many ports as it needs, regardless of what IANA or the expert reviewer thinks. The above section already allows for that. This makes it the responsibility of the IETF consensus process to follow the guidelines in this document. This document says, quite clearly, at the front of Section 7.2: This section summarizes the current principles by which IANA handles the Service Name and Transport Protocol Port Number Registry and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA has flexibility beyond these principles when handling assignment requests; other factors may come into play, and exceptions may be made to best serve the needs of the Internet. It never says that this is a process that the IESG or IETF is required to follow. The language of the section has wiggle words throughout, and does not use RFC 2119 language. Thus nobody anywhere is bound by it. c) RFC 2434 notes how expert reviewers are selected: Designated experts are appointed by the relevant Area Director of the IESG. They are typically named at the time a document that creates a new numbering space is published as an RFC, but as experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary. d) there is already a process to appeal decisions that are based on Expert Review: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG. -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Jan 27, 2011, at 17:29 , Michelle Cotton wrote: We are changing that process right now. We have begun to report the reviewer (with the review) in the email to the requester. We just need to make sure this small change is communicated to those experts that are part of review teams as their individual names are not published on the main list of registries. I don't think it needs to go in this document as this is already in progress. Let me know if you have any questions. As long as we agree that is the process, it's not a big deal to me if it is in or out of the document but I don't see any reason not to put it into the document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Jan 27, 2011, at 17:10 , Joe Touch wrote: On 1/27/2011 12:52 AM, Lars Eggert wrote: ... 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? AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Jan 27, 2011, at 8:12 , IETF Chair wrote: Originally, two ports were assigned for plain and over-TLS, which for HTTP mapped to two different URL schemes: http and https. Many people thought that this was a waste of a port, and the STARTTLS approach was developed. You say that it does not work in some cases, and you seem to be suggesting that we go back to the original way. Maybe it works in some cases and not others. Can we say which is which? I did misread the draft as saying that 2 ports were not allowed when clearly that was not what people meant but ... I'm mostly concerned about cases where latency or bandwidth are an issue - basically protocols for real time protocols for internet of things. For things like email I'm less concerned. However, I think we can make some observation about which works best. Consider some of the most successful protocols on the internet http, 2 ports email, pop, imap, and smtp, - more use on multi ports than STARTLS though many deployment support both sip, 2 ports ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
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 and 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. and 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. On Jan 27, 2011, at 1:17 , Magnus Westerlund wrote: We have extensive discussion on this in the WG last call. There was no consensus for having two ports. At the same time we did also have no consensus on mandating one port for any future protocol. Thus we adjusted the text to say in Section 7.2: IANA strives to assign only one assigned port number per service or application To my knowledge strive is not a binding RFC2119 term. I also think it is a good trade-off with the intention of preserving the space as well as possible with only assigning one port, and still allow for more than one if it really is needed. Is it the above text that triggered your comment or some other text? Cheers Magnus Westerlund Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/29/2011 8:53 PM, Cullen Jennings wrote: On Jan 27, 2011, at 17:29 , Michelle Cotton wrote: We are changing that process right now. We have begun to report the reviewer (with the review) in the email to the requester. We just need to make sure this small change is communicated to those experts that are part of review teams as their individual names are not published on the main list of registries. I don't think it needs to go in this document as this is already in progress. Let me know if you have any questions. As long as we agree that is the process, it's not a big deal to me if it is in or out of the document but I don't see any reason not to put it into the document. The reason is that this document isn't about the IANA process for reviewing ports; it's about unifying the port registries. RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments: Both the Source and Destination Port fields use the same namespace. Values in this namespace are assigned following a Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action process. The term Expert Review is defined in RFC 2434. Neither document mandates that IANA either act on the advice such a review, nor that the reviewer identity be disclosed as part of that process. Further, the list of such experts is known by IANA and the IESG: Designated experts are appointed by the relevant Area Director of the IESG. They are typically named at the time a document that creates a new numbering space is published as an RFC, but as experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary. If you want to codify this process further, you would need to revise RFC2434 - e.g., to require the disclosure of the expert reviewer. However, that is not in the scope of this document. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/29/2011 8:54 PM, Cullen Jennings wrote: On Jan 27, 2011, at 17:10 , Joe Touch wrote: ... AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. As per my other note: RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments. The term Expert Review is defined in RFC 2434. Neither document binds IANA to use the advice of a reviewer. Further, there is no single reviewer - we have a team, consulting each other on occasion, and all decisions are seen by multiple reviewers. However, none of that is worth codifying. If IANA or the IESG doesn't like how we serve them, they can replace us - at any time, for any reason, and there is an appeals process for decisions of the expert team: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Jan 27, 2011, at 1:26 , Lars Eggert wrote: On 2011-1-27, at 11:20, Carsten Bormann wrote: With UDP-based protocols, it is harder to do this. Please look at section 7.3 of http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3 and tell us whether this is how you would like this to be handled for UDP-based protocols in the future. If not, we may want to add to the guidance in the (tsvwg) draft. This looks like a totally reasonable way to to this in-band using a single port. How is the COAP working stepping on top of TLS code points any different that the ITU-T stepping on MPLS code points? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
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
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
Cullen Jennings skrev 2011-01-27 01:12: 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 We have extensive discussion on this in the WG last call. There was no consensus for having two ports. At the same time we did also have no consensus on mandating one port for any future protocol. Thus we adjusted the text to say in Section 7.2: IANA strives to assign only one assigned port number per service or application To my knowledge strive is not a binding RFC2119 term. I also think it is a good trade-off with the intention of preserving the space as well as possible with only assigning one port, and still allow for more than one if it really is needed. Is it the above text that triggered your comment or some other text? Cheers 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On Jan 27, 2011, at 09:52, Lars Eggert wrote: all new protocols should be security-capable Sure. How is this relevant? In some protocols, there is value to use them without communication security (think TLS) for some applications, and with communication security for others. We used to distinguish these two cases using two ports, now we use a single port plus per-connection negotiation like STARTLS. I think the draft is trying to encourage this conversion, and I agree with this, at least where latency is less relevant. With UDP-based protocols, it is harder to do this. Please look at section 7.3 of http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3 and tell us whether this is how you would like this to be handled for UDP-based protocols in the future. If not, we may want to add to the guidance in the (tsvwg) draft. Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 2011-1-27, at 11:20, Carsten Bormann wrote: With UDP-based protocols, it is harder to do this. Please look at section 7.3 of http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3 and tell us whether this is how you would like this to be handled for UDP-based protocols in the future. If not, we may want to add to the guidance in the (tsvwg) draft. This looks like a totally reasonable way to to this in-band using a single port. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Cullen: 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 ch airs, 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. Originally, two ports were assigned for plain and over-TLS, which for HTTP mapped to two different URL schemes: http and https. Many people thought that this was a waste of a port, and the STARTTLS approach was developed. You say that it does not work in some cases, and you seem to be suggesting that we go back to the original way. Maybe it works in some cases and not others. Can we say which is which? Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/27/11 8:12 AM, IETF Chair wrote: Originally, two ports were assigned for plain and over-TLS, which for HTTP mapped to two different URL schemes: http and https. Many people thought that this was a waste of a port, and the STARTTLS approach was developed. You say that it does not work in some cases, and you seem to be suggesting that we go back to the original way. Maybe it works in some cases and not others. Can we say which is which? In a word: no. We have very little operational experience, and where we do, it gives conflicting results. Some mail client developers say that POP and IMAP STARTTLS works fine, some say that it is unreliable and so they just use the alternate ports. Note that Cullen's example for where it almost certainly would not work is for non-stream UDP. Making UDP developers have to come up with a stream-like capability to do a STARTTLS-style single port solution defeats the purpose of using UDP. The benefit of we saved another port! over we forced someone to make UDP more like TCP! seems like a false one. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/27/11 8:41 AM, Paul Hoffman wrote: On 1/27/11 8:12 AM, IETF Chair wrote: Originally, two ports were assigned for plain and over-TLS, which for HTTP mapped to two different URL schemes: http and https. Many people thought that this was a waste of a port, and the STARTTLS approach was developed. You say that it does not work in some cases, and you seem to be suggesting that we go back to the original way. Maybe it works in some cases and not others. Can we say which is which? In a word: no. We have very little operational experience, and where we do, it gives conflicting results. Some mail client developers say that POP and IMAP STARTTLS works fine, some say that it is unreliable and so they just use the alternate ports. So I can say that having provided a large scale mail-service in a former life that we made it work for our customers. On the SMTP side on the virtually everyone has this working except those people that use 465, because the service you're talking to on 587 is fundamentaly the same one that's on 25. joelja-mac:tmp joelja$ telnet nagasaki.bogus.com 25 Trying 147.28.0.81... Connected to nagasaki.bogus.com. Escape character is '^]'. 220 nagasaki.bogus.com ESMTP Sendmail 8.14.4/8.14.4; Thu, 27 Jan 2011 17:28:24 GMT ehlo jaeggli 250-nagasaki.bogus.com Hello adsl-99-173-15-226.dsl.pltn13.sbcglobal.net [99.173.15.226], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN 250-STARTTLS 250-DELIVERBY 250 HELP Note that Cullen's example for where it almost certainly would not work is for non-stream UDP. Making UDP developers have to come up with a stream-like capability to do a STARTTLS-style single port solution defeats the purpose of using UDP. The benefit of we saved another port! over we forced someone to make UDP more like TCP! seems like a false one. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 1/27/2011 12:52 AM, Lars Eggert wrote: ... 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? AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I.e., we are advisors to IANA. Further, many requests are handled my multiple reviewers. Many of us do have specific conversations with applicants, and identify ourselves when that happens, but it doesn't seem important to codify that in this doc. Again, this doc is about the unification of the registries. It is NOT about all the other policies that govern them. The info that's there is advisory ONLY (it is not binding to IANA). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
We are changing that process right now. We have begun to report the reviewer (with the review) in the email to the requester. We just need to make sure this small change is communicated to those experts that are part of review teams as their individual names are not published on the main list of registries. I don't think it needs to go in this document as this is already in progress. Let me know if you have any questions. --Michelle On 1/27/11 5:10 PM, Joe Touch to...@isi.edu wrote: On 1/27/2011 12:52 AM, Lars Eggert wrote: ... 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? AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I.e., we are advisors to IANA. Further, many requests are handled my multiple reviewers. Many of us do have specific conversations with applicants, and identify ourselves when that happens, but it doesn't seem important to codify that in this doc. Again, this doc is about the unification of the registries. It is NOT about all the other policies that govern them. The info that's there is advisory ONLY (it is not binding to IANA). Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Big Issues 1: I don't like mandating one port for secure and not secure versions of a protocol I don't either, so it's good that the document doesn't do that. It says: Services are expected to include support for security, either as default or dynamically negotiated in-band. 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. is to be avoided != forbidden. There are legitimate use-cases for two port approaches - not many, but some - so they should be avoided but not banned. And the main reason for this isn't to encourage optional use of negotiated in-band security, but rather because deployment of insecure service variants no matter what the protocol details are bad idea. 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 chairs, more or less told the CORE guys to get stuffed (politely of course). Two ports is the obvious answer. And nothing in this document would prevent such an assignment from being made as long as there are compelling reasons to do so. 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. I have to say that that policy must be pretty tricky to implement given the widespread lack of encryption support in SMTP relay scenarios. 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. But this doesn't address the bad configuration problem at all - all it does is change the location where the problem would have to be, from the mail server configuration (which, if it was compliant with the relevant email standards, should have been fairly secure by default) to the firewall (which doesn't really have a means of being secure by default without DPI). Now, perhaps you'll argue that firewalls configs are less likely to be grinched than those of an email server. If so, all I can say is that doesn't jibe with my experience. 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. And lots of people screw up their firewall configurations in the process. 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. Actually, I suspect there is rough consensus on the one port approach, in the TCP space at least. A few exceptions don't invalidate that. As for two registrations versus one, I would not object for there to be some cleaner mechanism for two port assignments. But any such mechanism needs to jibe with the reality that the best solution for production services is not to have an insecure variant at all, either on a separate port or negotiated in-band. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
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
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
I would like to see more clarity in 8.1 For assignments done through IETF-published RFCs, the Contact will be the IESG. in that I am unclear what IETF-published RFCs are; presumably that is Standards Track, BCP and Individual Submissions, but not Independent Submissions or IRTF RFC. I think that the terminology here should follow that of RFC4844 with a reference thereto. Tom Petch - Original Message - From: Magnus Westerlund magnus.westerl...@ericsson.com To: apps-disc...@ietf.org; Internet Area int-a...@ietf.org; rai-disc...@ietf.org; ops-a...@ietf.org; SAAG s...@ieft.org Sent: Wednesday, January 19, 2011 9:30 AM Subject: [apps-discuss] Fwd: 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 Hi, I just want to make people aware of this IETF last call for an update of the IANA procedures for registration of Service Name and Transport protocol port numbers. Best Regards Magnus Westerlund Ursprungligt meddelande Ämne: 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 Datum: Tue, 18 Jan 2011 22:26:03 +0100 Från: The IESG iesg-secret...@ietf.org Till: IETF-Announce ietf-annou...@ietf.org Kopia: ts...@ietf.org ts...@ietf.org 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@ietf.org mailing lists by 2011-02-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
t.petch skrev 2011-01-21 12:43: I would like to see more clarity in 8.1 For assignments done through IETF-published RFCs, the Contact will be the IESG. in that I am unclear what IETF-published RFCs are; presumably that is Standards Track, BCP and Individual Submissions, but not Independent Submissions or IRTF RFC. I think that the terminology here should follow that of RFC4844 with a reference thereto. I guess we should use the IETF Stream, and I do agree that a reference for the definition of that should be included. Cheers Magnus Tom Petch - Original Message - From: Magnus Westerlund magnus.westerl...@ericsson.com To: apps-disc...@ietf.org; Internet Area int-a...@ietf.org; rai-disc...@ietf.org; ops-a...@ietf.org; SAAG s...@ieft.org Sent: Wednesday, January 19, 2011 9:30 AM Subject: [apps-discuss] Fwd: 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 Hi, I just want to make people aware of this IETF last call for an update of the IANA procedures for registration of Service Name and Transport protocol port numbers. Best Regards Magnus Westerlund Ursprungligt meddelande Ämne: 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 Datum: Tue, 18 Jan 2011 22:26:03 +0100 Från: The IESG iesg-secret...@ietf.org Till: IETF-Announce ietf-annou...@ietf.org Kopia: ts...@ietf.org ts...@ietf.org 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@ietf.org mailing lists by 2011-02-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss -- 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: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf