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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 21 January 2020 13:35 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 7121C1200E5; Tue, 21 Jan 2020 05:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=ZafCWNYe; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hy6YNKCk
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 1ixxcoKxlRAC; Tue, 21 Jan 2020 05:35:34 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AAE6120090; Tue, 21 Jan 2020 05:35:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22592; q=dns/txt; s=iport; t=1579613734; x=1580823334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KKME6+lMxz+aev+ylVJBLbtH4If8i1d5YNFkepyEfkU=; b=ZafCWNYex+Htr+Lfrx+MYzXaJ+H8R5SJ2LnQ4QMbQWS0hMIVhdE8SQui QkiDNasXsMTL1Xq2lOpW+e3K+iPFcj+GdIvdWAPc7wu+fSSSCVZsrLf3F h5qlii04er0klMWzrVXe74h8kqZIOmSObWJIQBJA1Yp1M7iSzlA03ysV7 M=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ar/Qrlh3wAQpt4HUwsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAADY/CZe/49dJa1cCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBe4FUUAVsWCAECyoKhAiDRgOLAYJfmA6BQoE?= =?us-ascii?q?QA1QGAwEBAQwBASMKAgEBgSsBN4JdAheBeyQ4EwIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhV4BAQEBAxIRBA0MAQElBA4BCwQCAQYCEQQBAQMCIwMCAgIwFAEICAEBBAE?= =?us-ascii?q?NBQgTB4J/BAKCSgMuAQIMkU2QZQKBOYgQBUx1fzOCfwEBBYUJAxWCDAMGN1c?= =?us-ascii?q?qjBQagUE/gRFHgU5+PoJkAgIBGYEUAQgKAQkYFYJ5MoIKIo08IBKCZ58BCoI?= =?us-ascii?q?5hz2KT4RAgkeICpAmjl6BSYcYkiUCBAIEBQIOAQEFgWkiDVpxcBUagw1QGA2?= =?us-ascii?q?IAQwXg1CFFIU/dAIBgSaKJw8XB4EEAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.70,346,1574121600"; d="scan'208";a="409772241"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jan 2020 13:35:33 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 00LDZWRA004707 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2020 13:35:33 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 07:35:32 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 07:35:30 -0600
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 21 Jan 2020 08:35:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Um+did6eNxEI0Zb+PvLz/xtwy3fD39SKB5OQ2yKbFWuk8DEBh2NSVscRoE7iz90eKynEe9ByWEUTkQcEXu6Yw9YJNdtWQe+h1DqiXgGXf6k7Wk3zy/JHe78Sl66N2jQYpjuOtOBYnk4s5sQCfd3n0DYYijW22qmda3mb9Pk52lBNS4ucUIhk4J+IQ4FopprEs0onS7PwAy3HnOAUr6vHFw9x0vjdDzWYm2j5MRc1cCqyCIPZVHC3hNkQHm2FEdUe1lsphCs+vfM51+vx/Od2fjmrtILtxqVZKmMkQ0XV/kX1xnR240TtU3pcGy8arbcRm0npdhHX/+8POzKfzrOffA==
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=KKME6+lMxz+aev+ylVJBLbtH4If8i1d5YNFkepyEfkU=; b=CqrNZwbCFqiVPvCO3FmZL0i2WeNqZTYViwEAzo3BFrbK2+Yvoramh/hxkx9vxz674zDNNLTHoi1b1GWaOsTKpfCXYiVu/cAGqYzoVkftKsua2VdrAI0wzhYFy08sbL0x3rc9odGlIAxTrIzrLmF6l6o8XyLrXJcBKPFY6Fhmcqf1FcShhZX/aK2PikZpWkYZ0srz9VQC0lnN6IfTpmeKcBBiMogKRnzkR1SRFVFv/J2akHzP2ze2biesq16Snz+FSN+SRjo57sTcBkK8v/TqIU+xHgmBE/3dMv3BLfNYj4cWxzpjq+SrkaEygD/7ERf9HTac34kzfedi+AzMMvmEzA==
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=KKME6+lMxz+aev+ylVJBLbtH4If8i1d5YNFkepyEfkU=; b=hy6YNKCkLibDU8Q6/svmA6gBONNslUvTXshZGuNd2WU9dpYmq63TPr08UC2GooewWpHZHqehDGN8fEpWMKHR/Y0VZZA+sob9YBjXB7f64EV78/nNxSRNwxpxTOwylKC72bcexqxsNnesP3MBxV4ysZj8UHCGp8sH7ARz5NoaReA=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3855.namprd11.prod.outlook.com (20.178.253.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Tue, 21 Jan 2020 13:35:29 +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.2644.027; Tue, 21 Jan 2020 13:35:29 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Zhenghaomian <zhenghaomian@huawei.com>, Aihua Guo <aihuaguo@futurewei.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+AADKm82AAKOM8kADK5fyQ
Date: Tue, 21 Jan 2020 13:35:29 +0000
Message-ID: <MN2PR11MB4366F98136C571A2E130D12FB50D0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43B93643E@dggeml511-mbx.china.huawei.com> <MN2PR11MB4366CA06F3A7B31BF54A5533B5360@MN2PR11MB4366.namprd11.prod.outlook.com> <CH2PR13MB33840C1AD54D62311BE8CD70C2360@CH2PR13MB3384.namprd13.prod.outlook.com> <E0C26CAA2504C84093A49B2CAC3261A43B95BF28@dggeml511-mbx.china.huawei.com>
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43B95BF28@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.50]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b95009fc-3a4e-4054-5d01-08d79e76c7ff
x-ms-traffictypediagnostic: MN2PR11MB3855:
x-microsoft-antispam-prvs: <MN2PR11MB385593F5C6CF35C97D7F1F4FB50D0@MN2PR11MB3855.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0289B6431E
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(4636009)(376002)(366004)(136003)(39860400002)(396003)(346002)(189003)(199004)(66446008)(76116006)(30864003)(66476007)(64756008)(66556008)(66946007)(71200400001)(110136005)(45080400002)(54906003)(55016002)(5660300002)(316002)(478600001)(966005)(9686003)(52536014)(8936002)(81156014)(2906002)(81166006)(8676002)(7696005)(33656002)(6506007)(4326008)(26005)(86362001)(186003)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3855; 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: /fiE2rY0pTU8n7TCCZPD+Bt50N58UjDKhPDO4LKFQLaLHxxeJynhMl3e9MxqOVNzK1cTDi+6XOh4NExpmk1smYMJ1KXQsYlkyOILb3r6X7vTOVUEUPnSFLEcJxcNF1S3j4ROs0a+5zSPkCpwL3ed02cn1jVI+cU4vmRctPfbsSPrR4NVcygjJrdB6Hn0IyV4p/MXE6f+w68bKIhX17N+Qr72F0Fi2zYGt1wIDSFK5X7d0AsGSRwurUiSLQxtxC7B3EuYvh381xSDDFiAjHDLRV6sNmPW1q3AF/zayLAkFXyDBRmrhaa0ePCiDmm0BqyUnGwOGx11UuIpjX1o+XlCjLgA7+w3FtBLDbEhpgfxJgiLo8MSqGV700vUZ3E9/FwHssxDf0sDx0ncRHzJhvcchgIImQTCG0Help6BlVK1udLHmjCNxOBMRgllyC2Hqkyis1wqrqbvqP67BkVYm0HGYtIQuEdeksz7C/BHMQWa3nundpWwEx8s2BUp9KECV/LVqJjnuG37QMcoS4x5Ft0pLPkteTeerlmL/UQuSuh+SkLEqTsfwZgeriYAYkj5w/kmCCSJPwI5g+jOZSMa52t2u1LdSdYTHjs1ncgxidUcyUJ+UAINj5A9V09F3a0JlDj8
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: b95009fc-3a4e-4054-5d01-08d79e76c7ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 13:35:29.2057 (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: 7rcJG+RWtPtws5k5Jy61CtrSc+C3WlH/6s8RWTs9QS66okoVaFXHsVb8v6VaFnv8YfDYQaDYgKM/Wp4KSCR/qw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3855
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/ta_brMnqBkEYULrfYATmeUGp0v0>
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: Tue, 21 Jan 2020 13:35:40 -0000

Hi Haomian, Aihua,

For "layer0-bandwidth-type" I think that identities are okay.  It seems quite plausible that there could be augmentations of other types here.  I do wonder whether this is really "layer0-bandwidth-type" or should it be something like "layer0-signal-type"?  E.g. I was just looking at the Wikipedia entry for "Optical Transport Network" and it refers to these as signals rather than bandwidths: https://en.wikipedia.org/wiki/Optical_Transport_Network.

For slot-width and channel-spacing, I think that enumerations would be better than identities.  I.e. if smaller channels are required then I think that it would be better to update this base types YANG module, rather than potentially define them in other YANG modules.

If you concern is about vendors needing smaller channels then there are few options to mitigate:
(i) define the smaller slots in the enumeration now (if you know they are coming).
(ii) vendors can "deviate replace" on the type of the leafs, e.g. to an enumeration with extra values, or a union of an enumeration and a numerical value.

Thanks,
Rob


> -----Original Message-----
> From: Zhenghaomian <zhenghaomian@huawei.com>
> Sent: 17 January 2020 12:33
> To: Aihua Guo <aihuaguo@futurewei.com>om>; 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: 答复: Yangdoctors last call review of draft-ietf-ccamp-layer0-
> types-03
> 
> Hi, Robert, Aihua,
> 
> Thank you for the feedback, please see inline with [Authors2], we are
> getting closer:)
> 
> Best wishes,
> Haomian
> 
> 
> -----邮件原件-----
> 发件人: Aihua Guo [mailto:aihuaguo@futurewei.com]
> 发送时间: 2020年1月17日 4:07
> 收件人: Rob Wilton (rwilton) <rwilton@cisco.com>om>; Zhenghaomian
> <zhenghaomian@huawei.com>om>; yang-doctors@ietf.org
> 抄送: last-call@ietf.org; draft-ietf-ccamp-layer0-types.all@ietf.org;
> ccamp@ietf.org
> 主题: RE: Yangdoctors last call review of draft-ietf-ccamp-layer0-types-03
> 
> Hi Rob, Haomian,
> 
> Re: using (floating point) values in a leaf vs. using identityref for
> optical bandwidth, spacing, slot-width etc, I'd lean towards using the
> identityref. Two main reasons from my point of view:
> 
> a) in optical layer, the value of bandwidth, slot width, channel spacing
> etc. are fixed and discrete, and is always determined by the technologies
> used underneath, e.g. FEC or modulation format. Those values are
> frequently compared/checked by the program. If using floating points the
> value comparison is not definitive, which may make it difficult for the
> program logic to handle. No such issue if using identityref. I'd prefer to
> avoid encoding those fixed values as floating points.
> 
> b) Optical technologies are evolving and new definitions such as new
> channel spacing or slot width would mandate changes to be made in the
> original model if using the numerical value leaf nodes. It may also cause
> backward compatibility issues. With identityref one creates new
> definitions in a new and augmented model, rather than making changes over
> the original model. YANG validation on the client side can filter out the
> new values automatically if it detects that the new values are not
> supported by the server (because the augmented model is not implemented).
> 
> Thanks,
> Aihua
> 
> -----Original Message-----
> From: Rob Wilton (rwilton) <rwilton@cisco.com>
> Sent: Thursday, January 16, 2020 5:08 AM
> To: Zhenghaomian <zhenghaomian@huawei.com>om>; yang-doctors@ietf.org
> Cc: last-call@ietf.org; draft-ietf-ccamp-layer0-types.all@ietf.org;
> ccamp@ietf.org
> Subject: RE: Yangdoctors last call review of draft-ietf-ccamp-layer0-
> types-03
> 
> 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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fietf-&amp;data=02%7C01%7Caihuaguo%40futurewei.com%7C93555aa03
> > 041406a21ec08d79a6bf5dc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C6
> > 37147660797808234&amp;sdata=JPWe96JXR556EQk%2FSsaCgVf3QuK%2FGl0ha1eQqS
> > NEfUU%3D&amp;reserved=0
> > 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.
> [Authors2] Agree on only formatting that technical. Let's keep as it is,
> and check again if necessary.
> 
> >
> > 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.
> [Authors2] Ok, the frequency-ghz will be brought back in upcoming -04.
> 
> 
> >
> > 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"?
> [Authors2] Refer to the first point raised in Aihua's feedback. On the
> perspective of optical network, the bandwidth for layer 0 is discrete
> rather than continuous. So when we specify the bandwidth, it's more a
> 'type configuration' than a 'value configuration', which I believe is a
> main difference between optical and IP. The current understanding from the
> authors is that the optical bandwidth is just like 'names of things' as
> you said, so we prefer to keep as is. BTW, for configuration, we think the
> proposal can reach equivalent functionality set as the current model in
> the draft.
> 
> 
> > 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.
> [Authors2] Similar as previous comments. Let me use another example here.
> In a potential GUI for the system who configure the network, it is
> possible to a) make a few options (100, 50, 25, 12.5, ...) in a menu
> format; b) leave it purely open to fill with any numbers. Given the finite
> values for optical configurations, the option a) would be easier with less
> chance to make mistakes.
> >
> > 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.
> [Authors2] Agree, this is our pain point now. We think all these
> parameters in this comment are a kind of 'type configuration' rather than
> 'number configuration'.
> >
> > 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.
> [Authors2] Okay.
> 
> 
> > [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-"
> [Authors2] Okay.
> 
> 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.