From magnus.westerlund@ericsson.com Tue Feb 1 02:10:59 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298453A6C40; Tue, 1 Feb 2011 02:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20WysXu9irDd; Tue, 1 Feb 2011 02:10:57 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 79BFD3A6C19; Tue, 1 Feb 2011 02:10:56 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-45-4d47dcf49eb6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.55.13987.4FCD74D4; Tue, 1 Feb 2011 11:14:12 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Tue, 1 Feb 2011 11:14:11 +0100 Message-ID: <4D47DCF2.1000200@ericsson.com> Date: Tue, 1 Feb 2011 11:14:10 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> In-Reply-To: <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IESG IESG , IETF discussion list , Paul Hoffman , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 10:11:00 -0000 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.westerlund@ericsson.com ---------------------------------------------------------------------- From paul.hoffman@vpnc.org Mon Jan 31 07:11:19 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E75B3A6B32; Mon, 31 Jan 2011 07:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.756 X-Spam-Level: X-Spam-Status: No, score=-101.756 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKwMntZxMrzm; Mon, 31 Jan 2011 07:11:13 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1EF243A6AC9; Mon, 31 Jan 2011 07:11:13 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0VFEQ3e066616 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 08:14:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D46D1D3.10701@vpnc.org> Date: Mon, 31 Jan 2011 07:14:27 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lars Eggert Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> In-Reply-To: <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Feb 2011 08:31:56 -0800 Cc: IESG IESG , tsvwg@ietf.org, IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:11:21 -0000 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. From paul.hoffman@vpnc.org Mon Jan 31 08:37:38 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7E33A67F0; Mon, 31 Jan 2011 08:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.755 X-Spam-Level: X-Spam-Status: No, score=-101.755 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbU4jGvOtuT4; Mon, 31 Jan 2011 08:37:37 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 096123A67B4; Mon, 31 Jan 2011 08:37:37 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0VGeTlB070327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 09:40:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D46E5FF.5040706@vpnc.org> Date: Mon, 31 Jan 2011 08:40:31 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Feb 2011 08:31:56 -0800 Cc: IESG IESG , tsvwg@ietf.org, IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:37:38 -0000 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. From fluffy@cisco.com Tue Feb 1 09:15:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BFB3A6DC9; Tue, 1 Feb 2011 09:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zji+QXaSv6ry; Tue, 1 Feb 2011 09:15:49 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CF91F3A67F9; Tue, 1 Feb 2011 09:15:49 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFLPR02rRN+J/2dsb2JhbAClB3OhV5shhVMEhROHEA Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 01 Feb 2011 17:19:07 +0000 Received: from sjc-vpn5-165.cisco.com (sjc-vpn5-165.cisco.com [10.21.88.165]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p11HJ6hE004674; Tue, 1 Feb 2011 17:19:06 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D46B3B9.4050804@ericsson.com> Date: Tue, 1 Feb 2011 12:19:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1082) Cc: IESG IESG , IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:15:50 -0000 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.=20 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.=20 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. > > >=20 > 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. >=20 > 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? From fluffy@cisco.com Tue Feb 1 09:16:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33A93A6E7F; Tue, 1 Feb 2011 09:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkusBUE52NnB; Tue, 1 Feb 2011 09:16:15 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 79EE63A6CC7; Tue, 1 Feb 2011 09:15:59 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANrOR02rRN+J/2dsb2JhbAClB3OhU5shAoVRBIUThxA Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 01 Feb 2011 17:19:16 +0000 Received: from sjc-vpn5-165.cisco.com (sjc-vpn5-165.cisco.com [10.21.88.165]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p11HJ6hF004674; Tue, 1 Feb 2011 17:19:16 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4D47DCF2.1000200@ericsson.com> Date: Tue, 1 Feb 2011 12:19:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <11676222-268E-4084-BF81-F49A5C0300D8@cisco.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1082) Cc: IESG IESG , IETF discussion list , Paul Hoffman , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:16:16 -0000 inline=20 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. >=20 > 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. >=20 > 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. >=20 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. >=20 > - 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.=20 > - 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 >=20 > 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.=20 >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From touch@isi.edu Tue Feb 1 09:36:36 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95CC3A6C00; Tue, 1 Feb 2011 09:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bMzGPtHlSja; Tue, 1 Feb 2011 09:36:35 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C066F3A6BFF; Tue, 1 Feb 2011 09:36:35 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p11HdFsa011189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 09:39:17 -0800 (PST) Message-ID: <4D484543.7010601@isi.edu> Date: Tue, 01 Feb 2011 09:39:15 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> <4D483C4F.3080507@vpnc.org> In-Reply-To: <4D483C4F.3080507@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Magnus Westerlund , IETF discussion list , "tsvwg@ietf.org" , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:36:37 -0000 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 From touch@isi.edu Tue Feb 1 09:46:23 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38883A6959; Tue, 1 Feb 2011 09:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.516 X-Spam-Level: X-Spam-Status: No, score=-104.516 tagged_above=-999 required=5 tests=[AWL=2.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzykfvE1q0Xx; Tue, 1 Feb 2011 09:46:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 5F17B3A6E88; Tue, 1 Feb 2011 09:46:17 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p11HnGxm001001 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 09:49:16 -0800 (PST) Message-ID: <4D48479C.3010104@isi.edu> Date: Tue, 01 Feb 2011 09:49:16 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> In-Reply-To: <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Magnus Westerlund , tsvwg@ietf.org, IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:46:23 -0000 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 From ned.freed@mrochek.com Tue Feb 1 08:43:32 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA59F3A6CCE; Tue, 1 Feb 2011 08:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leRcx-TZlFu2; Tue, 1 Feb 2011 08:43:30 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 6AE393A6959; Tue, 1 Feb 2011 08:43:29 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NXB18GGNGG00K6ZM@mauve.mrochek.com>; Tue, 1 Feb 2011 08:46:41 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NX5VCDTMLC007FL5@mauve.mrochek.com>; Tue, 1 Feb 2011 08:46:37 -0800 (PST) Message-id: <01NXB18EJ33U007FL5@mauve.mrochek.com> Date: Tue, 01 Feb 2011 08:38:25 -0800 (PST) From: Ned Freed Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP In-reply-to: "Your message dated Tue, 01 Feb 2011 11:14:10 +0100" <4D47DCF2.1000200@ericsson.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> To: Magnus Westerlund DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296575700; bh=o269w1zTK7aOX9kQ23i/8fAQOQyvZwGvUkNYqm4HA/E=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=KrQxLcfoCcHRQ0hmgv8/WNzHIxCR7VX/o86lKD6CqvrFe5YveRYEm44agdrEoCojm pkhRyIBs6ZXdGsY4uOB0dKasaqJcClREPTj03oK+SvJEK4jHOJ32OmrCVSfvnWt23d eWJKrsu8pbQiIMeo1qq5BxLeVtzzpVqExOTAncl0= X-Mailman-Approved-At: Tue, 01 Feb 2011 09:57:32 -0800 Cc: Paul Hoffman , IESG IESG , "tsvwg@ietf.org" , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 16:43:32 -0000 +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.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From ekr@rtfm.com Tue Feb 1 08:53:26 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997373A6E33; Tue, 1 Feb 2011 08:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.71 X-Spam-Level: X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R8BYMM-PU4v; Tue, 1 Feb 2011 08:53:24 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D352E3A6BFF; Tue, 1 Feb 2011 08:53:23 -0800 (PST) Received: by gxk27 with SMTP id 27so2961626gxk.31 for ; Tue, 01 Feb 2011 08:56:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.52.3 with SMTP id z3mr10888640agz.189.1296579400809; Tue, 01 Feb 2011 08:56:40 -0800 (PST) Received: by 10.90.116.7 with HTTP; Tue, 1 Feb 2011 08:56:40 -0800 (PST) In-Reply-To: <01NXB18EJ33U007FL5@mauve.mrochek.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> <01NXB18EJ33U007FL5@mauve.mrochek.com> Date: Tue, 1 Feb 2011 08:56:40 -0800 Message-ID: Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP From: Eric Rescorla To: ned+ietf@mauve.mrochek.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Feb 2011 09:57:32 -0800 Cc: Magnus Westerlund , "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 16:53:26 -0000 On Tue, Feb 1, 2011 at 8:38 AM, wrote: > +1 to everything Magnus says here. THis is exactly how I view the multipl= e 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. Sp= eaking > 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 - bu= t > rather to have proper checks and balances in the process itself. I believ= e 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 w= hich 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 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ned > >> 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 vers= ion 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 allocatio= n is fine. This seems fairly easy to deal with - first lets agree if partic= ular 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@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 > From paul.hoffman@vpnc.org Tue Feb 1 08:57:53 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F0A3A67F9; Tue, 1 Feb 2011 08:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.756 X-Spam-Level: X-Spam-Status: No, score=-101.756 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI7UzscUhO1j; Tue, 1 Feb 2011 08:57:53 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 14C8A3A6E4A; Tue, 1 Feb 2011 08:57:52 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p11H14Zr030532 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 10:01:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D483C4F.3080507@vpnc.org> Date: Tue, 01 Feb 2011 09:01:03 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> In-Reply-To: <4D47DCF2.1000200@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Feb 2011 09:57:32 -0800 Cc: "tsvwg@ietf.org" , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 16:57:53 -0000 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. From ekr@rtfm.com Tue Feb 1 09:57:17 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980BD3A6C95; Tue, 1 Feb 2011 09:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UpyzkJEFr6r; Tue, 1 Feb 2011 09:57:16 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 51E423A6BFA; Tue, 1 Feb 2011 09:57:16 -0800 (PST) Received: by gwb20 with SMTP id 20so2997944gwb.31 for ; Tue, 01 Feb 2011 10:00:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.91.20 with SMTP id o20mr11354328agb.27.1296583233379; Tue, 01 Feb 2011 10:00:33 -0800 (PST) Received: by 10.90.116.7 with HTTP; Tue, 1 Feb 2011 10:00:33 -0800 (PST) In-Reply-To: <4D484543.7010601@isi.edu> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> <4D483C4F.3080507@vpnc.org> <4D484543.7010601@isi.edu> Date: Tue, 1 Feb 2011 10:00:33 -0800 Message-ID: Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP From: Eric Rescorla To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Feb 2011 09:57:32 -0800 Cc: Magnus Westerlund , "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:57:17 -0000 On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch wrote: > To clarify some of this discussion, providing some context that might be > useful: > > 1) the current doc already explicitly states the procedures for assignmen= t > 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 appear= s > to be a point of confusion, I'll quote it directly: > > =A0 o =A0Ports in the User Ports range (1024-49151) are available for > =A0 =A0 =A0assignment through IANA, and MAY be used as service identifier= s > =A0 =A0 =A0upon successful assignment. =A0Because assigning a port number= for a > =A0 =A0 =A0specific application consumes a fraction of the shared resourc= e > =A0 =A0 =A0that is the port number registry, IANA will require the reques= ter > =A0 =A0 =A0to document the intended use of the port number. =A0This > =A0 =A0 =A0documentation will be input to the "Expert Review" procedure > =A0 =A0 =A0[RFC5226], by which IANA will have a technical expert review t= he > =A0 =A0 =A0request to determine whether to grant the assignment. =A0The > =A0 =A0 =A0submitted documentation MUST explain why using a port number i= n > =A0 =A0 =A0the Dynamic Ports range is unsuitable for the given applicatio= n. > =A0 =A0 =A0Ports in the User Ports range may also be assigned under the "= IETF > =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^ > =A0 =A0 =A0Review" or "IESG Approval" procedures [RFC5226], which is how = most > =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^ > =A0 =A0 =A0assignments for IETF protocols are handled. > =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For the purposes of clarification, then, this document has no impact whatso= ever on ports assigned through the IESG process? I.e., if my WG submits a propos= ed standard document to the IESG and it asks for two ports, I'm not going to g= et pushback based on the claim that this document imposes a presumption that that's wrong? -Ekr From touch@isi.edu Tue Feb 1 10:24:33 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271023A6FAC; Tue, 1 Feb 2011 10:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.555 X-Spam-Level: X-Spam-Status: No, score=-104.555 tagged_above=-999 required=5 tests=[AWL=2.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGLC38yOJpDE; Tue, 1 Feb 2011 10:24:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 241723A6FA7; Tue, 1 Feb 2011 10:24:32 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p11IQs2C009133 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 10:26:54 -0800 (PST) Message-ID: <4D48506E.2020200@isi.edu> Date: Tue, 01 Feb 2011 10:26:54 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eric Rescorla Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> <4D483C4F.3080507@vpnc.org> <4D484543.7010601@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Magnus Westerlund , "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:24:33 -0000 On 2/1/2011 10:00 AM, Eric Rescorla wrote: > On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch 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 From touch@isi.edu Tue Feb 1 10:35:31 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6073A6F64; Tue, 1 Feb 2011 10:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.573 X-Spam-Level: X-Spam-Status: No, score=-104.573 tagged_above=-999 required=5 tests=[AWL=2.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2-1xWR5IDQ9; Tue, 1 Feb 2011 10:35:31 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 02AA23A6844; Tue, 1 Feb 2011 10:35:30 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p11Ib5TE011207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 10:37:05 -0800 (PST) Message-ID: <4D4852D1.8060106@isi.edu> Date: Tue, 01 Feb 2011 10:37:05 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eric Rescorla Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> <4D483C4F.3080507@vpnc.org> <4D484543.7010601@isi.edu> <4D48506E.2020200@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Magnus Westerlund , "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:35:31 -0000 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 From lear@cisco.com Tue Feb 1 11:08:06 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F843A6FC4; Tue, 1 Feb 2011 11:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.236 X-Spam-Level: X-Spam-Status: No, score=-110.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-fpngPPzXeL; Tue, 1 Feb 2011 11:08:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F2A663A6E88; Tue, 1 Feb 2011 11:08:04 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJbpR02Q/khMgWdsb2JhbACEF6ByFgEWIiShaYpjkEKBJ4M3dQSMIw Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Feb 2011 19:11:22 +0000 Received: from dhcp-10-61-103-43.cisco.com (dhcp-10-61-103-43.cisco.com [10.61.103.43]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p11JBLms002380; Tue, 1 Feb 2011 19:11:21 GMT Message-ID: <4D485ACE.4000208@cisco.com> Date: Tue, 01 Feb 2011 20:11:10 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ned Freed Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> <01NXB18EJ33U007FL5@mauve.mrochek.com> In-Reply-To: <01NXB18EJ33U007FL5@mauve.mrochek.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund , "tsvwg@ietf.org" , IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:08:06 -0000 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. From hartmans@mit.edu Tue Feb 1 11:11:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62B03A700B; Tue, 1 Feb 2011 11:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYjl9nIl3w1Y; Tue, 1 Feb 2011 11:11:45 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 7EEE33A6FFB; Tue, 1 Feb 2011 11:11:42 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 66EC120289; Tue, 1 Feb 2011 14:12:58 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F0039432C; Tue, 1 Feb 2011 14:14:47 -0500 (EST) From: Sam Hartman To: Joe Touch Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> Date: Tue, 01 Feb 2011 14:14:47 -0500 In-Reply-To: <4D421795.70505@isi.edu> (Joe Touch's message of "Thu, 27 Jan 2011 17:10:45 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tsvwg@ietf.org, Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:11:50 -0000 >>>>> "Joe" == Joe Touch 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. From touch@isi.edu Tue Feb 1 11:22:34 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E103A6A7A; Tue, 1 Feb 2011 11:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDd76EHZeKpF; Tue, 1 Feb 2011 11:22:34 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F00BD3A6FDF; Tue, 1 Feb 2011 11:22:33 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p11JPWS4003535 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 11:25:33 -0800 (PST) Message-ID: <4D485E2B.4080201@isi.edu> Date: Tue, 01 Feb 2011 11:25:31 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sam Hartman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:22:35 -0000 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 From hartmans@mit.edu Tue Feb 1 12:08:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14E13A6E78; Tue, 1 Feb 2011 12:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRT9QzOE690M; Tue, 1 Feb 2011 12:08:50 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id DB3043A6E58; Tue, 1 Feb 2011 12:08:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1C6D72028C; Tue, 1 Feb 2011 15:10:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 42B32432C; Tue, 1 Feb 2011 15:12:01 -0500 (EST) From: Sam Hartman To: Joe Touch Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D485E2B.4080201@isi.edu> Date: Tue, 01 Feb 2011 15:12:01 -0500 In-Reply-To: <4D485E2B.4080201@isi.edu> (Joe Touch's message of "Tue, 01 Feb 2011 11:25:31 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tsvwg@ietf.org, Paul Hoffman , IESG IESG , Sam Hartman , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:08:50 -0000 >>>>> "Joe" == Joe Touch 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. From touch@isi.edu Tue Feb 1 13:03:42 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646D73A6C0E; Tue, 1 Feb 2011 13:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.609 X-Spam-Level: X-Spam-Status: No, score=-104.609 tagged_above=-999 required=5 tests=[AWL=1.990, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9FPqeMp3r-e; Tue, 1 Feb 2011 13:03:41 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 415FF3A6B4F; Tue, 1 Feb 2011 13:03:41 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p11L6PVf014294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 1 Feb 2011 13:06:25 -0800 (PST) Message-ID: <4D4875D1.6060106@isi.edu> Date: Tue, 01 Feb 2011 13:06:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sam Hartman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D485E2B.4080201@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:03:42 -0000 On 2/1/2011 12:12 PM, Sam Hartman wrote: >>>>>> "Joe" == Joe Touch 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 From ekr@rtfm.com Tue Feb 1 10:26:22 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6665D3A6844; Tue, 1 Feb 2011 10:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yFUTHsYt320; Tue, 1 Feb 2011 10:26:20 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 546AC3A6FC3; Tue, 1 Feb 2011 10:26:15 -0800 (PST) Received: by gwb20 with SMTP id 20so3012362gwb.31 for ; Tue, 01 Feb 2011 10:29:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.96.1 with SMTP id t1mr3929053agb.54.1296584972511; Tue, 01 Feb 2011 10:29:32 -0800 (PST) Received: by 10.90.116.7 with HTTP; Tue, 1 Feb 2011 10:29:31 -0800 (PST) In-Reply-To: <4D48506E.2020200@isi.edu> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> <4D483C4F.3080507@vpnc.org> <4D484543.7010601@isi.edu> <4D48506E.2020200@isi.edu> Date: Tue, 1 Feb 2011 10:29:31 -0800 Message-ID: Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP From: Eric Rescorla To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Feb 2011 13:12:40 -0800 Cc: Magnus Westerlund , "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 18:26:22 -0000 On Tue, Feb 1, 2011 at 10:26 AM, Joe Touch wrote: > > > On 2/1/2011 10:00 AM, Eric Rescorla wrote: >> >> On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch =A0wrote: >>> >>> To clarify some of this discussion, providing some context that might b= e >>> 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 i= s >>> a >>> valid path for assignment, distinct from Expert Review. Since that >>> appears >>> to be a point of confusion, I'll quote it directly: >>> >>> =A0 o =A0Ports in the User Ports range (1024-49151) are available for >>> =A0 =A0 =A0assignment through IANA, and MAY be used as service identifi= ers >>> =A0 =A0 =A0upon successful assignment. =A0Because assigning a port numb= er for a >>> =A0 =A0 =A0specific application consumes a fraction of the shared resou= rce >>> =A0 =A0 =A0that is the port number registry, IANA will require the requ= ester >>> =A0 =A0 =A0to document the intended use of the port number. =A0This >>> =A0 =A0 =A0documentation will be input to the "Expert Review" procedure >>> =A0 =A0 =A0[RFC5226], by which IANA will have a technical expert review= the >>> =A0 =A0 =A0request to determine whether to grant the assignment. =A0The >>> =A0 =A0 =A0submitted documentation MUST explain why using a port number= in >>> =A0 =A0 =A0the Dynamic Ports range is unsuitable for the given applicat= ion. >>> =A0 =A0 =A0Ports in the User Ports range may also be assigned under the= "IETF >>> =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^ >>> =A0 =A0 =A0Review" or "IESG Approval" procedures [RFC5226], which is ho= w most >>> =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^ >>> =A0 =A0 =A0assignments for IETF protocols are handled. >>> =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> 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 t= o >> get >> pushback based on the claim that this document imposes a presumption tha= t >> that's wrong? > > The ONLY impact is in the format of information required for an assignmen= t. > > (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 From ekr@rtfm.com Tue Feb 1 13:08:57 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD753A6C7F; Tue, 1 Feb 2011 13:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9-6ndLx3V91; Tue, 1 Feb 2011 13:08:55 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 2A1D83A6C75; Tue, 1 Feb 2011 13:08:55 -0800 (PST) Received: by gxk27 with SMTP id 27so3090225gxk.31 for ; Tue, 01 Feb 2011 13:12:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.52.3 with SMTP id z3mr11221374agz.189.1296594730870; Tue, 01 Feb 2011 13:12:10 -0800 (PST) Received: by 10.90.116.7 with HTTP; Tue, 1 Feb 2011 13:12:10 -0800 (PST) In-Reply-To: <4D47DCF2.1000200@ericsson.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com> Date: Tue, 1 Feb 2011 13:12:10 -0800 Message-ID: Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP From: Eric Rescorla To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Feb 2011 13:12:40 -0800 Cc: Paul Hoffman , IESG IESG , "tsvwg@ietf.org" , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:08:57 -0000 On Tue, Feb 1, 2011 at 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 i= ssue I am concerned with. Is allocating a second port for the secure versio= n 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 particul= ar 2nd port for secure version is a reason to reject requests or not then s= ee 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From magnus.westerlund@ericsson.com Wed Feb 2 01:13:17 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA1E3A7125; Wed, 2 Feb 2011 01:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXYijZUVqzqd; Wed, 2 Feb 2011 01:13:15 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CB4833A6B9C; Wed, 2 Feb 2011 01:13:14 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-ba-4d4920f08b25 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 12.9B.13987.0F0294D4; Wed, 2 Feb 2011 10:16:33 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Feb 2011 10:16:32 +0100 Message-ID: <4D4920F0.1070204@ericsson.com> Date: Wed, 2 Feb 2011 10:16:32 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> In-Reply-To: <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IESG IESG , IETF discussion list , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 09:13:17 -0000 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.westerlund@ericsson.com ---------------------------------------------------------------------- From daedulus@btconnect.com Wed Feb 2 04:23:55 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2141A3A6C14; Wed, 2 Feb 2011 04:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIiqJFOUmCcU; Wed, 2 Feb 2011 04:23:54 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 485413A7154; Wed, 2 Feb 2011 04:23:52 -0800 (PST) Received: from host81-152-46-124.range81-152.btcentralplus.com (HELO pc6) ([81.152.46.124]) by c2beaomr10.btconnect.com with SMTP id BNW94587; Wed, 02 Feb 2011 12:26:53 +0000 (GMT) Message-ID: <007101cbc2cb$8ee4cca0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joe Touch" , "Paul Hoffman" References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com><4D483C4F.3080507@vpnc.org> <4D484543.7010601@isi.edu> Subject: Re: Last Call: (Internet AssignedNumbers Authority (IANA) Proceduresfor the Management of the Service Nameand Transport Protocol Port Number Registry) to BCP Date: Wed, 2 Feb 2011 12:22:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D494D8C.00C8, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4D494D8E.011B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false X-Mailman-Approved-At: Wed, 02 Feb 2011 05:43:14 -0800 Cc: Magnus Westerlund , IESG IESG , IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 12:23:55 -0000 ----- Original Message ----- From: "Joe Touch" To: "Paul Hoffman" "IETF discussion list" ; ; "IESG IESG" Sent: Tuesday, February 01, 2011 6:39 PM > 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. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Joe I think that it is a point of confusion because the text is confused (well, it confuses me:-(. If you know in advance that there are two independent paths that can be taken, then you can read that meaning into it. If you do not know that, then having read "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" then it is obvious that Expert Review always happens, even when a later sentence talks about 'may also be assigned'. To make the two paths clear, the text should be reordered eg 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. For most IETF protocols, ports in the User Ports range will be assigned under the "IETF Review" or "IESG Approval" procedures [RFC5226] and no further documentation is required. Where these procedures do not apply, then the requester must input the documentation 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. Tom Petch > > 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 From touch@isi.edu Wed Feb 2 11:36:11 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1A63A6D51; Wed, 2 Feb 2011 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.303 X-Spam-Level: X-Spam-Status: No, score=-104.303 tagged_above=-999 required=5 tests=[AWL=1.696, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R6-fpDtH51i; Wed, 2 Feb 2011 11:36:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id B03943A6C41; Wed, 2 Feb 2011 11:36:10 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p12JcaEw028333 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 2 Feb 2011 11:38:36 -0800 (PST) Message-ID: <4D49B2BC.6050901@isi.edu> Date: Wed, 02 Feb 2011 11:38:36 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "t.petch" Subject: Re: Last Call: (Internet AssignedNumbers Authority (IANA) Proceduresfor the Management of the Service Nameand Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com><4D483C4F.3080507@vpnc.org> <4D484543.7010601@isi.edu> <007101cbc2cb$8ee4cca0$4001a8c0@gateway.2wire.net> In-Reply-To: <007101cbc2cb$8ee4cca0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Magnus Westerlund , tsvwg@ietf.org, Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:36:11 -0000 Hi, Tom, Thanks - yes, I can see where reordering the sentences in that paragraph could make the issue much clearer. I'll do that in the pending update ... Joe On 2/2/2011 3:22 AM, t.petch wrote: > ----- Original Message ----- > From: "Joe Touch" > To: "Paul Hoffman" > "IETF discussion list";; "IESG IESG" > > Sent: Tuesday, February 01, 2011 6:39 PM > >> 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. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Joe > > I think that it is a point of confusion because the text is confused > (well, it confuses me:-(. > > If you know in advance that there are two independent paths that > can be taken, then you can read that meaning into it. > > If you do not know that, then having read > "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" > > then it is obvious that Expert Review always happens, even when a later > sentence talks about 'may also be assigned'. > > To make the two paths clear, the text should be reordered eg > > 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. > > For most IETF protocols, ports in the User Ports range will be assigned under > the "IETF > Review" or "IESG Approval" procedures [RFC5226] and no further > documentation is required. > > Where these procedures do not apply, then the requester must > input the documentation 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. > > Tom Petch > > >> >> 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 From cbenson@adax.com Mon Feb 7 13:21:40 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835BF3A6EFE; Mon, 7 Feb 2011 13:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEz9xHPKI7II; Mon, 7 Feb 2011 13:21:37 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 844EE3A6E62; Mon, 7 Feb 2011 13:21:37 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id A92361209B4; Mon, 7 Feb 2011 13:21:42 -0800 (PST) Received: by adax (Postfix, from userid 243) id DCA758ED57; Mon, 7 Feb 2011 13:24:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id D536C8ED52; Mon, 7 Feb 2011 13:24:52 -0800 (PST) Date: Mon, 7 Feb 2011 13:24:52 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Sam Hartman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP In-Reply-To: Message-ID: References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IESG IESG , Paul Hoffman , IETF discussion list , tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:21:40 -0000 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. From jmpolk@cisco.com Mon Feb 7 19:11:45 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC26C3A6BD9 for ; Mon, 7 Feb 2011 19:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGiOXZzFRYFk for ; Mon, 7 Feb 2011 19:11:45 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 112293A6BD8 for ; Mon, 7 Feb 2011 19:11:45 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJtCUE2rR7Hu/2dsb2JhbAClKHOfeZsahVoEhHo Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Feb 2011 03:11:50 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p183BoXh025565 for ; Tue, 8 Feb 2011 03:11:50 GMT Message-Id: <201102080311.p183BoXh025565@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Feb 2011 21:10:53 -0600 To: tsvwg From: "James M. Polk" Subject: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 03:11:46 -0000 TSVWG I am starting the WGLC for "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)" http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs feel the WG has reviewed the draft and reached consensus to progress towards the ADs with the goal of becoming a proposed standard (PS) RFC. The chairs require substantive feedback from the WG regarding this draft before consensus can be called. I will be the document shepherd. James TSVWG chair From jmpolk@cisco.com Mon Feb 7 19:11:47 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4F73A7011 for ; Mon, 7 Feb 2011 19:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.421 X-Spam-Level: X-Spam-Status: No, score=-110.421 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVjd-TdftdLt for ; Mon, 7 Feb 2011 19:11:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7C7A53A6BD8 for ; Mon, 7 Feb 2011 19:11:46 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIxDUE2rR7H+/2dsb2JhbAClKHOgBJsahVoEhHo Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Feb 2011 03:11:52 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p183BpvU025288 for ; Tue, 8 Feb 2011 03:11:52 GMT Message-Id: <201102080311.p183BpvU025288@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Feb 2011 21:07:52 -0600 To: tsvwg From: "James M. Polk" Subject: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 03:11:47 -0000 TSVWG I am starting the WGLC for "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration" http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/ this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs feel the WG has reviewed the draft and reached consensus to progress towards the ADs with the goal of becoming a proposed standard (PS) RFC. The chairs require substantive feedback from the WG regarding this draft before consensus can be called. I will be the document shepherd. James TSVWG chair From bidulock@openss7.org Mon Feb 7 19:51:54 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C8C3A69F9 for ; Mon, 7 Feb 2011 19:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yJN4EXgDni4 for ; Mon, 7 Feb 2011 19:51:53 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 0F2B43A6C06 for ; Mon, 7 Feb 2011 19:51:52 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p183ptwR020771; Mon, 7 Feb 2011 20:51:55 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p183ptKx013633; Mon, 7 Feb 2011 20:51:55 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p183psXX013632; Mon, 7 Feb 2011 20:51:54 -0700 Date: Mon, 7 Feb 2011 20:51:54 -0700 From: "Brian F. G. Bidulock" To: "James M. Polk" Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Message-ID: <20110208035154.GA13501@openss7.org> Mail-Followup-To: "James M. Polk" , tsvwg References: <201102080311.p183BoXh025565@sj-core-5.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201102080311.p183BoXh025565@sj-core-5.cisco.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 03:51:54 -0000 James, The intended status of the document is INFORMATIONAL not PS. Was that just a typo? If not, my first comment is that any RFC issued for C-language APIs must be INFORMATIONAL and not PS. --brian James M. Polk wrote: (Mon, 07 Feb 2011 21:10:53) > TSVWG > > I am starting the WGLC for > > "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)" > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ > > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs > feel the WG has reviewed the draft and reached consensus to progress > towards the ADs with the goal of becoming a proposed standard (PS) RFC. > > The chairs require substantive feedback from the WG regarding this draft > before consensus can be called. > > I will be the document shepherd. > > James > TSVWG chair > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From jmpolk@cisco.com Mon Feb 7 20:04:47 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F0F3A6C04 for ; Mon, 7 Feb 2011 20:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcQYzNR0kaT2 for ; Mon, 7 Feb 2011 20:04:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8D3D03A6ACE for ; Mon, 7 Feb 2011 20:04:46 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssFAFlPUE2rR7H+/2dsb2JhbACXDI4cc6A3myCFWgSEeg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Feb 2011 04:04:52 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1844pFu020062; Tue, 8 Feb 2011 04:04:52 GMT Message-Id: <201102080404.p1844pFu020062@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 07 Feb 2011 22:04:50 -0600 To: bidulock@openss7.org From: "James M. Polk" Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started In-Reply-To: <20110208035154.GA13501@openss7.org> References: <201102080311.p183BoXh025565@sj-core-5.cisco.com> <20110208035154.GA13501@openss7.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 04:04:47 -0000 At 09:51 PM 2/7/2011, Brian F. G. Bidulock wrote: >James, > >The intended status of the document is INFORMATIONAL not PS. %*(&^%^%, *$%*&%.... and %^*&%*&^ grrrrrrrrrrrrr!!!!! I messed up obviously. That ought to teach me *not* to cut and paste (from the stream reset WGLC) without verifying. grrrrrrrrrrrr!! I apologize for the boneheaded mistake. I own it. This doc is INFORMATIONAL. err, thanks Brian for pointing this out so quickly. James with my chair hat on (covering my face in embarrassment!) >Was that just a typo? > >If not, my first comment is that any RFC issued for C-language >APIs must be INFORMATIONAL and not PS. > >--brian > >James M. Polk wrote: (Mon, 07 Feb 2011 21:10:53) > > TSVWG > > > > I am starting the WGLC for > > > > "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)" > > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ > > > > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs > > feel the WG has reviewed the draft and reached consensus to progress > > towards the ADs with the goal of becoming a proposed standard (PS) RFC. > > > > The chairs require substantive feedback from the WG regarding this draft > > before consensus can be called. > > > > I will be the document shepherd. > > > > James > > TSVWG chair > > > >-- >Brian F. G. Bidulock >bidulock@openss7.org >http://www.openss7.org/ From touch@isi.edu Mon Feb 7 20:32:11 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FA33A6C86; Mon, 7 Feb 2011 20:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYpe0KARzWUU; Mon, 7 Feb 2011 20:32:10 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 39D393A6BDF; Mon, 7 Feb 2011 20:32:10 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p184VWx2008295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 7 Feb 2011 20:31:47 -0800 (PST) Message-ID: <4D50C724.9040402@isi.edu> Date: Mon, 07 Feb 2011 20:31:32 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Chris Benson Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p184VWx2008295 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IESG IESG , IETF discussion list , Sam Hartman , tsvwg@ietf.org, Paul Hoffman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 04:32:11 -0000 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. From ietfc@btconnect.com Tue Feb 8 03:45:54 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894553A7120 for ; Tue, 8 Feb 2011 03:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX9kmNJlnAt3 for ; Tue, 8 Feb 2011 03:45:53 -0800 (PST) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id 663C93A711D for ; Tue, 8 Feb 2011 03:45:52 -0800 (PST) Received: from host86-156-136-65.range86-156.btcentralplus.com (HELO pc6) ([86.156.136.65]) by c2bthomr10.btconnect.com with SMTP id BRB88452; Tue, 08 Feb 2011 11:45:55 +0000 (GMT) Message-ID: <019c01cbc77c$cf119820$4001a8c0@gateway.2wire.net> From: "t.petch" To: "tsvwg" , "James M. Polk" References: <201102080311.p183BpvU025288@sj-core-2.cisco.com> Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started Date: Tue, 8 Feb 2011 11:41:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D512CE6.01E8, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4D512CF6.0267,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 11:45:54 -0000 I last posted a comment on this 15th january, part of an ongoing, for several months, discussion about race conditions. Given the seeming difficulty in getting this right, I do not think this I-D yet ready to progress (ie until this is resolved, I don't want to know what other problems I have with it:-) Tom Petch ----- Original Message ----- From: "James M. Polk" To: "tsvwg" Sent: Tuesday, February 08, 2011 4:07 AM Subject: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started > TSVWG > > I am starting the WGLC for > > "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration" > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/ > > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs > feel the WG has reviewed the draft and reached consensus to progress > towards the ADs with the goal of becoming a proposed standard (PS) RFC. > > The chairs require substantive feedback from the WG regarding this > draft before consensus can be called. > > I will be the document shepherd. > > James > TSVWG chair > From huitema@microsoft.com Tue Feb 8 12:41:32 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326673A6859; Tue, 8 Feb 2011 12:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8r6ecTio7+G; Tue, 8 Feb 2011 12:41:31 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 270773A6835; Tue, 8 Feb 2011 12:41:30 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 8 Feb 2011 12:41:37 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 8 Feb 2011 12:41:37 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.204]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 8 Feb 2011 12:41:37 -0800 From: Christian Huitema To: Chris Benson , Sam Hartman Subject: RE: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Topic: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Index: AQHLx65uYHyiMSXjuU2y+c+m+OGflZP4EPgQ Date: Tue, 8 Feb 2011 20:41:36 +0000 Message-ID: References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 08 Feb 2011 13:20:25 -0800 Cc: "tsvwg@ietf.org" , IETF discussion list , IESG IESG , Paul Hoffman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 20:41:32 -0000 > I don't see that "public identity" (of expert reviewers) is required for = "interactive discussion". =20 > Or would anonymous interaction fail a Turing test of some kind? Public identity is required for reviewer accountability. It is easy to imag= ine how withholding registration of some required numbers may delay a compe= titor's products. The best protection against shade is sunlight. -- Christian Huitema From randall@lakerest.net Tue Feb 8 14:13:54 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0FC3A6856 for ; Tue, 8 Feb 2011 14:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcij7yJgoOne for ; Tue, 8 Feb 2011 14:13:53 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 870BD3A6884 for ; Tue, 8 Feb 2011 14:13:52 -0800 (PST) Received: from [192.168.2.156] (pool-96-249-203-135.snfcca.dsl-w.verizon.net [96.249.203.135]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p18MDnRe016340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Feb 2011 17:13:51 -0500 (EST) (envelope-from randall@lakerest.net) Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Randy Stewart X-Priority: 3 In-Reply-To: <019c01cbc77c$cf119820$4001a8c0@gateway.2wire.net> Date: Tue, 8 Feb 2011 17:13:43 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6D33ABED-D082-4D18-AA4F-2EFD36826DF9@lakerest.net> References: <201102080311.p183BpvU025288@sj-core-2.cisco.com> <019c01cbc77c$cf119820$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1082) Cc: "James M. Polk" , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:13:54 -0000 Tom: I held off adding your comments.. which I plan on doing as part of WGLC comments.... Spinning the document endlessly over and over (I had already spinned it once).. with a few changes did not seem the right course.. instead I would like to collect all comments and do one more spin. And you are of course always welcome to send suggested text in your comments ;-) R On Feb 8, 2011, at 5:41 AM, t.petch wrote: > I last posted a comment on this 15th january, part of an > ongoing, for several months, discussion about race > conditions. Given the seeming difficulty in getting this > right, I do not think this I-D yet ready to progress (ie > until this is resolved, I don't want to know what other > problems I have with it:-) > > Tom Petch > > ----- Original Message ----- > From: "James M. Polk" > To: "tsvwg" > Sent: Tuesday, February 08, 2011 4:07 AM > Subject: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started > > >> TSVWG >> >> I am starting the WGLC for >> >> "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration" >> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/ >> >> this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs >> feel the WG has reviewed the draft and reached consensus to progress >> towards the ADs with the goal of becoming a proposed standard (PS) RFC. >> >> The chairs require substantive feedback from the WG regarding this >> draft before consensus can be called. >> >> I will be the document shepherd. >> >> James >> TSVWG chair >> > ----- Randall Stewart randall@lakerest.net From bob.hinden@gmail.com Tue Feb 8 22:38:41 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6CF3A6917; Tue, 8 Feb 2011 22:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlN4hHyiCsXR; Tue, 8 Feb 2011 22:38:39 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id A76B53A6900; Tue, 8 Feb 2011 22:38:39 -0800 (PST) Received: by pzk5 with SMTP id 5so1631163pzk.31 for ; Tue, 08 Feb 2011 22:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=h94Jts137J/3ATEjb2Xg0inTmBUVZwQeIG1S3cFtB/Q=; b=KaSVk8bz2bNVBQRLup2zgw09DjTQj9ZVXu8LfdgMvMSIrUWIuyej7H1U/865/B2N6V 8XY7/AixDhoXQLQk3p7SnU7g8xHzwuZdll71Uyd8wlMj3B96l6euMuR9FPVWbFAgidIF 2gFtokSl/LzyA14aA6PDhcOZmUIoJZ4QVjVXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=YqBG1fhzd1vifZjZ6IPP/r3UvkowGcBiYaCunxewKxd91YgBNl2pp7LmOv6tNbtp+G wUj6AMDpBoATrQYWjg8aCl4Dyn7VS7O/vXP0rUUTM+dem+oNxrkmbKMKPkuDb02tSqhA jlXePY9XLAMz02Qr1Vnam7GZWu10ACAnezBIg= Received: by 10.142.173.8 with SMTP id v8mr17884190wfe.397.1297233526534; Tue, 08 Feb 2011 22:38:46 -0800 (PST) Received: from [10.104.74.0] ([62.50.232.90]) by mx.google.com with ESMTPS id w42sm1389753wfh.3.2011.02.08.22.38.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Feb 2011 22:38:44 -0800 (PST) Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Wed, 9 Feb 2011 07:38:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> To: Christian Huitema X-Mailer: Apple Mail (2.1082) Cc: "tsvwg@ietf.org" , Bob Hinden , Paul Hoffman , IESG IESG , Sam Hartman , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 06:38:41 -0000 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". =20 >> Or would anonymous interaction fail a Turing test of some kind? >=20 > 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 >=20 > -- Christian Huitema >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From randall@lakerest.net Wed Feb 9 08:18:52 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47173A63EC for ; Wed, 9 Feb 2011 08:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nha650WWUBDx for ; Wed, 9 Feb 2011 08:18:51 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id DD4063A6866 for ; Wed, 9 Feb 2011 08:18:50 -0800 (PST) Received: from [10.193.34.57] ([12.133.183.34]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p19GImsh057115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Feb 2011 11:18:50 -0500 (EST) (envelope-from randall@lakerest.net) Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-09.txt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Randy Stewart X-Priority: 3 In-Reply-To: <00a801cbb4aa$544a8140$4001a8c0@gateway.2wire.net> Date: Wed, 9 Feb 2011 11:18:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <86BC9A07-C996-4E88-B2DF-1E42B39CDDD7@lakerest.net> References: <20101129173002.3461.46301.idtracker@localhost> <005501cb9138$122c99a0$4001a8c0@gateway.2wire.net> <2BA83253-C026-4A93-92D7-64C0324CC421@lakerest.net> <017801cb917c$08d462e0$4001a8c0@gateway.2wire.net> <8C635E3F-12CA-4EA1-9C80-33D3FFB2E393@lakerest.net> <01c001cb9311$1a274760$4001a8c0@gateway.2wire.net> <971CDA6A-93A2-40D2-86E9-7956C5A7BCF3@lakerest.net> <00a801cbb4aa$544a8140$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1082) Cc: Michael Tuexen , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:18:52 -0000 Tom: Just to let you know I did NOT forget about this... Here is the text = that is waiting in the xml for the -10 revision: *********************************************************** When a peer endpoint requests a Incoming SSN Reset Request it is possible that the local endpoint has just sent an Outgoing SSN Reset Request on the same stream and has not yet received a response. In such a case the local endpoint MUST do the following: 1) If the stream reset overlaps the outstanding request completely respond to the requestor with an acknowledgment indicating that there was 'Nothing to do'. 2) Otherwise process the stream reset request normally responding to the requestor with an acknowledgment. It is also possible that the Incoming request will arrive after the Outgoing SSN Reset Request just completed. In such a case the local endpoint MUST do the following: 1) If the stream reset overlaps the outstanding request completely all of the streams being requested will be already set to 0. If so, the local endpoint SHOULD send back a Stream Reset Response with the success code "Nothing to do". 2) Otherwise process the stream reset request normally responding to the requestor an acknowledgment. Note that in either race condition the local endpoint could optionally also perform the reset. This would result in streams that are already at sequence 0 being reset again to 0 which would cause no harm to the application but will add an extra message to the network. Note also that in any of the race conditions listed above the receiver MUST NOT send more than one response. In other words two responses MUST NOT be sent for the same request. ******************************************************************* When we get any other comments after LC I will issue the updated draft = with the above... If you would like further changes or this does not satisfy your comments = below let me know.. you can even send suggested text :-) Best wishes R On Jan 15, 2011, at 6:49 AM, t.petch wrote: > I like the change to 5.2.3 but think that it needs to go further. >=20 > -08 split out two cases, >=20 > Incoming SSN Reset Request received but no response yet to the = Outgoing request > Incoming SSN Reset Request received after response to the Outgoing = request >=20 > assuming that the Incoming and Outgoing requests have overlapping = stream > numbers. >=20 > -09 subdivides the first case into overlaps completely and overlaps = partially > but > I think that the second case is also in need of subdivision in the = same way. >=20 > And, a point of clarification, in any of the four cases, is it = required to send > just > the one response, ie you cannot send two responses in the partial = overlap case, > one saying no-op and the will do (or won't do!)? >=20 >=20 > Tom Petch >=20 ----- Randall Stewart randall@lakerest.net From chris.newman@oracle.com Wed Feb 9 18:12:15 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DBD3A682D; Wed, 9 Feb 2011 18:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.05 X-Spam-Level: X-Spam-Status: No, score=-104.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVW+bn-t9ZdI; Wed, 9 Feb 2011 18:12:14 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 5756C3A6826; Wed, 9 Feb 2011 18:12:14 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p1A2CNED010121; Thu, 10 Feb 2011 02:12:24 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id p1A2CNAY002395; Wed, 9 Feb 2011 18:12:23 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=utf-8; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.03 64bit (built Feb 6 2011)) with ESMTPSA id <0LGD00C4NQ4JD700@gotmail.sfbay.sun.com>; Wed, 09 Feb 2011 18:12:22 -0800 (PST) Date: Wed, 09 Feb 2011 18:12:18 -0800 From: Chris Newman To: Magnus Westerlund , tls@ietf.org Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) Message-id: In-reply-to: <4CD76B1B.5030308@ericsson.com> References: <4CD76B1B.5030308@ericsson.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-transfer-encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Feb 2011 03:00:39 -0800 Cc: tsvwg , Paul Hoffman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:12:15 -0000 I know I'm very late on this topic, but my position differs from others so=20 I'll comment. I can not deny that separate-port for SSL is simpler to implement on the=20 server side (having done both). Since the odds of security bugs increases=20 with the amount of code, I must conclude that separate-port SSL is more=20 secure for _implementers_ and _implementations_ for that reason alone. However, I believe STARTTLS is more secure for _operators_ and=20 _administrators_. The separate port model creates an illusion that there is = a "secure" and "insecure" variant of the protocol and that a single=20 firewall setting magically makes the application secure. In general, this=20 is not true. Most servers have several security settings and the default=20 settings have to compromise between common practice, secure-by-default=20 practice, deployability, management complexity and usability. There is, in=20 general, no way to make a server installation secure for a given site other = than to understand the security settings that server provides and set them=20 properly. A protocol that uses STARTTLS thus has the advantage of forcing the=20 administrator/operator to look at the server's security settings to make=20 the installation secure, thus increasing the odds of success relative to=20 the separate-port model where an administrator might falsely assume they're = done after blocking the non-SSL port. While I think the judgment call is close for separate-port-SSL-vs-STARTTLS, = I prefer STARTTLS weighing all the factors. And for the record I'm responsible for TLS integration into a server=20 product and maintain all the relevant code and find STARTTLS maintenance=20 annoying. I'm also author of RFC 2595, so perhaps that balances out my bias = as an implementer. ;-) It's also my opinion that a high quality client should use a "latched"=20 model by default. If the client ever sees "STARTTLS" advertised and=20 negotiates it successfully, the client records the fact in a local=20 operations file that it used STARTTLS with server X. Subsequent to that it=20 will require STARTTLS with server X and not back off. I will note that=20 implementation strategy is simpler with the STARTTLS model than with the=20 separate port model. As an aside, there is no interoperable specification for use of TLS client=20 certificate authentication with the "pops" protocol (does it start in=20 not-authenticated state and require an AUTH EXTERNAL, or does it start in=20 authenticated state -- no way to distinguish the two cases). However, use=20 of TLS client certificate authentication with POP+STLS according to written = rules in RFC 2595 does interoperate. - Chris --On November 8, 2010 11:14:35 +0800 Magnus Westerlund=20 wrote: > TLS experts, > > There currently a WG last call ongoing in on the IANA Procedures for the > Management of the Service Name and Transport Protocol Port Number > Registry update document. > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ > > A WG last call comment on this document was raised by Paul Hoffman: > http://www.ietf.org/mail-archive/web/tsvwg/current/msg10305.html > > My summary of that comment is that STARTTLS for SMTP (RFC 3207) has > shown to have some security issues, be complexer to implement than using > two ports and thus less popular. Thus the registration rules should be > less restrictive in assigning an additional port for TLS version of > services/applications/protocols. > > The downside of less restrictive port allocation rules is that the port > space will be consumed at a higher rate. Thus there is need to determine > what is the most suitable trade-off here. > > Clearly if the security issues are serious when one multiplex TLS and > non-secured version of the protocol on the same port we must allow such > port allocations. However if the issues are minor and the primarily > issue is implementation complexity then saving the limited port space is > probably more important. > > Your input into these questions would be very appreciated. > > Thanks > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nico@cryptonector.com Wed Feb 9 18:25:32 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23BE3A680C; Wed, 9 Feb 2011 18:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM+HQMHYv3XJ; Wed, 9 Feb 2011 18:25:32 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id EA9963A67FA; Wed, 9 Feb 2011 18:25:31 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 8E0736B0073; Wed, 9 Feb 2011 18:25:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=AeFtmH35WiEtK2PJpAsLy 3YXsRltHaXRR5BqRZdkb8g8njR9iFcj+5k8ezhMRcOpE9A2F1I39sQBGr66mwSUF lz5SBfW0NH48Ju7A/NbWRKFwU8IeQh2FafoCsoGLlhnPxVTQjGRTAb/9qjP5cqNp 2SmRZ+vwEJvN0Z9q7ZlOII= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vDkjkl0kvw1VKvuxPiX3 S346h/g=; b=VvNWTDtbVTTTzY99Wa0yRarmCZGr28lQR9j9cJmO4HHOLD/ub/tH 15UTE40gza4P4amsyfjd2mWTrxWDV8DNJpIEBpq3i6jFN7u1RDRThYP14RUcDkmW vJtXdi9jezqzamNIjAvRXKSmbRsN4iboEBUXeE3fyQ+xtQCmBcbaERE= Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 55B736B0070; Wed, 9 Feb 2011 18:25:42 -0800 (PST) Received: by gxk27 with SMTP id 27so416189gxk.31 for ; Wed, 09 Feb 2011 18:25:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.32.16 with SMTP id f16mr2083595agf.202.1297304741429; Wed, 09 Feb 2011 18:25:41 -0800 (PST) Received: by 10.90.103.11 with HTTP; Wed, 9 Feb 2011 18:25:41 -0800 (PST) In-Reply-To: References: <4CD76B1B.5030308@ericsson.com> Date: Wed, 9 Feb 2011 20:25:41 -0600 Message-ID: Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) From: Nico Williams To: Chris Newman Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 11 Feb 2011 03:00:39 -0800 Cc: Magnus Westerlund , Paul Hoffman , tls@ietf.org, tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:25:32 -0000 On Wed, Feb 9, 2011 at 8:12 PM, Chris Newman wrote: > I know I'm very late on this topic, but my position differs from others so > I'll comment. +1 But I'll also add that it's not necessarily harder for implementers to manage StartTLS with isolation. I realize that implementers have screwed this up in the past, but there is hope that we can learn, and even develop institutional memory -- if not we have other problems. Nico -- From demoss.matt@gmail.com Wed Feb 9 19:35:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D770A3A681A; Wed, 9 Feb 2011 19:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FIqncw6V2zk; Wed, 9 Feb 2011 19:35:49 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8B2FB3A680C; Wed, 9 Feb 2011 19:35:48 -0800 (PST) Received: by fxm9 with SMTP id 9so1023294fxm.31 for ; Wed, 09 Feb 2011 19:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MlAPwYKSyklW3vhixBNic+syWZ2m22ql6WBme7VJxsM=; b=NvMQQvqvS8ZOiMxZnarlkFH1D74k01sD6vPZBpeRBGJDXaWIbw3PQ8VJU1TABt+OWf hnIX1oUgeCzocgV/O0vLDxSNrTDnk0mE9cCDEU80WVq4OvSipPW8LyhMQ36BqgDdGfmg c5FXR6eg6pmnZaMsdmoHiRMgTz0A50SYjGY1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kAtJYV9VPJyV2PP2hgEvqmd2t48YfybqXytevqu8xMz5v7OIApGClSGW3wW3ajYmR0 gvT852xckqv++IaiTlTJx7qLVPZRVsq/f+Wx6fYkzaRFtxNEme43FhJK5whqmfZZL/4R 9ma5Kk1r1jnPkKqQ96aqIybyBKaA335oogLVY= MIME-Version: 1.0 Received: by 10.223.93.139 with SMTP id v11mr7347101fam.132.1297308959118; Wed, 09 Feb 2011 19:35:59 -0800 (PST) Received: by 10.223.37.218 with HTTP; Wed, 9 Feb 2011 19:35:59 -0800 (PST) In-Reply-To: References: <4CD76B1B.5030308@ericsson.com> Date: Wed, 9 Feb 2011 22:35:59 -0500 Message-ID: Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) From: Matt DeMoss To: Chris Newman Content-Type: multipart/alternative; boundary=20cf3054a541ac1662049be54709 X-Mailman-Approved-At: Fri, 11 Feb 2011 03:00:39 -0800 Cc: tls@ietf.org, tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 03:35:50 -0000 --20cf3054a541ac1662049be54709 Content-Type: text/plain; charset=ISO-8859-1 > > > I can not deny that separate-port for SSL is simpler to implement on the > server side (having done both). Since the odds of security bugs increases > with the amount of code, I must conclude that separate-port SSL is more > secure for _implementers_ and _implementations_ for that reason alone. > [...] > As an aside, there is no interoperable specification for use of TLS client > certificate authentication with the "pops" protocol (does it start in > not-authenticated state and require an AUTH EXTERNAL, or does it start in > authenticated state -- no way to distinguish the two cases). However, use of > TLS client certificate authentication with POP+STLS according to written > rules in RFC 2595 does interoperate. > > I think the argument for protecting complex code paths from exposure is much stronger in the case of required client certificate authentication where unauthorized users may be able to exercise fewer paths. There are also some cases where it seems like you get client-cert-auth 'for free' as a side effect of sitting on top of a TLS implementation that supports client auth. MS Outlook seems to like this with LDAPS: I doubt it was a conscious choice on their part to include that mode of authentication. The separate port model also makes it easier to terminate the TLS tunnel at a simple load balancing or TLS accelerating device that knows nothing of the underlying protocol. --20cf3054a541ac1662049be54709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I can not deny that separate-port for SSL is simpler to implement on the se= rver side (having done both). Since the odds of security bugs increases wit= h the amount of code, I must conclude that separate-port SSL is more secure= for _implementers_ and _implementations_ for that reason alone.
=A0[...]
As an aside= , there is no interoperable specification for use of TLS client certificate= authentication with the "pops" protocol (does it start in not-au= thenticated state and require an AUTH EXTERNAL, or does it start in authent= icated state -- no way to distinguish the two cases). However, use of TLS c= lient certificate authentication with POP+STLS according to written rules i= n RFC 2595 does interoperate.


I think the argument for protecting co= mplex code paths from exposure is much stronger in the case of required cli= ent certificate authentication where unauthorized users may be able to exer= cise fewer paths.

There are also some cases where it seems like you get c= lient-cert-auth 'for free' as a side effect of sitting on top of a = TLS implementation that supports client auth. MS Outlook seems to like this= with LDAPS: I doubt it was a=A0conscious=A0choice on their part to include= that mode of authentication.

The=A0separate=A0port model also makes it easier to ter= minate the TLS tunnel at a simple load balancing or TLS accelerating device= that knows nothing of the underlying protocol.
--20cf3054a541ac1662049be54709-- From ynir@checkpoint.com Wed Feb 9 23:19:09 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFDA3A68C5; Wed, 9 Feb 2011 23:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo+th-pbLZOG; Wed, 9 Feb 2011 23:19:09 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 974673A68A9; Wed, 9 Feb 2011 23:19:08 -0800 (PST) X-CheckPoint: {4D539177-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1A7JINS006850; Thu, 10 Feb 2011 09:19:18 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 10 Feb 2011 09:19:18 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 10 Feb 2011 09:19:18 +0200 From: Yoav Nir To: Chris Newman Date: Thu, 10 Feb 2011 09:19:15 +0200 Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) Thread-Topic: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) Thread-Index: AcvI8tQluol13oALTNiL9FBwZWuVOQ== Message-ID: References: <4CD76B1B.5030308@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 11 Feb 2011 03:00:39 -0800 Cc: Paul Hoffman , "tls@ietf.org" , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:19:10 -0000 I have to disagree with this. On Feb 10, 2011, at 4:12 AM, Chris Newman wrote: > I know I'm very late on this topic, but my position differs from others s= o=20 > I'll comment. >=20 > I can not deny that separate-port for SSL is simpler to implement on the= =20 > server side (having done both). Since the odds of security bugs increases= =20 > with the amount of code, I must conclude that separate-port SSL is more=20 > secure for _implementers_ and _implementations_ for that reason alone. >=20 > However, I believe STARTTLS is more secure for _operators_ and=20 > _administrators_. The separate port model creates an illusion that there = is=20 > a "secure" and "insecure" variant of the protocol and that a single=20 > firewall setting magically makes the application secure. In general, this= =20 > is not true. Most servers have several security settings and the default= =20 > settings have to compromise between common practice, secure-by-default=20 > practice, deployability, management complexity and usability. There is, i= n=20 > general, no way to make a server installation secure for a given site oth= er=20 > than to understand the security settings that server provides and set the= m=20 > properly. >=20 > A protocol that uses STARTTLS thus has the advantage of forcing the=20 > administrator/operator to look at the server's security settings to make= =20 > the installation secure, thus increasing the odds of success relative to= =20 > the separate-port model where an administrator might falsely assume they'= re=20 > done after blocking the non-SSL port. I think this is a recipe for failure. What you're saying here, is that by u= sing separate ports, you cannot use the firewall to prevent non-secure conn= ections and this forces the administrator to configure the server properly. There are several things wrong with this: 1. It does not force the administrator to configure the server properly. At= best, it forces them to find the "force SSL" checkbox and check it. That h= as pretty much the same effect as forcing this on the firewall. Some admini= strators will use any opportunity to configure the server wrong. 2. You underestimate firewalls. Modern firewalls can examine connections an= d cut them off if STARTTLS is not initiated in time. So the administrator s= till has the option of "fixing it in the firewall". In short, you can't force administrators to do the right thing. Ever.=20 From touch@isi.edu Fri Feb 11 15:48:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9AD43A69D1; Fri, 11 Feb 2011 15:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.832 X-Spam-Level: X-Spam-Status: No, score=-104.832 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R999rtvbCs87; Fri, 11 Feb 2011 15:48:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 902CD3A6838; Fri, 11 Feb 2011 15:48:48 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p1BNmRUY005939 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 11 Feb 2011 15:48:27 -0800 (PST) Message-ID: <4D55CACB.6020306@isi.edu> Date: Fri, 11 Feb 2011 15:48:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Chris Newman Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08) References: <4CD76B1B.5030308@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Magnus Westerlund , Paul Hoffman , tls@ietf.org, tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 23:48:50 -0000 FWIW, we have removed the text on this recommendation from this draft (a version will appear later today). However, I'd still appreciate resolving this issue, or at least clarifying the two different positions in detail, as part of a different draft that focuses on advise to how ports are used: http://tools.ietf.org/html/draft-touch-tsvwg-port-use-00 That doc will be updated in the next few days with more than just placeholders, and I'll include space for this debate there as well. FYI. Joe On 2/9/2011 6:12 PM, Chris Newman wrote: > I know I'm very late on this topic, but my position differs from others > so I'll comment. > > I can not deny that separate-port for SSL is simpler to implement on the > server side (having done both). Since the odds of security bugs > increases with the amount of code, I must conclude that separate-port > SSL is more secure for _implementers_ and _implementations_ for that > reason alone. > > However, I believe STARTTLS is more secure for _operators_ and > _administrators_. The separate port model creates an illusion that there > is a "secure" and "insecure" variant of the protocol and that a single > firewall setting magically makes the application secure. In general, > this is not true. Most servers have several security settings and the > default settings have to compromise between common practice, > secure-by-default practice, deployability, management complexity and > usability. There is, in general, no way to make a server installation > secure for a given site other than to understand the security settings > that server provides and set them properly. > > A protocol that uses STARTTLS thus has the advantage of forcing the > administrator/operator to look at the server's security settings to make > the installation secure, thus increasing the odds of success relative to > the separate-port model where an administrator might falsely assume > they're done after blocking the non-SSL port. > > While I think the judgment call is close for > separate-port-SSL-vs-STARTTLS, I prefer STARTTLS weighing all the factors. > > And for the record I'm responsible for TLS integration into a server > product and maintain all the relevant code and find STARTTLS maintenance > annoying. I'm also author of RFC 2595, so perhaps that balances out my > bias as an implementer. ;-) > > It's also my opinion that a high quality client should use a "latched" > model by default. If the client ever sees "STARTTLS" advertised and > negotiates it successfully, the client records the fact in a local > operations file that it used STARTTLS with server X. Subsequent to that > it will require STARTTLS with server X and not back off. I will note > that implementation strategy is simpler with the STARTTLS model than > with the separate port model. > > As an aside, there is no interoperable specification for use of TLS > client certificate authentication with the "pops" protocol (does it > start in not-authenticated state and require an AUTH EXTERNAL, or does > it start in authenticated state -- no way to distinguish the two cases). > However, use of TLS client certificate authentication with POP+STLS > according to written rules in RFC 2595 does interoperate. > > - Chris > > --On November 8, 2010 11:14:35 +0800 Magnus Westerlund > wrote: > >> TLS experts, >> >> There currently a WG last call ongoing in on the IANA Procedures for the >> Management of the Service Name and Transport Protocol Port Number >> Registry update document. >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ >> >> A WG last call comment on this document was raised by Paul Hoffman: >> http://www.ietf.org/mail-archive/web/tsvwg/current/msg10305.html >> >> My summary of that comment is that STARTTLS for SMTP (RFC 3207) has >> shown to have some security issues, be complexer to implement than using >> two ports and thus less popular. Thus the registration rules should be >> less restrictive in assigning an additional port for TLS version of >> services/applications/protocols. >> >> The downside of less restrictive port allocation rules is that the port >> space will be consumed at a higher rate. Thus there is need to determine >> what is the most suitable trade-off here. >> >> Clearly if the security issues are serious when one multiplex TLS and >> non-secured version of the protocol on the same port we must allow such >> port allocations. However if the issues are minor and the primarily >> issue is implementation complexity then saving the limited port space is >> probably more important. >> >> Your input into these questions would be very appreciated. >> >> Thanks >> >> 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.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > From Internet-Drafts@ietf.org Fri Feb 11 17:15:02 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400173A6A50; Fri, 11 Feb 2011 17:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3PH9ayEfEj1; Fri, 11 Feb 2011 17:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C9F3A6A21; Fri, 11 Feb 2011 17:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-tsvwg-iana-ports-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110212011501.19200.14616.idtracker@localhost> Date: Fri, 11 Feb 2011 17:15:01 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 01:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Author(s) : M. Cotton, et al. Filename : draft-ietf-tsvwg-iana-ports-10.txt Pages : 32 Date : 2011-02-11 This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number Registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA Service Name and Port assignment procedures for UDP-Lite [RFC3828], DCCP [RFC4340] [RFC5595] and SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782] to clarify what a service name is and how it is registered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-iana-ports-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-iana-ports-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-11170448.I-D@ietf.org> --NextPart-- From alexey.melnikov@isode.com Sat Feb 12 12:01:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6F23A6AEF; Sat, 12 Feb 2011 12:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbsjfM17OaBK; Sat, 12 Feb 2011 12:01:48 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B34DC3A6ADF; Sat, 12 Feb 2011 12:01:47 -0800 (PST) Received: from [188.28.20.209] (188.28.20.209.threembb.co.uk [188.28.20.209]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 12 Feb 2011 20:02:02 +0000 Message-ID: <4D56E703.7050304@isode.com> Date: Sat, 12 Feb 2011 20:01:07 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> In-Reply-To: <4D457FD9.5030905@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 12 Feb 2011 13:19:38 -0800 Cc: IETF discussion list , IESG IESG , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 20:01:49 -0000 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? From alexey.melnikov@isode.com Sat Feb 12 12:03:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F117E3A6A41; Sat, 12 Feb 2011 12:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txdNbcyusqGF; Sat, 12 Feb 2011 12:03:15 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F3DD83A6AEF; Sat, 12 Feb 2011 12:03:14 -0800 (PST) Received: from [188.28.20.209] (188.28.20.209.threembb.co.uk [188.28.20.209]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 12 Feb 2011 20:03:30 +0000 Message-ID: <4D56E75A.9070903@isode.com> Date: Sat, 12 Feb 2011 20:02:34 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> In-Reply-To: <4D46CC62.1040006@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 12 Feb 2011 13:19:38 -0800 Cc: IESG IESG , Joe Touch , tsvwg@ietf.org, IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 20:03:16 -0000 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. From fluffy@cisco.com Tue Feb 15 19:32:00 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9E43A6C7E; Tue, 15 Feb 2011 19:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.447 X-Spam-Level: X-Spam-Status: No, score=-109.447 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPI2-vPAyh8S; Tue, 15 Feb 2011 19:31:59 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 065F43A6CAB; Tue, 15 Feb 2011 19:31:59 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMzTWk2rR7Hu/2dsb2JhbAClYnOhY5toAoVcBIUGhwCDNg X-IronPort-AV: E=Sophos;i="4.60,478,1291593600"; d="scan'208";a="264195625" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2011 03:32:26 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1G3WO4o005430; Wed, 16 Feb 2011 03:32:25 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4D4920F0.1070204@ericsson.com> Date: Tue, 15 Feb 2011 20:34:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49CDF352-D900-4883-8D67-19172DBC8474@cisco.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> <4D4920F0.1070204@ericsson.com> To: Magnus Westerlund , IESG IESG X-Mailer: Apple Mail (2.1082) Cc: IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 03:32:00 -0000 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: >>=20 >> 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.=20 >>=20 >> 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.=20 >=20 > Cullen, >=20 > 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.=20 >=20 > - 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. >=20 > - 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.=20 >=20 > - 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.=20 >=20 > 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. >=20 > 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.=20 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.=20 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.=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From fluffy@cisco.com Tue Feb 15 19:59:52 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7918A3A6CAB; Tue, 15 Feb 2011 19:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.19 X-Spam-Level: X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABHJb3GhKt86; Tue, 15 Feb 2011 19:59:51 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A8DEC3A6B77; Tue, 15 Feb 2011 19:59:51 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMraWk2rR7Ht/2dsb2JhbAClYnOhWJtkhV4EhQaHAIM2 X-IronPort-AV: E=Sophos;i="4.60,478,1291593600"; d="scan'208";a="260669802" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 16 Feb 2011 04:00:18 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1G40G0G018511; Wed, 16 Feb 2011 04:00:17 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D5B4B98.4060704@vpnc.org> Date: Tue, 15 Feb 2011 21:02:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6AA482E6-924C-4981-9E7F-69AD8EE3DD6F@cisco.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> <4D4920F0.1070204@ericsson.com> <49CDF352-D900-4883-8D67-19172DBC8474@cisco.com> <4D5B4B98.4060704@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: Magnus Westerlund , tsvwg@ietf.org, IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 03:59:52 -0000 Paul's text is much better than mine. That was what I trying to get at.=20= 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: >>=20 >> 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. >=20 > 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: >=20 > 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. From fluffy@cisco.com Tue Feb 15 20:28:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BD63A6D45; Tue, 15 Feb 2011 20:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.946 X-Spam-Level: X-Spam-Status: No, score=-109.946 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj2WOVE58oCY; Tue, 15 Feb 2011 20:28:49 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D039C3A6CDA; Tue, 15 Feb 2011 20:28:49 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANLhWk2rRDoJ/2dsb2JhbAClYnOhdZtfgn6CYASFBocAgzY X-IronPort-AV: E=Sophos;i="4.60,478,1291593600"; d="scan'208";a="264218599" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2011 04:29:17 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1G4T5Id023583; Wed, 16 Feb 2011 04:29:15 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 15 Feb 2011 21:31:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2803F25F-A2BE-46E3-8284-A256A9B9D415@cisco.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> To: Christian Huitema X-Mailer: Apple Mail (2.1082) Cc: "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , Sam Hartman , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 04:28:50 -0000 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.=20 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.=20 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". =20 >> Or would anonymous interaction fail a Turing test of some kind? >=20 > 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. >=20 > -- Christian Huitema >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From alexey.melnikov@isode.com Wed Feb 16 03:11:48 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903623A6DF8; Wed, 16 Feb 2011 03:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwfkcyQkyw7z; Wed, 16 Feb 2011 03:11:42 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 97F153A6E05; Wed, 16 Feb 2011 03:11:41 -0800 (PST) Received: from [188.28.83.64] (188.28.83.64.threembb.co.uk [188.28.83.64]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 16 Feb 2011 11:12:06 +0000 Message-ID: <4D5BB0E8.5000503@isode.com> Date: Wed, 16 Feb 2011 11:11:36 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre , Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> <4D4920F0.1070204@ericsson.com> <49CDF352-D900-4883-8D67-19172DBC8474@cisco.com> <4D5B4B98.4060704@vpnc.org> <6AA482E6-924C-4981-9E7F-69AD8EE3DD6F@cisco.com> <4D5B4D86.3020102@stpeter.im> In-Reply-To: <4D5B4D86.3020102@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Magnus Westerlund , Paul Hoffman , IESG IESG , tsvwg@ietf.org, IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 11:11:48 -0000 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. >>> >>> From hartmans@mit.edu Wed Feb 16 04:13:43 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC61A3A6E3D; Wed, 16 Feb 2011 04:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlAeAmTvmxnl; Wed, 16 Feb 2011 04:13:43 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3F57D3A6B74; Wed, 16 Feb 2011 04:13:43 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 59812202FB; Wed, 16 Feb 2011 07:11:54 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2410A4307; Wed, 16 Feb 2011 07:13:51 -0500 (EST) From: Sam Hartman To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <2803F25F-A2BE-46E3-8284-A256A9B9D415@cisco.com> Date: Wed, 16 Feb 2011 07:13:51 -0500 In-Reply-To: <2803F25F-A2BE-46E3-8284-A256A9B9D415@cisco.com> (Cullen Jennings's message of "Tue, 15 Feb 2011 21:31:29 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , Christian Huitema , Sam Hartman , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 12:13:44 -0000 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. From daedulus@btconnect.com Wed Feb 16 04:17:28 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E6C3A6E34; Wed, 16 Feb 2011 04:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELAynWwZ3qQF; Wed, 16 Feb 2011 04:17:27 -0800 (PST) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by core3.amsl.com (Postfix) with ESMTP id 2AAB93A6CAA; Wed, 16 Feb 2011 04:17:26 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr07.btconnect.com with SMTP id BUF28912; Wed, 16 Feb 2011 12:17:50 +0000 (GMT) Message-ID: <009301cbcdca$91682300$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Cullen Jennings" , "Christian Huitema" References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <2803F25F-A2BE-46E3-8284-A256A9B9D415@cisco.com> Subject: Re: Last Call: (InternetAssigned Numbers Authority (IANA) Procedures for the Managementof the Service Name and Transport Protocol Port NumberRegistry) to BCP Date: Wed, 16 Feb 2011 12:13:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D5BC06E.0075, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4D5BC06F.0332,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: IETF discussion list , tsvwg@ietf.org, IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 12:17:28 -0000 ---- Original Message ----- From: "Cullen Jennings" To: "Christian Huitema" Cc: ; "Paul Hoffman" ; "Chris Benson" ; "IESG IESG" ; "Sam Hartman" ; "IETF discussion list" Sent: Wednesday, February 16, 2011 5:31 AM > > 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. > Cullen My understanding of this draft is that Expert Review only applies when "IETF Review" or "IESG Approval" does not apply, so a duly approved Standards Track RFC trumps all Experts. I proposed text on 2nd February to make this clearer, and understand that this change was accepted. Where the request is not via "IETF Review" or "IESG Approval", then I have less concern as to what the Expert may or may not allow. My text is "For most IETF protocols, ports in the User Ports range will be assigned under the "IETF Review" or "IESG Approval" procedures [RFC5226] and no further documentation is required. Where these procedures do not apply, then the requester must input the documentation 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." Tom Petch > 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 > > > > From ietfc@btconnect.com Wed Feb 16 04:28:13 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EEE43A6E49 for ; Wed, 16 Feb 2011 04:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_ADLTSUB4=0.89, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okfEF7feNphF for ; Wed, 16 Feb 2011 04:28:12 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 5281F3A6CA6 for ; Wed, 16 Feb 2011 04:28:11 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr10.btconnect.com with SMTP id BSH93014; Wed, 16 Feb 2011 12:26:49 +0000 (GMT) Message-ID: <00e001cbcdcb$d2918b40$4001a8c0@gateway.2wire.net> From: "t.petch" To: Subject: Last Call: (InternetAssigned Numbers Authority (IANA) Procedures for theManagementof the Service Name and Transport Protocol PortNumberRegistry) to BCP Date: Wed, 16 Feb 2011 12:22:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D5BC289.0061, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4D5BC2F7.00DE,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 12:28:13 -0000 ----- Original Message ----- From: "t.petch" To: "Cullen Jennings" ; "Christian Huitema" Cc: "IETF discussion list" ; ; "IESG IESG" Sent: Wednesday, February 16, 2011 12:13 PM Subject: Re: Last Call: (InternetAssigned Numbers Authority (IANA) Procedures for theManagementof the Service Name and Transport Protocol PortNumberRegistry) to BCP > > ---- Original Message ----- > From: "Cullen Jennings" > To: "Christian Huitema" > Cc: ; "Paul Hoffman" ; "Chris Benson" > ; "IESG IESG" ; "Sam Hartman" > ; "IETF discussion list" > Sent: Wednesday, February 16, 2011 5:31 AM > > > > 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. > > > Cullen My understanding of this draft is that Expert Review only applies when "IETF Review" or "IESG Approval" does not apply, so a duly approved Standards Track RFC trumps all Experts. I proposed text on 2nd February to make this clearer, and understand that this change was accepted. Where the request is not via "IETF Review" or "IESG Approval", then I have less concern as to what the Expert may or may not allow. My text is "For most IETF protocols, ports in the User Ports range will be assigned under the "IETF Review" or "IESG Approval" procedures [RFC5226] and no further documentation is required. Where these procedures do not apply, then the requester must input the documentation 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." Tom Petch > > 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 From fluffy@cisco.com Wed Feb 16 07:17:21 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B843A6CC7 for ; Wed, 16 Feb 2011 07:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.927 X-Spam-Level: X-Spam-Status: No, score=-108.927 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, SARE_ADLTSUB4=0.89, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrFFvAHAuVQe for ; Wed, 16 Feb 2011 07:17:20 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 52C463A6A25 for ; Wed, 16 Feb 2011 07:17:20 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiABAP54W02rR7H+/2dsb2JhbACXGo5Ic6Bam1qCH1+CYASFCIcCgzg X-IronPort-AV: E=Sophos;i="4.60,480,1291593600"; d="scan'208";a="264469891" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2011 15:17:48 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1GFHlhc029962; Wed, 16 Feb 2011 15:17:48 GMT Subject: Re: Last Call: (InternetAssigned Numbers Authority (IANA) Procedures for theManagementof the Service Name and Transport Protocol PortNumberRegistry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings X-Priority: 3 In-Reply-To: <00e001cbcdcb$d2918b40$4001a8c0@gateway.2wire.net> Date: Wed, 16 Feb 2011 08:20:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70CA1103-7163-460A-B3A8-5086A3D05AB1@cisco.com> References: <00e001cbcdcb$d2918b40$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 15:17:21 -0000 Sorry Tom - I should have phrased what I said more carefully. I meant to = scope my comments to user ports that were not going through IETF = process.=20 On Feb 16, 2011, at 4:22 AM, t.petch wrote: > ----- Original Message ----- > From: "t.petch" > To: "Cullen Jennings" ; "Christian Huitema" > > Cc: "IETF discussion list" ; ; "IESG = IESG" > > Sent: Wednesday, February 16, 2011 12:13 PM > Subject: Re: Last Call: = (InternetAssigned > Numbers Authority (IANA) Procedures for theManagementof the Service = Name and > Transport Protocol PortNumberRegistry) to BCP >=20 >=20 >>=20 >> ---- Original Message ----- >> From: "Cullen Jennings" >> To: "Christian Huitema" >> Cc: ; "Paul Hoffman" ; "Chris = Benson" >> ; "IESG IESG" ; "Sam Hartman" >> ; "IETF discussion list" >> Sent: Wednesday, February 16, 2011 5:31 AM >>>=20 >>> 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. >>>=20 >>=20 > Cullen >=20 > My understanding of this draft is that Expert Review only applies when = "IETF > Review" or "IESG Approval" does not apply, so a duly approved = Standards > Track RFC trumps all Experts. >=20 > I proposed text on 2nd February to make this clearer, and understand = that this > change was accepted. >=20 > Where the request is not via "IETF Review" or "IESG Approval", then I = have > less concern as to what the Expert may or may not allow. >=20 > My text is >=20 > "For most IETF protocols, ports in the User Ports range will be = assigned under > the "IETF Review" or "IESG Approval" procedures [RFC5226] and no = further > documentation is required. >=20 > Where these procedures do not apply, then the requester must > input the documentation 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." >=20 > Tom Petch >=20 >=20 >>> 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. >>>=20 >>> Pros & cons of this idea? >>>=20 >>> On Feb 8, 2011, at 1:41 PM, Christian Huitema wrote: >>>=20 >>>>> 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? >>>>=20 >>>> 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. >>>>=20 >>>> -- Christian Huitema >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >=20 From lear@cisco.com Wed Feb 16 08:34:17 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DFE3A6E74 for ; Wed, 16 Feb 2011 08:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.499 X-Spam-Level: X-Spam-Status: No, score=-109.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsphhZNNClCT for ; Wed, 16 Feb 2011 08:34:17 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0B8183A6E6D for ; Wed, 16 Feb 2011 08:34:17 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL+LW02rR7Ht/2dsb2JhbACEHaFMc6BXinGQYYEng0F2BIUIhwI X-IronPort-AV: E=Sophos;i="4.60,480,1291593600"; d="scan'208";a="330775455" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2011 16:34:45 +0000 Received: from dhcp-171-70-255-219.cisco.com (dhcp-171-70-255-219.cisco.com [171.70.255.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1GGYjDp018346 for ; Wed, 16 Feb 2011 16:34:45 GMT Message-ID: <4D5BFC8F.1090506@cisco.com> Date: Wed, 16 Feb 2011 08:34:23 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg Subject: discovery and draft-ietf-tsvwg-iana-ports X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 16:34:17 -0000 Hi, The current draft doesn't really delve sufficiently into discovery of services. Currently it seems that every other request I deal with has some sort of discovery component to it. I would like us to consider gating normatively on draft-cheshire-dnsext-sd and requiring its use for discovery. Eliot From lars.eggert@nokia.com Wed Feb 16 08:55:43 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A913A6B7C for ; Wed, 16 Feb 2011 08:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9b71wBWtPTb for ; Wed, 16 Feb 2011 08:55:39 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 5C38E3A6E9D for ; Wed, 16 Feb 2011 08:55:39 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1GGu5kw029466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Feb 2011 18:56:06 +0200 Subject: Re: discovery and draft-ietf-tsvwg-iana-ports X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-43--406905474; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D5BFC8F.1090506@cisco.com> Date: Wed, 16 Feb 2011 18:55:57 +0200 Message-Id: <49FFC0E6-060A-4524-B558-B4CEF6438570@nokia.com> References: <4D5BFC8F.1090506@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 16 Feb 2011 18:56:03 +0200 (EET) X-Nokia-AV: Clean Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 16:55:44 -0000 --Apple-Mail-43--406905474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-2-16, at 18:34, Eliot Lear wrote: > The current draft doesn't really delve sufficiently into discovery of > services. Currently it seems that every other request I deal with has > some sort of discovery component to it. I would like us to consider > gating normatively on draft-cheshire-dnsext-sd and requiring its use = for > discovery. I think this is fully out of scope for an RFC that intends to describe = IANA registry management practices. (I'd be all for a different BCP that would try to get consensus for this = in the IETF, however.) Lars= --Apple-Mail-43--406905474 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNjE2NTU1OFowIwYJKoZIhvcNAQkE MRYEFA8gmOaI0E242dy5FNvlUXg14n+7MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AIhq85qXK7L1GC43SCbyaKHZRrth7+aVZc4UCC72Uvhhq6ERR4Lm58NZ5fWRXkTj7P/SsShtkwsc VDaOf37ENRVMGdmwnT2EwBtqlTygdqIvVrm4eW5S2NqkkpO+H7qmePnvdADKkH44NMitx6hCtJ6i CPdu4hjUF3hL5JtAG20OkTEgKxQw6q1A5AVEYRnKeVUPSJaCu/Cl+Bd014kkmIx8Aym5zFtDu9m2 ykGY5EzIVtQqRsZ0ZMInkoP13haI4X7l7Ms/nGzPW68gt+7Fif61QRN6+8OEEqg+lFSH+OsGTsYU crdgTFr2qgptLUP96Mszgb0C/DKfqEtgYCl60xkAAAAAAAA= --Apple-Mail-43--406905474-- From paul.hoffman@vpnc.org Tue Feb 15 19:58:59 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1DDF3A6B8E; Tue, 15 Feb 2011 19:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.316 X-Spam-Level: X-Spam-Status: No, score=-100.316 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b13ffshfUA5; Tue, 15 Feb 2011 19:58:58 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 425963A6B77; Tue, 15 Feb 2011 19:58:58 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1G3xK66028915 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Feb 2011 20:59:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D5B4B98.4060704@vpnc.org> Date: Tue, 15 Feb 2011 19:59:20 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> <4D4920F0.1070204@ericsson.com> <49CDF352-D900-4883-8D67-19172DBC8474@cisco.com> In-Reply-To: <49CDF352-D900-4883-8D67-19172DBC8474@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Feb 2011 10:13:55 -0800 Cc: Magnus Westerlund , tsvwg@ietf.org, IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 03:58:59 -0000 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. From stpeter@stpeter.im Tue Feb 15 20:07:10 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4543A6CD1; Tue, 15 Feb 2011 20:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJhvobNzJ75K; Tue, 15 Feb 2011 20:07:09 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CABAF3A6CB6; Tue, 15 Feb 2011 20:07:09 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 27707400F6; Tue, 15 Feb 2011 21:25:40 -0700 (MST) Message-ID: <4D5B4D86.3020102@stpeter.im> Date: Tue, 15 Feb 2011 21:07:34 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> <4D46B3B9.4050804@ericsson.com> <755A9333-6960-4BCC-B996-3775E76B5D9E@cisco.com> <4D4920F0.1070204@ericsson.com> <49CDF352-D900-4883-8D67-19172DBC8474@cisco.com> <4D5B4B98.4060704@vpnc.org> <6AA482E6-924C-4981-9E7F-69AD8EE3DD6F@cisco.com> In-Reply-To: <6AA482E6-924C-4981-9E7F-69AD8EE3DD6F@cisco.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090609060805040009070606" X-Mailman-Approved-At: Wed, 16 Feb 2011 10:13:55 -0800 Cc: IESG IESG , Magnus Westerlund , IETF discussion list , Paul Hoffman , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 04:07:10 -0000 This is a cryptographically signed message in MIME format. --------------ms090609060805040009070606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, thanks to Paul for the proposed text. On 2/15/11 9:02 PM, Cullen Jennings wrote: >=20 > Paul's text is much better than mine. That was what I trying to get > at. >=20 > On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: >=20 >> 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: >>>=20 >>> 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. >>=20 >> 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: >>=20 >> 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. --------------ms090609060805040009070606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx NjA0MDczNFowIwYJKoZIhvcNAQkEMRYEFFc6EOxT89Pc6PJRhHl9UhQdSK6gMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAOSx3bgfp+PX+yFrLcOgO5rTLFrT8FsG0qJuwTFP2Iv78YIYa3AfwrwRG4 U8VtBg9hZStPAJa9szjL9Z3tGm5FOczm39uTt3uvrXQUJdNnCJXx1GiZAnp1X9VksY7E2KGU TQv+QTRuqj9t8QvxyDRcrOr2qALYeZHh84zNtCU+ktX4KfO1bo3eR+3EPiiNberWvDu+GPXr HlM24FtFkgz2EsSqIs1ri+mUpbUjPhGPPuj6a9k/yAUAXREANKJlxO+k6OAUt1xTEGO2D7mA OokLjKUUj+S2qqcHjXVoE7vAjptAMBWUrWNbZw7s3OOp6nKD8GRx2nB3c7+esTkkoAFpAAAA AAAA --------------ms090609060805040009070606-- From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Feb 22 10:38:08 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB883A695C for ; Tue, 22 Feb 2011 10:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLcMLdZzR5Jm for ; Tue, 22 Feb 2011 10:38:07 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id B703E3A6943 for ; Tue, 22 Feb 2011 10:38:06 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 682A2633B1; Tue, 22 Feb 2011 19:38:49 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 59C1D59A8A; Tue, 22 Feb 2011 19:38:49 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: tsvwg@ietf.org Subject: Re: I-D Action:draft-ietf-tsvwg-byte-pkt-congest-03.txt Date: Tue, 22 Feb 2011 19:38:48 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <20101025221535.A7CE33A68B7@core3.amsl.com> In-Reply-To: <20101025221535.A7CE33A68B7@core3.amsl.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201102221938.48204.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Bob Briscoe X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:38:08 -0000 Hi, I reviewed the doc. Here are comments: =2D> I haven't read the previous version but I still find the doc quite har= d to=20 read. I would prefer to have the recommendation right after the introductio= n=20 and all kind of reasoning afterwards. The whole section "1.2 Why now?" migh= t=20 not be intresting for somebody how really wants a recommendation. Maybe mov= e=20 it to the appendix.=20 =2D> You mention this mail [pktByteEmail] at least 4 times at different pla= ces.=20 After a while I really got annoyed reading the same things over and over=20 again... as the doc is anyway quite long, maybe there is an option to short= en=20 this. =2D> 1. Introduction =2D----------------- - page 6, 1. paragraph: "However, there are ways of addressing these issues at the transport layer, rather than reverse engineering network forwarding to fix the problems of one specific transport." At this point in the doc it is not clear if the network is reverse=20 engineering the transport or vice versa... - page 6, 4 paragraph: Reference to RFC 3465 - TCP Congestion Control with Appropriate Byte=20 Counting (ABC)? - page 6, 3. paragraph: Maybe have a brief list with the arguments described in 2. Motivating=20 Arguments. I would say, if somebody is reading the doc to get some=20 recommendations he would like to hear some arguments right at the beginning= =20 but having the full discussion is not necessary. That's why I would move 2.= =20 Motivating Arguments after the recommendation section itself. - 1.2. Why now:=20 Its 2. and 3. the same? Would move the whole section to the appendix... =2D> 2. Motivating Arguments =2D----- - 2.3. page 12, 2. paragraph From my point of view does this example give the main reason why=20 packet-mode drop is the right thing to do and all other points just support= =20 this with examples showing that either byte-mode drop is wrong or packet-si= ze=20 congestion control would be the easier solution. But the example is=20 complicated to read and the reason itself is never clearly stated: Network= =20 should provide the same behavior against all flows (in this case the same=20 rate reduction) independent of their higher level characteristics! I would include this example in the introduction and maybe a table like thi= s=20 might help (?): Packet Size 1500B 60B # of packet per 1.2 sec 100 2500 drop probability 25% 1% # of drops 25 25 rate reduction 300k 12k =09 With the first reading I was confused because the example says XX% of packe= ts=20 drops. But as there is a different number of packet in the same time, this= =20 equals XX% of bits dropped. Maybe this table is a way to make this more=20 explicit and thus easier to read (or maybe its just me....). Moreover, you= =20 could include a picture like this: 1 Mbps ---------| 25% |----------750 kbps | RED | 1 Mbps............ | 1% |.............990 kbps =46urther remarks on the example to make thing clearer: =2D The rates are not the link capacity but the transmission rates if suffi= cient=20 link capacity is available. =2D The RED queue would just operate in a certain state with 25% and 1% dro= p but=20 whenever RED is dropping packets the one probability will be 25 times large= r=20 than the other. =2D This is the troughput not the goodput. Thus header overhead it not take= n=20 into account. =2D> 3. Recommendations =2D---------------- - 3.1. Recommendations on Queue Measurement The 2. paragraph says the same than the 2. corollary. Also I don't know= =20 why the 2. corollary says "If RED is used" because this is true for all que= ue=20 measurements. This paragraph should be the first collary and for the other= =20 one I would suggest to rephrase to: "An Admin SHOULD NOT be able to configure the way a queue measures itself,= =20 because wether a queue is bit-congestible or packet-congestible is a proper= ty=20 of the resource." Maybe add an example here. - 3.2. page 14, 4. paragraph NOTE WELL This is important for understanding the whole wording used. Maybe make= =20 this statement earlier more explicit. - 3.3. Both corollaries basically say if modifications are needed because= of=20 layer-specific characteristics, those changes MUST be done in the same laye= r=20 and MUST never been done in any layer below. But the question left open here is: If the network is doing the wrong thing= =20 and I can't know what the network is doing, how can I do the right thing=20 (e.g. to get equal rates)? =2D> 4. A Survey and Critique of Past Advice =2D----------------------- - 4.1.: 1. paragraph: Do you have the respective reference? - 4.2.3.: 1.paragraph: "... these two proposal are safer and ..." Why are= =20 they safer? - 4.2.3.: 2.paragraph: Doesn't this give a new option for attacks? =2D> Would move 4.2.5. to Appendix =2D> Even though section 4. and 5. are intresting to read, I would see this= doc=20 as a guideline for implementers or transport designers. Some point are more= =20 about open research issues. Maybe there is a way to shorten these parts (or= =20 to move them into a second doc...). Maybe have something like implementor's= =20 guidelines or design principles instead. Allover the message of the doc is= =20 (more or less) quite simple but the long discussions on various different=20 side effects makes the doc hard to read and it's hard to focus on the=20 actually statement.=20 =2D> I like the conclusion! Mirja On Tuesday 26 October 2010 00:15:32 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Area Working Group > Working Group of the IETF. > > > Title : Byte and Packet Congestion Notification > Author(s) : B. Briscoe, J. Manner > Filename : draft-ietf-tsvwg-byte-pkt-congest-03.txt > Pages : 41 > Date : 2010-10-25 > > This memo concerns dropping or marking packets using active queue > management (AQM) such as random early detection (RED) or pre- > congestion notification (PCN). We give three strong recommendations: > (1) packet size should be taken into account when transports read > congestion indications, (2) packet size should not be taken into > account when network equipment creates congestion signals (marking, > dropping), and therefore (3) the byte-mode packet drop variant of the > RED AQM algorithm that drops fewer small packets should not be used. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-03.= tx >t > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From dreibh@iem.uni-due.de Sat Feb 26 04:45:02 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EA53A6856 for ; Sat, 26 Feb 2011 04:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaBIrPQvXhMT for ; Sat, 26 Feb 2011 04:45:01 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id 053A53A683C for ; Sat, 26 Feb 2011 04:45:00 -0800 (PST) Received: from lupo.localnet (p5086C0EE.dip.t-dialin.net [80.134.192.238]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p1QCjoZK004472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Feb 2011 13:45:51 +0100 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Date: Sat, 26 Feb 2011 13:45:45 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.38-rc5dreibholz; KDE/4.6.0; x86_64; ; ) References: <201102080311.p183BoXh025565@sj-core-5.cisco.com> In-Reply-To: <201102080311.p183BoXh025565@sj-core-5.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1452139.4lgcH4cq8J"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201102261345.49729.dreibh@iem.uni-due.de> X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: "James M. Polk" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 12:45:02 -0000 --nextPart1452139.4lgcH4cq8J Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I have read the document and think it should be progressed. Since the early versions of this draft, I have implemented the described AP= I=20 as part of the Socket API library for the well-known SCTPLIB userland SCTP= =20 implementation. The implementation is Open Source and can be found here:=20 http://www.sctp.de/sctp-download.html . I am also the author and maintainer of RSPLIB, the Open Source RSerPool=20 implementation, which can be found here: http://tdrwww.exp-math.uni- essen.de/dreibholz/rserpool/ . RSerPool is based on SCTP, and RSPLIB makes = use=20 of a lot of advanced features of SCTP and its API. Since RSPLIB currently r= uns=20 with kernel SCTP on Linux, FreeBSD and MacOS X as well as userland SCTP wit= h=20 SCTPLIB/Socket API on all supported platforms, I have also used the SCTP AP= I=20 of multiple independent SCTP implementations. In particular, due to its mul= ti- platform support and advanced SCTP usage, RSPLIB is a very useful tool to t= est=20 the SCTP Socket API. I think the API described in the draft is very useful and having it fixed a= s=20 RFC is crucial for a more widespread and compatible adoption of SCTP into=20 applications. On Dienstag 08 Februar 2011, James M. Polk wrote: > TSVWG >=20 > I am starting the WGLC for >=20 > "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)" > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ >=20 > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs > feel the WG has reviewed the draft and reached consensus to progress > towards the ADs with the goal of becoming a proposed standard (PS) RFC. >=20 > The chairs require substantive feedback from the WG regarding this > draft before consensus can be called. Best regards =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart1452139.4lgcH4cq8J Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1o9foACgkQ32BbsHYPLWVDMQCfRYNjffnm/nl+fGUCo4k1tRvU XN4AnjvXbHu8QmtFTB8uiV2fzfczVKX+ =FFNf -----END PGP SIGNATURE----- --nextPart1452139.4lgcH4cq8J-- From I.Ruengeler@fh-muenster.de Sat Feb 26 05:47:20 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884EC3A692F for ; Sat, 26 Feb 2011 05:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm-It9w8kUBm for ; Sat, 26 Feb 2011 05:47:19 -0800 (PST) Received: from mail.fh-muenster.de (dvz-002.FH-Muenster.DE [193.174.88.2]) by core3.amsl.com (Postfix) with ESMTP id 2910C3A6929 for ; Sat, 26 Feb 2011 05:47:18 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.fh-muenster.de (Postfix) with ESMTP id DD19A1CC34D; Sat, 26 Feb 2011 14:43:45 +0100 (CET) Received: from mail.fh-muenster.de ([127.0.0.1]) by localhost (dvz-002.fh-muenster.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKqUa70qOEp5; Sat, 26 Feb 2011 14:43:45 +0100 (CET) Received: from [192.168.179.26] (dslb-092-072-071-150.pools.arcor-ip.net [92.72.71.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: ruengele) by mail.fh-muenster.de (Postfix) with ESMTP id B15D21CC33D; Sat, 26 Feb 2011 14:43:44 +0100 (CET) Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-52-445821557 From: =?iso-8859-1?Q?Irene_R=FCngeler?= In-Reply-To: Date: Sat, 26 Feb 2011 14:48:04 +0100 Message-Id: <7528D21B-F3DF-4A8B-8CC9-D80C82BDF4EE@fh-muenster.de> References: <201102080311.p183BoXh025565@sj-core-5.cisco.com> To: tsvwg X-Mailer: Apple Mail (2.1082) Cc: "James M. Polk" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 13:47:20 -0000 --Apple-Mail-52-445821557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear all, I have read SCTP Socket API draft and implemented part of it in the INET = framework which is a widely used part of the OMNeT++ simulation = environment. The Socket API is very important in that it defines an interface between = SCTP and its upper layer, and thus makes porting applications from one = platform to another easier. I am very much in favor of advancing the draft to an RFC. Best regards Irene R=FCngeler >> From: "James M. Polk" >> Date: February 8, 2011 4:10:53 AM GMT+01:00 >> To: tsvwg >> Subject: WGLC for draft-ietf-tsvwg-sctpsocket-26 started >>=20 >> TSVWG >>=20 >> I am starting the WGLC for >>=20 >> "Sockets API Extensions for Stream Control Transmission Protocol = (SCTP)" >> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ >>=20 >> this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs = feel the WG has reviewed the draft and reached consensus to progress = towards the ADs with the goal of becoming a proposed standard (PS) RFC. >>=20 >> The chairs require substantive feedback from the WG regarding this = draft before consensus can be called. >>=20 >> I will be the document shepherd. >>=20 >> James >> TSVWG chair >>=20 >>=20 >>=20 ***************************************** Dr. Irene R=FCngeler=20 Fachhochschule M=FCnster, Abt. Steinfurt=20 FB Elektrotechnik und Informatik=20 Labor f=FCr Netzwerkprogrammierung, Datenbanklabor=20 Bismarckstr. 11=20 Tel.: 02551-962561=20 Fax: 02551-962563=20 EMail: I.Ruengeler@fh-muenster.de --Apple-Mail-52-445821557 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
From: "James M. Polk" = <jmpolk@cisco.com>
=
Date: February 8, 2011 4:10:53 AM = GMT+01:00
To: tsvwg <tsvwg@ietf.org>
Subject: WGLC for draft-ietf-tsvwg-sctpsocket-26 = started

TSVWG

I am starting = the WGLC for

"Sockets API = Extensions for Stream Control Transmission Protocol = (SCTP)"
http= ://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/

this is a 2 week WGLC, ending February 22nd, 2011 or when = the chairs feel the WG has reviewed the draft and reached consensus to = progress towards the ADs with the goal of becoming a proposed standard = (PS) RFC.

The chairs = require substantive feedback from the WG regarding this draft before = consensus can be called.

I will be the = document shepherd.

James
TSVWG = chair




*****************************************

Dr. Irene R=FCngeler 
Fachhochschule M=FCnster, Abt. = Steinfurt 
FB Elektrotechnik und = Informatik 
Labor f=FCr = Netzwerkprogrammierung, Datenbanklabor 
Bismarckstr. 11 
Tel.: = 02551-962561 
Fax: = 02551-962563 
EMail: I.Ruengeler@fh-muenster.de<= /font>







= --Apple-Mail-52-445821557-- From michawe@ifi.uio.no Sat Feb 26 05:58:42 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79AC73A692F for ; Sat, 26 Feb 2011 05:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1PrCM-CtkfM for ; Sat, 26 Feb 2011 05:58:41 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 625923A6929 for ; Sat, 26 Feb 2011 05:58:41 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PtKgJ-00054J-IE; Sat, 26 Feb 2011 14:59:35 +0100 Received: from cm-84.208.175.27.getinternet.no ([84.208.175.27] helo=[192.168.0.199]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PtKgJ-0000np-4h; Sat, 26 Feb 2011 14:59:35 +0100 Message-Id: <4F964A0F-1868-4EC7-9E98-732A76C2D80A@ifi.uio.no> From: Michael Welzl To: James M. Polk In-Reply-To: <201102080311.p183BoXh025565@sj-core-5.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Date: Sat, 26 Feb 2011 14:59:13 +0100 References: <201102080311.p183BoXh025565@sj-core-5.cisco.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 6949 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D82CC38C884F750DF92CF9545CE4EA8AB23FA1AA X-UiO-SPAM-Test: remote_host: 84.208.175.27 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 511 max/h 13 blacklist 0 greylist 0 ratelimit 0 Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 13:58:42 -0000 I also think that this is an extremely useful document and would like to see it as an RFC; and being version number 26, it has gone through enough iterations, I suppose :-) There's really not much of a point in specifying a transport protocol without providing its API IMO (and I'm looking in the direction of DCCP when I say this...) On Feb 8, 2011, at 4:10 AM, James M. Polk wrote: > TSVWG > > I am starting the WGLC for > > "Sockets API Extensions for Stream Control Transmission Protocol > (SCTP)" > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ > > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs > feel the WG has reviewed the draft and reached consensus to progress > towards the ADs with the goal of becoming a proposed standard (PS) > RFC. > > The chairs require substantive feedback from the WG regarding this > draft before consensus can be called. > > I will be the document shepherd. > > James > TSVWG chair > > From martin.becke@uni-due.de Sat Feb 26 11:39:52 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D31A3A67EE for ; Sat, 26 Feb 2011 11:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlG4AQBCHv-a for ; Sat, 26 Feb 2011 11:39:51 -0800 (PST) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by core3.amsl.com (Postfix) with ESMTP id ECBBF3A66B4 for ; Sat, 26 Feb 2011 11:39:50 -0800 (PST) Received: from HT01.win.uni-due.de (virt080.zim.uni-duisburg-essen.de [132.252.185.80]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id p1QJeGpB014256; Sat, 26 Feb 2011 20:40:16 +0100 Received: from ccr01.win.uni-due.de ([169.254.1.5]) by HT01.win.uni-due.de ([132.252.190.233]) with mapi id 14.01.0218.012; Sat, 26 Feb 2011 20:40:15 +0100 From: "Becke, Martin" To: "tsvwg@ietf.org" Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Thread-Topic: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Thread-Index: AcvV7Ay78v6sqxMURfWgTaeAqyTnYA== Date: Sat, 26 Feb 2011 19:40:15 +0000 Message-ID: <466847B318CFAB419C80EFC5014D621E8AD650@ccr01.win.uni-due.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.205.51.224] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 Cc: "James M. Polk" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 19:39:52 -0000 Hello all, IMO the Socket API document is important, needed and should be progressed. I have implemented parts of the described API as co-author of the measureme= nt tool netperfmeter and currently in a new library for video data transfer= with a special focus on the Multi-Homing capability. IMO this draft is ready for the next step.... However, here some minor Issues: Section 3.2: - Note that this can also be done using the sctp_send() call described in S= ection 9.10. Perhaps it could also be noted that this is deprecated... Section 3.3=20 The fact that a one-to-many style socket can provide access to many SCTP a= ssociations through a single socket descriptor has important implications f= or both application programmers and system programmers implementing this AP= I. -> This is hard to read. I think a comma is missing... If the reader stops reading, the sender queues messages in the socket layer= until it uses all of its socket buffer space allocation creating a "stalle= d connection". =20 -> For my feeling there is a word or separator missing... Section 4.18=20 The semantics is similar to those used in the one-to-many style (see Sectio= n 3.1.3), ->=20 should be Section 3.1.4 Section 5.1 In the msghdr structure, the usage of msg_name has been discussed in previ= ous sections (see Section 3.1.3 and Section 4.1.8). -> Found no discussion in 3.1.3 -> I think that is the same as above Section 5.3.9 and 5.3.10 What is send_msg() in this context? Is this a typo? Section 6.2.1 An example where an application would like to receive data io events and as= sociation events but no others would be as follows: -> IMO there should be a comma after data... Section 7.1 len: the size of the message or the size of the buffer. to: one of the peer addresses of the association to be used to send the me= ssage. ->=20 Upper Case The.... One... Section 7.5 (see Section 3.1.3). -> should be (see Section 3.1.4). Section (8.2) see Section 8.1.2 on spp_pathmaxrxt) ->=20 should be ...see Section 8.1.12 on spp_pathmaxrxt) Section 8.14 Posix -> POSIX=20 Section 8.1.12 spp_pathmaxrxt -> Just a naming, but a would expect spp_pathmaxrtx (rtx) Section 8.1.20 sctp_data_io_events=20 -> IMO using plural of sctp_data_io_event is not needed.=20 Section 8.1.27 At most one socket being bound to the same port may be listening. -> Mmmh..I'm not sure what is behind this Section 8.3.1 The order of the explanation of sspp_addr and sspp_assoc_id should be swit= ched Section 8.3.2 Add a Chunk That Must Be Authenticated (SCTP_AUTH_CHUNK) -> I'm not sure if this is the correct usage of upper and lower case.... (that= must be) Section 9.11 addrs: is an array of addresses. -> addrs: Is an array of addresses. -> I would switch the order of sctp_recvv() and sctp_sendv(). Most the used pattern is send/recv-like -> Check the draft for association id and association ID. The usage is not consistent. Best regards Martin=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0Martin Becke =A0University of Duisburg-Essen,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Room 308a =A0Inst. for Experimental Mathematics=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Ellernstra=DFe 29 =A0Computer Networking Technology Group=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0D-= 45326 Essen/Germany ----------------------------------------------------------------------- =A0Phone :=A0=A0=A0=A0 +49-201-183-7667 =A0E-Mail:=A0=A0=A0=A0 martin.becke@uni-due.de =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 On Dienstag 08 Februar 2011, James M. Polk wrote: > TSVWG >=20 > I am starting the WGLC for >=20 > "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)" > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ >=20 > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs=20 > feel the WG has reviewed the draft and reached consensus to progress=20 > towards the ADs with the goal of becoming a proposed standard (PS) RFC. >=20 > The chairs require substantive feedback from the WG regarding this=20 > draft before consensus can be called. From Michael.Tuexen@lurchi.franken.de Sun Feb 27 05:16:15 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726033A69AF for ; Sun, 27 Feb 2011 05:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtLWOkCb2kWi for ; Sun, 27 Feb 2011 05:16:14 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9FD0A3A69A3 for ; Sun, 27 Feb 2011 05:16:13 -0800 (PST) Received: from [192.168.1.113] (p508FAA71.dip.t-dialin.net [80.143.170.113]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 397891C0C0BED; Sun, 27 Feb 2011 14:17:08 +0100 (CET) Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <466847B318CFAB419C80EFC5014D621E8AD650@ccr01.win.uni-due.de> Date: Sun, 27 Feb 2011 14:17:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <466847B318CFAB419C80EFC5014D621E8AD650@ccr01.win.uni-due.de> To: "Becke, Martin" X-Mailer: Apple Mail (2.1082) Cc: "James M. Polk" , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 13:16:15 -0000 On Feb 26, 2011, at 8:40 PM, Becke, Martin wrote: >=20 > Hello all, >=20 > IMO the Socket API document is important, needed and should be = progressed. > I have implemented parts of the described API as co-author of the = measurement tool netperfmeter and currently in a new library for video = data transfer with a special focus on the Multi-Homing capability. >=20 > IMO this draft is ready for the next step.... >=20 > However, here some minor Issues: Hi Martin, thank you very much for the comments. >=20 > Section 3.2: >=20 > - Note that this can also be done using the sctp_send() call described = in Section 9.10. >=20 > Perhaps it could also be noted that this is deprecated... I changed the reference to sctp_sendv(). >=20 > Section 3.3=20 > The fact that a one-to-many style socket can provide access to many = SCTP associations through a single socket descriptor has important = implications for both application programmers and system programmers = implementing this API. >=20 > -> > This is hard to read. > I think a comma is missing... Inserted. >=20 >=20 > If the reader stops reading, the sender queues messages in the socket = layer until it uses all of its socket buffer space allocation creating a = "stalled connection". =20 > -> > For my feeling there is a word or separator missing... Changed to If the reader stops reading, the sender queues messages in the socket layer until the send socket buffer is completely filled. This results in a "stalled connection". >=20 > Section 4.18=20 >=20 > The semantics is similar to those used in the one-to-many style (see = Section 3.1.3), >=20 > ->=20 > should be Section 3.1.4 Fixed. >=20 > Section 5.1 > In the msghdr structure, the usage of msg_name has been discussed in = previous sections (see Section 3.1.3 and Section 4.1.8). >=20 > -> > Found no discussion in 3.1.3 -> I think that is the same as above Correct. Fixed. >=20 >=20 > Section 5.3.9 and 5.3.10 >=20 > What is send_msg() in this context? Is this a typo? Typo: sendmsg() is correct. >=20 > Section 6.2.1 >=20 > An example where an application would like to receive data io events = and association events but no others would be as follows: > -> > IMO there should be a comma after data... No, I do not think so. I changed it to An example where an application would like to receive data_io_events and association_events but no others would be as follows: which should make it cleaner.... >=20 > Section 7.1 >=20 > len: the size of the message or the size of the buffer. >=20 > to: one of the peer addresses of the association to be used to send = the message. >=20 > ->=20 > Upper Case > The.... > One... Fixed. >=20 > Section 7.5 >=20 > (see Section 3.1.3). > -> > should be (see Section 3.1.4). Fixed. >=20 > Section (8.2) >=20 > see Section 8.1.2 on spp_pathmaxrxt) >=20 > ->=20 > should be > ...see Section 8.1.12 on spp_pathmaxrxt) Fixed. >=20 > Section 8.14 > Posix -> POSIX=20 Fixed. >=20 > Section 8.1.12 > spp_pathmaxrxt > -> > Just a naming, but a would expect spp_pathmaxrtx (rtx) I too. But you can call this a deployed typo... Linux, FreeBSD and Solaris use this name. A similar on is sasoc_asocmaxrxt... >=20 > Section 8.1.20 >=20 > sctp_data_io_events=20 >=20 > -> IMO using plural of sctp_data_io_event is not needed.=20 Fixed. >=20 > Section 8.1.27 > At most one socket being bound to the same port may be listening. > -> > Mmmh..I'm not sure what is behind this We only want a single listening socket on a port. >=20 > Section 8.3.1 >=20 > The order of the explanation of sspp_addr and sspp_assoc_id should be = switched Fixed. >=20 > Section 8.3.2 >=20 > Add a Chunk That Must Be Authenticated (SCTP_AUTH_CHUNK) >=20 > -> > I'm not sure if this is the correct usage of upper and lower case.... = (that must be) Fixed. >=20 >=20 > Section 9.11 > addrs: is an array of addresses. > -> > addrs: Is an array of addresses. Fixed. >=20 > -> > I would switch the order of sctp_recvv() and sctp_sendv(). > Most the used pattern is send/recv-like Fixed. > -> > Check the draft for association id and association ID. > The usage is not consistent. Fixed. Using association identifier. >=20 >=20 > Best regards > Martin=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Martin Becke >=20 > University of Duisburg-Essen, Room 308a > Inst. for Experimental Mathematics Ellernstra=DFe 29 > Computer Networking Technology Group D-45326 Essen/Germany > = ----------------------------------------------------------------------- > Phone : +49-201-183-7667 > E-Mail: martin.becke@uni-due.de > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 > On Dienstag 08 Februar 2011, James M. Polk wrote: >> TSVWG >>=20 >> I am starting the WGLC for >>=20 >> "Sockets API Extensions for Stream Control Transmission Protocol = (SCTP)" >> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ >>=20 >> this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs=20= >> feel the WG has reviewed the draft and reached consensus to progress=20= >> towards the ADs with the goal of becoming a proposed standard (PS) = RFC. >>=20 >> The chairs require substantive feedback from the WG regarding this=20 >> draft before consensus can be called. >=20 From seggelmann@fh-muenster.de Sun Feb 27 23:54:38 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0593A6AD4 for ; Sun, 27 Feb 2011 23:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ-WPffPyhNo for ; Sun, 27 Feb 2011 23:54:38 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by core3.amsl.com (Postfix) with ESMTP id D4FF53A6AC8 for ; Sun, 27 Feb 2011 23:54:37 -0800 (PST) Received: from [212.201.121.94] (helo=[10.0.1.103]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PtxxA-00087Z-Dk; Mon, 28 Feb 2011 08:55:36 +0100 Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robin Seggelmann In-Reply-To: <201102080311.p183BoXh025565@sj-core-5.cisco.com> Date: Mon, 28 Feb 2011 08:55:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201102080311.p183BoXh025565@sj-core-5.cisco.com> To: James M. Polk X-Mailer: Apple Mail (2.1082) X-Df-Sender: mail@robin-seggelmann.de Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 07:54:38 -0000 Dear all, I have also read the draft and have been working with the SCTP API for = quite some time. Among other SCTP related projects, I implemented SCTP = support for OpenSSL and the API draft has always been a very helpful = resource and should become an RFC as soon as possible. Best regards Robin On Feb 8, 2011, at 4:10 AM, James M. Polk wrote: > TSVWG >=20 > I am starting the WGLC for >=20 > "Sockets API Extensions for Stream Control Transmission Protocol = (SCTP)" > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ >=20 > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs = feel the WG has reviewed the draft and reached consensus to progress = towards the ADs with the goal of becoming a proposed standard (PS) RFC. >=20 > The chairs require substantive feedback from the WG regarding this = draft before consensus can be called. >=20 > I will be the document shepherd. >=20 > James > TSVWG chair >=20 >=20 From pasi.sarolahti@iki.fi Mon Feb 28 01:08:57 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65833A6AC2 for ; Mon, 28 Feb 2011 01:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oQXnprlGt7u for ; Mon, 28 Feb 2011 01:08:56 -0800 (PST) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by core3.amsl.com (Postfix) with ESMTP id 8CC113A692D for ; Mon, 28 Feb 2011 01:08:56 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id p1S99stD031062 for ; Mon, 28 Feb 2011 11:09:54 +0200 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 07189-418 for ; Mon, 28 Feb 2011 11:09:54 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id p1S99rIi031051 for ; Mon, 28 Feb 2011 11:09:53 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 4D5321E141 for ; Mon, 28 Feb 2011 11:09:53 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8YMhRNKqxUN0 for ; Mon, 28 Feb 2011 11:09:49 +0200 (EET) Received: from [192.168.0.10] (cs181059059.pp.htv.fi [82.181.59.59]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 6F3601E0C0 for ; Mon, 28 Feb 2011 11:09:49 +0200 (EET) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: [dccp] WGLC for draft-ietf-dccp-udpencap Date: Mon, 28 Feb 2011 11:09:49 +0200 References: <9610_1298631433_ZZ0LH600GE26F708.00_9847_1298631427_4D678B03_9847_2510_1_51F3C3D7-3CA1-4A4E-AAF3-A526F253B497@iki.fi> To: tsvwg IETF list Message-Id: <0F4E2D93-F132-4FE8-AF69-8313A0B0BD69@iki.fi> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 09:08:57 -0000 Hello, We just started DCCP WG last call on draft-ietf-dccp-udpencap that = specifies UDP encapsulation for DCCP packets (see pointer below). The = issue of UDP encapsulation was discussed earlier also on this list, so = people might be interested to read the draft. Please send comments to = the DCCP mailing list by March 11. Thanks! - Pasi Begin forwarded message: > From: Pasi Sarolahti > Date: February 25, 2011 12:56:46 PM GMT+02:00 > To: 'dccp' working group > Subject: [dccp] WGLC for draft-ietf-dccp-udpencap >=20 > Hi, >=20 > This mail starts a working group last call for the UDP encapsulation = draft. The draft is available at = http://tools.ietf.org/html/draft-ietf-dccp-udpencap-06 . Please read the = draft and send any comments to the DCCP mailing list. >=20 > The WGLC lasts for two weeks, until March 11. >=20 > - Pasi >=20 From Michael.Tuexen@lurchi.franken.de Mon Feb 28 01:41:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2103A3A69CD for ; Mon, 28 Feb 2011 01:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LZ9Py34auKt for ; Mon, 28 Feb 2011 01:41:49 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 0EC4C3A69C1 for ; Mon, 28 Feb 2011 01:41:48 -0800 (PST) Received: from [192.168.1.113] (p508FCD42.dip.t-dialin.net [80.143.205.66]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 763B81C0B4624 for ; Mon, 28 Feb 2011 10:42:46 +0100 (CET) From: =?iso-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: SCTP socket API implementations Date: Mon, 28 Feb 2011 10:42:45 +0100 Message-Id: <9FD08021-3027-4664-96BE-2340AE7A86A6@lurchi.franken.de> To: "tsvwg@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 09:41:50 -0000 Dear all, I just wanted to state that http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket was used by the FreeBSD, Linux and Solaris developers to make sure that programs using SCTP can be written in a portable way. These developers are represented by coauthors, problems coming up during the implementation resulted in text improvements. This is done for a long time, almost since the beginning of the writing of the document. The ID was also used for the SCTP kernel implementations in HP-UX and AIX. The FreeBSD implementation has been ported to Windows and Mac OS X. However, these are not supported by the vendors of the operating system but also support the Socket API. A portable userland implementation of the socket API is available which uses a portable SCTP userland implementation. There is substantial implementation experience, however not every feature is currently implemented by every implementation. The latest additions, for example, have not been incorporated. Most of the deprecated ones are implemented and since they are implemented as documented, we kept the descriptions in the ID. Best regards Michael From leighton@cis.udel.edu Mon Feb 28 11:17:17 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6273A6A27 for ; Mon, 28 Feb 2011 11:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knX262zJRiGh for ; Mon, 28 Feb 2011 11:17:16 -0800 (PST) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by core3.amsl.com (Postfix) with ESMTP id 5117C3A6820 for ; Mon, 28 Feb 2011 11:17:16 -0800 (PST) Received: from imac-24.home (pool-173-75-228-224.phlapa.fios.verizon.net [173.75.228.224]) (Authenticated sender: leighton@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id C717B18CA for ; Mon, 28 Feb 2011 14:18:16 -0500 (EST) Message-ID: <4D6BF4F8.2000408@cis.udel.edu> Date: Mon, 28 Feb 2011 14:18:16 -0500 From: Jon Leighton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leighton@cis.udel.edu List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 19:17:17 -0000 Dear All, I have read the draft and have worked with the SCTP API for many years. It has been invaluable to me in a number projects I've worked on, including creating SCTP enabled versions of NSPR, Firefox and Chrome, on multiple platforms. I fully support the draft being advanced to an RFC. Respectfully, Jon Leighton On Feb 8, 2011, at 4:10 AM, James M. Polk wrote: > TSVWG > > I am starting the WGLC for > > "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)" > http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/ > > this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs feel the WG has reviewed the draft and reached consensus to progress towards the ADs with the goal of becoming a proposed standard (PS) RFC. > > The chairs require substantive feedback from the WG regarding this draft before consensus can be called. > > I will be the document shepherd. > > James > TSVWG chair