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 16:10 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 C17D33A6C3F; Mon, 31 Jan 2011 08:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.582
X-Spam-Level:
X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Op4uPkcF4THd; Mon, 31 Jan 2011 08:10: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 554D83A6C39; Mon, 31 Jan 2011 08:10: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: AvsEAFtuRk2rR7Ht/2dsb2JhbACkeXOiNJp7hU4EhROHDoNF
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2011 16:14:00 +0000
Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0VGDwuU011891; Mon, 31 Jan 2011 16:13:58 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1082)
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
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4D46D1D3.10701@vpnc.org>
Date: Mon, 31 Jan 2011 09:13:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2152494-8C79-4A0F-951F-B3DB1D274A61@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>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Lars Eggert <lars.eggert@nokia.com>, tsvwg@ietf.org, IETF discussion list <ietf@ietf.org>, IESG IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.1082)
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 16:10:53 -0000

On Jan 31, 2011, at 8:14 , Paul Hoffman wrote:

> On 1/31/11 7:06 AM, Lars Eggert wrote:
> > But I see the point you're raising. The document should somewhere say
> > that "Expert Review" is the procedure used for assignment requests
> > made directly to IANA, whereas for documents on the IETF Stream,
> > "IETF Consensus" is sufficient to make the assignment. In other
> > words, no expert review doesn't really need to happen for those,
> > since IETF Review and IESG Approval are at least equivalent.
> >
> > Did I get that right?
> 
> Yes, that would greatly reduce the concern about where and when (and how
> often!) the review would happen.
> 

Hmm ... I don't agree that solves the issue. 

Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. 

I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. 

I'm sure that some people believe the draft, by using the word "strives", actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that "strives" means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this.