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

[Magnus Westerlund <[e-mail]>]

Hi,

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


Magnus Westerlund skrev 2010-09-16 14:56:
> 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.
> 
> 
> 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.
> 
> 
> 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.
> 


-- 

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