"The service in a public namespace should not be specific to a

particular country or region; unlike private namespace ex= tensions,

which may be country, region or enterprise specific;=94

How about the third pending issue in Section 5? Do we want to have req= uirements 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 <a.james.winterbottom@gmail.com<= /a>>
Date: Monday, June 23, 2014 at 7:25= PM
To: Roger Marshall <RMarshall@telecomsys.com>
Cc: Andrea Forte <forte@att.com>, "ecrit@ietf.org" <ecrit= @ietf.org>
Subject: Re: [Ecrit] New Version No= tification for draft-ietf-ecrit-service-urn-policy-04.txt

I would add further to Roger=92s final sentence:

"Public namespaces should not be specific to a particular country= or region; unlike private namespace extensions, which may be country, regi= on 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 <RMarshall@telecomsys.com> wrote:

I'd like to see some folks weigh in on public vs. private namespaces for se= rvice URN naming as outlined in draft-ietf-ecrit-service-urn-policy-04. &nb= sp;

The chairs would like to close on these 3 open issues in the thread below.<= span class=3D"Apple-converted-space">

I'll give my own opinion to start with:

Section 3 of the draft lists example public namespaces, but says nothing ab= out allowing private namespaces, such as urn:nena:service.sos or other subs= ervices outlined in NENA specification 08-003 "i3", a spec that s= everal 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 ma= ke 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 (s= ee 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 regio= n specific

-roger.

-----Original Message-----
From: FORTE, ANDREA G [mailto:forte@att.co= m]
Sent: Friday, May 30, 2014 12:58 PM
To: ecrit@ietf.org
Cc: Roger Marshall; Marc Linsner (mlinsner); Alissa Cooper; Henning Schulzr= inne
Subject: FW: New Version Notification for draft-ietf-ecrit-service-urn-poli= cy-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 docu= ment? If so, please take a look at Section 3 of the draft and let me know i= f the writing is sufficient.
2. If we allow private namespaces, should Section 4 apply only to the publi= c namespace domain or do we still want to provide some general guidelines f= or 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 re= view. Should we have some requirements about this document in Section 5? An= y specific suggestions on the direction to follow?

Regarding #2, my inclination would be to limit the guidelines only to publi= c namespaces. For private namespaces, perhaps, the expert reviewer would ju= st make sure that there are no conflicts with registered public namespaces.=

Thanks,
-Andrea

On 5/30/14, 3:06 PM, "inte= rnet-drafts@ietf.org" <internet-drafts@ietf.org>
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-e= crit-service-urn-policy
Revision: 04
Title: Policy for = defining new service-identifying labels
Document date: <= /span>2014-05-30
Group: ecrit
Pages: 4
URL:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-p= olicy
-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=3Ddraft-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 f= or
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 pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibit= ed. If you have received this message in error, please notify the sender im= mediately, and delete it and all attachments from your computer and network= .

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit

--_000_CFD7065A8CA6forteattcom_-- From nobody Mon Jun 30 10:00:40 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A5C1A03A5 for ; Mon, 30 Jun 2014 10:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itrPX_omvGrQ for ; Mon, 30 Jun 2014 10:00:35 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2481A0397 for ; Mon, 30 Jun 2014 10:00:35 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id LgzL1o0071vXlb859h0bLf; Mon, 30 Jun 2014 17:00:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Lh0a1o00U3ZTu2S3dh0a76; Mon, 30 Jun 2014 17:00:34 +0000 Message-ID: <53B197B2.8020300@alum.mit.edu> Date: Mon, 30 Jun 2014 13:00:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ecrit@ietf.org References: <20140530190648.27325.52041.idtracker@ietfa.amsl.com>

<0E3A640B-1FC1-41CE-8C56-F2CC96F42827@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404147635; bh=HOi2f0Aj4ZMGVJJu+EIh3QZ0vaJb6SigjwiRZZY2Feo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MrrZJkLpzgriSplYd7mx8r6Dw5SfnOuYIc8EbREwfTwqXTyYPuBRW1U4hyXli4hQ4 TFsHwbjaWwYY/dFOi2wfYS5+9Cd81jXzJm0skEyhT2RIoy2qOm6AyYhA94LwSgykLU kdkZaU0GKO9BOOazx25EC2/0n+qvuuWsaQqvIWGm4+BmEx+7RCwE1912v10noc3foh M42qcy4YgVlpo/OTe6althoQVXhF6E/+ekiPEqz1DeL3mwrWunK1peLBCPdJrOZaio uphgOL75DZqciSYKk72C/QNEcoDZcvFehddpilIIZgAuXTnHTDSlEN+CDeuDwMqwZZ SgOsKv/XZV16g== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Nqu14X3_HO445_3vY17LpDI0lQM Subject: Re: [Ecrit] New Version Notification for draft-ietf-ecrit-service-urn-policy-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 17:00:37 -0000 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 > > Date: Monday, June 23, 2014 at 7:25 PM > To: Roger Marshall > > Cc: Andrea Forte >, "ecrit@ietf.org > " > > 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 > 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:forte@att.com] >> Sent: Friday, May 30, 2014 12:58 PM >> To:ecrit@ietf.org >> 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, "internet-drafts@ietf.org >> " > > >> 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 >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >