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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Sep 2010 14:56:51 +0200

Hi,

I am back working and have now completed reviewing the discussion on the
team list and the WG list. I also reviewed the published version 6 and
all the changes from 6 until 07-to be based on SVN revision 68.

I have the following comments.

1. Section 23 uses "RR" without expansion. I have fixed that and
committed a new version.

2. I like the current alias text description of section 5. No need for
further changes in my eyes except with the possibility that alias isn't
the best word for what STUN and TURN does.

3. Section 5.1. As the ABNF etc has been discussed I think the current
text mandating the text description over ABNF is good.

4. Section 7.2:
IANA decisions are not required to be bound by these
   principles; other factors may come into play, and exceptions may
   occur where deemed in the best interest of the Internet.

I find this a bit confusing. I assume the intention is to say that these
are principles that should be followed. The hard rules are in Section 8.
How do you interpret the above?

I would also like to point out that the above quote can be interpreted
to apply also on section 7.3 where rules are specified that I think are
not possible for IANA to waive.

5. Section 7.3:

Should really section 7.3 be under Section 7 at all? Doesn't this belong
under Section 8.1? The reasons is that is is not principles but actual
rules.

6. Section 8.1:
   o  Transport Protocol(s): The transport protocol(s) for which the
      allocation is requested MUST be provided.  This field is currently
      limited to one or more of TCP, UDP, SCTP, and DCCP.  This field is
      required even for services with no port number.

To me it is not clear what I should enter in the case of requesting only
a service name and no ports. Should I list the transport protocols that
my application is capable of using this service over? In that case I
think a clarification is in order.

7. Section 8.1:

Reserved numbers and names
   are assigned only after review by IANA and the IETF, and are
   accompanied by a statement explaining the reason a Reserved number or
   name is appropriate for this action.

How is the review by IETF performed in the above case? I think that
needs to be explicitly stated.

8. Section 8.1:
The following text did diseaper from this section:

   If the registration request is for a service name alias (see
   Section 5), IANA needs to confirm with the administrative contact for
   the existing service name whether the registration of the alias is
   appropriate.

I think for the STUN/TURN case it was a good rule that the registrant
present where an extension has requested to be assigned a service name
associated with the same port as a previous service name is contacted.
This to ensure that they truly are compatible extensions rather that
blatant attempt to do hostile takeover on the port.

9. Section 8.1:
   o  Port Number: If assignment of a port number is desired, either the
      currently Unassigned or Reserved port number the requester
      suggests for allocation, or the text "ANY", MUST be provided.  If
      only a service name is to be assigned, this field MUST be empty.
      If a specific port number is requested, IANA is encouraged to
      allocate the requested number.  If the text "ANY" is specified,
      IANA will choose a suitable number from the User Ports range.
      Note that the applicant MUST NOT use the requested port prior to
      the completion of the registration.

Is is worth clarifying that applicants requesting to register a System
port must propose such a port. Either that or include an alias SYS to
mean any in the System range.

10. Section 8.2
IANA should not re-assign port numbers that have
   been de-registered until all other available port numbers in the
   specific range have been assigned.

I have changed "all other available" to "all unassigned"

11. Section 8.2: Service name de-registration. I saw it somewhere that
it was proposed to allow de-registration of service name in the purpose
of getting the HISTORIC stamp on the record. I think we should allow the
registrant to request the service name to be marked historic rather the
unassign it.

12. Section 8.2:
   Because there is much less danger of exhausting the service name
   space compared to the port number space, it is RECOMMENDED that a
   given service name remain assigned even after all associated port
   number assignments have become de-registered.  Under this policy, it
   will appear in the registry as if it had been created through a
   service name registration request that did not include any port
   numbers.

When the above happens I think it should be made clear in the comment
field what has happened.

13. Section 8.5: What is unclear is if the Registrant is allowed to
perform an update if the legal name of the individual, organization or
company is changed. I think we should allow it to ensure that IANA can
keep their records up to date. However, the change history should make
clear what has happened.

In addition I think we are making a mistake by not allowing the
registrant to be transfered. If a company sells its product line
associated with a protocol to another company. The expertize to judge if
an registration request will move. If only the contact information is
moved to the "buyer" of the product line, I think IANA gets into the
difficult situation to determine if the contact is allowed to answer
questions or not on behalf of the registrant.

14. Section 10.2:

I think we should update the registrations for UDP and TCP port 1021 and
1022. This to fill in the registrant and contact person correctly.

I have done this, but I haven't include RFC 4727 in the "Updates" list
nor added comments about what is done in other places than 10.2.

15. Appeal process: Do we need to explicitly define the appeal process?
I think a pointer to Section 7 of RFC 5226 is sufficient, but I think it
is worth pointing out that this is the appeal order that applies. I
think a section 8.7 would be the appropriate place.

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: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Sep 2010 16:56:09 +0200

Hi,

I have removed all issues that has been resolved in r70. However, most
of my questions still remains. Please comment.

-- 

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Fri, 24 Sep 2010 08:58:56 +0300

Hi,

>> How do you interpret the above?

I think we should instead say something like "these are the rules that IANA SHOULD follow, but in exceptional cases special considerations MAY apply."

>> under Section 8.1? The reasons is that is is not principles but actual

Yes, I think this could be moved (it is likely here for historic reasons).

>> think a clarification is in order.

I think we touched on this in another thread. I believe the result was that we go with Stuart's suggestion: if you only want a service name, and your service runs on TCP, this  will be TCP, in all other cases this will be UDP. Or do I mis-remember?

>> needs to be explicitly stated.

I think we should actually say that these are only assigned after a Standards Action or IESG Approval, and that any such request must be submitted to IANA with a statement explaining why.

>> blatant attempt to do hostile takeover on the port.

Agree.

>> mean any in the System range.

You only get System ports after "IETF Review" or "IESG Approval" anyway, so the general public won't be affected by this much. But yes, we should clarify.

>> registrant to request the service name to be marked historic rather the

This probably came from Alfred, whose philosophy is that an IANA registry should somehow reflect actual deployment or use. I think this will cause too much management overhead and the informaiton will be inaccurate and stale anyway, so what's the point.

>> When the above happens I think it should be made clear in the comment

Agreed.

>> keep their records up to date. However, the change history should make

If the legal name changes, it is still the same registrant though. (The name is an identifier, not an identity.)

>> questions or not on behalf of the registrant.

That case is IMO handled by the "coordinated de-registration and re-registration." Company A (who is being bought) returns the codepoints to IANA, and at the same time company B (the buyer) requests assignment. This allows IANA the option to say no, in cases where codepoints are being transferred without companies being bought. 

>> think a section 8.7 would be the appropriate place.

Agreed that a pointed to RFC5226 is all we need.

Lars

> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Sep 2010 14:25:06 +0200

Hi,

I have made a number of changes and committed them as r71. There is
likely need to word smith, but I wanted to put in embryo of text for
people to react to.

See discussion inline.

> I think we should instead say something like "these are the rules that IANA SHOULD follow, but in exceptional cases special considerations MAY apply."

I am a bit worried by that. I think the general rules should not be
possible to void at least not by IANA. I think we can require IESG
approval to break a rule.

I have tweaked this sentence a bit to indicate that it IANA's handling
of the request that the principle applies to.

> Yes, I think this could be moved (it is likely here for historic reasons).

I will move it and people can yell if it was better or not.

> I think we touched on this in another thread. I believe the result was that we go with Stuart's suggestion: if you only want a service name, and your service runs on TCP, this  will be TCP, in all…

Okay, but then we need text that makes it clear that service name
registrations shall indicate the protocols that is being used.

Transport Protocol(s): The transport protocol(s) for which a
allocation is requested MUST be provided. This field is currently
limited to one or more of TCP, UDP, SCTP, and DCCP. Requests
without any port allocation and only a service name are still required
to indicate which protocol the service uses.

> I think we should actually say that these are only assigned after a Standards Action or IESG Approval, and that any such request must be submitted to IANA with a statement explaining why.

Implemented:

Reserved numbers and names are assigned only by Standards Action or IESG
Approval, and MUST accompanied by a statement explaining the reason a
Reserved number or name is appropriate for this action.

>>> blatant attempt to do hostile takeover on the port.

Implemented

> You only get System ports after "IETF Review" or "IESG Approval" anyway, so the general public won't be affected by this much. But yes, we should clarify.

Ok, attempted to clarify this.

> This probably came from Alfred, whose philosophy is that an IANA registry should somehow reflect actual deployment or use. I think this will cause too much management overhead and the informaiton w…

Yes, I agree that it will never be up to date. However, an entry marked
as historic will clearly be historic. While you never know if an umarked
one is used or not.

I am fine with the current text indicating that service name should
normally not be de-registered.

>>> When the above happens I think it should be made clear in the comment

Text added at the end of the section.

> If the legal name changes, it is still the same registrant though. (The name is an identifier, not an identity.)

well, but 8.6 says:

"(Note that Registration Administrative Contact cannot
   be changed; see Section 8.5 above.)"

Which from my perspective prohibits IANA to change the value of the
field, even if simply to update what is clearly the same Registrant.

> That case is IMO handled by the "coordinated de-registration and re-registration." Company A (who is being bought) returns the codepoints to IANA, and at the same time company B (the buyer) request…

Ok, I don't have a strong view on this. But I think we are overly
sensitive on this.

> Agreed that a pointed to RFC5226 is all we need.

Okay, added text in new section 8.7.

I have attached text of r71 and a diff between 70 and 71.

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Sep 2010 06:47:04 -0700

One minor comment:

pg 18:
References to specific form text, such as "USR" or "SYS", should be 
removed, and the text should just say that the application must indicate 
whether the desired port number is in the User or System range.

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Sep 2010 13:17:25 +0200

> whether the desired port number is in the User or System range.

I have removed the form specific text from the ports bullet and
committed the revision.

Cheers

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Sep 2010 21:16:19 +0300

OK, I suggest everyone give the current version a read, and then we ship it.

Lars

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 30 Sep 2010 16:25:07 -0700

All,

Here are our comments/questions for the proposed version 07.
Let us know if anything below needs clarification.

Thanks,

Michelle and Pearl

******* 

1.  In Section 2, we believe the following should be changed from:

...so that management requests can complete in a timely manner.

To:
...so that requests can be completed in a timely manner.

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?

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?

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?

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.

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

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?

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

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

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

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.

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)

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

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