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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------