RE: Errata and clarifications: netconf-prot-03

[Andy Bierman <abierman@cisco.com>]

At 02:43 PM 7/21/2004, Rob Enns wrote:
>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.

okay


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

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.


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

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


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