On Mon, Nov 28, 2016 at 7:47 AM, Robert Wilton <[email protected]> wrote:
> Hi Bart,
>
> Alas, it sounds like you are attempting to do exactly what the existing
> text is attempting to prevent you from doing. In particular, your approach
> will break an existing client from working that hasn't been coded to be
> aware of the new augment-base module.
>
> In terms of your solution, unless I'm missing something, then I'm not sure
> whether the deviation really helps - it seems to be equivalent to be just
> writing the must statement directly on 'leaf d' in the augment-base module
>
> IIRC, I don't think that YANG prevents you from using a "must" statement
> to effectively make a leaf mandatory. However, even if this is allowed, it
> is probably against the spirit of the constraint that YANG is attempting to
> impose here. I.e. specifically that changes/augmentations to YANG modules
> are expected to be fully backwards compatible.
>
>
YANG conformance is per module.
That means is is OK for a client to code to "base-class" and not
the "augment-base" module.
I have tried several times to fix that in YANG with conformance statements
that
can be more than one module, but this has not been seen as important.
Robert is correct that the deviation does not change things at all,
other than this is the correct way to do things that are not allowed
(and your server must advertise the deviation, which tells the world
"I do not implement module "base-class" correctly".)
6087bis allows conditionally mandatory,
which usually means you pick a new value for something in the base module
(e.g, leaf a, b, or c). The old client will not set leaf b to the new
value.
leaf b {
enumeration {
// old enums
enum new;
}
}
leaf d {
when "../b = new";
mandatory true;
type string;
}
Thanks,
> Rob
>
Andy
>
>
> On 28/11/2016 15:01, Bogaert, Bart (Nokia - BE) wrote:
>
>> What we want to express is that if the NC client sends a request to
>> configure an object of class base we have a means to express that it also
>> has to send a value for the augmented leaf. The reason why it is in an
>> augment is because we can't modify the base class.
>>
>> Best regards - Vriendelijke groeten,
>> Bart Bogaert
>> Broadband-Access System Architect Data
>> Contact number +32 3 2408310 (+32 477 673952)
>>
>> NOKIA
>> Copernicuslaan 50, 2018 Antwerp, Belgium
>> Fortis 220-0002334-42
>> VAT BE 0404 621 642 Register of Legal Entities Antwerp
>>
>> <<
>> This message (including any attachments) contains confidential information
>> intended for a specific individual and purpose, and is protected by law.
>> If
>> you are not the intended recipient, you should delete this message. Any
>> disclosure, copying, or distribution of this message, or the taking of any
>> action based on it, is strictly prohibited without the prior consent of
>> its
>> author.
>> -----Original Message-----
>> From: Martin Bjorklund [mailto:[email protected]]
>> Sent: 28 November 2016 14:45
>> To: Bogaert, Bart (Nokia - BE) <[email protected]>
>> Cc: [email protected]; [email protected]
>> Subject: Re: [netmod] Mandatory leafs via augment
>>
>> "Bogaert, Bart (Nokia - BE)" <[email protected]> wrote:
>>
>>> Hi Rob,
>>>
>>>
>>> In the case we're trying to work out basically client and server would
>>> be aware of base class, augmentation and deviation as the SW running
>>> on the box is expecting a value for a leaf of the augmented data, so
>>> leaf d for the NC server (and the application SW dealing with the HW)
>>> is expected to have a value in the device. The device would not
>>> support objects of the base class only. I could understand that a NC
>>> client interacts with other servers only supporting the base class as
>>> that device may not require the augmented leafs.
>>>
>> I don't understand what you want to do. It seems as if you're saying that
>> if the client thinks that leaf d is mandatory then leaf d is mandatory.
>> Otherwise leaf d is not mandatory.
>>
>>
>> /martin
>>
>>
>>
>>> Best regards - Vriendelijke groeten,
>>>
>>> Bart Bogaert
>>>
>>> Broadband-Access System Architect Data
>>>
>>> Contact number +32 3 2408310 (+32 477 673952)
>>>
>>>
>>> NOKIA
>>>
>>> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE
>>> 0404 621 642 Register of Legal Entities Antwerp
>>>
>>>
>>>
>>> <<
>>> This message (including any attachments) contains confidential
>>> information intended for a specific individual and purpose, and is
>>> protected by law. If you are not the intended recipient, you should
>>> delete this message. Any disclosure, copying, or distribution of this
>>> message, or the taking of any action based on it, is strictly
>>> prohibited without the prior consent of its author.
>>>
>>> From: Robert Wilton [mailto:[email protected]]
>>> Sent: 28 November 2016 12:48
>>> To: Bogaert, Bart (Nokia - BE) <[email protected]>
>>> Cc: [email protected]
>>> Subject: Re: [netmod] Mandatory leafs via augment
>>>
>>>
>>> Hi Bart,
>>>
>>> In your idea, am I correct to assume that only the client loads
>>> (base-class, augment-base, and base-deviation), and the server only
>>> knows about (base-class and augment-base)?
>>>
>>> Further, am I right to assume that the server would still support
>>> clients configuring base even if they don't know about augment-base?
>>> I.e. from a server perspective, leaf d isn't actually mandatory.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>>> On 28/11/2016 11:28, Bogaert, Bart (Nokia - BE) wrote:
>>>
>>> Assume the following.
>>> module base-class {
>>> prefix base;
>>> container base {
>>> leaf a;
>>> leaf b;
>>> leaf c;
>>> }
>>> }
>>> module augment-base {
>>> prefix aug;
>>> import base-class { prefix base; }
>>> augment '/base:base'{
>>> leaf d;
>>> }
>>> }
>>> module base-deviation {
>>> prefix base-dev;
>>> deviation "/base:base" {
>>> deviate add {
>>> must "./aug:d" {
>>> error-message "A value for d must be present when configuring
>>> augmented base";
>>> }
>>> }
>>> }
>>> Best regards - Vriendelijke groeten,
>>> Bart Bogaert
>>> Broadband-Access System Architect Data Contact number +32 3 2408310
>>> (+32 477 673952)
>>> NOKIA
>>> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE
>>> 0404 621 642 Register of Legal Entities Antwerp
>>> <<
>>> This message (including any attachments) contains confidential
>>> information intended for a specific individual and purpose, and is
>>> protected by law. If you are not the intended recipient, you should
>>> delete this message. Any disclosure, copying, or distribution of this
>>> message, or the taking of any action based on it, is strictly
>>> prohibited without the prior consent of its author.
>>>
>>>
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder
>>> [mailto:[email protected]]
>>> Sent: 28 November 2016 12:09
>>> To: Bogaert, Bart (Nokia - BE) <mailto:[email protected]>
>>> <[email protected]>
>>> Cc: [email protected] <mailto:[email protected]>
>>> Subject: Re: [netmod] Mandatory leafs via augment
>>> On Mon, Nov 28, 2016 at 10:42:42AM +0000, Bogaert, Bart (Nokia - BE)
>>>
>> wrote:
>>
>>> How can we achieve the same if no when-clause can be constructed but
>>> we still would like to have a leaf to be mandatory. One way we
>>> thought of achieving this is
>>> - have a YANG module defining the augmented data
>>> - construct a must statement on the object being augmented
>>> where
>>>
>>> we
>>>
>>> check that something needs to be present that is added via a deviation.
>>>
>>> An example may help here...
>>> /js
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>>
>>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
