[netmod] Questions on coordination of models between standards orgs

Rodney Cummings <rodney.cummings@ni.com> Thu, 18 June 2020 20:44 UTC

Return-Path: <prvs=943832d55a=rodney.cummings@ni.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 1EC313A0F06 for <netmod@ietfa.amsl.com>; Thu, 18 Jun 2020 13:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.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 Df3zsGJmZBuV for <netmod@ietfa.amsl.com>; Thu, 18 Jun 2020 13:44:37 -0700 (PDT)
Received: from mx0b-00010702.pphosted.com (mx0b-00010702.pphosted.com [148.163.158.57]) (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 124AB3A09F9 for <netmod@ietf.org>; Thu, 18 Jun 2020 13:44:36 -0700 (PDT)
Received: from pps.filterd (m0098779.ppops.net [127.0.0.1]) by mx0b-00010702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05IKb3DU025353 for <netmod@ietf.org>; Thu, 18 Jun 2020 15:44:35 -0500
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) by mx0b-00010702.pphosted.com with ESMTP id 31q67pegtd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <netmod@ietf.org>; Thu, 18 Jun 2020 15:44:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D0OhoGdLMZjkY1gXPTgkYcPCxuohjtuZo/nnI2iO1IhDulEZ/8ahX7pcCyqpRk/YvKhNuYWyZMoW0HMr6NTunTCZU1Cf9Dh1glMVLYLsdQK11eqCvsyYRL6c+QHQQ090y7R7pjQu0SnOzTxoy8s3OUwyc6N7f5s5e+uLY8jQpiAlpkID2aA9YneWSkpKs5hoRSbXQGhv//paK/t0j5yp7vLjnd4/nUPcqzgDUQxr+jq2r2UDiC9hBeYZ3JhmUyXzcaOkcKh3C+HWhtgYHeBDkDApMXovntvO3r/EMJudt/O/9WfF3U563jmC2fGsJDwSh7TQxhGZknh1sSzmT0NA2g==
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=JsO4mo7RUZdw6Pwy0M2Pv0QWcupWUrHAYASODPR+5bk=; b=MY1CgUvY0GmlDR7kvVRkpn02h6RXWuF6wCv3077UxA6oiUvdipc2qg8t0Ym2F9rMSNhVysbSbOSTLZqBw2XGWeRuU/saOGPBSiQVFf3F4NQg1ktf6saUMLScA3ktkciLXVEE6Bhk3/iOBgWVETLgZBBKrv7rpHtX7LQdiTHhOostCrJwYcewBUDZC4srFNSAKWD0tQXMrqG0neu+1DZKskuOF/h0qD94Nc9frkbbOzDMe2oS67y5bo1vZeN2j1ynQugFHc8iMTOXuPE1JsDENBP1mOK7OESHNWbI6Iek35pDEOMW7KRMY/CqEVGfp2Z0aVTLCtRqcEStZVqPW7FJkQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ni.com; dmarc=pass action=none header.from=ni.com; dkim=pass header.d=ni.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector2-nio365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JsO4mo7RUZdw6Pwy0M2Pv0QWcupWUrHAYASODPR+5bk=; b=T/PMYQSlwppbx7buAqr+U9UM6V4ci65sPu+CqBOkA1xMr8hWdw+g8pJzZFQwzlLqLBbJqWoqOY+T6t5JA7SyPMzENKy2StWL5aKizpxt2pQxw0uv7v+2tQ5CQjOV6UyGHuZy3Dxg/YYJ+cCc7mbm0fcZHSj56JfUX9SwoI1ufLY=
Received: from DM6PR04MB4795.namprd04.prod.outlook.com (2603:10b6:5:1f::20) by DM5PR04MB0523.namprd04.prod.outlook.com (2603:10b6:3:a2::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 20:44:31 +0000
Received: from DM6PR04MB4795.namprd04.prod.outlook.com ([fe80::ddfd:de2b:905a:c74e]) by DM6PR04MB4795.namprd04.prod.outlook.com ([fe80::ddfd:de2b:905a:c74e%7]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 20:44:31 +0000
From: Rodney Cummings <rodney.cummings@ni.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Questions on coordination of models between standards orgs
Thread-Index: AdZFkAcQF4ehX9uMTVegRCelg8fTuQ==
Date: Thu, 18 Jun 2020 20:44:31 +0000
Message-ID: <DM6PR04MB47959C8DBE77E7A862597025929B0@DM6PR04MB4795.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ni.com;
x-originating-ip: [66.196.7.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 00fd7337-4bae-4999-82b7-08d813c86724
x-ms-traffictypediagnostic: DM5PR04MB0523:
x-microsoft-antispam-prvs: <DM5PR04MB05234146DC8084353716F0A3929B0@DM5PR04MB0523.namprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0438F90F17
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: G5nJ0BgfTR+Zp2KK6BMADX1tnYsv7Mi356yCUqKRl8Qx9gIFZ15bTw4ASxwFcDDEpdW1LeyRGqhLJKDV8aFkVqpbNGGyIEkzdj6iRK+GSIvRvQ/CZxxXAhQ+a8csCK1dNwUBPNKmNpgy19YMokcgSYzZs5zHXHNHAux3W6qIee7r23kYQlYBgDDH2ztr6qqBxDvc/i60NXo7rWvxm8LsRf0Kv45CiLEyS572NY5CioFNqBnUeMQfMJVIXCK56F45NM9Z6nl6uwGaqF+QF6q8g8X6bRc/+NtNatewoxijjMnmQ4/BWgovn6GrExqYRsxooBkCruyFWDoTRWJlW0K0UQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR04MB4795.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(376002)(136003)(396003)(346002)(86362001)(44832011)(9686003)(7696005)(55016002)(966005)(5660300002)(30864003)(71200400001)(478600001)(8676002)(6916009)(33656002)(8936002)(76116006)(66946007)(316002)(186003)(26005)(66446008)(66476007)(64756008)(66556008)(2906002)(6506007)(52536014)(83380400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: ifrbGrkbsLTlnGo4umnPFCfNB2QQw3+9kEK7WbutgE3mK6f42OlS3jTANbQbQr6GRiP84h8PbeW/JWRgssHvFfJvzEpN8sYvcbqpko0l4tFZ6y/1oq+XBKTQc7+QQP+jPCqKqcLxcRJjVG1qMGFD0+DWhR3OKfP27gCp2UVeVin0WTjXP8T0ETWQtYQs69hJumWIkCWj9RN8rbKLmfyYL9mDRq5YdcKyctoemhU1pJF9ICmHOjNNnpxzfPSRjJC0uCObYbeTGpQZWI9LXWDnw8/jjUZPqYt4e8UVGZPk8eRStNeyUVkF1kipq5uFb825DLO78+VZODkALseeBQ3SBdj05x/wWkYJD9dJWVV5MC/TkEwp3VRWfR9mEkcTiRXVrs2GGm8ft8nnogLeQ24c7lxB1Q3ihLpgUU2XH0fVTk4zxndIAfkoUrrzxAOZpaoL1DvlpGG2e6oIudxb/PZpKSj23QRMACepQzqd7BeH7kM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR04MB47959C8DBE77E7A862597025929B0DM6PR04MB4795namp_"
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00fd7337-4bae-4999-82b7-08d813c86724
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 20:44:31.6338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: V5opzFWQNEyV0y5MHEplOy1Cs9fm5aT4xX/eJKvuK7389QZTP+O0fp0yEo4Lygsaqg92xWLKHky+zx53XkNPhg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0523
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_21:2020-06-18, 2020-06-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 malwarescore=0 cotscore=-2147483648 bulkscore=0 impostorscore=0 adultscore=0 mlxlogscore=566 suspectscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 spamscore=0 phishscore=0 clxscore=1011 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180157
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RRGQWYv6vVGaNAJrTZEfG8HWjEY>
Subject: [netmod] Questions on coordination of models between standards orgs
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 18 Jun 2020 20:44:39 -0000

Hello YANG doctors/experts,

I'm hoping to get some opinion on the best ways to coordinate development of YANG models among multiple standards organizations (e.g., IETF, IEEE, ITU-T, SMPTE<https://www.smpte.org/>).

As a reference for my questions, let's say that we have two standards organizations, one that specifies a "base" standard, and another that specifies a "profile" of that base standard. The base standard has a core set of required specifications, and a large set of optional specifications. The profile standard uses the base standard as its foundation, and it a) selects a subset of optional specifications from the base that are required for the profile, and b) adds its own unique specifications (some optional, some required). The engineers in each standards organization work on their documents independently. The profile standard uses the latest published revision of the base standard, but otherwise there isn't much explicit coordination.

In the context of YANG, the base standard organization will have its own timeline for YANG module revisions, and the profile standard organization will have an independent timeline for YANG module revisions. Each YANG module revision will align with a revision of the organization's published specification document (e.g., IETF RFC, IEEE standard in PDF).

The preceding description can apply to almost anything, but a specific example might help to understand. An example of a base standard is IEEE 1588 (Precision Time Protocol), which has a YANG model for its 2008 revision (RFC 8575). There are a large number of standards organizations that specify profiles of IEEE 1588, including ITU-T, IEEE (e.g. IEEE 802.1AS, IEEE C37.238), and SMPTE. Many of these profile organizations are currently planning YANG development for their 1588 profiles.

Question 1: What are the best mechanisms in the YANG data modeling language to use for a profile standard?

My assumption is that "import" and "augment" provide many benefits. The YANG modules for the profile can "import" the YANG of the base standard. This provides the core specifications from the base, as well as the base features that the profile is using (item a) above). The import also includes some nodes that the profile is not using, but since those nodes are optional in the core standard, they will not be marked as "mandatory", so the profile implementers can ignore them as desired. As for the new specifications in the profile (item b) above), "augment" can be used in the profile's YANG to add new nodes to the base tree.

As an alternative, the profile YANG could copy the contents of the base YANG into its own module, and edit from there (without import). The disadvantage of that technique is that the base nodes in the profile's YANG are more likely to diverge from the base standard's YANG over time. In addition to coordination problems between standards organizations, that can create challenges for implementers that are trying to support both YANG models.

Maybe there are other alternatives? Maybe there are other aspects of the language that would help?

Question 2: Assuming the import/augment technique is used, how do standards best handle a node that migrates from profile YANG to base YANG?

As an example, assume the base standard has YANG for 2021, and the profile standard has YANG for 2022 (which imports/augments base 2021). The 2022 profile YANG has an augment that adds a "performance-monitoring" container to the base tree. Later in 2023 the standards organization for the base decides that "performance-monitoring" is a great feature, so the base incorporates "performance-monitoring" into the base standard. The base YANG for 2023 is published with "performance-monitoring" exactly as it is in the profile's 2022 YANG (same location, exact same container and leaves, etc). In 2024 the profile's standards organization is working on the profile YANG, so the profile's revised YANG imports the base YANG from 2023.

What should the 2024 profile YANG do with the profile's "performance-monitoring"?

Is it sufficient to mark "performance-monitoring" with obsolete status in the 2024 profile YANG, so that "performance-monitoring" in the base 2023 YANG replaces it?

As an alternative, in 2023 should the the base standard rename the container to avoid all collisions/confusion, such as "performance-monitoring-v2"?

Thanks so much,
Rodney Cummings