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

[Magnus Westerlund <[e-mail]>]

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.

Lars Eggert skrev 2010-09-24 07:58:
> 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."

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.


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

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

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

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.

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

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.

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

Implemented


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

Ok, attempted to clarify this.

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

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.

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

Text added at the end of the section.

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

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.

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

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

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

Okay, added text in new section 8.7.

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

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