Subject: Re: [Netconf] comments on with-defaults-01 draft

From: Balazs Lengyel <[email-masked]>
Date: Mon, 18 May 2009 17:35:05 +0200

Andy Bierman wrote:
> Hi,
> 
> There was an important semantic change that was
> made in this draft that needs to be corrected.
> Sorry I did not catch it sooner.
> 
> Before, if with-defaults is set to 'true' the
> agent MUST return all default data.  Now, there
> is no requirement or even suggestion to support 'report-all'.
> This is not acceptable.  The whole point of creating
> this capability was to get the defaults from the agent.
> An agent MUST support 'report-all' in order to advertise
> the :with-defaults capability.

BALAZS: report-all will be made mandatory to support

> 
> Also, I think there should be a YANG module (ietf-with-defaults.yang)
> instead of an XSD in the draft.  The new 4741-bis will have
> a netconf.yang module which can be augmented.  The NETCONF WG
> decided to use only normative YANG starting when YANG is approved.
> Unless the delay would be way too long, this document should
> also use normative YANG.

BALAZS: Basically I agree, but the time-line for the 4741bis effort is not clear for me. I will 
try to include both.

> 
> 
> Andy
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 May 2009 13:29:54 +0200

Phil Shafer wrote:
> Not a full review, but a couple of notes:
> 
> 2.1. refers to "NETCONF <rpc-reply> messages", but I think
> this is more general (like a <copy-config> to an <url>).

BALAZS: Could you list what you have a mind beside rpc-replies please!
I am not sure whether copy-config should be included. What does it mean if this is valid for 
copy-config running -> candidate ? Will it alter what is stored in candidate?
It makes more sense if the target is a URL. Maybe we should say copy-config if target is URL?

> 
> 2.1.1 lists "Report all", "Trim", and "Explicit", but should
> use "report-all", "trim", and "explicit", since 2.3 and 2.4
> say "Possible method names are taken from the list in 2.1.1".

BALAZS: OK, will be changed

> 
> Use of the terms "methods" and "method names" is confusing, given
> that 4741 uses this term to mean the element name under the <rpc>
> element.  Use "modes" or some other term.

BALAZS: OK, will be changed to mode

> 
> 2.3 uses ":" to separate the members of the list.  It should
> use "," for this, in the same way we do in rfc4741 (8.8.3).
> 
> 2.3 makes is sound like "supported" doesn't need to list
> all supported modes, which is surprising.  It should be
> a complete list.

BALAZS: OK, will be clarified

> 
> 2.5 uses the phrase "added to the 'method-name' element.  This
> phrase is new and not meaningful.  Putting it in quotes makes
> it look like a string.  Better to just list the specific method
> names directly, as is done in the next sentence.

BALAZS: the list is open ended, it potentially includes future operations. I removed the quotes.

> 
> The example uses "<get>" but section 2.1 says this affects
> config data, not state data.

BALAZS: replies to get does contain config data, but as favor I will change it to get-config.

> Thanks,
>  Phil