Subject: [Netconf] comments on -with-defaults-00

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Mar 2009 16:08:10 +0100

Hi,

here are my comments on draft-ietf-netconf-with-defaults-00:

1. I strongly support removing the sentence "However, an agent MUST
accept it even if no namespace is used." at the end of sec. 2.5.

2. What happens if a subtree filter explicitly selects or matches the
content of the leaf affected by default substitution when with-defaults
is false? Using the example from the draft:

<rpc message-id="103"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0">
  <get>
    <wd:with-defaults>false</wd:with-defaults>
    <filter type="subtree">
      <interfaces xmlns="http://example.com/interfaces/1.2">
        <interface>
          <mtu/>
        </interface>
      </intefaces>
    </filter>
  </get>
</rpc>

or

<rpc message-id="104"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
    xmlns:wd="urn:ietf:params:xml:ns:netconf:with-defaults:1.0">
  <get>
    <wd:with-defaults>false</wd:with-defaults>
    <filter type="subtree">
      <interfaces xmlns="http://example.com/interfaces/1.2">
        <interface>
          <mtu>1500</mtu>
        </interface>
      </intefaces>
    </filter>
  </get>
</rpc>

Does the result in either case depend on server's "basic" behaviour and if so, how?

3. Along the same lines, I think this capability in fact interacts
with :xpath. Continuing the example, the results for the following
expressions should be specified when with-defaults is false and for the
different "basic" behaviours:

//interfaces/interface/mtu

//interfaces/interface[mtu='1500']

4. Typos:
   - page 4, line 4: "its" instead of "it's"
   - first sentence in sec. 2.1.1: All three commas should IMO be 
     removed, the word "device" probably too.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 13 Mar 2009 17:16:56 +0100

> accept it even if no namespace is used." at the end of sec. 2.5.

BALAZS: OK, will be removed.

BALAZS>
> Does the result in either case depend on server's "basic" behaviour and if so, how?

BALAZS: I don't know, but my opinion:
If the manager explicitly asks for mtu=1500=default, then he should always get what he wants, 
all interfaces with mtu=1500 irrespective of how 1500 got there. If  he just asks for 
interfaces with an MTU, we should follow the default behavior as described by the draft. If 
defaults are sent back the whole interface shall be sent back, if defaults are not sent back 
any interface with a default mtu=1500 should be absent from the reply.

> //interfaces/interface[mtu='1500']

BALAZS: Same as for subtree

>      removed, the word "device" probably too.
BALAZS: OK.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Mar 2009 09:39:46 -0700

Balazs Lengyel wrote:
> If the manager explicitly asks for mtu=1500=default, then he should 
> always get what he wants, all interfaces with mtu=1500 irrespective of 
> how 1500 got there. If  he just asks for interfaces with an MTU, we 
> should follow the default behavior as described by the draft. If 
> defaults are sent back the whole interface shall be sent back, if 
> defaults are not sent back any interface with a default mtu=1500 should 
> be absent from the reply.
> 

1) The <mtu> node will not be returned in any of the
    retrieved values, depending on how the agent handles defaults.
    Currently, the manager may have no idea which nodes will be returned.
    See my previous mail on with/without vs. basic=report-all.
    The current URI scheme is deficient. This is why.

2) The subtree/select filters are applied first.
    All the <interface> entries with an <mtu> CURRENTLY equal
    to 1500 match this test.

3) The with-defaults test is applied to all the leafs/leaf-lists
    selected by the filter.  If <mtu> was set explicitly by any manager,
    or was present in the startup config, it will  match
    for 'basic=explicit'.  If the <mtu> has a default of '1500',
    it will match for 'basic=trim'.  This test is skipped
    for all key leafs.

4) Only the 'default' node is removed from the <rpc-reply>.
    All the <interface> entries that matched are still returned.
    Only the <mtu> node (and any other default nodes) are omitted.

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

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Mar 2009 17:51:36 +0100

> all interfaces with mtu=1500 irrespective of how 1500 got there. If  he just asks for 

I think the idea of the "explicit" behaviour is that the value is not in
the configuration unless explicitly set. So strictly speaking it hasn't
got there.

> interfaces with an MTU, we should follow the default behavior as described by the draft. If 

The case with message-id="103" doesn't ask for interfaces with mtu but
for the mtu leaf itself. So the reply could contain either

<interfaces>
  <interface>
    <mtu>8192</mtu>
  </interface>
  <interface>
    <mtu>1500</mtu>
  </interface>
</interfaces>

or

<interfaces>
  <interface>
    <mtu>8192</mtu>
  </interface>
  <interface/>
</interfaces>

or even

<interfaces>
  <interface>
    <mtu>8192</mtu>
  </interface>
</interfaces>

Which one is correct?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Mar 2009 18:17:16 +0100

I think it is necessary to precisely define the XML documents that
various operations work with. While the document "with defaults" is
probably unambiguous, the one "without defaults" is fuzzy and depends on
the "basic" behaviour. One way for resolving this would be to define two
documents that can be mapped to each other in both directions given a
full specification of default values:

(1) Configuration with all defaults

(2) Configuration without defaults, meaning that ALL leaves having the
same (value-space) value as the default spec are removed.

Then by definition with-default=true will operate of the tree (1)
whereas with-default=false on (2). The results will then be quite
predictable.

Agents could work internally with either (1) or (2), or even something
in between, but must be prepared to derive either tree if necessary and
do the right thing.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Mar 2009 10:56:15 -0700

> full specification of default values:

IMO the correct approach is to specify in the capability URI
which behavior will be used for with-defaults=false.

> in between, but must be prepared to derive either tree if necessary and

The 'right thing', according to your POV.

One of the significant differences between SNMP and NETCONF
it the design goal in NETCONF to accommodate common practices
and implementation strategies, instead of ignoring them or
picking 1 way to do something. (e.g., :candidate vs. :writable-running).

There is another definition of 'default' in use, which
is called 'explicit' in the draft.  In this definition,
the value of default-stmt (or any other schema form of default-stmt)
is irrelevant.  The only thing that matters is whether
the operator set the value or the agent set the value.
There is no schema validation possible for this 'mode',
but that is not really important.  This is just another hard-wired
retrieval filtering mechanism, like <get> vs. <get-config>.

I understand that an operator expecting the filtering
to be more predictable will not be happy, but the NETCONF
behavior will be consistent with the native CLI behavior.
The main behavior this draft mandates is what happens
when with-defaults=true.  All leafs are returned,
no matter what internal implementation strategy is used.
That feature is currently missing from the protocol.

Andy

---

From: WashamFan <[email-masked]>
Date: Mon, 16 Mar 2009 11:46:21 +0800

>  for the mtu leaf itself. So the reply could contain either

In my opinion, the 2nd one makes more sense.
To my understanding, with-default is not intended to
deal with what you request but what I return. So the
default data, if exists in reply, will be present or absent
in <reply-rpc> depending on <with-default> value or
basic behavior.

But I got a question. the basic behavior has three types
(report-all, trim, explicit)
whereas operation behavior on with-default has two types.
 (true or false).
Why allowing for this inconsistency?

washam