Hi, Tom,
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
