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(_at_)ietf(_dot_)org mailing lists by 2014-12-22. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)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 ..."