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

[Lars Eggert <[e-mail]>]

Hi,

On 2010-9-23, at 17:56, Magnus Westerlund wrote:
> 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 think we should instead say something like "these are the rules that IANA SHOULD follow, but in exceptional cases special considerations MAY apply."

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

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

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

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?


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

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.

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

Agree.

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

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.

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

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.

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

Agreed.

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

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

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

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. 

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

Agreed that a pointed to RFC5226 is all we need.

Lars

>> 
> 
> 
> -- 
> 
> 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]
> ----------------------------------------------------------------------
> _______________________________________________
> Port-srv-reg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/port-srv-reg