Joe Thanks for the information. I had missed the IESG update to the guidelines on Port allocation, which relaxes the constraints on a separate port for security a little.
Also, from experience with requests to IANA for the specification of URI and such like schemes, where there is a pro forma which I always see in the requesting RFC, I had imagined that something similar would now be needed for Port number requests but perhaps not; and if there is, then you have provided it for us. Tom Petch ----- Original Message ----- From: "Joe Touch" <[email protected]> To: "t.petch" <[email protected]> Cc: "Christopher Morrow" <[email protected]>; <[email protected]>; <[email protected]>; "Randy Bush" <[email protected]> Sent: Monday, August 22, 2011 6:01 PM > On 8/22/2011 4:03 AM, t.petch wrote: > > Chris > > > > I don't know if your training included > > draft-ietf-tsvwg-iana-ports-10 > > currently in AUTH48 but it does say, as some on this list know well, > > > > " A service name or port number assignment request contains the > > following information. The service name is the unique identifier of > > a given service: > > > > Service Name (REQUIRED) > > Transport Protocol(s) (REQUIRED) > > Assignee (REQUIRED) > > Contact (REQUIRED) > > Description (REQUIRED) > > Reference (REQUIRED) > > Port Number (OPTIONAL) > > Service Code (REQUIRED for DCCP only) > > Known Unauthorized Uses (OPTIONAL) > > Assignment Notes (OPTIONAL)" > > > > which suggests a fairly rapid rejection of our I-D. > > Sure, but on trivial grounds (the service names you provide have spaces). > > To assist with your application, here's a suggestion (this need not be > in the RFC, but the RFC should conform to the following information > where it differs, e.g., the list of requested service names - note that > this isn't guaranteed to fly, though, as per below): > > Service Name (REQUIRED) RPKI-Rtr > Transport Protocol(s) (REQUIRED) TCP > Assignee (REQUIRED) IESG <[email protected]> (as per sec 8.1.1.) > Contact (REQUIRED) IETF Chair <[email protected]> > Description (REQUIRED) request/response exchange, including > an initial message indicating version number; data transferred > as native records with in-band record separators and > transaction terminators; transport connection is > persistent across multiple request/response exchanges; > exchanges MUST be protected by access control, and MAY > use TCP MD5, TCP-AO, or IPsec > Reference (REQUIRED) See RFC (TBD) > Port Number (OPTIONAL) any in the well-known range > Service Code (REQUIRED for DCCP only) N/A > Known Unauthorized Uses (OPTIONAL) N/A > Assignment Notes (OPTIONAL) > > Service Name (REQUIRED) RPKI-Rtr-TLS > Transport Protocol(s) (REQUIRED) TCP > Assignee (REQUIRED) (as per sec 8.1.1.) > Contact (REQUIRED) IETF Chair <[email protected]> > Description (REQUIRED) request/response exchange, including > an initial message indicating version number; data transferred > as native records with in-band record separators and > transaction terminators; transport connection is > persistent across multiple request/response exchanges; > exchanges MUST be protected by access control and TLS > Reference (REQUIRED)See RFC (TBD) > Port Number (OPTIONAL) any in the well-known range > Service Code (REQUIRED for DCCP only) N/A > Known Unauthorized Uses (OPTIONAL) N/A > Assignment Notes (OPTIONAL) > > Regarding Chris's question: > On 8/22/2011 6:17 AM, Christopher Morrow wrote: > > Oddly, 'CONTACT' there is a person? or a WG? a 'person' seems > > non-scalable in a number of dimensions. > > Again see Sec 8.1.1. It's a person (usually the person who issues the > request) in all cases except IETF document stream assignments. > > > The section on two ports or > > one, which I alluded to earlier, is section 7.2 which starts with > > " o IANA strives to assign only one assigned port number per service > > or application"\ > > This was updated as a result of IETF last call and IESG review. The > current text (pending final typo corrections) reads as follows (the > tracker here shows this:) > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/writeup/ > > -- > o IANA strives to assign only one assigned port number per service > or application > > Note: At the time of writing of this document there is no IETF consensus > on when it is appropriate to use a second port for an insecure version > of a protocol. > -- > > This is a bit of a sticky example, mostly because you're asking for a > well-known port. It'd help to have IESG consensus on the use of an > insecure protocol in that range. > > The current doc is a bit confusing on this point - do you ever intend to > allow both insecure and TCP MD5/TCP-AO/IPsec on the same port? > > AFAICT, you actually want (need) three ports: > > RPKI-Rtr-open - insecure > RPKI-Rtr-tnsec - transport/network security > RPKI-Rtr-apsec - application-layer security (TLS) > > Then you need to explain clearly why you *cannot* determine which > category a connection falls from the packets that arrive -- and > performance alone is not a sufficient reason (that could then be used to > argue, e.g., for dozens of ports for various services, and the port > space is too limited to support that just for performance reasons). > > It seems like -open is an uphill issue if you ask for a well-known port, > IMO. > > Joe _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
