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

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> Tue, 06 March 2018 12:04 UTC

Return-Path: <bart.bogaert@nokia.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 5EA36127775 for <netmod@ietfa.amsl.com>; Tue, 6 Mar 2018 04:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 Jq3F65FoE9EY for <netmod@ietfa.amsl.com>; Tue, 6 Mar 2018 04:04:11 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AC6120047 for <netmod@ietf.org>; Tue, 6 Mar 2018 04:04:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ekQ3v1NQR1Fmnbd1t3HDVFyAQF+cW6WrKOfkJQ6wj7M=; b=FUsJMMHJxIYTCneTW9AfxaPxByT/EfNFKWDy/AuycuNCf6Or5Go59e+LMFuDkaXqvI8YysrApVFpIss2YM1HOyH3e94rOxC3QQsWwlfBidlIniJ0wCCayiPgOxrxDkDyMz/gbqFQ5wwhMAtNhhE9iltnmPQAYni+uGCV+g6/VGM=
Received: from AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) by AM4PR07MB1666.eurprd07.prod.outlook.com (10.166.133.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Tue, 6 Mar 2018 12:04:07 +0000
Received: from AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::34d9:5205:4b82:61e3]) by AM4PR07MB1716.eurprd07.prod.outlook.com ([fe80::34d9:5205:4b82:61e3%4]) with mapi id 15.20.0567.011; Tue, 6 Mar 2018 12:04:07 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com>
To: Robert Wilton <rwilton@cisco.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Guideline on modeling including features and phased support by a device
Thread-Index: AdO0Y9X7Z6zjEN4LQ8Siy72k21o7KQAyvFEAAAP100AAAPzHAAAADMgg
Date: Tue, 6 Mar 2018 12:04:07 +0000
Message-ID: <AM4PR07MB1716BBA8251F86270473819294D90@AM4PR07MB1716.eurprd07.prod.outlook.com>
References: <AM4PR07MB1716E07EE14F80BA7094C0DD94DA0@AM4PR07MB1716.eurprd07.prod.outlook.com> <9b0efc1c-675a-5cc6-3ab3-e6bae2481a78@cisco.com> <AM4PR07MB171668D649123B2F6F21C88194D90@AM4PR07MB1716.eurprd07.prod.outlook.com> <1ee1d963-ad66-6fa8-65fb-902ca23e164b@cisco.com>
In-Reply-To: <1ee1d963-ad66-6fa8-65fb-902ca23e164b@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com;
x-originating-ip: [131.228.32.183]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1666; 7:LmpLqMiTjR632Wjitj4vXD8ly9UP3FnTHaTNywjOq0LA+lGlLs3/Uw53qxQR0KYoGo8IA8MMaVCzTDM0471nUrA6NpD9NDpdr2qT2BUFZkSrGYVgdq8EwOXtUscur8/ODvIwa2xoo/EAotb2RRopARFxxwkptiC64K8G7HfJogqdZuUMDdZS0qaQ5JrHnek+Jya3x1p8C23myeQrCRAEPRrAtjnUL+je5xxukNxHkCiTHPS+alQHNTZNqjsD7XuE
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 45f7086c-8886-464c-18b8-08d5835a5d16
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:AM4PR07MB1666;
x-ms-traffictypediagnostic: AM4PR07MB1666:
x-microsoft-antispam-prvs: <AM4PR07MB1666081B8E2ECBE72B13A46794D90@AM4PR07MB1666.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(82608151540597)(95692535739014)(21748063052155)(79290750141951);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231220)(11241501184)(806099)(944501244)(52105095)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:AM4PR07MB1666; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1666;
x-forefront-prvs: 06036BD506
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(39380400002)(346002)(376002)(377424004)(51444003)(199004)(189003)(26005)(81156014)(93886005)(66066001)(33656002)(186003)(3280700002)(86362001)(4326008)(606006)(25786009)(8676002)(6916009)(3846002)(316002)(97736004)(81166006)(2906002)(790700001)(6116002)(8936002)(53936002)(55016002)(6306002)(236005)(9686003)(54896002)(6436002)(102836004)(105586002)(76176011)(5250100002)(106356001)(14454004)(478600001)(68736007)(2950100002)(3660700001)(7696005)(6506007)(966005)(99286004)(5660300001)(53546011)(229853002)(74316002)(2900100001)(7736002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1666; H:AM4PR07MB1716.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: aBWZCDtSKklJSBTNst2HZ6csTb6bX92W3Ag/h9+h92hshIyqCtpd6yhfSBbGT7zrpyiQl9iB3nPD5BLlCWRccwMmNyNgVV8fpt06zMzSOfEuWiIQfEC7od4NTgtgCPmdX/dVnvllG1fwSI49JO02rNILQx7LcgLS43LRTG/IyCNbK576jGh1/bRbiQQjDzU/O+FcehMGAS9zLwW2WrW9+fbAawh4YosgJwcJp8MwvnyPpmO8Qz85z6kSotBihgiZPGz/fNPrSx53Jo5uTUxnLhkS6k5+CjaNh8TD9LgEXYu83FhtQ2f0oHEIn3jvOk4dM9M2SveFtdXuJZK7Z3nyPXyKKrnXKhAeUCWlHHunDNIVEz3kJ4NlQWYw5JfsqlVo
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR07MB1716BBA8251F86270473819294D90AM4PR07MB1716eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 45f7086c-8886-464c-18b8-08d5835a5d16
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2018 12:04:07.3906 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1666
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/olCM_MYIPGzR_OUK9Pm5SNAfm30>
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 12:04:14 -0000

Rob,

Just to clarify: in this case we are not changing the model, it is the same model but the device SW in release X is not supporting the feature and in release Y it is.  Supporting the feature results in adding that part of the tree to the configuration that is related to the feature and the data leafs related to that feature are simply not there in the data configured when SW release X was active.

Regards, Bart

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Tuesday, March 6, 2018 12:59 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.bogaert@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Guideline on modeling including features and phased support by a device


Arguably the guidelines, or YANG, should say "don't allow this" ;-)

I think that what you are describing is just another instance of "don't augment with a mandatory node rule", or "only backwards compatible changes revisions should be made to a published YANG module".

The key reasoning behind these rules is that the a client should be able to work unchanged after the server has been upgraded, as long as they are not making use of any new functionality.
Thanks,
Rob

On 06/03/2018 11:34, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
Hi Rob,

I agree but the fact is that some of the BBF models have constructions like that and we were wondering whether this should not be mentioned in the guildelines document.  Normally a server can't set config true leafs if there is no default available in the model.  That is the reason we reached out to NETMOD.  Your suggestions can work but require adaptation of the current model.

Regards, Bart

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Tuesday, March 6, 2018 10:38 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.bogaert@nokia.com><mailto:bart.bogaert@nokia.com>; netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Guideline on modeling including features and phased support by a device


Hi Bart,

I think that the best solution to problem is perhaps to avoid it altogether.  I.e. I don't think that the only-if-feature leaf should be marked mandatory.  Instead, it would be better to define a sensible default value/behaviour if the leaf is absent even when the feature is supported.

Alternatively, you can simulate something similar to an if-feature statement by using a when or must expression instead that is predicated on a leaf that the client must explicitly set to enable the feature, giving control back to the client.

E.g. something along the lines of ...

leaf enable-super-feature {
  if-feature test-feature;
  type boolean;
  default "false";
}

...
      leaf only-if-feature {
        when '/enable-super-feature = "true"';
        type string;
        mandatory true;
      }

It would be interesting if you have a concrete example where neither of the above suggestions would work or be appropriate.

Thanks,
Rob


On 05/03/2018 09:25, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
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






_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod