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

[Roger Marshall <[e-mail]>]

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]
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]" <[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.