Subject: [Ecrit] Forward of Off-List Service URN Draft Discussions (8)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 16 Aug 2006 14:26:46 +0200

-----Ursprüngliche Nachricht-----
Von: Leslie Daigle [mailto:[email-masked]] 
Gesendet: Freitag, 28. Juli 2006 03:38
An: Henning Schulzrinne
Cc: Marc Linsner; Tschofenig, Hannes; 'James M. Polk'; [email-masked]
Betreff: IANA considerations Re: Moving forward with the Service URN Draft

(Messing with the subject lines, so that these threads remain
separable):

Henning Schulzrinne wrote:
>>> 5.1  New Service-Identifying Labels
>>>    New service-identifying labels and sub-services are to be managed by
>>>    IANA, according to the processes outlined in [4].  The policy for
>>>    top-level service names is 'IETF Consensus'.  The policy for
>>>    assigning labels to sub-services may differ for each top-level
>>>    service designation and MUST be defined by the document describing
>>>    the top-level service.
>>
>>
>> This needs more explicit instructions for IANA.  [4] is the generic
>> "how you can build IANA registries" document.
>>
>> If this is supposed to be adding labels to an existing registry,
>> that must be made clear:  which registry (e.g., the S-NAPTR
>> application service registry, perhaps?).
>>
> 
> No, this is the label defined in the BNF. An example is 'sos'. Do you 
> mean there is a need for more detail than saying 'IETF Consensus'? I'm 
> not quite sure what to say here, since it is hard to anticipate what 
> top-level services might be defined in the future.

The key question is -- is there a new registry you want to create
("Service URN services registry"), or are you suggesting adding
these to an existing registry? (I could argue my way either direction,
from the document).

> 
> 
>> If this is supposed to be creating a new registry of services and
>> sub-services, it should say so, and be more explicit about whether
>> registrations are FCFS, or under what circumstances they are
>> reviewed (so that IANA can know, objectively, that they are ready
>> for assignment) etc.
>>
> 
> I'll try to add wording, but I'm not sure how much more I can say beyond 
> (the new)

OK.

> 
> Services and sub-services are identified by labels managed by
> IANA, according to the processes outlined in <xref target="RFC2434"/>. 
> Thus, creating a new service requires IANA action.
> 
> 
>> IANA *will* prod for clarification at approval time, of course,
>> but getting some of that clarified now would help the rest of
>> us hapless readers ;-)
>>
> 
> I will add some additional wording to that section, but am a bit at  a 
> loss what more to say. We obviously seem to have difficulty 
> communicating how the whole thing works, so maybe this isn't an IANA 
> section problem.
> 
> 
>>> 5.3  Sub-Services for the 'sos' Service
>>>    The 'sos' service type describes emergency services requiring an
>>>    immediate response, typically offered by various branches of the
>>>    government or other public institutions.  Additional sub-services can
>>>    be added after expert review and should be of general public interest
>>>    and have a similar emergency nature.  The expert review should take
>>>    into account whether these emergency services are offered widely and
>>>    in different countries, with approximately the same caller
>>>    expectation in terms of services rendered.  The 'sos' service is not
>>>    meant to invoke general government, public information or social
>>>    services.
>>
>> So -- I *think* this is a first service registration in the
>> IANA registry -- so it should declare that expliclty.
> 
> I'll add a sentence.
> 
>>
>> But, it also implies "expert review" -- so the earlier section must
>> make clearer how that expert review is to occur.   Also, it
> 
> The earlier section said that top-level registrations requires IETF 
> Consensus, but that each sub-service can define its own policy.

Ah, okay, got it.

I think it would be clearer to spell out that an expert review
assignment process is being set up (and, explicitly or implicitly,
the IESG needs to appoint an expert reviewer).

I know I've never gotten away with creating an IANA registry
and just saying "expert review", but that may very well be my
own varying mileage.

> 
> 
>> must be made clear what the expert reviewer, or IANA, is expected
>> to do if the services are (or are not) widely offered -- what
>> does "take into account" mean?  Does it mean "refuse the registration
>> if they are not"?  In my experience, that's been hard to enforce;
>> people will push back and ultimately clear definitions of "what is
>> enough" are needed.  But, perhaps I've misunderstood, and this simply
>> needs clarification so that others do not share my misunderstanding
>> upon reading this.
> 
> I wish there were a hard line that I could draw ahead of time, but then 
> we could replace the expert by an expert robot... I replaced 'should' 
> with 'must be of general interest'. I also used stronger language saying 
> "The expert review should only approve ...".

Why do you suppose the URN NID registration process document grew
to such lengths?!  Sigh.

I hear you.  And YMMV.

Leslie.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit