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

[Peter Saint-Andre <[e-mail]>]

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:[e-mail]] On Behalf Of Peter Saint-Andre
>> Sent: Thursday, June 14, 2018 2:57 AM
>> To: [e-mail]
>> 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 <[e-mail]
>>> <mailto:[e-mail]>> 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 <[e-mail]
>>>>> <mailto:[e-mail]>> 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
>>>> [e-mail] <mailto:[e-mail]>
>>>>
>>>
>>>
>>> _______________________________________________
>>> urn mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/urn
>>>
>