Subject: RE: Errata and clarifications: netconf-prot-03

From: "Rob Enns" <[email-masked]>
Date: Wed, 21 Jul 2004 14:43:18 -0700

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Jul 2004 15:42:18 -0700

>Yep. I'm leaving the filtering piece alone until the WG

okay

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

I'll look to see if there are any of these URNs are
missing.  Sec. 6.8.3 (#url capability) should have
some examples of valid values.  We should define a
specific set of URL types that can be used in NETCONF.
This came up in the IESG review of an RMON MIB with
a URL MIB object much like our <url> element.

>have to specify the <target> parameter.

You are assuming that no product would ever allow
both writes to <candidate> or directly to <running>.
I don't think we should assume that.  

Regardless, I am in favor of using the 'default' attribute,
and minOccurs="0" in the NETCONF XSD, when there is a clear 
default for all use cases.  Having to overlay (and override)
bits and pieces of the XSD to generate platform-specific
schema is something we should avoid.   This looks like
a parameter that should not have a default -- everybody
should have to specify a value for <source> and <target>.

Andy