Subject: Re: [urn] [Marketing Mail] Re: New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID)

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Oct 2018 12:52:16 -0600

Hi all,

Yesterday Mahesh submitted a revised I-D:

https://tools.ietf.org/html/draft-mahesh-etsi-urn-04

Although I'd prefer to see more detail in the syntax description (which
exists in documentation on the ETSI site), as far as I can see all
issues have been addressed and this can move forward.

Peter

On 8/14/18 1:20 PM, Peter Saint-Andre wrote:
> During discussion with IANA, Lars noticed that the "Security and
> Privacy" section of the template says:
> 
>    If an namespace is URN-equivalent to another namespace used by the
>    device, as per the rules specified in Section 3.1 of URNs [RFC8141],
>    Section 6.1 of URI Generic Syntax [RFC3986], and the lexical rules
>    specified in this document, the request is rejected.
> 
> It would be helpful to clarify what kind of request is involved here
> (presumably a configuration or management request using YANG, but let's
> make that explicit).
> 
> Also, the "Purpose" section says "the URN" in two places, but that
> should be "the URN namespace".
> 
> The "Declaration of syntactic structure" section doesn't seem to reflect
> the structure of the examples (e.g., "urn:etsi:yang:etsi-services"). Do
> you foresee having additional "sub-identifiers" other than "yang"?
> 
> Finally, draft-mahesh-etsi-urn-03 uses the old template from RFC 3406,
> but IANA requires that registrations use the new template from RFC 8141.
> 
> Thanks!
> 
> Peter
> 
> On 6/14/18 9:22 AM, Svensson, Lars wrote:
>> Apart from what Peter already said, I have no further comments on this draft, as far as I'm concerned we're ready to proceed.
>>
>> Best,
>>
>> Lars
>>
>>> -----Original Message-----
>>> From: urn [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
>>> Sent: Thursday, June 14, 2018 2:57 AM
>>> To: [email-masked]
>>> Subject: [Marketing Mail] Re: [urn] New Version Notification for draft-mahesh-etsi-
>>> urn-03.txt (Was Re: URN expert review of 'etsi' NID)
>>>
>>> Thanks, Mahesh, that is helpful.
>>>
>>> I'm still not sure if we want to make a normative reference to RFC 1737
>>> (an Informational RFC from 1994) in the Security Considerations section;
>>> do you feel that it discusses issues that we left out of RFC 8141?
>>>
>>> Other than that, the document looks ready to proceed.
>>>
>>> Peter
>>>
>>> On 6/13/18 5:18 PM, Mahesh Jethanandani wrote:
>>>> ETSI has now published a web page that is publicly available and
>>>> describes the two questions outlined below. Please let us know if there
>>>> are any questions.
>>>>
>>>> https://portal.etsi.org/PNNS/GenericAllocation/ETSIURNNamespace.aspx
>>>>
>>>> Thanks.
>>>>
>>>> On Jun 8, 2018, at 8:18 PM, Mahesh Jethanandani <[email-masked]
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>> The following update to the draft addresses the comments raised as
>>>>> part of expert review. The remaining action items are for us to make
>>>>> available a public version of the ancillary document, whose URL was
>>>>> provided in the draft, that describes:
>>>>>
>>>>> - the NSS namespace and how it will be allocated by ETSI
>>>>> - how a separate “root” namespace under the allocated URN can be used
>>>>> for experimental namespaces.
>>>>>
>>>>> Thanks
>>>>> ---------------------------------------------------
>>>>>
>>>>> A new version of I-D, draft-mahesh-etsi-urn-03.txt
>>>>> has been successfully submitted by Mahesh Jethanandani and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:draft-mahesh-etsi-urn
>>>>> Revision:03
>>>>> Title:URN Namespace for ETSI Documents
>>>>> Document date:2018-06-08
>>>>> Group:Individual Submission
>>>>> Pages:6
>>>>> URL:
>>>>>            https://www.ietf.org/internet-drafts/draft-mahesh-etsi-urn-03.txt
>>>>> Status:         https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/
>>>>> Htmlized:       https://tools.ietf.org/html/draft-mahesh-etsi-urn-03
>>>>> Htmlized:
>>>>>       https://datatracker.ietf.org/doc/html/draft-mahesh-etsi-urn
>>>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-mahesh-etsi-urn-03
>>>>>
>>>>> Abstract:
>>>>>   This document describes the Namespace Identifier (NID) 'etsi' for
>>>>>   Uniform Resource Names (URNs) used to identify resources published by
>>>>>   European Telecommunications Standards Institute (http://etsi.org).
>>>>>   ETSI specifies and manages resources that utilize this URN
>>>>>   identification model.  Management activities for these and other
>>>>>   resources types are handled by the manager of the ETSI Protocol
>>>>>   Naming and Numbering Service (PNNS).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>> <http://tools.ietf.org>.
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>>>> On Jun 7, 2018, at 6:53 PM, Dale R. Worley <[email-masked]
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Comments on draft-mahesh-etsi-urn-02
>>>>>>
>>>>>>   1.1.  Terminology
>>>>>>
>>>>>>       | PNNS    | Protocol Name and Numbering Service             |
>>>>>>
>>>>>> It would be helpful to state that PNNS is an ETSI function:
>>>>>>
>>>>>>       | PNNS    | ETSI Protocol Name and Numbering Service        |
>>>>>>
>>>>>>   Declaration of syntactic structure:
>>>>>>
>>>>>>      The syntax of namespace specific strings for the 'etsi' namespace
>>>>>>      is <NSS> in Uniform Resource Names (URNs) [RFC8141].
>>>>>>
>>>>>> This is completely legitimate, but it is not satisfying.  If ETSI has
>>>>>> plans for how it will organize the space of NSSs, it would be nice to
>>>>>> describe them here.
>>>>>>
>>>>>>   Relevant ancillary documentation:
>>>>>>
>>>>>>      ETSI publishes information regarding the registered resources in
>>>>>>      the ETSI URN Namespace (EUN) registry
>>>>>>      (https://portal.etsi.org/PNNS/GenericAllocation/
>>>>>>      ETSIURNNamespace.aspx).
>>>>>>
>>>>>> It's good that ETSI gives the URL of its URN registry; many other
>>>>>> organizations do not.  However, I notice that that URL is
>>>>>> password-protected.  It would be much better for the community if the
>>>>>> registry was readable by the world, since there is no stated intention
>>>>>> that etsi URNs are used only within a closed community.
>>>>>>
>>>>>>   Identifier uniqueness considerations:
>>>>>>
>>>>>>      [...]  ETSI is expected to guarantee the uniqueness [...]
>>>>>>
>>>>>> Formally, this registration is being submitted by ETSI, so it reads
>>>>>> oddly for ETSI to say "ETSI is expected...".   Much better would be
>>>>>> "ETSI will...".
>>>>>>
>>>>>> Similarly, "ETSI could..." is used where it is more natural to say "ETSI
>>>>>> may...".
>>>>>>
>>>>>>      Note that using experimental types may create
>>>>>>      collision as multiple users may use the same values for different
>>>>>>      resources and specific strings.
>>>>>>
>>>>>> It would be very helpful if the registration stated how the ETSI
>>>>>> registry will make clear how to recognize experimental URIs within the
>>>>>> etsi namespace.
>>>>>>
>>>>>> Dale
>>>>>
>>>>> Mahesh Jethanandani
>>>>> [email-masked] <mailto:[email-masked]>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> urn mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/urn
>>>>
>>
>

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 24 Oct 2018 19:41:27 +0000

Peter, all,

> issues have been addressed and this can move forward.

No objection from me -- this spec can move forward.

Thanks,

Lars
 
> >> Apart from what Peter already said, I have no further comments on this draft, as
> far as I'm concerned we're ready to proceed.
> >>
> >> Best,
> >>
> >> Lars
> >>

---

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 25 Oct 2018 05:44:33 +0000

Hello, 

+ 1 

Juha

-----Original Message-----
From: urn <[email-masked]> On Behalf Of Svensson, Lars
Sent: keskiviikko 24. lokakuuta 2018 22.41
To: Peter Saint-Andre <[email-masked]>; [email-masked]
Subject: Re: [urn] [Marketing Mail] Re: New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID)

Peter, all,

On Tuesday, October 23, 2018 8:52 PM, Peter Saint-Andre [mailto:[email-masked]] wrote:

> Although I'd prefer to see more detail in the syntax description 
> (which exists in documentation on the ETSI site), as far as I can see 
> all issues have been addressed and this can move forward.

Thanks,

Lars
 
> > (presumably a configuration or management request using YANG, but 
> > let's make that explicit).
> >
> > The "Declaration of syntactic structure" section doesn't seem to 
> > reflect the structure of the examples (e.g., 
> > "urn:etsi:yang:etsi-services"). Do you foresee having additional "sub-identifiers" other than "yang"?
> >
> > Finally, draft-mahesh-etsi-urn-03 uses the old template from RFC 
> > 3406, but IANA requires that registrations use the new template from RFC 8141.
> >
> > Thanks!
> >
> > Peter
> >
> >>> Subject: [Marketing Mail] Re: [urn] New Version Notification for 
> >>> draft-mahesh-
> etsi-
> >>> I'm still not sure if we want to make a normative reference to RFC 
> >>> 1737 (an Informational RFC from 1994) in the Security 
> >>> Considerations section; do you feel that it discusses issues that we left out of RFC 8141?
> >>>
> >>>> describes the two questions outlined below. Please let us know if 
> >>>> there are any questions.
> >>>>
> >>>>> The following update to the draft addresses the comments raised 
> >>>>> as part of expert review. The remaining action items are for us 
> >>>>> to make available a public version of the ancillary document, 
> >>>>> whose URL was provided in the draft, that describes:
> >>>>>
> >>>>> - how a separate “root” namespace under the allocated URN can be 
> >>>>> used for experimental namespaces.
> >>>>>
> >>>>> Thanks
> >>>>> A new version of I-D, draft-mahesh-etsi-urn-03.txt has been 
> >>>>> successfully submitted by Mahesh Jethanandani and posted to
> the
> >>>>> IETF repository.
> >>>>>
> >>>>> Title:URN Namespace for ETSI Documents Document date:2018-06-08 
> >>>>> Status:         
> >>>>> https://datatracker.ietf.org/doc/draft-mahesh-etsi-urn/
> >>>>> Htmlized:       
> >>>>> https://tools.ietf.org/html/draft-mahesh-etsi-urn-03
> >>>>> Htmlized:
> >>>>>       
> >>>>> Diff:           
> >>>>> https://www.ietf.org/rfcdiff?url2=draft-mahesh-etsi-urn-03
> >>>>>
> >>>>> Abstract:
> >>>>> 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 <http://tools.ietf.org>.
> >>>>>
> >>>>> The IETF Secretariat
> >>>>>
> >>>>>> This is completely legitimate, but it is not satisfying.  If 
> >>>>>> ETSI has plans for how it will organize the space of NSSs, it 
> >>>>>> would be nice to describe them here.
> >>>>>>
> >>>>>> It's good that ETSI gives the URL of its URN registry; many 
> >>>>>> other organizations do not.  However, I notice that that URL is 
> >>>>>> password-protected.  It would be much better for the community 
> >>>>>> if the registry was readable by the world, since there is no 
> >>>>>> stated intention that etsi URNs are used only within a closed community.
> >>>>>>
> >>>>>> Formally, this registration is being submitted by ETSI, so it 
> >>>>>> reads oddly for ETSI to say "ETSI is expected...".   Much 
> >>>>>> better would be "ETSI will...".
> >>>>>>
> >>>>>> Similarly, "ETSI could..." is used where it is more natural to 
> >>>>>> say "ETSI may...".
> >>>>>>
> >>>>>> It would be very helpful if the registration stated how the 
> >>>>>> ETSI registry will make clear how to recognize experimental 
> >>>>>> URIs within the etsi namespace.
> >>>>>>
> >>>>>> Dale
> >>>>>
> >>>>> Mahesh Jethanandani