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 >> ietf@xxxxxxxx mailing lists by 2014-12-22. Exceptionally, comments may be >> sent to iesg@xxxxxxxx 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. > 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. > 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. Would it be preferable to say that "applications asking for both... might not be approved when..."? > 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? Joe