URN Namespace for ETSI Documents

Note: This ballot was opened for revision 03 and is now closed.

Ignas Bagdonas Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

Comment (2018-09-25 for -03)
No email
send info
Why does this document not have a document shepherd? I guess technically this is allowed but I'm curious about the justification for it

I'm also interested in the answer to Mirja's question.

Benjamin Kaduk No Objection

Comment (2018-09-27 for -03)
No email
send info
A lot of good points have already been raised by other ADs, so I'll try to not belabor them.

The "Purpose" starting with "[t]o begin with" is slightly jarring to read.
I understand that the initial trigger for this NID is for YANG modules, and
it can of course subsequently be used for other purposes, and we need to
acknowledge both these facts.  It might be less jarring to me in the other
order, something like "a general-purpose delegation for use by ETSI when
unique URNs are needed.  Intended applications include, but are not limited
to, YANG modules".

In "Identifier uniqueness considerations":
Maybe something like "allow for use of experimental type values in
specific, documented, subtrees, for testing purposes only" would be more 
clear about the scope of potential conflicts?

In "Security and Privacy:

   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.

What are "the device" and "the request" in this context?

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja K├╝hlewind No Objection

Comment (2018-09-19 for -03)
No email
send info
This is all fine with me but one question to the AD: Why is this RFC needed? Registration policy for "Uniform Resource Names (URN) Namespaces" is Expert Review (or there is actuually an own section in rfc8141 for SDOs).

(Terry Manderson) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2018-11-16 for -04)
No email
send info
Thank you for addressing my DISCUSS.

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-09-24 for -03)
No email
send info
I-D Nits reports:

  -- Obsolete informational reference (is this intentional?): RFC 5246
     (Obsoleted by RFC 8446)

This registration seems fine to me, although the phrasing in this document makes it seem as if the registration is only for YANG. Given that this is a delegation of a subtree to ETSI for whatever purposes make sense for their uses, I would recommend text in here that indicates that the subtree can be used for non-YANG purposes as well, at ETSI's discretion.

Martin Vigoureux No Objection

Comment (2018-09-27 for -03)
No email
send info

I second Mirja's question noting that 8141 allows for a fast track procedure for "Standards Development Organizations, Scientific Societies, and Similar Bodies"