Subject: Re: [Netconf] 答复: Re: Some questions about the usage of 'operation' attribute in edit-config

From: Randy Presuhn <[email-masked]>
Date: Fri, 13 Jun 2014 09:49:00 -0700 (GMT-07:00)

Hi -

>From: Radek Krejčí <[email-masked]>
>Sent: Jun 13, 2014 2:31 AM
>To: [email-masked], Andy Bierman <[email-masked]>
>Cc: [email-masked], [email-masked], Netconf <[email-masked]>, [email-masked]
>Subject: Re: [Netconf] 答复: Re:  Some questions about the usage of 'operation' attribute in edit-config
...
>Dne 10.6.2014 08:15, [email-masked] napsal(a):
...
>> No, if a NP container itself can be accepted as valid configuration, and
>> sever delete it, client can use 'replace' as remove, 'merge' as remove.
>>
>> If sever can decide whether support it. what client can do? If client
>> send
>> a request to replace a NP container with a element contains empty
>> node, the
>> response is uncertain.
>>
>
>but the empty NP container has no information value. It doesn't matter
>if the server deletes it or not. If you want to be sure, that the
>container will be removed, use 'remove' operation.
>
>> I think it's so bad for interoperability. I suggest NETCONF/NETMOD WGs
>> reject
>> the NP container itself as invalid configuration. It's no any value
>> and would
>> cause confusion.
>>
>
>I don't think this is an issue.

One of the basic tasks in configuration management is to
compare two configurations to determine whether they differ.
This behaviour complicates something that should be trivial.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2014 10:00:46 -0700

On Fri, Jun 13, 2014 at 9:49 AM, Randy Presuhn <[email-masked]
> wrote:

> This behaviour complicates something that should be trivial.
It isn't trivial for many reasons. NP-containers are just 1 of them.
Default leafs and system ordered lists (which are not ordered at all)
also make trivial XML tree comparison unreliable.

There are many aspects of server variability where a client developer
would be wise to pay attention to the server minimum requirements and design
code accordingly. (e.g., why would you write code that depended on an
empty NP container being present, knowing that servers are allowed to
delete them?)

Randy

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2014 10:20:41 -0700

> This behaviour complicates something that should be trivial.
To be clear -- I am in favor of changing the rules completely in YANG 1.1
so that empty
NP containers MUST (conceptually) always be part of the config.
XPath evaluation is currently implementation-dependent, which is much more
than an
inconvenience to YANG designers.

Randy

Andy