Hello Lada,
The issue is what is "too much protocol details" ?
I agree that there are many things that are not part of the YANG
language/metamodel itself. On the other hand if a simple create leaf
operation on different interfaces can result in different datastores and
different operation of the network node, then IMHO the different
interfaces use different models, NOT the same.
I consider autodelete a basic property of the YANG model. A mechanism
that results in deleting data nodes should work (or not) the same way on
all interfaces.
regards Balazs
P.S. I still hate autodelete
On 2015-10-22 13:15, Ladislav Lhotka wrote:
On 22 Oct 2015, at 12:45, Balazs Lengyel <[email protected]> wrote:
Hello,
I STRONGLY agree with Andy, Interfaces MUST work the same way. Autodeletion
MUST work or NOT work for all interfaces (Netconf, Restconf, CLI, GUI, etc.)
the same way. IMO it is not a protocol issue. It is part of the YANG definition.
This however limits the use of YANG to NETCONF and closely related protocols,
which is IMO short-sighted. People have already started using YANG models with
other protocols:
https://mailarchive.ietf.org/arch/msg/netmod/h_0jZbqfdcWFA8_hXx0gGzoi4X0
Putting too much protocol details into data modelling language definition
actually undermines the value of the standard - users of other protocols will
simply ignore those MUSTs and MUST NOTs they cannot or don't want to implement.
Lada
The whole idea behind model driven OAM is that we have one model that works
(mostly) the same way on all interfaces. The more differences we have the less
usable the product, the more difficult to implement.
regards Balazs
On 2015-10-21 15:07, Andy Bierman wrote:
On Wed, Oct 21, 2015 at 5:46 AM, Ladislav Lhotka <[email protected]> wrote:
On 21 Oct 2015, at 14:33, Andy Bierman <[email protected]> wrote:
Hi,
IMO we do not need lots of rules for when-stmt.
They are harder to enforce than just implementing the auto-deletion.
Note that auto-deletion also applies to nodes already in candidate or running.
It is just a derivative case to have a newly-created node deleted right away.
If you add node /foo it may cause node /bar and node /baz to get deleted.
I strongly object to treating a false when-stmt in a datastore validation
as an error. This is not how YANG 1.0 works, and this is not
backward-compatible.
I think it has nothing to do with YANG (1.0 or whatever), and RFC 6020 correctly describes this
auto-deletion behaviour for "choice" in sec. 7.9.6 NETCONF <edit-config>
Operations. It is indeed protocol business - YANG spec should just define what's valid and what
isn't.
IMO RESTCONF spec doesn't require auto-deletion.
Our server uses the same validation engine for both protocols.
RESTCONF does not change the behavior of YANG in any way.
I don't see how YANG validation procedures would not apply to RESTCONF.
YANG says that the node semantics apply IFF the when-stmt evaluates to true.
It is up to the implementation to enforce that. It applies to server-created
nodes or nodes created via some protocol.
Lada
Andy
Andy
On Wed, Oct 21, 2015 at 5:16 AM, Balazs Lengyel <[email protected]>
wrote:
Hello Martin,
I would want to codify this. My earlier proposal was:
- when MUST NOT be dependent on a data node controlled by a when or choice
statement
Notice the strong MUST NOT statement. This would simplify life greatly.
regards Balazs
On 2015-10-20 10:09, Martin Bjorklund wrote:
I have never seen anyone trying to refer to the conditional nodes in a
when expression - simply b/c it doesn't make any sense.
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909 email: [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909 email:
[email protected]
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909 email: [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
