[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IANA considerations update for NETCONF protocol draft
Inline
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Rob Enns
> Sent: Wednesday, November 30, 2005 03:03
> To: netconf@ops.ietf.org
> Subject: IANA considerations update for NETCONF protocol draft
>
>
> The IANA review of the protocol draft raised some questions on how
> to handle review of the spec for new capabilities. Based on those
> questions
> and input from Andy, here's a proposed update to the IANA
> considerations
> section that requests 2 different registries for NETCONF capabilities:
>
> - the first would be for IETF standardized capabilities, and would
> require IETF consensus for new capabilities
>
I think we rather see IETF Standards Action.
IETF consensus is a bit vague in fact.
Standards Action clearly includes IETF Consensus.
More below.
> - the second would be for enterprise capabilities, and would be
> first come first served, with a specification required
>
> Could the WG review this and comment?
>
> thanks,
> Rob
>
> ------------------
>
> 10.3. NETCONF Capability URNs
>
> This document requests that IANA create a registry for allocating
> NETCONF capability identifiers. Allocation from the registry
> requires a specification and IETF consensus (approval by the NETCONF
> working group or a follow-on working group).
>
"approval by a WG" does not mean IETF consensus. IETF Consensus includes
some for of "IETF Last Call". For stds track documents that happens
automacally, and they get much better review than a "IETF Consnens Last Call
for an informational or experimental.
So that is why I think I prefer "Standards Action".
> 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.
> 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 |
.. snip ..
>
> 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.
>
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?
I think we need 2 templates, no?
Bert
> 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 netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>