Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice
Alexey Melnikov <alexey.melnikov@isode.com> Sun, 04 January 2015 19:35 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3191A8ABD; Sun, 4 Jan 2015 11:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV1llmnWK56b; Sun, 4 Jan 2015 11:35:57 -0800 (PST)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 365851A8ABC; Sun, 4 Jan 2015 11:35:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1420400156; d=isode.com; s=selector; i=@isode.com; bh=zC9N4hlw2wmyeH7JezAiGPPvICAaol5t4IF40c2h3p0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KAJ7ocBwaK5X47wdoPL6ZyTKZirvXK5O58YKGRpHI9/ofjKD8dWvDGqFMWbpBp0miUL2OT NZHvjmCYZb16HQ8AsjeTnq4A98PHrXfvqE7topK9Ft/wx2sGehp0yezJYBBeibb6JLSU1C tvyBf1XRn8RigiYWc/NYmmgyU3Orb1o=;
Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id <VKmWGwAKaF=n@waldorf.isode.com>; Sun, 4 Jan 2015 19:35:55 +0000
Message-ID: <54A990F4.9040509@isode.com>
Date: Sun, 04 Jan 2015 19:13:56 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice
References: <20141208235619.4442.37821.idtracker@ietfa.amsl.com>
In-Reply-To: <20141208235619.4442.37821.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/prOc05eEPX-wJwj6MYjuxmIckAY
Cc: tsvwg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 04 Jan 2015 19:35:59 -0000
On 08/12/2014 23:56, The IESG wrote: > The IESG has received a request from the Transport Area Working Group WG > (tsvwg) to consider the following document: > - 'Recommendations for Transport Port Number Uses' > <draft-ietf-tsvwg-port-use-06.txt> as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document provides recommendations to application and service > designers on how to use the transport protocol port number space. IT > complements (but does not update) RFC6335, which focuses on IANA > process. My apologies for late review of the document. I generally think that the document is well written and is nearly done, but I have some comments/concerns. 1. Introduction This document provides information and advice to system designers on the use of transport port numbers. It provides a detailed historical background of the evolution of transport port numbers and their multiple meanings. It also provides specific recommendations to system designers on how to use assigned port numbers. Note that this document provides information to potential port number applicants that complements the IANA process described in BCP165 [RFC6335], but it does not update that document. I am a bit confused by the status and purpose of this document. It is a BCP, but the introducting says that it is purely informational. But then the document has lots of RFC 2119 language. Is there any intent for this document to be of use to port expert reviewers, for example if they want to point out why a particular port registration request is rejected? In 7.1: Additional port numbers are not intended to replicate an existing service. For example, if a device is configured to use a typical web browser then it the port number used for that service is a copy of the http service that is already assigned to port number 80 and does not warrant a new assignment. However, an automated system that happens to use HTTP framing - but cannot be accessed by a browser - might be I have some concerns about "be access by a browser". One particular case I have in mind is when a service expose some data using JSON or ASN.1 (for example a certificate revocation list is returned), but also allow a browser to view certificate in a nice form using HTML (e.g. for debugging or convenience). I don't think the ability to return HTML automatically disqualify this from being an independent service, because the whole functionality supported by the service can't be implemented just by use of returned HTML. Inserting "solely" before "by a browser" would address my concern. a new service. A good way to tell is "can an unmodified client of the existing service interact with the proposed service"? If so, that service would be a copy of an existing service and would not merit a new assignment. In 7.4: Note however that a new service might not be eligible for IANA assignment of both an insecure and a secure variant of the same service, and similarly IANA might be skeptical of an assignment for I don't think use of wording like "IANA might be skeptical" is correct here, because IANA doesn't define policy on this. IETF does. So let's call things with right names and don't misuse "IANA" here. an insecure port number for a secure service. In both cases, security of the service is compromised by adding the insecure port number assignment. Similarly (in the same section): "IANA currently permits ..."
- Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt>… Alexey Melnikov
- Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt>… Joe Touch
- Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt>… Alexey Melnikov
- Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt>… Joe Touch
- RE: [tsvwg] Last Call: <draft-ietf-tsvwg-port-use… Black, David
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-port-use… Spencer Dawkins at IETF
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-port-use… Alexey Melnikov
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-port-use… gorry
- Re: [tsvwg] Last Call: <draft-ietf-tsvwg-port-use… gorry