> On 23 Oct 2015, at 10:58, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>> Martin Bjorklund <[email protected]> writes:
>>
>>> Balazs Lengyel <[email protected]> wrote:
>>>> 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.
>>>
>>> I agree. This is what makes "when" different than "must".
>>
>> Right, that's why I tend to avoid "when", except in augments.
>>
>>> auto-deletion in choice/when should be described as a property of the
>>> data model for the datastore. Parts of the text from Section 8.2.2
>>> should be made more generic and moved, probably to a new section
>>> 8.1.1. I will have a look at this.
>>
>> I think that defining a general datastore API as a part of YANG spec is
>> not useful. Protocols that potentially might use YANG (gRPC, Cap'n
>> Proto) won't be changed, so should we tell them not to use YANG?
>
> It is not a datastore API. It would specify what happens within a
> datastore as "when" expressions become false.
Well, I assume you want *all* "NETCONF <edit-config> ..." sections to hold for
all protocols using YANG - key handling, list insertions etc. And these
sections together represent quite a significant part of a datastore API that in
fact reflect limitations in <edit-config> design.
>
> Note that the concept of datastores, and specifically config vs state
> is a core feature of YANG. By default, if you just specify some
Yes, "config true/false" is rather NETCONF-specific. We are already seeing
protocols (I2RS) that might want something else.
> nodes, they are config true. If you want to use YANG define some kind
> of other datastructure, you need to put the nodes in some extension.
> For example, we use:
>
> tailf:structure foo {
> leaf a { ... }
> container b { ... }
> }
>
> to define a structure that doesn't have any real semantics associated.
It could also be done the other way around, e.g. remove the "config" and "key"
statements from the YANG core and define them as extensions for NETCONF-like
protocols. I know this idea is not going to become popular but then IMO YANG is
bound to remain a niche technology, unfortunately.
Lada
>
>
> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
