Re: [port-srv-reg] ACTION ITEMS - final updates - ports doc

[Lars Eggert <[e-mail]>]

Hi,

Gorry and me did our to-dos. Which gives me the moral high ground :-) to point the finger and ask all of you to please get to the things that have your name on them in the list below. We need to progress this document to IETF LC before Maastricht.

Lars

On 2010-5-5, at 21:28, Joe Touch wrote:

> As requested by Lars, here's the list of action items pending on the
> ports doc.
> 
> I've included the answer to my action item herein.
> 
> Joe
> 
> ******************************************************************************
> 
> Update to the updates:
> 
> ------------------------------------------------------------------------------
> 
> - assigned vs registered
> 
> 5226 is IANA Considerations, explains what these terms mean.
> 
> Mark:
> 
> Will give us text & check for consistency throughout the doc.
> 
> ------------------------------------------------------------------------------
> 
> - need to specify transports for service names
> 
> Lars:
> 
> This focuses on how to ask for a service name.
> 
> Ask for just a service name. The entry will be:
> 	banana TCP
> 	banana UDP
> 
> Olafur's doc will indicate how to use this.
> 
> ------------------------------------------------------------------------------
> 
> - who gets to add transports to a service that exists?
> 
> Draft text:
> 
> IANA will reserve updates that add transports to existing services with
> priority to the owner of the existing registrations, with exceptions
> coordinated with the IESG.
> 
> ------------------------------------------------------------------------------
> 
> - WKS needs to be addressed
> 
> Olafur:
> 
> Remove WKS text from our docs. Point to Olafur's doc, which closes other
> registries as a result.
> 
> ------------------------------------------------------------------------------
> 
> - the online tables may need to support "sort on multiple fields"
> 
> IANA action item TBD. Does not affect doc.
> 
> ------------------------------------------------------------------------------
> 
> - Alfred's observation that, "looking for "transport"/"protocol", I
> found that the draft repeatedly uses "protocol number[s]" or even
> "address[es]" where it should say "port number[s]"
> 
> Olafur:
> 
> Will check for consistency.
> 
> ------------------------------------------------------------------------------
> 
> - the doc should focus on user interfaces to IANA actions
> 
> Current intro/abstract are OK. No changes to doc.
> 
> ------------------------------------------------------------------------------
> 
> - Gorry's input that: Section 10.3.1:  It is good to also cite RFC 5595
>>>>>>> (you currently cite the draft) for service code information,
> since this
>>>>>>> updated RFC 4340 in many ways. Also Section 10.3.2 since this
> explains
>>>>>>> how ports and SC interact and how you can manage without port
> allocations
>>>>>>> To be added (AFAICT, it wasn't yet)
> 
> Gorry:
> 
> To fix as request. Check also the appendix for DCCP.
> 
> ------------------------------------------------------------------------------
> 
> - Gorry's input that: We MUST note in the new draft that no registry
>>>>>>> allocations can be made for zero or 4294967295, and no registry
>>>>>>> allocations can be made for 1056964608-1073741823 (high byte
> ASCII "?")
>>>>>>> reserved for private use [19.8 of RFC 4340].
>>>>>>> To be added.
> 
> Gorry:
> 
> To fix as requested. Check also the appendix for DCCP.
> 
> ------------------------------------------------------------------------------
> 
> - Gorry's input that: see 10.3.2: IANA MUST NOT allocate a single
>>>>>>> Service Code value to more than one DCCP server port. // revise
> to MUST
>>>>>>> NOT allocate more than one port to a single service code value;
> multiple
>>>>>>> SC per port is allowed, subject to expert review.
>>>>>>> To be added.
> 
> Gorry:
> 
> To fix as requested. Check also the appendix for DCCP.
> 
> ------------------------------------------------------------------------------
> 
> - Gorry's input that: updates RFC 5595, since the latter states where
>>>>>>> ports and service codes are registered
>>>>>>> To be added.
> 
> Gorry:
> 
> To fix as requested. Check also the appendix for DCCP.
> 
> ------------------------------------------------------------------------------
> 
> - Gorry's input that we fix the acknowledgements (ref to Tom - who?)
>>>>>>>>>>> GORRY - can you clarify?
> 
> Gorry:
> 
> To fix as requested. Check also the appendix for DCCP.
> 
> ------------------------------------------------------------------------------
> 
>>>>> [ P.S. The note I sent simply said the "ack" to Tom Phelan isn't
>>>>> really the full story. Tom pointed to the text in section 6 of
>>>>> draft http://tools.ietf.org/html/draft-ietf-dccp-serv-codes-04.
>>>>> This ID was edited by me, with some inputs from Eddie Kohler and
>>>>> some from Tom. I removed this text from the DCCP RFC, when it was
>>>>> sent to help make this draft. That's all.]
> 
> ------------------------------------------------------------------------------
> 
> - point about multiple names that use the same port number
> 
> Two cases:
> 
> 	www/http = synonyms
> 	stun/turn = in-band negotiation
> 
> Lars:
> 
> Will update text as needed.
> 
> ------------------------------------------------------------------------------
> 
>>>>>>>>>>> My suggestion would be to add a section to that draft
> grandfathering
>>>>>>>>>>> ports 465, 993, 2000 and a few more (adding as much negative
> verbiage as
>>>>>>>>>>> seems wise; I don't think the exact amount makes and
> difference at all).
>>>>>>>>>>> IIRC port 2000 can be grandfathered a half-dozen times.
> 
> This document does not document protocols no longer used.
> 
> No changes to the doc for this.
> 
> ------------------------------------------------------------------------------
> 
>>> There are two separate issues:
>>> 
>>> - previous assignments that don't follow the proposed recommendations
>>> 	- as noted, there's no goal to fix that
> 
> Already note we're leaving existing stuff alone.
> 
> No changes to the doc for this.
> 
> ------------------------------------------------------------------------------
> 
>>> - 'squatting', or use of ports without registering through IANA
>>> 	- IMO, these should not be ignored, but clearly cannot be
>>> 	treated as equivalent to 'self assigned'
>>> 
>>> 	i.e., IMO, IANA should list these as "unauthorized use",
>>> 	as a service to the community to help those using those
>>> 	ports as assigned.
> 
> Out of scope for this doc.
> 
> No changes to the doc for this.
> 
> ------------------------------------------------------------------------------
> 
> - email to registrants whose entries will be modified
> 
> Stuart:
> 
> Will send/review text.
> 
> No changes to the doc for this.
> 
> ------------------------------------------------------------------------------
> 
> - table boilerplate
> 
> Michelle:
> 
> Will send draft text.
> 
> No changes to the doc for this.
> 
> ------------------------------------------------------------------------------
> 
> - names for table entries to coordinate with Olafur's tables
> 
> Joe:
> 
> Will clarify list of table entries and ensure they are described
> completely in the current doc.
> 
> (PS - here's my input)
> The current list of registration information is listed in Section 8.1:
> 
>      Registration Administrative Contact (REQUIRED)
>      Registration Technical Contact (REQUIRED)
>      Service Name (REQUIRED)
>      Port Number (OPTIONAL)
>      Transport Protocol(s) (REQUIRED if port number requested)
>      Service Code (only REQUIRED for DCCP)
>      Description (REQUIRED)
>      Reference (REQUIRED)
> 
> This provides a list from which the table can be created, with one
> correction (transport protocol(s) are always REQUIRED; this should be
> corrected in Sec 8.1). This is as is already contained in the example
> table provided for feedback at
> http://www.viagenie.ca/ianaxml/port-numbers.xhtml
> 
>      *Service Name
>      *Transport Protocol(s)
>      Port Number (where applicable)
>      Service Code (for DCCP)
>      Short description
>      +Comments (typically lists unauthorized uses by squatters,
> 		also lists deprecated, changes, etc.)
>      References
>      Registration Admin Contact (listed as Registrant)
>      Registration Technical Contact (listed as Point of Contact)
> 
> (* = the pair {service name, transport protocol} forms a unique key into
> this table)
> 
> All the items above except for "Comments" are described in the doc, and
> constitute the registration information. The comments field should, IMO,
> be broken down into a few separate fields; I'm not sure any of these
> need to be listed in the doc, however, since the information it presents
> is administrative 'out-of-band' context. Comments should NOT include
> items eligible for other fields, e.g., references.
> 
> Here's what I would break it into two fields:
> 
> 	Known Unauthorized Uses
> 	Assignment comments (de-registration, owner change, name change)
> 
> I'm not sure it's appropriate to list the known unauthorized uses in the
> same table as the authorized ones; I would prefer de-valuing that list
> to a separate table on a separate page.
> 
> ------------------------------------------------------------------------------
> 
> - updates for new transport protocols
> 
> Lars:
> 
> Will add text for how new transports are handled.
> 
> ------------------------------------------------------------------------------
> 
> - how you get a port number vs ask for a port number
> 
> Lars:
> 
> Clarify how you either leave this open in the request or ask for a
> number. (how you state a preference)
> 
> - sec 7.3 / need to add IESG approval to IETF approval for system ports
> 
> Michelle:
> 
> To update text.
> 
> ------------------------------------------------------------------------------
> 
> -- end.
> 
> 
> <signature.asc><ATT00001..txt>