RE: problems in draft-ietf-netconf-prot-08

["Rob Enns" <rpe@juniper.net>]

> 1) Clarification added to sec. 7.9:
> 
>       The <kill-session> operation does not rollback configuration or
>       other device state modifications made by the entity holding the
>       lock.
> 
> Note that this is not true for a confirmed-commit  (see sec. 8.4.1).
> If you kill the session that is holding the lock, and of course
> also issued the first commit, the agent must revert the 
> running config.

True. 

> 2) Change to NETCONF Base URN inconsistently applied:
> 
> Throughout the examples, and some normative text (3.1, 8.1),
> the base URN is listed in 3 different forms:

Let me try to clarify this:
 
> (A)  urn:ietf:params:xml:ns:netconf:base:1.0

This is the NETCONF protocol XML namespace we should be using. 
 
> (B)  urn:ietf:params:netconf:base:1.0

This is the base capability URN, it's not an XML namespace. 
(one might argue it should be:
urn:ietf:params:netconf:capability:base:1.0 -- if folks feel
strongly about it I can change it)

In any case a URN of the form "urn:ietf:params:netconf:..." should
be found only in capabilities. I believe the document is correct in
this regard--if you see specific examples where it's wrong please
point them out.

>  From sec. 10.1:
> 
> (C)   URI: Please assign the URI 
> "urn:ietf:params:xml:ns:netconf" for use
>       by the NETCONF protocol.

By asking for the URI above I'm assuming we can also use:
urn:ietf:params:xml:ns:netconf:base:1.0 (ie. (A) above)
as the namespace. Perhaps that was a little presumptuous.
Perhaps this is best resolved by requesting the entire
namespace URI (ie. (A) above):

urn:ietf:params:xml:ns:netconf:base:1.0

> Form (C) of the NETCONF NS is not used at all within the document.
> All xmlns declarations are in form (A).  Only the capability exchange
> in sec 8.1 shows form (B) in use. 
>  
> Shouldn't they all be changed to form (B) for
> both the NETCONF NS (all xmlns declarations)
> and the NETCONF Base capability (used as content
> for the <capability> element for the version of
> the protocol supported)?

I think the capability URIs (including the base capability) and 
namespace URI should be different.

> ---------------------------------------------------
> 
> 
> 3) From sec. 10.2, NETCONF Schema IANA request:
> 
>    URI: Please assign the URI "urn:ietf:params:xml:schema:netconf" for
>    use by the NETCONF protocol.
> 
> This string is not used anywhere in the document.
>
>  From the XSD in appendix B:
> 
>            <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
>               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
>               
> targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
> 
> 
> Shouldn't this targetNamespace be the same as the string
> used in all the xmlns examples in the document for the
> NETCONF namespace?  Which is supposed to be form (B) above?

The namespace we're defining in the XML schema is the NETCONF protocol
namespace. I think it is correct as it stands. The URI registration
for the NETCONF protocol XML schema in independent, and afaik
that URI does not need to appear in the XSD document.

> ---------------------------------------------------------------
> 
> 4) From sec 10.3:
> 
>    This document requests that IANA create a registry for allocating
>    NETCONF capability identifiers.  Allocation from the 
> registry is on a
>    First Come First Served Basis, but a specification is required.
> 
>    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.
> 
>    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: Section 8 of this document.
> 
> 
> Does paragraph 1 imply that the NETCONF registry will have
> values defined outside the WG? I am opposed to this.  
> We need to keep WG and vendor definitions separate, just like
> we do with SMI.

Agreed. By requiring a specification an RFC or other
permanent document needs to be provided (see RFC 2434). We could
raise the bar and say that IETF Consensus is required--this effectively
means that an IETF WG must approve additions to this registry.
 
> The specification of the capability URNs is listed as 'Section 8'.
> This is not sufficient because the values are scattered throughout
> a very large section.  IMO we need a table added in sec 8 that
> lists all the actual strings, and 10.3 should refer to that table.

It would certainly be easier to gather the capability strings from
a table, at the cost of duplicating them in the document. Isn't the 
normative text enough?

Rob

--
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/>