Re: [Ecrit] New Version Notification for draft-ietf-ecrit-service-urn-policy-04.txt

[Paul Kyzivat <[e-mail]>]

On 6/30/14 12:34 PM, FORTE, ANDREA G wrote:
> Roger, James,
>
> Thank you for the comments.
>
> The first paragraph of Section 3 now reads:
>
> "Whereas one entity applies for the registration of several new top-
>     level services which are of no interest to the general public, the
>     expert reviewer SHOULD consider the creation of an ad-hoc private
>     namespace (e.g., urn:nena [RFC6061]) under which such entity would be
>     free to define its own set of services and service labels.  These
>     SHOULD follow the same rules as outlined in this draft.”
>
> And in Section 4 the third bullet point says:
>
> "The service in a public namespace should not be specific to a
>     particular country or region; unlike private namespace extensions,
>     which may be country, region or enterprise specific;”

I think you missed something. How about:

    The service in a public namespace should not be specific to a
    particular country, region or enterprise; ...

> How about the third pending issue in Section 5? Do we want to have
> requirements for a non-IETF template or document that people should
> submit to the expert reviewer in order to apply for new service labels?

If the requirement is only for expert review, then it is important that 
there be a template that provides the reviewer with all the information 
he/she should use to render a decision. And then, it is probably wise to 
include most/all of that information into the registrry in order that 
the rationale for acceptance be comprehensible after the fact.

It is easier when a document is required, because the info can be in the 
document rather than in the template and registry.

In any case, please give clear guidelines to the expert, so that the 
expert decisions can be justified rather than being arbitrary. (I'm the 
expert for feature tags, and IMO there are insufficient guidelines.)

Also, let me warn you to take care in how you define the identifiers 
that denote private namespaces. We have been going through this with 
draft-ietf-salud-alert-info-urns, and got into quite a mess. We 
initially used FQDNs as identifiers for private namespaces, and didn't 
require them to be registered at all. But got shot down by the URN 
police because ownership of FQDNs can change, potentially invalidating 
the stability of old definitions.

We are currently working on a change to a FCFS registry of private 
names. But we have at least been considering that this could be abused 
by registering FQDNs, which would present some of the same problems. We 
probably will only allow tokens, not FQDNs, but even then we are 
wondering if this can then present problems with trademarks, etc.

I don't have a specific recommendation for you, but I recommend that you 
consider it carefully.

	Thanks,
	Paul

> Thanks,
> -Andrea
>
>
> From: James Winterbottom <[e-mail]
> <mailto:[e-mail]>>
> Date: Monday, June 23, 2014 at 7:25 PM
> To: Roger Marshall <[e-mail]
> <mailto:[e-mail]>>
> Cc: Andrea Forte <[e-mail] <mailto:[e-mail]>>, "[e-mail]
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Ecrit] New Version Notification for
> draft-ietf-ecrit-service-urn-policy-04.txt
>
> I would add further to Roger’s final sentence:
>
> "Public namespaces should not be specific to a particular country or
> region; unlike private namespace extensions, which may be country,
> region *or enterprise* specific."
>
> Since the NENA extension are specific to NENA implemented enterprises.
>
> Cheers
> James
>
>
>
> On 24 Jun 2014, at 8:45 am, Roger Marshall <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>> I'd like to see some folks weigh in on public vs. private namespaces
>> for service URN naming as outlined in
>> draft-ietf-ecrit-service-urn-policy-04.
>>
>> The chairs would like to close on these 3 open issues in the thread below.
>>
>> I'll give my own opinion to start with:
>>
>> Section 3 of the draft lists example public namespaces, but says
>> nothing about allowing private namespaces, such as
>> urn:nena:service.sos or other subservices outlined in NENA
>> specification 08-003 "i3", a spec that several NG9-1-1 systems are
>> built upon and are being deployed.  So, NENA i3 already defines a
>> private namespace of urn:nena:service, along with a variety of
>> subservices.  It would make sense, therefore, to go ahead and state
>> here, in section 3 of this draft, that private service namespaces are
>> expected to exist, and should follow the same rules as outlined in
>> this draft.
>>
>> Section 4 may need to change some in order to accommodate this
>> allowance (see below).
>>
>> Suggest change from:
>>  - It should not be specific to a particular country or region;
>> Change to:
>>  - Public namespaces should not be specific to a particular country or
>> region; unlike private namespace extensions, which may be country or
>> region specific
>>
>> -roger.
>>
>>
>>
>> -----Original Message-----
>> From: FORTE, ANDREA G [mailto:[e-mail]]
>> Sent: Friday, May 30, 2014 12:58 PM
>> To:[e-mail] <mailto:[e-mail]>
>> Cc: Roger Marshall; Marc Linsner (mlinsner); Alissa Cooper; Henning
>> Schulzrinne
>> Subject: FW: New Version Notification for
>> draft-ietf-ecrit-service-urn-policy-04.txt
>>
>> Hi all,
>>
>> I have just submitted revision 04 of the draft. There are still three
>> open issues regarding this draft that I would like the WG to discuss.
>> There is a corresponding "NOTE" paragraph
>>
>> in the draft for each one of those.
>>
>> 1. Have we agreed to allow private namespaces such as urn:nena in this
>> document? If so, please take a look at Section 3 of the draft and let
>> me know if the writing is sufficient.
>> 2. If we allow private namespaces, should Section 4 apply only to the
>> public namespace domain or do we still want to provide some general
>> guidelines for private namespaces as well?
>> 3. When we last discussed this document, there were suggestions on
>> allowing external non-IETF documents/templates to be submitted to the
>> expert for review. Should we have some requirements about this
>> document in Section 5? Any specific suggestions on the direction to
>> follow?
>>
>> Regarding #2, my inclination would be to limit the guidelines only to
>> public namespaces. For private namespaces, perhaps, the expert
>> reviewer would just make sure that there are no conflicts with
>> registered public namespaces.
>>
>> Thanks,
>> -Andrea
>>
>>
>>
>>
>> On 5/30/14, 3:06 PM, "[e-mail]
>> <mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>
>> wrote:
>>
>>>
>>> A new version of I-D, draft-ietf-ecrit-service-urn-policy-04.txt
>>> has been successfully submitted by Andrea G. Forte and posted to the
>>> IETF repository.
>>>
>>> Name:draft-ietf-ecrit-service-urn-policy
>>> Revision:04
>>> Title:Policy for defining new service-identifying labels
>>> Document date:2014-05-30
>>> Group:ecrit
>>> Pages:4
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-policy
>>> -04
>>> .txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-service-urn-policy/
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-policy-04
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-service-urn-policy-04
>>>
>>> Abstract:
>>>  In order to provide location-based services, descriptive terms for
>>>  services need to be defined.  This document updates the policy for
>>>  defining new service-identifying labels.
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: The information contained in this message may
>> be privileged and/or confidential. If you are not the intended
>> recipient, or responsible for delivering this message to the intended
>> recipient, any review, forwarding, dissemination, distribution or
>> copying of this communication or any attachment(s) is strictly
>> prohibited. If you have received this message in error, please notify
>> the sender immediately, and delete it and all attachments from your
>> computer and network.
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>