Last Call: <draft-ietf-tsvwg-iana-ports-09.txt>(InternetAssigned Numbers Authority (IANA) Procedures for theManagementof the Service Name and Transport Protocol PortNumberRegistry) to BCP

"t.petch" <ietfc@btconnect.com> Wed, 16 February 2011 12:28 UTC

Return-Path: <ietfc@btconnect.com>
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 <tsvwg@core3.amsl.com>; 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 <tsvwg@core3.amsl.com>; 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 <tsvwg@ietf.org>; 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" <ietfc@btconnect.com>
To: tsvwg@ietf.org
Subject: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt>(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 <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Feb 2011 12:28:13 -0000

----- Original Message -----
From: "t.petch" <daedulus@btconnect.com>
To: "Cullen Jennings" <fluffy@cisco.com>; "Christian Huitema"
<huitema@microsoft.com>
Cc: "IETF discussion list" <ietf@ietf.org>; <tsvwg@ietf.org>; "IESG IESG"
<iesg@ietf.org>
Sent: Wednesday, February 16, 2011 12:13 PM
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt>(InternetAssigned
Numbers Authority (IANA) Procedures for theManagementof the Service Name and
Transport Protocol PortNumberRegistry) to BCP


>
> ---- Original Message -----
> From: "Cullen Jennings" <fluffy@cisco.com>
> To: "Christian Huitema" <huitema@microsoft.com>
> Cc: <tsvwg@ietf.org>; "Paul Hoffman" <paul.hoffman@vpnc.org>; "Chris Benson"
> <cbenson@adax.com>; "IESG IESG" <iesg@ietf.org>; "Sam Hartman"
> <hartmans-ietf@mit.edu>; "IETF discussion list" <ietf@ietf.org>
> 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