Re: [yang-doctors] [CCAMP] Use of identityref and enumerations
Xufeng Liu <xufeng.liu.ietf@gmail.com> Wed, 29 January 2020 02:37 UTC
Return-Path: <xufeng.liu.ietf@gmail.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 AC7D7120130; Tue, 28 Jan 2020 18:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ac-A64u69vZ2; Tue, 28 Jan 2020 18:37:41 -0800 (PST)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314FB120125; Tue, 28 Jan 2020 18:37:41 -0800 (PST)
Received: by mail-il1-x133.google.com with SMTP id f5so12629037ilq.5; Tue, 28 Jan 2020 18:37:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KNIxzViptuU8HC3rnFNcCgPexBZDmWs6w9JPjczf3uE=; b=EJLrTy3e6uZkOLmhlPY6LX1mgD2gG11FvqCbr5Ks9DUq/xFwrV7qVjlBObrbrjHOXT dpu/zR1LO4LRN0PhdqOE1GViLewM7atcxRh3KbjO5NOKetL+wDxE4/q5Mbp9hR1RSMKR AtouHqsuWgsTD6MZgbMLZq5FL+iBFYaMfe0GqlC9gMzMzadDGcffcovR0U3iwVnJkTb4 fYmxMz/hrJnYUU8vfERVp6K2PvoerEs7OKwLfROwRJQBd3GIuW+xq0+ZKc1CDwR8QBVV wqyBqL6b6ZmoClGSHkxWx/MYCoF4VGrIxfY9orOa5ketA6GOkMmtuVvEDCI+gfMqyNb9 XZkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KNIxzViptuU8HC3rnFNcCgPexBZDmWs6w9JPjczf3uE=; b=NOviiHRh24pKtDXl4vZHWRiDkhwhn3Doi/cRfBcq+jX8I17+l8A9S9CW5WIorvIeab m/M3nPLknEManrPPQQSRJGVToazint/YF0XogdwuJsfZVVz8+h4vsr10eIYfrG21XrKb q9bPkGjQH1GnOQ5Nu45tEuWuTcR/dJJLmHD00uVrzrCwQ5EUX5YkbXmH7w01S4dQ5p4n qBRX/2qOxD7HdVUCYy8eMqV+wkAwmdyjobe5esXvD8Ozf94c0veleqOt8A2Zv4oa+Y8a 14FZSJ+ZpSKw9eB7zsNBZa3QrasevluIMOLxtBx6fjyN4NDFPOeXb2p7AN5c67sK0wHt Sycg==
X-Gm-Message-State: APjAAAU18MC5+2C8aU9hiCsciJkfv2Qi6dNPlv10OSQtkAXPuexam1f9 EnqKJD2lVZqon1QNjpzPxQgJccjWb3bS7te3f+w=
X-Google-Smtp-Source: APXvYqzcfI0Tew7DNb0EE108Ksll7OOqbcLAm1EbV9zOBOC91K012jcJpdZkxoeTwEvzy45lQKSTIJaj47t/G6wsRUw=
X-Received: by 2002:a92:1a12:: with SMTP id a18mr16685615ila.10.1580265460302; Tue, 28 Jan 2020 18:37:40 -0800 (PST)
MIME-Version: 1.0
References: <bbeb60bee9094f22bce77e440ee8f631@huawei.com> <MN2PR11MB4366EDFBA9D4C396AF63AAA3B50A0@MN2PR11MB4366.namprd11.prod.outlook.com> <CAEz6PPT-A=W3ai73mjBSPXaWg5wGKct30fLUJ=hGCzVD+W4v9g@mail.gmail.com> <20200128.231444.1935528540203880271.mbj@tail-f.com>
In-Reply-To: <20200128.231444.1935528540203880271.mbj@tail-f.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Tue, 28 Jan 2020 21:37:29 -0500
Message-ID: <CAEz6PPQHrCteTiG9RnGULHtS72E84zNi=so+yvTX7uYqQOiX9g@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, Aihua Guo <aihuaguo@futurewei.com>, draft-ietf-ccamp-layer0-types.all@ietf.org, last-call@ietf.org, yang-doctors@ietf.org, CCAMP <ccamp@ietf.org>, "Zhenghaomian (zhenghaomian@huawei.com)" <zhenghaomian@huawei.com>, EXT Italo Busi <Italo.Busi@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000069887a059d3e3913"
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/wKWrj1M8vqbcZlfNFxM-y13ENbQ>
Subject: Re: [yang-doctors] [CCAMP] Use of identityref and enumerations
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: Wed, 29 Jan 2020 02:37:46 -0000
Hi Martin, Thanks for pointing out the error. I should have instead meant the inconvenience described in Sec 6.4 of RFC7950. Regards, - Xufeng On Tue, Jan 28, 2020 at 5:14 PM Martin Bjorklund <mbj@tail-f.com> wrote: > Hi > > A quick comment on one issue below. > > Xufeng Liu <xufeng.liu.ietf@gmail.com> wrote: > > On Tue, Jan 28, 2020 at 5:22 AM Rob Wilton (rwilton) <rwilton= > > 40cisco.com@dmarc.ietf.org> wrote: > > [...] > > > > If you want increased flexibility, perhaps consider defining it as a > union > > > of enum and decimal value. > > > > > > For the purpose of identity instead of quantity, I would avoid the > decimal > > type, for which RFC7950 only specifies the external string > representation. > > Internally the system may use float or double, which might introduce > > inconveniences or issues of encoding differently or losing precisions. > > Such an implementation would not be compliant with RFC 7950. The > whole point of the decimal64 type is that it is fixed point and not a > floating point number. > > I do not think it is correct to recommend people to avoid decimal64! > > > /martin > > > > > > Thanks, > > - Xufeng > > > > This could be done either in the standard model or a vendor specific > > > deviation-replace of the type. This would allow is to be configured > either > > > using a standard defined enum name, or as a raw numerical value, where > the > > > device would police what numerical values are allowed. > > > > > > My interpretation is that flexi-ch-spc-type, > flexi-slot-width-granularity, > > > and cwdm-ch-spc-type are all like dwdm-ch-spc-type. > > > > > > Using identities for fec-type is fine. > > > > > > Do any of the other YANG Doctors have a view on this? > > > > > > Thanks, > > > Rob > > > > > > > > > > -----Original Message----- > > > > From: Italo Busi <Italo.Busi@huawei.com> > > > > Sent: 28 January 2020 01:28 > > > > To: Rob Wilton (rwilton) <rwilton@cisco.com>; Zhenghaomian > > > > <zhenghaomian@huawei.com>; Aihua Guo <aihuaguo@futurewei.com>; yang- > > > > doctors@ietf.org > > > > Cc: last-call@ietf.org; draft-ietf-ccamp-layer0-types.all@ietf.org; > > > > ccamp@ietf.org > > > > Subject: Use of identityref and enumerations (was RE: [CCAMP] > Yangdoctors > > > > last call review of draft-ietf-ccamp-layer0-types-03) > > > > > > > > Looking at some YANG doctor review comments, I have the feeling that > > > there > > > > is some debate about whether we should use identityref or enumeration > > > > types, which requires some broader discussion to understand which > > > > guidelines we can follow since it is impacting multiple YANG models > we > > > are > > > > working on > > > > > > > > The key question is about future extensibility. > > > > > > > > I have understood that it is possible to extend an enumeration after > the > > > > data plane standards are updated by revising the YANG model. > Therefore > > > > possible data plane standard extensions are not a criteria for > preferring > > > > identities to enumeration. > > > > > > > > However, there are some cases where vendor-private extensions are > > > > possible. > > > > > > > > For technical and political reasons, I would prefer not to add > vendor- > > > > private values to a standard enumeration especially when dealing with > > > data > > > > plane standards not owned by IETF. > > > > > > > > I have some concerns with using "deviate replace" for an enumeration > > > since > > > > these are more extensions than deviations. Having vendor-private > > > > identities extending the standard ones seems a more natural choice to > > > > describe an extension and to allow the client understanding that the > > > > server supports such an extension. > > > > > > > > Moreover, even if two vendors supports similar extensions, there is > no > > > > guaranteed of interoperability between them. The two vendors can > define > > > > their own identities within their own namespace so the clients will > not > > > be > > > > confused. > > > > > > > > Therefore, my suggestion is that we should use identities when we > think > > > it > > > > is possible to have vendor-private extensions > > > > > > > > Just my 2 cents > > > > > > > > Italo > > > > > > > > > -----Original Message----- > > > > > From: Rob Wilton (rwilton) [mailto:rwilton@cisco.com] > > > > > Sent: martedì 21 gennaio 2020 14:35 > > > > > To: Zhenghaomian <zhenghaomian@huawei.com>; Aihua Guo > > > > > <aihuaguo@futurewei.com>; yang-doctors@ietf.org > > > > > Cc: last-call@ietf.org; draft-ietf-ccamp-layer0-types.all@ietf.org > ; > > > > > ccamp@ietf.org > > > > > Subject: Re: [CCAMP] Yangdoctors last call review of > > > > > draft-ietf-ccamp-layer0- > > > > > types-03 > > > > > > > > > > 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>; Rob Wilton (rwilton) > > > > > > <rwilton@cisco.com>; 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>; Zhenghaomian > > > > > > <zhenghaomian@huawei.com>; 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>; > 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>; > > > > > > > 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%2F > > > > > > > gi > > > > > > > th > > > > > > > ub.com%2Fietf- > > > > > &data=02%7C01%7Caihuaguo%40futurewei.com%7C93555aa > > > > > > > 03 > > > > > > > > > > > > 041406a21ec08d79a6bf5dc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7 > > > > > C1%7 > > > > > > > C6 > > > > > > > > > > > > 37147660797808234&sdata=JPWe96JXR556EQk%2FSsaCgVf3QuK%2FGl > > > > > 0ha1eQ > > > > > > > qS > > > > > > > NEfUU%3D&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. > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > >
- [yang-doctors] Use of identityref and enumeration… Italo Busi
- Re: [yang-doctors] [CCAMP] Use of identityref and… Xufeng Liu
- Re: [yang-doctors] Use of identityref and enumera… Ladislav Lhotka
- Re: [yang-doctors] [CCAMP] Use of identityref and… Rob Wilton (rwilton)
- Re: [yang-doctors] [CCAMP] Use of identityref and… Andy Bierman
- Re: [yang-doctors] [Last-Call] [CCAMP] Use of ide… Rob Wilton (rwilton)