Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

Cullen Jennings <fluffy@cisco.com> Mon, 31 January 2011 17:41 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C213A6977; Mon, 31 Jan 2011 09:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.583
X-Spam-Level:
X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 2yJszrRVSqii; Mon, 31 Jan 2011 09:41:15 -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 BDFA33A6807; Mon, 31 Jan 2011 09:41:15 -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: AvsEAISDRk2rR7Hu/2dsb2JhbACkeXOiPJsQhU4EhROHDoNF
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2011 17:44:30 +0000
Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0VHiSJH013208; Mon, 31 Jan 2011 17:44:29 GMT
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4D46E623.3080602@ericsson.com>
Date: Mon, 31 Jan 2011 10:44:28 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com>
References: <20110118212603.5733.34489.idtracker@localhost> <B88A8A82-9C4A-40AC-89AF-F177260760F7@cisco.com> <ECA80A72-4E72-44D2-B40E-C90D7197E8C5@nokia.com> <4D421795.70505@isi.edu> <EFADE5D0-BB33-4418-B743-DFEC11B12740@cisco.com> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <B1E38EDF-E78E-47E2-B9A9-D7320A908217@nokia.com> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <F2152494-8C79-4A0F-951F-B3DB1D274A61@cisco.com> <4D46E623.3080602@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1082)
Cc: IESG IESG <iesg@ietf.org>, IETF discussion list <ietf@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2011 17:41:16 -0000

On Jan 31, 2011, at 9:41 , Magnus Westerlund wrote:

> Cullen Jennings skrev 2011-01-31 17:13:
> 
>> Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. 
> 
> I am not certain I understand what your issue is here. Is it that they
> can come to different conclusions, and that IETF can decided to override
> the expert review team? I think that is the logical conclusion, as the
> IETF's decision will have gone through a consensus process. One which
> the expert can provide their view into this.
> 
>> 
>> I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. 
> 
> 
> My reading of the WG last call consensus is that nobody is disagreeing
> with the goal of trying minimize the port consumption. My interpretation
> is that we do need to state that goal in the document. And the only way
> of achieving this is to try to minimize the consumption by each protocol
> that requires a registration. That includes trying to get all
> multiplexing into that single socket, or at least use it for agreeing on
> dynamic range port for this protocol.
> 
>> 
>> I'm sure that some people believe the draft, by using the word "strives", actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that "strives" means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this. 
> 
> It is a high level goal to minimize the port space consumption. I do
> believe there is strong consensus for this. And I believe that the only
> way of ensuring that this goal is meet is to take a pretty hard stance
> against frivolous use of ports.
> 
> Thus, I still think there is clear grounds for rejecting requests for
> multiple ports based on not sufficiently motivating why it is impossible
> to not use one port. I do agree that these guidelines should be
> documented, and that is the plans as far as I know.

Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that.