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

[Magnus Westerlund <[e-mail]>]

Hi,

I have edited the clear changes indicated by Michelle and Perle. This is
commited as rev 73. Text and diff from previous provided.

I also provide my view on the questions below.

Joe Touch skrev 2010-10-03 21:34:
> 
> 
> 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.

I agree that we don't need to exclude it in the syntax. A question is if
we should include a recommendation against doubl hyphen and other cases
of repetitions that aren't readable as regular english?

I can see either way.

> 
>> 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).

I think that is simply fine.

> 
>> 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


Yes, I think IANA and the port experts team need to discuss what
additional guidelines they should provide in the application form.

> 
>> 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.

Yes, I did intentionally write Registrant here, but I think in most case
the Contact will be able to answer for the Registrant if it is ok.

> 
>> 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.

Done.

> 
>> 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.

This comes back to my question earlier about a sentence saying that the
Registrant can't be changed. I think we should make clear that the it
can be updated in case of name changes or mergers. I think we should
encourage Registrants to update their information.

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

Fixed.

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

Fixed

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

Fixed
> 
>> 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.

This was changed by Stuart, I have changed all the Sixteen-bit to 16-bit.

> 
>> 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.

Yes, I think even a statement before the list saying that protocols for
a given port number that has at least on registration are reserved but
not explicitly indicated will do the trick.

> 
>> 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.

Agree with Joe here

> 
>> 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.
> 

Fixed

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------