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

Joe Touch <touch@isi.edu> Sun, 30 January 2011 17:31 UTC

Return-Path: <touch@isi.edu>
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 863DA3A6AF1; Sun, 30 Jan 2011 09:31:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.502
X-Spam-Level:
X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 LK2u4Kuh5rO6; Sun, 30 Jan 2011 09:31:14 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 23BBF3A6ABD; Sun, 30 Jan 2011 09:31:14 -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 vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0UHY2IY008760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 30 Jan 2011 09:34:13 -0800 (PST)
Message-ID: <4D45A105.1020102@isi.edu>
Date: Sun, 30 Jan 2011 09:33:57 -0800
From: Joe Touch <touch@isi.edu>
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 <paul.hoffman@vpnc.org>
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
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>
In-Reply-To: <4D457FD9.5030905@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: Cullen Jennings <fluffy@cisco.com>, IESG IESG <iesg@ietf.org>, tsvwg@ietf.org, IETF discussion list <ietf@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: Sun, 30 Jan 2011 17:31:15 -0000

Paul (et al.),

See below.

Note that IANA can't just make its own decisions either and ignore IETF 
process *AND* expert review.

I wasn't trying to imply that, but it appears to have been inferred from 
my claim that "neither document binds IANA to the advice of a reviewer". 
IANA is bound by the "OR" of basic IETF process and Expert Review. The 
former can override the latter (or vice versa), but there is an appeal 
process - through the IETF - as well.

If you have issue with these processes, then RFC 2434 and RFC 2780 are 
your targets, not this doc.

Joe

On 1/30/2011 7:12 AM, Paul Hoffman wrote:
> On 1/29/11 9:34 PM, Joe Touch wrote:
...
>> As per my other note:
>> RFC2780 specifies Expert Review as *one* of the viable means by which
>> IANA can decide on transport protocol port assignments. The term "Expert
>> Review" is defined in RFC 2434.
>>
>> Neither document binds IANA to use the advice of a reviewer.
>>
>> Further, there is no single reviewer - we have a team, consulting each
>> other on occasion, and all decisions are seen by multiple reviewers.
>> However, none of that is worth codifying. If IANA or the IESG doesn't
>> like how we serve them, they can replace us - at any time, for any
>> reason, and there is an appeals process for decisions of the expert team:
>>
>> Any decisions made by the designated expert can be appealed using the
>> normal IETF appeals process as outlined in Section 6.5 of [IETF-
>> PROCESS].
>
> Now that this has been made clear to me, I am *much* more worried about
> the wording in the current draft. The above emphatic statements means
> that IANA can reject a request for an IETF-approved protocol that needs
> two ports without recourse.

Repeating myself:

a) this document is NOT proscribing IANA processes for expert review of 
port requests

b) RFC 2790 describes MANY ways IANA decides how to allocate ports:

    Values in this namespace are assigned following a Specification
    Required, Expert Review, IESG Approval, IETF Consensus, or Standards
    Action.

Note the word *OR* above. Expert review doesn't override IETF process here.

> The document should be amended to say that protocols with IETF
> consensus should get as many ports as it needs, regardless of what
> IANA or the expert reviewer thinks.

The above section already allows for that.

> This makes it the responsibility
> of the IETF consensus process to follow the guidelines in this
> document.

This document says, quite clearly, at the front of Section 7.2:

    This section summarizes the current principles by which IANA handles
    the Service Name and Transport Protocol Port Number Registry and
    attempts to conserve the port number space.  This description is
    intended to inform applicants requesting service names and port
    numbers.  IANA has flexibility beyond these principles when handling
    assignment requests; other factors may come into play, and exceptions
    may be made to best serve the needs of the Internet.

It never says that this is a process that the IESG or IETF is required 
to follow. The language of the section has wiggle words throughout, and 
does not use RFC 2119 language. Thus nobody anywhere is bound by it.

c) RFC 2434 notes how expert reviewers are selected:

    Designated experts are appointed by the relevant Area Director of the
    IESG. They are typically named at the time a document that creates a
    new numbering space is published as an RFC, but as experts originally
    appointed may later become unavailable, the relevant Area Director
    will appoint replacements if necessary.

d) there is already a process to appeal decisions that are based on 
Expert Review:

    Any decisions made by the designated expert can be appealed using the
    normal IETF appeals process as outlined in Section 6.5 of [IETF-
    PROCESS]. Since the designated experts are appointed by the IESG,
    they may be removed by the IESG.

------