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

From: Joe Touch <[email-masked]>
Date: Sun, 03 Oct 2010 12:34:28 -0700

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
> [email-masked] 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.

----

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Oct 2010 16:24:42 +0200

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.

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

> indicated for some entries).

I think that is simply fine.

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

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

> is being assigned at all.

Done.

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

>> be changed to the Registrant.

Fixed.

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

Fixed

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

Fixed
> expressed as words, and over 10 expressed as digits.

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

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

> mergers/acquisitions as above.

Agree with Joe here

>> Should that be changed to "original requester" or Registrant?

Fixed

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 Oct 2010 09:11:53 -0700

On 10/4/2010 7:24 AM, Magnus Westerlund wrote:
...
> of repetitions that aren't readable as regular english?

I see no need to do so.

FWIW, I had thought we already agreed to change the rules to prevent 
sequences of hyphens. Right now, the ABNF is correct in this regard, but 
the normative rules need another rule:

- hyphens are not allowed adjacent to other hyphens

> a given port number that has at least on registration are reserved but
                                         ^^^ = one
> not explicitly indicated will do the trick.

That works for humans, but not for systems using the table source as a 
database (screen-scraper or otherwise). For the latter, we need an entry 
for anything that is not "available".

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Oct 2010 09:33:51 +0200

> - hyphens are not allowed adjacent to other hyphens

Ok, that is now edited in. However, I changed it to match the other
rules from style point of view:

hyphens MUST NOT be adjacent to other hyphens

Checked in as revision 74.

> for anything that is not "available".

I see your point. I think IANA might need to consider doing the ports
registry web page with a few selectors on what info to display so humans
can reduce it.

Cheers

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Sat, 9 Oct 2010 08:41:58 +0300

> Checked in as revision 74.

Are we good to submit?

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Oct 2010 10:58:31 +0200

>From my perspective, yes!

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Oct 2010 12:14:54 +0300

OK, I fixed one last typo and submitted it.

(We can always update again if we need to.)

Lars