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

"t.petch" <daedulus@btconnect.com> Thu, 27 January 2011 17:59 UTC

Return-Path: <daedulus@btconnect.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 AE46A3A684C; Thu, 27 Jan 2011 09:59:36 -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=[AWL=0.000, 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 kuprjlyINNLU; Thu, 27 Jan 2011 09:59:31 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by core3.amsl.com (Postfix) with ESMTP id 1AEF73A67CF; Thu, 27 Jan 2011 09:59:30 -0800 (PST)
Received: from host86-134-204-119.range86-134.btcentralplus.com (HELO pc6) ([86.134.204.119]) by c2beaomr07.btconnect.com with SMTP id BOB92254; Thu, 27 Jan 2011 18:02:28 +0000 (GMT)
Message-ID: <00a401cbbe43$76e693e0$4001a8c0@gateway.2wire.net>
From: "t.petch" <daedulus@btconnect.com>
To: Lars Eggert <lars.eggert@nokia.com>, Cullen Jennings <fluffy@cisco.com>
References: <20110118212603.5733.34489.idtracker@localhost><B88A8A82-9C4A-40AC-89AF-F177260760F7@cisco.com> <ECA80A72-4E72-44D2-B40E-C90D7197E8C5@nokia.com>
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (InternetAssigned Numbers Authority (IANA) Procedures for the Managementof the Service Name and Transport Protocol Port NumberRegistry) to BCP
Date: Thu, 27 Jan 2011 17:58:43 +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=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D41B334.00A8, actions=tag
X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4D41B335.0037, 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: IESG IESG <iesg@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: Thu, 27 Jan 2011 17:59:36 -0000

And what happens when we have ProtocolX over SSH and ProtocolX over TLS?

Must they share a port, with ProtocolX, which has been quietly using its
assigned port for
20 years?

Tom Petch


----- Original Message -----
From: "Lars Eggert" <lars.eggert@nokia.com>
To: "Cullen Jennings" <fluffy@cisco.com>; "Paul Hoffman" <paul.hoffman@vpnc.org>
Cc: "IESG IESG" <iesg@ietf.org>; "IETF discussion list" <ietf@ietf.org>;
<tsvwg@ietf.org>
Sent: Thursday, January 27, 2011 9:52 AM
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (InternetAssigned
Numbers Authority (IANA) Procedures for the Managementof the Service Name and
Transport Protocol Port NumberRegistry) to BCP


On 2011-1-27, at 2:12, Cullen Jennings wrote:
> Big Issues 1: I don't like mandating one port for secure and not secure
versions of a protocol
>
> I don't think this reflects IETF consensus given the number of protocols that
deliberately choses to use two ports. I also don't think that it is a good idea
in all cases. I believe the decision should be left to the people designing the
protocol if they want one port or two. Let me give some examples

Paul Hoffman raised this issue as well (email from Nov 4 to this list.)

There was some discussion that lead to Paul suggesting specific edit to this
document. (Which are not reflected in -09; us editors may have dropped the ball
here). I'm attaching Paul's proposed changes below, could you check if you'd
agree with them?

> Big Issue #2: The draft has close to no review advice for the expert reviewer.

Joe Touch (who leads the expert review team for ports) is working on a separate
document (draft-touch-tsvwg-port-use). The first version of that draft was
issued on the same day as the -09 version of iana-ports, which is why we don't
refer to it.

Does draft-touch-tsvwg-port-use have the content you are looking for? If so, we
should refer to it. (We should probably refer to it anyway, in a "you may also
want to read this" kind-of way.)

> 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?

Lars

PS: Paul's proposed changes re item #1:

Begin forwarded message:
> From: Paul Hoffman <paul.hoffman@vpnc.org>
> Date: November 15, 2010 21:44:24 GMT+02:00
> To: <tsvwg@ietf.org>
> Subject: Proposed resolution for security issues with
draft-ietf-tsvwg-iana-ports-08
>
> As this list and the TLS has seen, there is a wide variety of views on how to
deal with fallback-to-insecure in protocols. I believe that the security
community has no consensus on what this means, much less how to do it. My
earlier proposal (continue to allow registration of two ports) was popular with
some, unpopular with others; similarly, so was "force all protocols to use one
port".
>
> Therefore, I retract my proposal to allow two-port registrations for
fallback-to-insecure. However, I still recommend some changes to the text to
reflect the view that STARTTLS is not the only way to have such a feature on one
port.
>
> This will be an interesting IETF Last Call discussion.
>
> I propose the following changes to draft-ietf-tsvwg-iana-ports:
>
> Section 7.2 current:
> o  IANA will allocate only one assigned port number for all versions
>   of a service (e.g., running the service with or without a security
>   mechanism, or for updated variants of a service)
>
> Section 7.2 current:
[in the line above s/current/proposed/, I think]
> o  IANA will normally allocate only one assigned port number for all versions
>   of a service (e.g., running the service with or without a security
>   mechanism, or for updated variants of a service). This policy can
>   be overridden by the expert reviewer.
>
> Section 7.2 current:
>   Further,
>   previous separation of protocol variants based on security
>   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
>   not recommended for new protocols, because all new protocols should
>   be security-capable and capable of negotiating the use of security
>   in-band.
>
> Section 7.2 proposed:
>   Further,
>   previous separation of protocol variants based on security
>   capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
>   not recommended for new protocols, because all new protocols should
>   be security-capable.
>
> --Paul Hoffman, Director
> --VPN Consortium