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

["FORTE, ANDREA G" <[e-mail]>]

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