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

From: Roger Marshall <[email-masked]>
Date: Mon, 23 Jun 2014 22:45:08 +0000

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:[email-masked]] 
Sent: Friday, May 30, 2014 12:58 PM
To: [email-masked]
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, "[email-masked]" <[email-masked]>
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.

---

From: James Winterbottom <[email-masked]>
Date: Tue, 24 Jun 2014 09:25:14 +1000

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 <[email-masked]> wrote:

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

---

From: "FORTE, ANDREA G" <[email-masked]>
Date: Mon, 30 Jun 2014 16:34:10 +0000

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;”

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?

Thanks,
-Andrea

From: James Winterbottom <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 23, 2014 at 7:25 PM
To: Roger Marshall <[email-masked]<mailto:[email-masked]>>
Cc: Andrea Forte <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] New Version Notification for draft-ietf-ecrit-service-urn-policy-04.txt

Cheers
James

On 24 Jun 2014, at 8:45 am, Roger Marshall <[email-masked]<mailto:[email-masked]>> wrote:

Suggest change from:

-roger.

-----Original Message-----
From: FORTE, ANDREA G [mailto:[email-masked]]
Sent: Friday, May 30, 2014 12:58 PM
To: [email-masked]<mailto:[email-masked]>
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,

Thanks,
-Andrea

On 5/30/14, 3:06 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
wrote:

Abstract:

The IETF Secretariat

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 13:00:34 -0400

>     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

> Cc: Andrea Forte <[email-masked] <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [Ecrit] New Version Notification for
> draft-ietf-ecrit-service-urn-policy-04.txt
>
> "Public namespaces should not be specific to a particular country or
> region; unlike private namespace extensions, which may be country,
> region *or enterprise* specific."
>
> On 24 Jun 2014, at 8:45 am, Roger Marshall <[email-masked]
> <mailto:[email-masked]>> 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.
>>
>> 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.
>>
>>  - Public namespaces should not be specific to a particular country or
>> region; unlike private namespace extensions, which may be country or
>> region specific
>>
>> -roger.
>>
>>
>>
>> To:[email-masked] <mailto:[email-masked]>
>> 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
>>
>> 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, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>> wrote:
>>
>>>
>>> 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:
>> 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.
>>
>> [email-masked] <mailto:[email-masked]>