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

[Joe Touch <[e-mail]>]

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.