Re: [port-srv-reg] Comments on SVN revision 68

[Joe Touch <[e-mail]>]

On 9/30/2010 4:25 PM, Michelle Cotton wrote:
> All,
>
> Here are our comments/questions for the proposed version 07.
> Let us know if anything below needs clarification.
>
> Thanks,
>
> Michelle and Pearl
>
> *******
...
> 2. Related to section 5.1, what about the rule that there are no consecutive
> hypens?
> Could someone register a---------5 as a service name/port number?
> Are there any issues with that?

They can now; under the new rules, they could not. I see no issues with 
that.

Sequential hyphens are confusing. So is the name "oooooooh" - you have 
to count the 'o's and get it right.

I don't see syntax as a place to specify how to avoid such confusion. 
That can (and already does) happen via gentle suggestion by IANA reviewers.

> 3. In section 8.1, we saw this part taken out:
>
>   Service names, on the other hand, are not tied to a specific
>     transport protocol, and registration requests for only a service name
>     (but not a port number) allocate that service name for use with all
>     transport protocols.
>
> I also read the section below that paragraph in the document. Just to
> confirm, there are no situations where a service name would be registered
> without identifying a transport protocol?

That's my understanding based on the discussion we had in Maastricht.
The current SRV registry states that all entries are defined only for 
TCP or UDP as indicated (TCP is the default; UDP or UDP and TCP is 
indicated for some entries).

> 4.  In section 8.1, there is the list of what is required to apply for a
> port number assignment.  Are those pieces of information going to fully
> replace the current application form or will we retain some of the other
> questions currently asked?

8.1 indicates "description"

the other questions currently asked help us guide the applicant in 
providing the description in a useful way. I don't see this document as 
constraining how IANA solicits or assists in applicants providing that info

> 5. Also in section 8.1, the document says:
>
>    If the registration request is for the addition of a new transport
> protocol to an already assigned service name, IANA needs to confirm with the
> Registrant for the existing assignment whether this addition is appropriate.
>
> If the registration request is for a service name overloading a port number
> (see Section 5), IANA needs to confirm with the Registrant for the existing
> service name whether the registration of the overloading is appropriate.
>
> Is checking with the listed contact person be sufficient in these cases? If
> they are not available we check with the organization/company.

That depends on whether we believe the tech contact represents what the 
registrant would have decided. That's up to IANA; the key is that the 
registrant is the ultimate authority, though.

> 6. In section 8.1, we think this should be slightly changed
>
>     When IANA receives a registration request - containing the above
>     information - that is requesting a port number, IANA SHALL initiate
>     an "Expert Review" [RFC5226] in order to determine whether an
>     assignment should be made.  For requests that do not include a port
>     number, IANA SHOULD assign the service name under a simple "First
>     Come First Served" policy [RFC5226].
>
> It should say something like "For requests that are not requesting a port
> number,"

Yes; it's not that they don't suggest a port number, but that no number 
is being assigned at all.

> 7.  In section 8.5, what about mergers or acquisitions? How are those to be
> handled in the case of port number/service name contact information?

We should assume that the registrant is the owner, and that ownership 
moves as would the identity of the owner (the company or individual). 
None of that needs to be specified here, AFAICT.

> 8.  In section 8.6 it uses the term "administrative contact".  This should
> be changed to the Registrant.

Agreed.

> 9.  In section 10, just double checking...should "duplicante" be
> "duplicate"????

Yes.

> 10. In section 5.1, there is a typo 'maximu'.  Should be maximum?

Yes.

> 11. In section 6.1, it mentions '64-bit'.  We noticed that the new version
> changed all 16-bit to 'sixteen-bit'.  So would it be consistent to use
> 'sixty-four-bit' to replace '64-bit'? They should probably at least be in
> the same format.

I don't know why 16-bit was changed to "sixteen-bit". The RFC Editor is 
likely to want to change that back. Typically, numbers under 10 are 
expressed as words, and over 10 expressed as digits.

> 12.  The following paragraph describes that we only assign the requested
> protocol and mark others 'Reserved':
>
> "The new allocation procedure conserves resources by allocating a port
> number to an application for only those transport protocols (TCP, UDP, SCTP
> and/or DCCP) it actually uses.  The port number will be marked as Reserved -
> instead of Assigned - in the port number registries of the other transport
> protocols."
>
> QUESTION: When reserving the non-used protocols, are we putting additional
> lines for each entry?  This will make it very clear however the registry
> will get much larger.  (and it is already quite large)

There ought to be an explicit indication of reserved ports; this can be 
accomplished several ways:

	1) separate lines
	2) some other organization where one listing also indicates
	which other protocols are reserved

This is out of scope for the doc, though - the doc shouldn't focus on 
how the info is represented in the registry.

> 13. In section 8.1 about the Registrant and Contact, we have a clarifying
> question.
>
> Will a role account acceptable? I imagine that is partly up to how we handle
> the contacts internally.  If a registrant wants the contact to be
> [e-mail] then this should be OK.  Would we require an acutal
> person's name to go with it?

I would say yes. That is needed for legal tracking in case of 
mergers/acquisitions as above.

> Or would "Technical Department" be sufficient?
> Also, should we add the word "valid" to the email address so they know it
> should be a valid/working email address?

Valid is ephemeral; it would be know valid only at the time of 
registration anyway, so that seems unnecessary to mention.

> 14. This document still uses one instance of "assignee" in section 8.1.
> Should that be changed to "original requester" or Registrant?

Registrant.

----