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;
  import base-class { prefix base; }

  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.

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

On Mon, Nov 28, 2016 at 7:47 AM, Robert Wilton <[email protected] <mailto:[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]
        <mailto:[email protected]>]
        Sent: 28 November 2016 14:45
        To: Bogaert, Bart (Nokia - BE) <[email protected]
        <mailto:[email protected]>>
        Cc: [email protected] <mailto:[email protected]>;
        [email protected] <mailto:[email protected]>
        Subject: Re: [netmod] Mandatory leafs via augment

        "Bogaert, Bart (Nokia - BE)" <[email protected]
        <mailto:[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]
            <mailto:[email protected]>]
            Sent: 28 November 2016 12:48
            To: Bogaert, Bart (Nokia - BE) <[email protected]
            <mailto:[email protected]>>
            Cc: [email protected] <mailto:[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]
            <mailto:[email protected]>]
            Sent: 28 November 2016 12:09
To: Bogaert, Bart (Nokia - BE) <mailto:[email protected]
            <mailto:[email protected]>>
            <[email protected] <mailto:[email protected]>>
            Cc: [email protected] <mailto:[email protected]>
            <mailto:[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]>
            <mailto:[email protected] <mailto:[email protected]>>
            https://www.ietf.org/mailman/listinfo/netmod


    _______________________________________________
    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

Reply via email to