Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice

[Alexey Melnikov <[e-mail]>]

Hi Joe,

On 16/01/2015 18:56, Joe Touch wrote:
> Hi, Alexey (et al.),
>
> Suggestions on how to address these concerns below.
>
> On 1/4/2015 11:13 AM, Alexey Melnikov wrote:
>> 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
>>> [e-mail] mailing lists by 2014-12-22. Exceptionally, comments may be
>>> sent to [e-mail] 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?
> AFAICT, expert reviewers can use any reason they want to recommend an
> approval or rejection; the same is true for IANA. There is an appeals
> process to the IESG when a decision disagreement occurs, and they can
> make decisions on a case-by-case basis.
>
> The review team does try to provide a consistent set of responses, i.e.,
> to treat similar requests as similarly as possible, but again that's not
> scripted.
>
> I don't think it's useful to closely or tightly constrain a process
> which is both advisory and intended to deal with corner cases.
>
> That's why I think it's appropriate for this doc to be BCP
> recommendation to the user (which is how it's written), rather than
> explicit constraints for expert review. However, I would expect that
> recommendations for users from TSV would be taken as context for
> reviews, as would any other TSV documents.
My concerns is that BCP are commonly used by ADs to enforce compliance. 
So I am wondering why this document is not just Informational?
>> 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.
> Would "primarily" also work? It's hard to argue "solely" even for
> conventional web access.
Yes, "primarily" is actually better.
>>           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.
> The document isn't written by IANA. We recommend to IANA, and IANA makes
> a decision that the IESG can override. I don't think it's outside the
> scope of the doc to indicate this context.
Actually I disagree. IANA is just following procedure prescribed by 
IETF. Experts are not really acting as advisors (although in practice 
there is always a dialogue, which is as it should be).
> Would it be preferable to say that "applications asking for both...
> might not be approved when..."?
Yes.
>>     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 ..."
> Same solution here?
Sure.