Re: [Detnet] Yangdoctors early review of draft-ietf-detnet-yang-12

Don Fedyk <dfedyk@labn.net> Mon, 28 June 2021 12:28 UTC

Return-Path: <dfedyk@labn.net>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A51A3A3791; Mon, 28 Jun 2021 05:28:56 -0700 (PDT)
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, RCVD_IN_MSPIKE_H2=-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=labn.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 lCZ9yFWYZrhW; Mon, 28 Jun 2021 05:28:52 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2132.outbound.protection.outlook.com [40.107.244.132]) (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 D870C3A378E; Mon, 28 Jun 2021 05:28:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fUJoAkhDDce5DsPaan45Q1kMDulmY5jMeOgR34ssZ+XBwFio2S7xwvZ4qgsaMEx0YDjYVTOYrUn42/PkBHlxvgM61uKHWezeMNt5d3DAouIzDrpkpWPZSkyMexqHdSst8jFeGN/coWqdx/o4Nrt0OJ17YtjaoNz+Xieov2txmDXO6eHbJlUT5zM6jUJSF7TmoBZlh+ro7h9x2NCRvz4dd1dPsgyUUUFYzWj1AGtS+ZixUc3vzfTfVw+bwltHUAGqh/0Qedv34KLNXoW9o2lCHkQoqzSV7smWDvc1zipOm+KLn9bfG204kPDTjGoJ+cXCI9MRKuvQNCwq0iymcivaFg==
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=bZDSasKNlM+FQ/lG/z1BAs9ikk4T1PG1WVtWc4WP+Ow=; b=J23UUU5goIUWl2ioAT34IBXofxj4DgLhRUtGgulz6yHTSChUQcwwkdDZVmIMEVdvTJimpPbLT4X7XAAvcwB37uCMwAKoxbxU2surY39ZQEuSdLqnYBHFt6DZwHbNRoKZ6O5ij07IZKYFbdxrwje8UtsCIhpBFmAsrDEiWm37+g8n3Glj6cOtcWl869t4yA9TPatRO3HnSuJTpF7Gd0vBmHaDxvHJLEnq/XaRT24R/1r4vF/vO9cskk5sVoZY5a/O+FGr2MZTkLrCHqZpvZoCDrVhkZ2BqnIvzPk7Ehb3/VeKitLRPvspUyIkWn6MFnej5R6WqdLTWouJcnv3Bqm7fA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bZDSasKNlM+FQ/lG/z1BAs9ikk4T1PG1WVtWc4WP+Ow=; b=WtluutfM+MLF8V3r7ZehYgi7ChYARJLcYgeuQ4hyFeWGu7XBBBE63xHmx9fv8xQ5hrgp+/ToAAHjwpHbELwWEZv4xzDkNYxao7C8/ZbZHyo6rsLV1HWDsigUBjwJYbSI8Mst+WuKeNILs4OGGP5UpiRGZzDTHEaBiggGp/zO/TU=
Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by MN2PR14MB3437.namprd14.prod.outlook.com (2603:10b6:208:1ae::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Mon, 28 Jun 2021 12:28:47 +0000
Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4c5e:8db3:e6b5:256f]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4c5e:8db3:e6b5:256f%5]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 12:28:46 +0000
From: Don Fedyk <dfedyk@labn.net>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-yang.all@ietf.org" <draft-ietf-detnet-yang.all@ietf.org>
Thread-Topic: Yangdoctors early review of draft-ietf-detnet-yang-12
Thread-Index: AQHXa6FR+jTUdZ7hXkirvrAWreK31KspVvWA
Date: Mon, 28 Jun 2021 12:28:46 +0000
Message-ID: <MN2PR14MB40309592708DBCF44336CFFDBB039@MN2PR14MB4030.namprd14.prod.outlook.com>
References: <162483184905.11951.18366537346797539633@ietfa.amsl.com>
In-Reply-To: <162483184905.11951.18366537346797539633@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=labn.net;
x-originating-ip: [173.48.105.206]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 21ae80f8-b906-4e16-1e3e-08d93a3046b5
x-ms-traffictypediagnostic: MN2PR14MB3437:
x-microsoft-antispam-prvs: <MN2PR14MB3437018BABD90FAEB6CA6F90BB039@MN2PR14MB3437.namprd14.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PT/fbow8cCVqPwuwly5SGHw5D3eHhQstfkk7JepGkz+Piv2ONQkTQ07mqMeYn8sZXcncttcS9cEufA2lmAspcAFnwR4b0voNab0gZluHuxeSbmn+Vi9nUgt1DnNXORwbsz3GRbTyHtHHDEsR4JaOlkaB6/DU9bMVHpjKtsyk9qI8q3/2+bSO/sm1aTYCeyTG9INj2GPhIj3WmcPF5zwMTutk9FStOFIMelGJuoqWCTr3EIFXtIDPV7YTloRqQTJJ/Wbs8Xe8sN1cHveygqPxwnlBDyKs3r22faugqq3rxnzAlOstNAD44W2wj1T4TC7IAmSzUOFzGZ/mmfW/IleE/cQaxj4qtYajJpj5UI/kEFhT7/OsnqxUEUYw+y/KSy7MgBydsVVX+Jqb+vYZk7YbVXeivzQF63ZI4Z0zHzBmqecKc9vugGuam8cpiX9omX1vQWkBJqn4C0Faojd8K/D0uESbqIU8n9PqqOAPgAhn9rF2mhlfhhOsjG+ymjTWJzkQi9wKsRxvjc3yi++GgX34wJTj9n0/ydIjBqLPAy7V9Zw7gIRuBTr6FELGto7w3du28JmxOZWSeC404XqzuKf9tK8Qeih7Xu0a0CPu7jpr7DUquN6XJoyKnp/Pjp0rB0CxlwkYTB+dFVov3HtoulzHeXv1xDXfJwAYVY+xjWA8VPoIXulRt6vJny2op7VAHIy+9nwvHccu602s+qhqfous4HwaXGnY1W3y/vk4O3Eh/wNQsw+zDoRdaR1nAm0USLFF1F2SbQepHCV0tv6HrRuBNw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(366004)(346002)(396003)(39830400003)(9686003)(33656002)(86362001)(8936002)(186003)(4326008)(55016002)(83380400001)(26005)(71200400001)(8676002)(2906002)(6506007)(66946007)(5660300002)(66446008)(64756008)(38100700002)(66556008)(53546011)(478600001)(54906003)(110136005)(122000001)(966005)(316002)(76116006)(7696005)(66476007)(52536014); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?T0U3cjdXTFowRXczS2dzQ2xYQ3h5OW5reVNjbXloNy9leHluKzZyM1JaYzR1?= =?utf-8?B?eUMyamVxUmhSV3lvNTQreUFWWDdpb0dVaDhKK0haZUVMMk1XckJtRkJ3YUxt?= =?utf-8?B?ZjhQby9PN3ZwblZvQ0FRdGVTSThna3VqZTdBd05tR0taVVc1QWtQS0wrV3pZ?= =?utf-8?B?RU9Yb2s2VU1nNzM0WXdkNEI3MHR5U0NRMDJGQk9xRW1xdWZva2Njd2h1azRn?= =?utf-8?B?Z0dpaGtwSWxCdEtTY3pUbVRiZ2VvVS80dW9jN0ljWjdlUXd4aUwyOXpiOFM3?= =?utf-8?B?bEJvSXY5RHBWeC8yZHlaend5YW9yRlJRcncxQ1QycW1HNGd0OThhZU5nckZ4?= =?utf-8?B?Snd1cERmUVJlL3RqOHRkNzVQbWZzMkdKZ1VVRW54OU4zYUZNOTJ1cytuZlpo?= =?utf-8?B?UUw1MEl5SlRRWnZudEtWSHJSYnRwQmF6SDdGQWxHYXE0M3VYeGltZC9aZjYv?= =?utf-8?B?b0U5aDM5ejNjSjVQaWR1eXExa3dMZXE1VE9vVVJkK0tQdGlHNGM5bllZay9u?= =?utf-8?B?c0cxNEtKeFREbVNMNzgrbnB0VS9qRmtaZ1hERkp1L0JLeGx6UTJkeWJubVRw?= =?utf-8?B?WjJLU0VlUkhyaGF0QjlrMml5dXdEQlBGeGl5VjBaellFSXBZOUFmWmcxZWto?= =?utf-8?B?SnBrZ2FLL09HR0xxNDNZTnBYTW9OWStualFhbjg2NEUzL0I3MkxPaWc4UUhK?= =?utf-8?B?b3JsZUcvaWJIbjlwZlRPYjgyVnJmd0hBMDBFVHlZYXBIOGZmQTJIU1pUVHVZ?= =?utf-8?B?RVd3Zm0rZDFEVlAyREx6NHdMRWdCeTFkakVPeHFudkVDT1NCWmVudU5GNEJY?= =?utf-8?B?VFNhL2p3cnFBSTJldEFvdnBEdVVvdyt3ZUl1Y3ZYaXpRRUJiczhoRGtKbmNH?= =?utf-8?B?ZUdHQkVpSk9RU09Zb1V2SUpmNEtkRXI2UVhIN2lDVG9kbk5Vd0FoYnJBM2xU?= =?utf-8?B?K2ZpZ0I5MHBkRzlCQUpMYlJmUW9iV25IUVdFWmp5YTZiT2J3a0FVSmVUbTdW?= =?utf-8?B?WEI5ekJ1d3JoSjBEU2NLV2N3K1BGRlJJbW12MUIvbEtvaWlMdkpVTVFoeVNY?= =?utf-8?B?Yng2VGF1YnZqQUQzVm5hcDMyZGN0WVJzcUlxOHdBZG5HVm0vTForNlpJWURk?= =?utf-8?B?U2lnQ0E2VFNqb1FlYXhldnZrTlQvK1NhcjU3Z1FwSERRKzg5YWFMQXdkTm5U?= =?utf-8?B?MWdYbzZRZHQyaVlDbVBDK3M0dGVZQllHTjZDK0gxbXpCVWdUbEZXWDlrdlVJ?= =?utf-8?B?enJJYjBQZ1A2WmZONVF5ckpPNEVMODhkY29neW5lOXVzbFpzRC93d3VHei9B?= =?utf-8?B?OXRNQWtpNlkzUm9QUmJjT3JiRzViYys4K0JoZWNoZk9ObDZVZU5kVkZFdWgr?= =?utf-8?B?c1pSSTEvRXU0eU1MSi9qNEMwY1NPTVV3ZHU3TVVUUlZyLzN5SW9LMnhDeTNR?= =?utf-8?B?bGlsOEE0WFFVU2FpM3ZkellhZXJrY0tzaTk0bHRuVjZsdGJJQkxMVngvRDUw?= =?utf-8?B?cmpjdDVESnpZSkpzVVBxLzJZNjluN1kyUW1uWFBEUlV0V0p5MThZU0t6aytV?= =?utf-8?B?YlZCUG14Z3ZUa1VScXFxNzJIMVhrTjV0N3M5MWZkSGJEckwyTk5RQnZKaFJv?= =?utf-8?B?ek9LNTJETGlsUGdPZys2TmUzRUdCNzRyN3lIdXpnZVlhRGIrZmowZ3VWTlZx?= =?utf-8?B?MWk1eTRvYVkybEdxdCtYQlNZcndDY0FzY0VvVVpURzJkaXdBdEVlWlY2ZlFJ?= =?utf-8?Q?9+18RAyoz2Zzd9wHQZanVmjrxal1M6PiuvmU+uU?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: labn.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 21ae80f8-b906-4e16-1e3e-08d93a3046b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 12:28:46.7109 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6jMBEkSV3BIlJpnPJCrjB/ZNZbFxxVy8taap+Aj1CIfqT3aK7k8jsWcx3Wv4fGB+fLfE4QirgzRy5ArnHKT7uA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3437
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/3FxlIXlShO25R3AdIXflpXaeqP0>
Subject: Re: [Detnet] Yangdoctors early review of draft-ietf-detnet-yang-12
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jun 2021 12:28:57 -0000

Hi Xufeng

Thank you for your review.  We will address your points in some subsequent emails and updates. 
We are currently working some points on raised on the list by Tom Petch.
Your first point about missing diagrams I think is a IETF toolchain issue.  The HTML at 
https://www.ietf.org/archive/id/draft-ietf-detnet-yang-12.html
renders diagrams correctly but the PDF is not what I get when I generated using the local xml2rfc toolchain.  
I have sent off a request to the RFC tools team to see if the PDF can be corrected or if there is a submission item I missed.

Thanks,
Don and the YANG draft authors.



-----Original Message-----
From: Xufeng Liu via Datatracker <noreply@ietf.org> 
Sent: Sunday, June 27, 2021 6:11 PM
To: yang-doctors@ietf.org
Cc: detnet@ietf.org; draft-ietf-detnet-yang.all@ietf.org
Subject: Yangdoctors early review of draft-ietf-detnet-yang-12

Reviewer: Xufeng Liu
Review result: On the Right Track

This is a review of the YANG module in draft-ietf-detnet-yang-12.

1) Missing diagrams in the PDF and HTML versions of the document.
Sec A.1. says “Please consult the PDF or HTML versions for the Case A-1 Diagram”, but the this diagram and other diagrams are not present. Because of the missing diagrams, it is unclear how these examples work, so the following comments are based on some assumptions that may or may not be what the authors intend to hold.

2) Implementation locations and the users of the model.
    Is this a network model implemented on a controller or a device model
    implemented on a network element? The abstract section states “The model
    allows for provisioning of end-to-end DetNet service”, but the YANG module
    and all examples use “ietf-interfaces”, which is a device model. The
    interface name such as “eth0” is unique within the scope of a device. There
    is no explanation in the YANG module and any of these examples.
   If the model is intended to be used on a network-wide controller, any device
   module should not be imported. A network-wide module may be used on a
   device, and a device module may then be imported.

3) In Sec 5., in the diagram, “TR” is used, but not defined. Amusing that “Ref”
means “referencing”, the abbreviation also needs to be defined, especially if this is using the YANG leafref mechanism.

4) In Sec 5., the last paragraph states “four parts of DetNet functions defined in section 3”, but “section 3” does not define the “four” parts.

5) In Sec 5., the last paragraph describes “three instances in DetNet YANG Model”. The term “instance” is not clear here. A YANG data model does not usually consist of “instances”. RFC7950 uses “instance” to indicate the configuration data or operational data, so “instance” means “data instance”, which is not part of a YANG data model that “describes how data is represented and accessed”.

In Sec A.1, Example A-1 provides one data instance that contains all three “parts” (or components) of the DetNet system, so there is no such a concept of “App-flow instance”, “service sub-layer instance”, or “forwarding sub-layer instance”, because one single “data instance” may contain all three parts.

6) In Sec 6. in the sub-tree app-flows,
    6.1) Does this sub-tree model App-flow or NetNet flow, or both?
    draft-ietf-detnet-flow-information-model-14 defines both terms and
    describes the distinctions between them.

    6.2) Except the leaf "name", all other leaves are optional. When a user
    creates an instance of app-flow with only the name specified, what does the
    system do?

    6.3) Containers “ingress” and “egress” are specified. However, based on Sec
    2.1 of draft-ietf-detnet-flow-information-model-14, An app-flow consists of
    source and destination, not ingress and egress. “DN Ingress” and “DN
    Egress” are parts of a “DetNet flow”, not app-flow.

    6.4) Container “ingress” should not contain both source and destination.
    Sec 2.1. of draft-ietf-detnet-flow-information-model-14 defines the
    “ingress” as the location where DetNet flow starts, so the ingress is
    related only to the source, not the destination.

    6.5) Based on Sec 5.4. of draft-ietf-detnet-flow-information-model-14, the
    choice data-flow-type under the container “ingress” is how a DN flow is
    identified, so this choice is not just related to the ingress of the flow,
    and should be outside of the container “ingress”.

    6.6) Based on Sec 5.6. of draft-ietf-detnet-flow-information-model-14, the
    ingress section of the model should identify the ingress node(s) and/or
    starting reference points. It would be good to have some description on how
    the ingress node(s) is (are) identified, especially in the case of
    mpls-app-flow. The description on the leaf name currently is "Ingress
    DetNet application", which is not consistent with the definition in
    draft-ietf-detnet-flow-information-model-14.

    6.7) Why is app-flow-status under the container ingress? app-flow-status is
    related to an instance of app-flow, not only the “ingress” part of the
    app-flow, right?

    6.8) The leaf interface in the container ingress would only work when this
    model is implemented on a device (but not on a controller) because
    ietf-interfaces is a device model. Based on my previous assumption that
    this model may be used as a network-wide model on a controller, the
    referencing to ietf-interfaces would not be appropriate.

    6.9) The relationship between app-flow and service-sub-layer needs better
    described. When an app-flow is served by a DN service, the packets of this
    app-flow are processed by this particular ND service, so there is only one
    supporting service. Why are there the “incoming-service” and
    “outgoing-service”? Are the terms “incoming-service” and “outgoing-service”
    defined and/or described in any document?

7) In Sec 6. in the  sub-tree traffic-profile:
   The container flow-spec is not consistent with
   draft-ietf-detnet-flow-information-model-14, which defines the leaves under
   this container as TrafficSpecification in Sec 4.1.

8) Before Sec 6, the document does not have an informative reference to the YANG tree diagrams specification RFC8340. Refer to Section 2.2 of [RFC8349] for an example of such a reference.

9) In Sec 7, the document text does not have the references to the RFCs cited in the YANG module. These references also need to be listed in the document.
Sec 5 of RFC7317 provides a good example.

10) In Sec 9, the Security section is missing.

11) In Sec 8, the IANA Considerations section is incorrect, with missing IANA requests.

12) For the IP address or prefix examples in the Appendix,  a mix of either
IPv4 and IPv6 addresses or IPv6 addresses exclusively SHOULD be used.

13) The module prefix ietf-detnet is better to be changed to detnet.
IETF-defined YANG modules usually do not use “ietf-” as part of the prefix name.

14) As described in Sec 4.3.1. of RFC8407, child nodes within a container or list SHOULD NOT replicate the parent identifier. There are several occasions in the YANG module, for example, profile-name, app-flow-bidir-congruent, service-protection, and service-operation-type.

15) The node name in the list or leaf-list statements should not contain the suffix “-list”, or in the plural format. For example, service-sub-layer-list is better to be changed to service-sub-layer; member-services should be member-service. The structure of app-flows/app-flow* is the common convention used in IETF. It would be good to be consistent within this module, so it will be a good idea to add a container "traffic-profiles" to the list "traffic-profile".

16) Most of the leaves in this module are defined as optional, but only one leaf has a default statement in the entire module. It is generally needed to either provide a default value or an explanation in the description for such an optional leaf.

17) There is no configuration node and operational state node to indicate whether DetNet is enabled on the system. Please confirm that this is the intention. The fact that this module is supported on a system may not mean that DetNet is enabled.

Thanks,
- Xufeng