RE: Errata and clarifications: netconf-prot-03

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

Thanks Andy.  A few comments below. - Rob

> - pg 17, para 2, filter parameter
> 
>   This parameter needs some more explanation.  The concept
>   of retrieval filtering needs to be explicitly introduced 
>   before this section (5.1).  At least mention where filtering
>   is defined.
> 
>   The larger issues related to filtering need to be resolved
>   before this new section can be written.

Yep. I'm leaving the filtering piece alone until the WG
agrees on what to do.

> - pg 27, para 3, bullet 2
> 
>   This is very 'candidate model' centric.  If the "changes have
>   not been committed" does not apply if the #candidate capability
>   is not supported.  There are also "implicit locking" issues that 
>   need to be resolved by the WG (not in this email).

Agree. The WG agreed to remove this restriction and I must have 
dropped it in my notes. I've removed it from the working draft.

> - pg 33, onward
> 
>   Include the actual URI for each capability.  Include multiple
>   examples for capabilities that have parameter values.

I think the URIs (URNs) are in there, for example:
  urn:ietf:params:xml:ns:netconf:base:1.0#rollback-on-error 

If this isn't what you're after can you be more specific?

> - pg 37, para 5
> 
>   The default target for <lock> cannot be <candidate> on one 
>   platform and <running> on another.  This isn't represented 
>   in the XSD (don't know if it can be represented).  This also
>   doesn't seem consistent with the defaults for some other
>   operations.  This gives lots of ammo to the people that
>   want to take out defaults from the protocol operations altogether.

While it can't be represented in the XSD, it makes sense to
have <lock/> do the right thing no matter if you're managing
a device with a single <running/> configuration or one with
a <candidate/> configuration. We could remove the inconsistency
by taking out the default behavior for <lock/>, but that would
make using NETCONF more of a pain, since a user would always
have to specify the <target> parameter.



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