Subject: RE: IANA considerations update for NETCONF protocol draft

From: "Rob Enns" <[email-masked]>
Date: Thu, 1 Dec 2005 12:58:50 -0800

Thanks Bert, comments and updated sections below.

> for an informational or experimental.
> So that is why I think I prefer "Standards Action".

"Standards Action" is fine with me too.
 
> >    The initial content of the registry will be the capability URNs
> >    defined in Section 8.  Once further experience is gained with
> >    NETCONF, this sub-namespace may be used for additional purposes.
> > 
> I think last sentence can go away, because defining the registry and
> requiring Standards Action (or IETF consensus if that is what the WG
> wants) basically allow for that Netconf impact anyway.

Ok.

> > 10.4.  NETCONF Enterprise Capability URNs
> > 
> >    This document requests that IANA create a registry for allocating
> >    NETCONF capability identifiers to enterprises.  
> Allocation from the
> >    registry is on a First Come First Served basis, but a 
> specification
> >    is required in the form of Appendix C of this document.
> > 
> 
> Mmm the template in appendix C looks (to me anyway) a template to
> register new entries in the "standards" space, not in the vendor 
> or enterprise space. Or am I missing something?

We can replace the "standard" NETCONF URN prefix in Appendix C with
an {insert your capability URI here} wildcard and the
single Appendix C should be ok.

Here are the 2 updated sections from IANA considerations.

10.3.  NETCONF Capability URNs

   This document requests that IANA create a registry for allocating
   NETCONF capability identifiers.  Allocation from the registry
   requires IETF Standards Action.

   The initial content of the registry will be the capability URNs
   defined in Section 8.

   Following the guidelines in RFC 3553 [7], IANA is requested to assign
   a NETCONF sub-namespace as follows:

   Registry name: netconf

   Specification: Section 8 of this document.

   Repository: The following table.

   +--------------------+----------------------------------------------+
   | Index              | Capability Identifier                        |
   +--------------------+----------------------------------------------+
   | :writable-running  | urn:ietf:params:netconf:capability:writable- |
   |                    | running:1.0                                  |
   | :candidate         | urn:ietf:params:netconf:capability:candidate |
   |                    | :1.0                                         |
   | :confirmed-commit  | urn:ietf:params:netconf:capability:confirmed |
   |                    | -commit:1.0                                  |
   | :rollback-on-error | urn:ietf:params:netconf:capability:rollback- |
   |                    | on-error:1.0                                 |
   | :validate          | urn:ietf:params:netconf:capability:validate: |
   |                    | 1.0                                          |
   | :startup           | urn:ietf:params:netconf:capability:startup:1 |
   |                    | .0                                           |
   | :url               | urn:ietf:params:netconf:capability:url:1.0   |
   | :xpath             | urn:ietf:params:netconf:capability:xpath:1.0 |
   +--------------------+----------------------------------------------+

   Index value: The capability name.

10.4.  NETCONF Enterprise Capability URNs

   This document requests that IANA create a registry for allocating
   NETCONF capability identifiers to enterprises.  Allocation from the
   registry is on a First Come First Served basis, but a specification
   is required in the form of Appendix C of this document.

   Following the guidelines in RFC 3553 [7], IANA is requested to assign
   a NETCONF sub-namespace as follows:

   Registry name: netconf-enterprise

   Specification: To be provided by the registrant.  The specification
   document must conform to Appendix C of this document.

   Repository: IANA is requested to store the submitted specifications
   in a public location such as
   http://www.iana.org/assignments/netconf/capabilities.html.

   Index value: The capability name.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Rob Enns" <[email-masked]>
Date: Mon, 5 Dec 2005 10:46:48 -0800

> > I'm not sure it's worth it either. My preference is to drop the IANA
> > allocated enterprise capability registry. Enterprises defining their
> > own capabilities can choose URIs that make sense to them. Much like
> > XML namespaces, common sense would dictate the choice of a URI that
> > won't clash with others. 
> >   
> 
> Common sense is something that works with small numbers, but not with
> large.  Why can't we solve this problem the same way SNMP 
> solved it?  I
> do think we can defer this until we see large numbers of netconf agent
> implementations.

You are referring to the way enterprises register under the  enterprise
OID?

For capabilities we could do the same but I think common sense will
keep "foo networks" using foonetworks.com in their URI when defining
new capabilities.

Once we get around to defining data models, an enterprise registry is
a necessity... so if we can defer capability registry until then, fair
enough.

Rob

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 5 Dec 2005 11:06:41 -0800

Eliot Lear wrote:

> Sent: Monday, December 05, 2005 1:10 PM
> To: Rob Enns
> Cc: Tom Petch; Randy Presuhn; netconf
> Subject: Re: IANA considerations update for NETCONF protocol draft
> 
> 
> Rob Enns wrote:

XML sloppily addresses this problem (in dozens of W3C, OASIS, and other
specs) by saying just use an enterprise URI (with the durability problem 
that Randy complains about).

But this is not rocket science.  The NetConf spec should say that
Enterprise Capabilities MUST be prefixed by a durable URN (not simply
a URI) and are not going to be IANA registered.  End of problem.

And I suggest that you further specify that Enterprise Capabilities
SHOULD use the UUID URN Namespace (RFC 4122, July 2005).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]