Subject: [netmod] Mandatory leafs via augment

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 28 Nov 2016 10:42:42 +0000

Hi,

In RFC 7950 we find the following statement

If the augmentation adds mandatory nodes (see Section 3) that

represent configuration to a target node in another module, the

augmentation MUST be made conditional with a "when" statement. Care

must be taken when defining the "when" expression so that clients

that do not know about the augmenting module do not break.

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.

A client that knows about the augmented data model would also be aware of
the deviation that has been added, a client that does not know about the
augmented leafs would also not know about the deviation.  So in principle
this seems to be a solution.

Are there any problems with this approach?

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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Nov 2016 12:08:43 +0100

> check that something needs to be present that is added via a deviation.

An example may help here...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 28 Nov 2016 11:28:46 +0000

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";
      }
    }
  }

NOKIA

<<

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 28 November 2016 12:09
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: [email-masked]
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
> 

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 28 Nov 2016 11:47:42 +0000

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:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 28 Nov 2016 12:30:05 +0000

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.

Bart Bogaert

NOKIA

<<

From: Robert Wilton [mailto:[email-masked]] 
Sent: 28 November 2016 12:48
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: [email-masked]
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

Assume the following.
 
module base-class {
   prefix base;
   container base {
      leaf a;
      leaf b;
      leaf c;
   }
}
 
module augment-base {
  prefix aug;
 
  augment '/base:base'{
    leaf d;
  }
}
 
module base-deviation {
  prefix base-dev;
 
  deviation "/base:base" {
    deviate add {
      must "./aug:d" {

NOKIA
 
<< 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 28 November 2016 12:09
To: Bogaert, Bart (Nokia - BE)  <mailto:[email-masked]>
<[email-masked]>
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [netmod] Mandatory leafs via augment

 
 
-          construct a must statement on the object being augmented where

we

 
 
/js

_______________________________________________
netmod mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Nov 2016 14:45:07 +0100 (CET)

> supporting the base class as that device may not require the augmented

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

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 28 Nov 2016 15:01:01 +0000

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.

NOKIA

<<

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 28 November 2016 14:45
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] Mandatory leafs via augment

"Bogaert, Bart (Nokia - BE)" <[email-masked]> 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

> 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.
> >> 
> 
>  
> 
> 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: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: Robert Wilton <[email-masked]>
Date: Mon, 28 Nov 2016 15:47:46 +0000

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.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Nov 2016 09:39:05 -0800

On Mon, Nov 28, 2016 at 7:47 AM, Robert Wilton <[email-masked]> wrote:

> 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
>
> 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 Mon, Nov 28, 2016 at 10:42:42AM +0000, Bogaert, Bart (Nokia - BE)
>>>
>> wrote:
>>

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 29 Nov 2016 08:23:10 +0000

Andy,

Thanks for this feedback.  The server would indeed advertise this deviation as a “flag” to the client that the server is expecting more than just the base class.

Bart Bogaert

NOKIA

<<
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: Andy Bierman [mailto:[email-masked]] 
Sent: 28 November 2016 18:39
To: Robert Wilton <[email-masked]>
Cc: Bogaert, Bart (Nokia - BE) <[email-masked]>; [email-masked]
Subject: Re: [netmod] Mandatory leafs via augment

On Mon, Nov 28, 2016 at 7:47 AM, Robert Wilton <[email-masked] <mailto:[email-masked]> > 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.

I have tried several times to fix that in YANG with conformance statements that

(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

NOKIA

<<
-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: 28 November 2016 14:45
To: Bogaert, Bart (Nokia - BE) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [netmod] Mandatory leafs via augment

"Bogaert, Bart (Nokia - BE)" <[email-masked] <mailto:[email-masked]> > wrote:

Hi Rob,

/martin

Bart Bogaert

NOKIA

<<
  
From: Robert Wilton [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: 28 November 2016 12:48
To: Bogaert, Bart (Nokia - BE) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [netmod] Mandatory leafs via augment

Hi Bart,

Thanks,
Rob

Assume the following.
  module base-class {
    prefix base;
    container base {
       leaf a;
       leaf b;
       leaf c;
    }
}
  module augment-base {
   prefix aug;

  -----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked] <mailto:[email-masked]> ]
Sent: 28 November 2016 12:09
To: Bogaert, Bart (Nokia - BE)  <mailto:[email-masked] <mailto:[email-masked]> >
<[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
Subject: Re: [netmod] Mandatory leafs via augment
  On Mon, Nov 28, 2016 at 10:42:42AM +0000, Bogaert, Bart (Nokia - BE)

wrote:

we

_______________________________________________
netmod mailing list
[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
https://www.ietf.org/mailman/listinfo/netmod

---

From: Robert Wilton <[email-masked]>
Date: Tue, 29 Nov 2016 10:46:30 +0000

Hi Bart,

You have probably already considered this, but an alternative solution 
would be to use a global flag to predicate a "leaf d" when statement on, 
e.g. something along the lines of ...

module base-class {
    prefix base;
    container base {
       leaf a;
       leaf b;
       leaf c;
    }
}

module augment-base {
   prefix aug;

   leaf globalEnableAugmentedBase {
     type empty;
     description "Global flag to control whether leaf d is required."
   }

   augment '/base:base' {
     when '/globalEnableAugmentedBase';
     leaf d {
       mandatory true;
     }
   }
}

This is compliant with the rules, in that a client has to be explicitly 
aware and enable the "leaf d" functionality.  Of course there is still 
an expectation that clients that are not aware of "augment-base" could 
still configure "base" objects.

It still isn't clear to me whether in your case "base-class" is a 
standard module, and "augment-base" is a vendor augmentation, in which 
case it is strongly desirable not to force vendor specific mandatory 
augmentations, since it means that a generic client that only knows 
about base-class cannot inter-operate with a device that expects 
augment-base.

Conversely, if the base container is expected to represent an abstract 
base class, with separate concrete instantiations, then adding a 
mandatory choice statement to your container base, may allow you to 
express this more cleanly in YANG.

E.g. an example for the latter case is:

module base-class {
   namespace "urn:temp:augment";
   prefix base;
   container base {
     leaf a { type string; }
     leaf b { type string; }
     leaf c { type string; }
     choice subtype {
       mandatory true;
     }
   }
}

module augment-base {
   namespace "urn:temp:augment-base";
   prefix aug;
   import base-class { prefix base; }

   augment '/base:base/base:subtype'{
     case d-subclass {
       container d {
         leaf d {
           mandatory true;
           type string;
         }
       }
     }
   }
}

Regards,
Rob

On 29/11/2016 08:23, Bogaert, Bart (Nokia - BE) wrote:
>
> Andy,
>
> Thanks for this feedback.  The server would indeed advertise this 
> deviation as a “flag” to the client that the server is expecting more 
> than just the base class.
>
> *NOKIA*
> *From:*Andy Bierman [mailto:[email-masked]]
> *Sent:* 28 November 2016 18:39
> *To:* Robert Wilton <[email-masked]>
> *Cc:* Bogaert, Bart (Nokia - BE) <[email-masked]>; [email-masked]
> *Subject:* Re: [netmod] Mandatory leafs via augment
>
> On Mon, Nov 28, 2016 at 7:47 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>         information
>         From: Martin Bjorklund [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         To: Bogaert, Bart (Nokia - BE) <[email-masked]
>         <mailto:[email-masked]>>
>         Cc: [email-masked] <mailto:[email-masked]>;
>         "Bogaert, Bart (Nokia - BE)" <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi Rob,
>
>
>             From: Robert Wilton [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             To: Bogaert, Bart (Nokia - BE) <[email-masked]
>             <mailto:[email-masked]>>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             To: Bogaert, Bart (Nokia - BE) 
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>
>             <[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 29 Nov 2016 12:31:13 +0000

Hi Rob,

Thanks for your feedback.  The base module we’re talking about is an IETF standard module (now called ietf-hardware) and the augmentations have been added by BBF in the context of pre-provisioning of pluggable HW items in a device (there is a mail thread on including the BBF extension to the IETF entity model but this is not concluded yet.

Your second alternative would require us to modify the ietf-hardware module and that needs to come from IETF first before we can adopt this.

Bart Bogaert

NOKIA

<<

From: Robert Wilton [mailto:[email-masked]] 
Sent: 29 November 2016 11:47
To: Bogaert, Bart (Nokia - BE) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Mandatory leafs via augment

Hi Bart,

You have probably already considered this, but an alternative solution would be to use a global flag to predicate a "leaf d" when statement on, e.g. something along the lines of ... 

module base-class {
   prefix base;
   container base {
      leaf a;
      leaf b;
      leaf c;
   }
}
 
module augment-base {
  prefix aug;

  augment '/base:base' {

This is compliant with the rules, in that a client has to be explicitly aware and enable the "leaf d" functionality.  Of course there is still an expectation that clients that are not aware of "augment-base" could still configure "base" objects.

It still isn't clear to me whether in your case "base-class" is a standard module, and "augment-base" is a vendor augmentation, in which case it is strongly desirable not to force vendor specific mandatory augmentations, since it means that a generic client that only knows about base-class cannot inter-operate with a device that expects augment-base.

Conversely, if the base container is expected to represent an abstract base class, with separate concrete instantiations, then adding a mandatory choice statement to your container base, may allow you to express this more cleanly in YANG.

module base-class {
 
module augment-base {

Regards,
Rob

Andy,

Bart Bogaert

NOKIA

<<

From: Andy Bierman [mailto:[email-masked]] 
Sent: 28 November 2016 18:39
To: Robert Wilton  <mailto:[email-masked]> <[email-masked]>
Cc: Bogaert, Bart (Nokia - BE)  <mailto:[email-masked]> <[email-masked]>; [email-masked] <mailto:[email-masked]> 
Subject: Re: [netmod] Mandatory leafs via augment

Hi Bart,

 

 

  leaf b {

    enumeration {

      // old enums

      enum new;

    }

  }

  leaf d {

    when "../b = new";

    mandatory true;

    type string;

  }

 

Thanks,
Rob

Andy

NOKIA

<<
-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: 28 November 2016 14:45
To: Bogaert, Bart (Nokia - BE) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [netmod] Mandatory leafs via augment

Hi Rob,

/martin

Bart Bogaert

NOKIA

<<

Hi Bart,

Thanks,
Rob

Assume the following.
  module base-class {
    prefix base;
    container base {
       leaf a;
       leaf b;
       leaf c;
    }
}
  module augment-base {
   prefix aug;

  -----Original Message-----

wrote:

we