Re: [CCAMP] Yangdoctors last call review of draft-ietf-ccamp-layer0-types-03

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 16 January 2020 10:07 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F267F12002F; Thu, 16 Jan 2020 02:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Nwyq/S4A; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EpD3fL8y
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 g7Gf_PJpb5Wy; Thu, 16 Jan 2020 02:07:53 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CA712001E; Thu, 16 Jan 2020 02:07:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14316; q=dns/txt; s=iport; t=1579169273; x=1580378873; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IeDgXF+tt6dQ7U1GdVrMgOYKYtNAeoXNxFmqdjJZ6aQ=; b=Nwyq/S4A9f4CPeoN3sLIUOtDiEaLb7bLz5DrKAcKIuJzOIL5KYoEy8nV imvWCE26tsaX1FPN6fWCainxSYRd4LPeHM/DLlLyQ70ED+6xRx1IFZ9tV H6v8YugIlTr8XK3ZG3dGi1hUTCg1B/CnlQoydjjgrrAh4UogIj2XFXGJY c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AK67qtRGa/y6bdqGj1Rw3JJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBQANNSBe/5pdJa1cCRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gVRQBWxYIAQLKgqEBoNGA4p4gl+YDoFCgRADVAYDAQEBDAE?= =?us-ascii?q?BGxICAQGBKwGDFAIXgWskOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAwESEQQ?= =?us-ascii?q?NDAEBJQQOAQQHBAIBBgIRBAEBAwIjAwICAjAUAQgIAQEEAQ0FCBMHgwWCSgM?= =?us-ascii?q?OIAECjlqQZAKBOYgQBUx1fzOCfwEBBYUlGIINAwY3VyiMGBqBQT+BEUeBTn4?= =?us-ascii?q?+gmQCgTABCAoBIRWCeTKCCiKQU559CoI5hz2KT4Q/gkeIBJAljlyBSYYNgQq?= =?us-ascii?q?SJAIEAgQFAg4BAQWBaSJncXAVGoMNUBgNiAEMF4NQilN0gSmKIYEiAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.70,325,1574121600"; d="scan'208";a="467203961"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jan 2020 10:07:51 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00GA7pHj026806 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jan 2020 10:07:51 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 04:07:51 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 04:07:50 -0600
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 16 Jan 2020 04:07:50 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lk6bee96h7ZTvdDJRfqOfdZ+BxoHveUbz+g2U/yIWJrGTcCr76vaHwLYwqMTwgBYmN7GMPoaIt/R4F/mt0+ilSwRCoho2dHaQ66zm3sceJ4gpdcIV8UckRJeVnPWhdzpfkN7XYpI3ExwUAHiDA1UWVCQkOtAryfyXEU2iFOtxp+VYAh9T0i8YpUND49PRTd9+m+mUdWOP+bhFKptmA1u1STH6B8+SAW3I6rdbNhmrjxofyLqbo+JwHmk6u64Mn34SSoseBAYCQ5JCSL/ezks0O/n+0VG9DZtmcf/XlEYIJGq75Pcq0bKhRqsbF648KDAnHnDk41bALk1SY8koY1kOQ==
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=IeDgXF+tt6dQ7U1GdVrMgOYKYtNAeoXNxFmqdjJZ6aQ=; b=HLWRjlyBGGQuLCeWzHbKq7Bb8IJOZILo6V4wfDeNYOW+D+bn3/PRnCwArqBiDCvZJZK1vk1lLGc5iAkK+3ZV9yqK0iyCIPcY1ZySzYOtLlN8KaCDs5GJAo9biHYhHXmZ58X/V2uLVWEjTrcP9iBFBjc7bqj59EEzTxI77vsMR3oLZZ0M5pTRhXoJKk5rcc6J6Jw3psA7O7PsgPVv1vRaAJxmGD2pqtPFFQSeHJnp0XSklF0f0myKCYq9wPLkrc9m2wXjntmHx4DTt3Of+j1g2uxPjKcJiZFDgihoVnv9fQBCZgm+8hozDFY9RlRxglQFbyZFGUxeOerP9TB3/IugxQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IeDgXF+tt6dQ7U1GdVrMgOYKYtNAeoXNxFmqdjJZ6aQ=; b=EpD3fL8ygqNIN3dfHSLoitw6BHcg549lXN1eL2CEuve18NoC6zeeFLwgBr6AYPAWlOeOMPpNEUVHmIZtWSoBAyb7sWzJMlyNeZB5Bx7FJ0wLh0fnFxaVLUiRcL2LcSl2ziQ1/pzAp63lx5YDQaU+3E/wy1zVQhN2gIYqMHg8TGQ=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3885.namprd11.prod.outlook.com (10.255.180.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 16 Jan 2020 10:07:49 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2623.018; Thu, 16 Jan 2020 10:07:49 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Zhenghaomian <zhenghaomian@huawei.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-ccamp-layer0-types.all@ietf.org" <draft-ietf-ccamp-layer0-types.all@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: Yangdoctors last call review of draft-ietf-ccamp-layer0-types-03
Thread-Index: AdW6/Aj1g5UqEMoXRQWkhe6nP5hgSAQx31+A
Date: Thu, 16 Jan 2020 10:07:49 +0000
Message-ID: <MN2PR11MB4366CA06F3A7B31BF54A5533B5360@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43B93643E@dggeml511-mbx.china.huawei.com>
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43B93643E@dggeml511-mbx.china.huawei.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=rwilton@cisco.com;
x-originating-ip: [173.38.220.36]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2b3a282a-34fd-4b89-4ec9-08d79a6bf147
x-ms-traffictypediagnostic: MN2PR11MB3885:
x-microsoft-antispam-prvs: <MN2PR11MB388582A6B60EC1D570B0E70CB5360@MN2PR11MB3885.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02843AA9E0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(39860400002)(376002)(346002)(189003)(199004)(110136005)(54906003)(52536014)(66446008)(66476007)(66556008)(64756008)(66946007)(76116006)(966005)(26005)(8936002)(316002)(7696005)(4326008)(33656002)(8676002)(186003)(81166006)(81156014)(55016002)(71200400001)(86362001)(6506007)(5660300002)(2906002)(53546011)(478600001)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3885; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BbOGCeEEmtRxRP1B5kpOsNmAsty8MiBFoust3yiaxClr0Kr6XTve4hmV5Um85lfNcrkM545ecgtrkXcJ4scdMerzsbNt/IEKjo1qdRUwqDYLTOClk/2eLXUqRVEbWiMOrmrRTHoJIufBnZdwMjSJpETL1DR2h5B1VualljYVnhYwfWu4ilgM5hzSOb7q2ps/xqe39k0pViDsJ9IJO0NZ4caK4DHfS/MnUGmBE8tKCNOgLOkpoy945Znwkhh2Y62gRrWgJ+PTGwn3o448pyBN9dP9RYLIWvYO95un8d08Epaq7cv0c/RRBfIbPLhS0axdmMZgXwrSHUXG/uoNEK9Zl4UKEeXYnFfwzm/r/5s2cQ2P3xWRLHjv9YKDpF3DTi+I5ks0jvpw7IfXJSD6/6rltOIfaIcCYCvUcPO8JEsRxfUg73BR1U6CbpGemxUTu1FLOYxa1OYcwUFl2ByualG7odZQYM5EMo/IcTP1fOPHKy9Mx6BlmQNVBLkc6gQhN3exx73QUb7YonEx5hK+zwdNvw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b3a282a-34fd-4b89-4ec9-08d79a6bf147
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 10:07:49.3796 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HL3rfmDwlndNMzbwTSeSxQ/PRGbMdWF4/ntp5Nd0mnjdwNBdNFpWoQaZ+v8COr53V1HeFmig+0MOWTrTzI485g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3885
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/arz5YIbVeybIzUF1PQBPJrQqU_U>
Subject: Re: [CCAMP] Yangdoctors last call review of draft-ietf-ccamp-layer0-types-03
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2020 10:07:56 -0000

Hi Haomian,

Sorry, I had missed your email over Christmas.  Replying back to the original email to capture the other aliases.

Please see inline ...



> -----Original Message-----
> From: last-call <last-call-bounces@ietf.org> On Behalf Of Zhenghaomian
> Sent: 25 December 2019 08:20
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; yang-doctors@ietf.org
> Cc: last-call@ietf.org; draft-ietf-ccamp-layer0-types.all@ietf.org;
> ccamp@ietf.org
> Subject: Re: [Last-Call] Yangdoctors last call review of draft-ietf-ccamp-
> layer0-types-03
> 
> Hi, Robert,
> 
> Again, thank you very much for your detailed review and comments. The
> authors had a few iterations of discussions and give the update for this
> document as follow.
> 
> Model update can be found as the pull request: https://github.com/ietf-
> ccamp-wg/draft-ietf-ccamp-layer0-types/pull/3 ; you (and other experts)
> are welcome to follow up in this thread.
> An updated draft have been locally created, with the diff files attached;
> For detailed comments response/discussion, please see inline starting with
> '[Authors]';
> 
> Please help review if the comments are addressed, any discussion/calls are
> welcome and can be arranged by chairs, thank you.
> 
> Best wishes,
> Haomian (on behalf of all authors & contributors)
> 
> -----邮件原件-----
> 发件人: Robert Wilton via Datatracker [mailto:noreply@ietf.org]
> 发送时间: 2019年12月14日 0:50
> 收件人: yang-doctors@ietf.org
> 抄送: last-call@ietf.org; draft-ietf-ccamp-layer0-types.all@ietf.org;
> ccamp@ietf.org
> 主题: Yangdoctors last call review of draft-ietf-ccamp-layer0-types-03
> 
> Reviewer: Robert Wilton
> Review result: Almost Ready
> 
> Comments on the document:
> 
> 1) I would delete the "overview" paragraph at the top of section 2, and
> just promote section 2.1 as section 2.
> [Authors] done in -04.
> 
> 2) 2.1. Layer 0 Types Module Contents:
> 
> The descriptions are good, but I would suggest formatting these as a
> table, or more tightly link the definition to it's description.
> 
> E.g.
> 
> "Operational-mode: A type that represents operational mode as defined in
> [ITU-Tg6982]."
> 
> Instead of:
> 
> "Operational-mode:
> 
> A type that represents operational mode as defined in [ITU-Tg6982]."
> [Authors] Discussion needed: we need to be careful on changing this, as
> currently the layer0-types and layer1-types are in consistent format. Need
> to change in both sides or don't change any of them.
[RW]
I agree that they should be consistent between the two drafts.  My aim was to make them as readable as possible, but this is purely a stylistic thing.


> 
> 3) I would define the module as YANG version "1.1" (because the language
> behaviour is generally better specified) and then reference only RFC 7950
> in the introduction.
> [Authors] done in -04.
> 
> 4) typo in the Security Considerations "layer0 => layer 0", and also in
> the title of section 3.
> [Authors] done in -04.
> 
> 5) I have suggested changing the module prefix to "l0-types" rather than
> layer2-types.  If you make this change then the IANA considerations would
> need to be updated, along with section 1.2.
> [Authors] done in -04.
> 
> Comments on the YANG module:
> 
> 1) I would suggest changing the YANG prefix to "l0-types" to help keep it
> short (particularly for the identities).
> [Authors] done in -04.
> 
> 2) I would suggest making the module "yang-version 1.1;", because the
> behaviour of YANG 1.1 is better specified.  In fact, I would recommend
> that all IETF YANG modules are defined as YANG 1.1.
> [Authors] done in -04.
> 
> 3) It is actually necessary to define frequency-thz at all?  I think that
> the discussion in the WG suggested that it might be better if the
> frequencies are always defined in Ghz and then converted in the client as
> necessary.
> [Authors] We have checked all the typedef, and agreed on removing
> frequency-thz and frequency-ghz together, as they are not referenced in
> later groupings. Need to further check whether the modules who import this
> type module would use such typedef. May need to add back if the answer is
> yes. Moreover, like flexi-n, another typedef flexi-m is added and
> referenced in this module.
[RW] 
I think that defining frequency-ghz is probably still helpful, it was only frequency-thz that I was suggesting removing, effectively encouraging everyone to standardize on using frequency-ghz for layer 0 properties/considerations.



> 
> 4) frequency-ghz: Is 3 fraction digits sufficient for future expansion?
> E.g.
> It would seem to support a flex grid 3.125Ghz channel spacing, but not
> 1.5625 ...
> [Authors] Discussion needed: currently the channel spacing is 6.25GHz, and
> we reserve the 3.125GHz for proof-of-future.  According to Singapore
> discussion, WG agreed on 3.125 with 3 fraction digits. We prefer to keep
> the current format given the following considerations:
> [Authors] Consideration 1: Technically it won't make much sense for Layer
> 0 to come down to 1.5625G, as layer 1 is providing the granularity at ODUk
> (<100Gbps) which is make very good use of such spectrums.
> [Authors] Consideration 2: furthermore, if 1.5625G happens in the future,
> can we keep fraction digits as 3 and specify the channel spacing as
> '1.562G'? There should not be difficulties in understanding, and we solve
> the problem forever.
> [Authors] Consideration 3: the channel spacing is not binded with the
> frequency on the grid, but a number... So maybe we can change the
> dependency on the grid as well.
[RW] 
Okay, keeping this to 3 dpi is fine.

> 
> 5) We should aim for consistency of the identity names in the layer-1
> types module.  E.g. perhaps OTU, ODU and OPU should be capitalized.
> [Authors] done in -04.
> 
> 6) The models uses identities for bandwidth, but I wonder whether defining
> a numerical typedef might be a better choice (e.g. more efficient and
> perhaps easier for programs to work with).  Here, I have constrained the
> values that are allowed, but they could also be unconstrained:
> 
> E.g.
> typedef channel-bandwidth {
>   type decimal64 {
>     fraction-digits 2;
>     range
>       "2.66|10.70|11.04|11.09|11.27|11.31|43.01|44.57|44.58|100.00 ...
> max"
>     description
>       "Bandwidth carried by a single wavelength channel"
>   }
>   units "Gb/s";
> }
> Or another alternative would be to use Mb/s, which would then allow them
> to be specified as a union of specific values and an arbitrary bandwidth
> value.
> 
> [Authors] Discussion needed: we hope this proposal is different with the
> ones on 'identity->enumeration' but maybe push back by extensibility,
> could you please confirm? Gbps is used for data plane and should be
> accurate enough to be described in the YANG module. We are open to the
> proposal, but need to understand the difference and how it affects the
> configuration. After that we can discuss whether decimal 64 is good, Gbps
> or Mbps, etc...
> 
[RW] 
Identities are just names of things.  So, it if the bandwidth value that clients and implementations care about, then I would expect them to need to write code to translate between the identity names and numerical values.  E.g. what does a client configuring the device primarily care about here.  Is it that the bandwidth is "otu2" or that it the bandwidth is "10.70G"?


> 7) Same comment as for bandwidth applies to the channel spacing
> identities.
> I.e. I wonder whether these wouldn't be better defined using a decimal64
> type.
> 
> E.g.
> typedef dwdm-channel-spacing {
>   type decimal64 {
>     fraction-digits 2;
>     range
>       "12.5|25|50|100"
>     description
>       "Bandwidth carried by a single wavelength channel"
>   }
>   units "Ghz";
> }
> [Authors] Discussion needed: probably reject, see the consideration about
> extensibility on layer1-types. 6.25/3.125 GHz is coming...
[RW] 
The model can always be extended to support 6.25/3.125 in future.  In either solution this would require a backwards compatible change to the model.

My hunch is that having this as a numerical value is more useful for clients than having it as a named identity.  I.e. I think that the argument for using a numerical value here is stronger than for channel bandwidth above.

> 
> 8) Same comment as for bandwidth and dwdm-channel-spacing could also be
> applied to flexi-grid-channel-spacing, flexi-slot-width-granularity, cwdm-
> channel-spacing.
> [Authors] Discussion needed: probably reject, see the consideration about
> extensibility on layer1-types.
[RW] 
These should be resolved with whatever the conclusion is above.

> 
> 9) In grouping layer0-label-range-info
> I would rename this grouping to l0-layer-range-info, change "layer0" =>
> "layer 0" in the description.  Also "priority" could do with a more
> detailed description as to what it means, etc.
> [Authors] Confirmation firstly: probably a mis-spelling, propose to 'l0-
> label-range-info'.
[RW] 
Yes.


> [Authors] Discussion secondly: there are multiple identities/typedef
> started with 'layer0-' and it should be better to keep consistency in
> naming format, do we rename all of them or none of them?
[RW] 
Yes, I think that I would rename all of them "l0-"

Thanks,
Rob


> [Authors] priority updated in -04.
> 
> 10) In grouping flexi-grid-label-start-end, I think that the type should
> be "flexi-n" rather than "int16".
> [Authors] done in -04,
> 
> Typos: "girds" => "grids", "attrtibutes" => "attributes"
> [Authors] done in -04,
> 
> Spacing/indenting needs to be fixed:
>  - In "grouping wson-label-hop", just before case cwdm
>  - In "grouping flexi-grip-label-hop", should have a blank line before,
> and  "case super" block/fields indentation doesn't look right. - In some
> of the  typedef definitions, the "{" should move from the start of the
> following line  to the typedef line. In general, as a starting point,
> after all other markups  have been made then it might be a good idea to
> use pyang to format the YANG  file for you, e.g., "pyang -f yang --yang-
> line-length 69", but probably with  some more blank lines, otherwise it is
> a bit dense.
> [Authors] done in -04, probably some compilation problems and will double
> check per update.