Re: [netmod] Guideline on modeling including features and phased support by a device

Alex Campbell <Alex.Campbell@Aviatnet.com> Tue, 06 March 2018 03:30 UTC

Return-Path: <Alex.Campbell@Aviatnet.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6046412DA14 for <netmod@ietfa.amsl.com>; Mon, 5 Mar 2018 19:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrsKtxEPXtb5 for <netmod@ietfa.amsl.com>; Mon, 5 Mar 2018 19:30:52 -0800 (PST)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A571712E87D for <netmod@ietf.org>; Mon, 5 Mar 2018 19:30:52 -0800 (PST)
From: Alex Campbell <Alex.Campbell@Aviatnet.com>
To: "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Guideline on modeling including features and phased support by a device
Thread-Index: AdO0Y9X7Z6zjEN4LQ8Siy72k21o7KQAl4Rhu
Date: Tue, 6 Mar 2018 03:30:50 +0000
Message-ID: <1520307050117.40190@Aviatnet.com>
References: <AM4PR07MB1716E07EE14F80BA7094C0DD94DA0@AM4PR07MB1716.eurprd07.prod.outlook.com>
In-Reply-To: <AM4PR07MB1716E07EE14F80BA7094C0DD94DA0@AM4PR07MB1716.eurprd07.prod.outlook.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: multipart/alternative; boundary="_000_152030705011740190Aviatnetcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JCT75bimwwfeSa0odqS34-TcAy8>
Subject: Re: [netmod] Guideline on modeling including features and phased support by a device
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 03:30:54 -0000

Presumably you will have to decide on a sensible default value to use.


What value will your actual device use after the software upgrade? That should be the value it stores in the data tree when performing the upgrade.



________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of Bogaert, Bart (Nokia - BE/Antwerp) <bart.bogaert@nokia.com>
Sent: Monday, 5 March 2018 10:25 p.m.
To: netmod@ietf.org
Subject: [netmod] Guideline on modeling including features and phased support by a device

Hi,

We have a question with respect to YANG models using features.  Assume that a part of the model is defined under a feature and that this feature-dependent part defines a leaf as mandatory.

module servers {
  namespace "http://www.example.com/servers";
  prefix servers;

  import ietf-inet-types {
    prefix inet;
  }

  revision 2018-03-01 {
    description
       "Initial version.";
  }

  feature test-feature {
    description "testing feature";
  }

  container servers {
    list server {
      key name;
      max-elements 64;
      leaf name {
        type string;
      }
      leaf ip {
        type inet:ip-address;
        mandatory true;
      }
      leaf port {
        type inet:port-number;
        mandatory true;
      }
      leaf only-if-feature {
        if-feature test-feature;
        type string;
        mandatory true;
      }
    }
  }
}

Now assume that we have a device that implements the model step-wise by first not supporting this feature and in a sub-sequent release by supporting this feature (and uses a persistent running datastore).  The question arising now is how to deal with this mandatory leaf?  Normally this can only be configured by a client, meaning that without any "help", the NC server will not be able to startup with the data contained in the device's persistent datastore unless a value is set for the mandatory leaf that now becomes available as a result of supporting the feature.

When modeling as follows it seems the NC server can start with the model supporting the feature that was not supported before:

module servers {
  namespace "http://www.example.com/servers";
  prefix servers;

  import ietf-inet-types {
    prefix inet;
  }

  revision 2018-03-01 {
    description
       "Initial version.";
  }

  feature test-feature {
    description "testing feature";
  }

  container servers {
    list server {
      key name;
      max-elements 64;
      leaf name {
        type string;
      }
      leaf ip {
        type inet:ip-address;
        mandatory true;
      }
      leaf port {
        type inet:port-number;
        mandatory true;
      }
      container only-if-feature {
        presence "see if this helps";
        if-feature test-feature;
        leaf only-if-feature {
          type string;
          mandatory true;
        }
      }
    }
  }
}

Are recommendations or guidelines in place to deal with this?

Regards, Bart