[yang-doctors] Ensuring top/base models are designed as augmentable

Ebben Aries <exa@arrcus.com> Mon, 18 November 2019 00:02 UTC

Return-Path: <exa@arrcus.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8015912022A for <yang-doctors@ietfa.amsl.com>; Sun, 17 Nov 2019 16:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 LL2_N6lPxDlj for <yang-doctors@ietfa.amsl.com>; Sun, 17 Nov 2019 16:02:00 -0800 (PST)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680076.outbound.protection.outlook.com [40.107.68.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8701612020A for <yang-doctors@ietf.org>; Sun, 17 Nov 2019 16:02:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mKnM5NPaBVeX2FwnxNJUpGARWg+ipIeCRhtrvXmKGZrK7JcfMRoS3MFe3jyGDYH4MZTzMB2p6d+JheeewI7Hs6n5Ypz5AGF8o3I+4ADVGz2s5DKinpQ+OkrcqfCkMQbWdV7unqPzkAcTgrmioCLAbLV4EBQLAEle1pX1gzjvCMjsDtrt27x1i59E1mGkUDIBc4bYrdysfkQ8AiXfSqV2qkOLvSyAEccATNcZyPdp3d0hablIQpOk62RMTZaisTiudeBvSCRWIMh4YYzKIkPusCRO54aOTltYZlW2sjjOiVAPLZLiVklQxoLDSkRCYK/O2LGJYRrfCZ7wVqA/oVy8Nw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/xw4Pb27/GpinitojGSea/h+FU9pJbFWmEbPZcmpDkM=; b=HUYpNglyLb8euQqwEeTDH0CDk/Id5MIJa3LEeEwyeY6Bj4qj9nb82xI+XHljiJSflAYzafrhFt6BDEXorh23knuWzXv2znWwWrSagZNmw4yyfEd4WXnzXD5F9wfDzl4xgTEK7+V4iVTQpoxoLcJMzwybSuaPLglob7dFt8K0r/I5gikID0MRHQ+5YvHSIK2mdvj7J3+gxtLwbUGWCbIQqmq9maFNQGKDdZS5+8ZBm+xQyETcgk4wSWkvjiZnQOIlxkv3HtnVW1pFV9GG3129ItzX1kjk35mdT4W5YpKacbb45PwW6zaoEknJeWpATBzqaZ9SZNFGUNYQGrxM1pP5RQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/xw4Pb27/GpinitojGSea/h+FU9pJbFWmEbPZcmpDkM=; b=Wk7PyGRNTiUGaeME5Gp5l3xW4InTwkVclR5arQ8UO9GznMVfUkymmP1/6nOdXRPsNszU3WQ82F14Zqud5kmwiSADvfbql0dXXxnUHVW0/Gkqa5ksKImEFNFxmbwsps3rjFTQ3Z/2KRJrQUdcNpuBRg6ARL9Cohk/eob4vGjXBsA=
Received: from DM6PR18MB2602.namprd18.prod.outlook.com (20.179.71.89) by DM6PR18MB2508.namprd18.prod.outlook.com (20.179.105.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.27; Mon, 18 Nov 2019 00:01:58 +0000
Received: from DM6PR18MB2602.namprd18.prod.outlook.com ([fe80::dd61:d000:bf1a:a9c1]) by DM6PR18MB2602.namprd18.prod.outlook.com ([fe80::dd61:d000:bf1a:a9c1%6]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 00:01:58 +0000
From: Ebben Aries <exa@arrcus.com>
To: "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Thread-Topic: Ensuring top/base models are designed as augmentable
Thread-Index: AQHVnaNki2FbS4UL+Ey8kTDBcVGJhA==
Date: Mon, 18 Nov 2019 00:01:57 +0000
Message-ID: <20191118000150.amlnwhgagufkft5t@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: HK2PR02CA0196.apcprd02.prod.outlook.com (2603:1096:201:21::32) To DM6PR18MB2602.namprd18.prod.outlook.com (2603:10b6:5:15d::25)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=exa@arrcus.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [203.127.152.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4ac057aa-74d7-451c-70be-08d76bba8764
x-ms-traffictypediagnostic: DM6PR18MB2508:
x-microsoft-antispam-prvs: <DM6PR18MB25085009215B5C297960D634CD4D0@DM6PR18MB2508.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916004)(346002)(136003)(366004)(39830400003)(376002)(396003)(199004)(189003)(14454004)(7736002)(5640700003)(305945005)(8676002)(316002)(81166006)(81156014)(476003)(486006)(6916009)(6486002)(8936002)(25786009)(2906002)(2501003)(99286004)(508600001)(66946007)(2351001)(5660300002)(66556008)(66446008)(64756008)(66476007)(102836004)(26005)(9686003)(6512007)(6436002)(186003)(1076003)(33716001)(3846002)(6116002)(66066001)(52116002)(86362001)(71200400001)(71190400001)(256004)(14444005)(6506007)(386003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR18MB2508; H:DM6PR18MB2602.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: F67Pwft6CHLXbB2FiIMK18YHdhyS6xZ1q32mJ1UqZ4FOFOYAWea0DFb6xV5ae6C9FWh+4P4iTgFVJRa2ljg6mJnvV/ow+rJLZjGwlaCQyMjJvt6GzLBP/TFJWqD1IERY6XVJC0McEl3o6Z1OrLBY13FLFX8HoJEOQPUfysvr1D3Vu6LaFpZtn0N8h61d8fpOWUUYeEMAsmqNppDOcTu075iB2YqKL1tOrby9auXkT8r68funI57fHViASmOgWqpWqLZCPPGEyPDdOJal0xjtE4X0j4moRwTqxe+3jXl0rVp6Jip7Syuik04dilneeK4Sr6TZ6Zo98Ur9nUjeIdQlvf0w1+ivGOskPYaAgUovGSKLLAnA4J6xoJeU4d/eQrPLWt3DrbQeShU6h4laFVUKDFI75WfHhMMoHVyHmNrGePB3dv7vafgqwl0lRf7wZW2y
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9A7374B27EDC534D9890A76E3E2E703E@namprd18.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ac057aa-74d7-451c-70be-08d76bba8764
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 00:01:57.8278 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1EqWKSXL1XvO00kL/QbHghGrRWiGD8ao/OybY5xII23j1g1X4V90U8RS9dKVm/dE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR18MB2508
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/LKM23QhaPc1jcjzKtTVXlo16qlw>
Subject: [yang-doctors] Ensuring top/base models are designed as augmentable
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 00:02:02 -0000

I was looking for any such possible wording in 8407 but could not find
anything around this design consideration.

Case in point, there are many modules that may be defined with top-level
nodes where the intention is that other domains add/augment in either at
a later date or at a bare minimum via another set of
definitions/modules in related domains.  When this occurs, it seems
important that the top level modules are designed in such a way to
account for such augmentation and to pick on one case, is the use of
'must' statements in top-level modules.

If we look at ietf-system below, for authentication, there are 2
definitions carried in the top-level module (local-users/radius) with a
must restriction being placed at a node which is a target candidate for
augmentation.

# ietf-system@2014-08-06.yang

    container authentication {
      nacm:default-deny-write;
      if-feature authentication;

       description
         "The authentication configuration subtree.";

       leaf-list user-authentication-order {
         type identityref {
           base authentication-method;
         }
         must '(. != "sys:radius" or ../../radius/server)' {
           error-message
             "When 'radius' is used, a RADIUS server"
           + " must be configured.";
           description
             "When 'radius' is used as an authentication method,
              a RADIUS server must be configured.";
         }
         ordered-by user;

Now if one were to augment in with say 'tacacs' which would define an
identity that would base off sys:authentication-method, this would
either mean

- Any augmented identities cannot follow the same design pattern as
  those in the base module
- A deviation could account for adjustment of the base must statement

Obviously, the latter is not a design choice we want for SDO models