Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ccamp-layer1-types-04

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 21 January 2020 13:41 UTC

Return-Path: <rwilton@cisco.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 DDF041200F7; Tue, 21 Jan 2020 05:41:21 -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=hlOiDL/W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CjBVcCxn
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 PHq2KpZGXJLC; Tue, 21 Jan 2020 05:41:17 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA9B1208B2; Tue, 21 Jan 2020 05:41:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22140; q=dns/txt; s=iport; t=1579614076; x=1580823676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xXg30bsQuuwZDoTxSc3HTarzRSpy7IyIJRmDFi8P0j8=; b=hlOiDL/WmmugmCytncGSvv7kheYPKZrBxg3sa7TjB0mvEufSwhCLoJTF p1km0qa/s12sRskp2V//oCgSImdwA71IBDKu8Nrm7xsbCePxE47vkN/Lm bzr0yxVcp6IxsRuwCRYMpeIlRaVzHBayjRhN8UrHdFKzIhO+kyFcsy0C9 M=;
IronPort-PHdr: 9a23:d2nSKB+9ginysP9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUERoMiMEYhQslVdSaCEnnK/jCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CnBQAA/yZe/4YNJK1cCRwBAQEBAQcBAREBBAQBAYF7gVRQBWxYIAQLKgqECINGA4sBgl+BAZcNgUKBEANUBgMBAQEMAQEjCgIBAYRAAheBeyQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAxIRBA0MAQEpDgELBAIBBgIRBAEBAwIjAwICAjAUAQgIAQEEAQ0FCBqDBYJKAy4BAgyRUJBlAoE5iBAFTHV/M4J/AQEFhQYYggwDBjdXKowUGoFBP4EQAUeBTkk1PoJkAoE5EhoVD4JqMoIKIo08EkSCQ4YAmAt2CoI5hz2FQ4UMhECCR4gKBY47gWaOXoFJhxiSJQIEAgQFAg4BAQWBaSKBWHAVO4JsUBgNiAGDc4pTdIEpi1gBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.70,346,1574121600"; d="scan'208";a="709247946"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jan 2020 13:41:15 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00LDfFa6029277 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2020 13:41:15 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 07:41:14 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 07:41:13 -0600
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 21 Jan 2020 07:41:13 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IHqyVf++CI8WDJR6YpkTOdbnkGuYpZ0TPrUb8haJex+CNhC6oiwIVaU+1hLRAEQgJ98ZPirUtSVebZs4VbYcHU3ue5tVWA6F13KwA2HeqZK9g44HD8uf8H/Io2PfD6ZsQaF7JY+RRO3vURS9ESlJRl5ifg92ot3sxYJO192/f4qkycezwu7JjQb7YTpsjcP/vKiuW1Y984Lp+YcoKT5AJmazb7VjCqcNkZVDxhLFUva6wmdBGFy1i5EAh4HD2PDnUbC41cttE0eJgmGGqroW3iPBzfhH59po6QlaBBGjoVyChL/w/ENqs66pDqdaGEtSgO69pCr3A7+gJjKJ4x9m/g==
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=xXg30bsQuuwZDoTxSc3HTarzRSpy7IyIJRmDFi8P0j8=; b=FWmkAXnPODvNjyHUg4Xf1MYWyBYQSYLbNzRfrMszXbYl2Js9pVDklW6V7YpEnPUDvKXt23AtjK/rR8cZ4zxHnyRgwS6oCmdRNBCP1zNl/H3daUo7vQEkSea8VnGl3jZvrp1ZiLuiFiVNHHZHq7/bBEP5y1fSaGca1TaWd77fTdkkGTlaWJZjwVdHUGY7s7sCopb3U6YA4+TTfoDtlgrS6ZZGgM4z8bLgEmeA+kGtVKMem6l+10yEiZKppMyY9lBgr0lC5tGhaYbjAO2uo2Yb6j1M5dOgu13n8OBN8g0zorhv0NG0e4qTlkDaTtpPqgxFXoPBQ79fo7oi47f1x5KPtA==
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=xXg30bsQuuwZDoTxSc3HTarzRSpy7IyIJRmDFi8P0j8=; b=CjBVcCxnA082/2EM3LZpAhnV9J6ZqbE/Rj9sS96Ptvh79nzFwGJeEBaLk7uX4nft0Ovnz+REnja28BFbIqNKYikwPMxaU7fylgdg9qXJvHBXAabD7Gc/KyuNXCN7T4xLzHS9BBayI82L7a3Vv2yYTGXG26QtdEz9G1g+BOEl/Cg=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4000.namprd11.prod.outlook.com (20.179.150.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.25; Tue, 21 Jan 2020 13:41:12 +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:41:12 +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>, "ccamp@ietf.org" <ccamp@ietf.org>, "draft-ietf-ccamp-layer1-types.all@ietf.org" <draft-ietf-ccamp-layer1-types.all@ietf.org>
Thread-Topic: Yangdoctors last call review of draft-ietf-ccamp-layer1-types-04
Thread-Index: AdXNNFLvUcFE+Wj7RPWEeQF8aquoEADK0fTQ
Date: Tue, 21 Jan 2020 13:41:12 +0000
Message-ID: <MN2PR11MB4366610549A2F612F8883431B50D0@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <E0C26CAA2504C84093A49B2CAC3261A43B95BF55@dggeml511-mbx.china.huawei.com>
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43B95BF55@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: 4fb3739f-1aae-441c-0734-08d79e779456
x-ms-traffictypediagnostic: MN2PR11MB4000:
x-microsoft-antispam-prvs: <MN2PR11MB4000B2306BA9A183F33D5CDEB50D0@MN2PR11MB4000.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0289B6431E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(376002)(366004)(136003)(199004)(189003)(9686003)(86362001)(55016002)(52536014)(66446008)(33656002)(66476007)(64756008)(66946007)(66556008)(186003)(53546011)(6506007)(7696005)(316002)(76116006)(110136005)(26005)(54906003)(2906002)(478600001)(8936002)(81166006)(71200400001)(5660300002)(81156014)(8676002)(19627235002)(4326008)(966005)(30864003)(473944003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4000; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: HCV+Svchx8bDvLwkIIwGX2KmYUX57PHG6xWPIiky8355oadC8/Xx7Mk8VjbWD6u0j5Uf58qnKIfCI3ZF1UrtGJWnE8M2oNZfb0L8XMt2Imjn0P2y+XvEsKRlCnloZJmqYeEBD5k1DgsXclTDQMiaP54oAMWEEr6p6trDXmzkD8rCgmUW4ygY54/0kvR+esL+DV1yBhf0uZ+2eN0oUTsIXFdxQcyHt48fu5iwrTP8CLH2pVTcjwmttXwLYwzDf79ijm4qHdL0xXJ4nXPaJcDYgGaCqcs+7AGL6gqsNflCPoASYwgOo5DEdBHMGp6I20nztDvv+93sV4+OF4CPJBLR2tPamOt1tMzZmZJxSJ0qxpLVRV31a1mbGkFXb0vl5S0xmMltEok+qyVScfnZ0fAURO6SMei3PjKU2/N9OPYxVrorWTM2hmo4YJI3e4JrV7BX203LEB/bFIG2lIp2/x1n0cu/9lghxlVidB9XFf4e6s9053X6ZQR7VIWnPmYL9rVTjP0nJM0Mgw9LDMCdO17DXR8+5sx/62SGKhlKxtY4g3jJsg4/WzfrMzQyEVP6KLFp
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: 4fb3739f-1aae-441c-0734-08d79e779456
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 13:41:12.1378 (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: 6+XiJrbqh/NlUb3ZPT9U5PsKy405kMCRFfSMP79GPL0qckrodIrxRixzno6+pEG8OUNYKWtEvgBw++DPXugwsg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4000
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/E9FDhVUL5VxRoqHmJ4M-HxhziFs>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ccamp-layer1-types-04
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: Tue, 21 Jan 2020 13:41:22 -0000

Hi Haomian,

Please see inline [RW] ...


> -----Original Message-----
> From: Zhenghaomian <zhenghaomian@huawei.com>
> Sent: 17 January 2020 12:48
> To: Rob Wilton (rwilton) <rwilton@cisco.com>; yang-doctors@ietf.org
> Cc: last-call@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-layer1-
> types.all@ietf.org
> Subject: Re: Yangdoctors last call review of draft-ietf-ccamp-layer1-
> types-04
> 
> Hi, Robert,
> 
> Thank you for the feedback, please see inline with [Authors2] as well.
> 
> We will send updated pull request after we address the open issues on
> default values, probably in a few days.
> 
> Best wishes,
> Haomian
> 
> 
> -----邮件原件-----
> 发件人: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
> 发送时间: 2020年1月16日 19:26
> 收件人: Zhenghaomian <zhenghaomian@huawei.com>; yang-doctors@ietf.org
> 抄送: last-call@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-layer1-
> types.all@ietf.org
> 主题: RE: Yangdoctors last call review of draft-ietf-ccamp-layer1-types-04
> 
> Hi Haomian,
> 
> Please see inline ...
> 
> > -----Original Message-----
> > From: Zhenghaomian <zhenghaomian@huawei.com>
> > Sent: 25 December 2019 06:22
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>; yang-doctors@ietf.org
> > Cc: last-call@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-layer1-
> > types.all@ietf.org
> > Subject: 答复: Yangdoctors last call review of draft-ietf-ccamp-layer1-
> > types-04
> >
> > Hi, Robert,
> >
> > Thank you very much for your detailed review and comments. The authors
> > had a few iterations of discussions and give the update as follow.
> >
> > Model update can be found as the pull request:
> > https://github.com/haomianzheng/IETF-ACTN-YANG-Model/pull/52; 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
> > with '[Authors]';
> >
> > Please help review if the comments are addressed, any discussion/calls
> > are welcome and can be arranged by chairs, thank you.
> >
> > Wish you a Merry Christmas and Happy new year.
> >
> > Best wishes,
> > Haomian (on behalf of all authors & contributors)
> >
> > -----邮件原件-----
> > 发件人: Robert Wilton via Datatracker [mailto:noreply@ietf.org]
> > 发送时间: 2019年12月14日 0:48
> > 收件人: yang-doctors@ietf.org
> > 抄送: last-call@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-layer1-
> > types.all@ietf.org
> > 主题: Yangdoctors last call review of draft-ietf-ccamp-layer1-types-04
> >
> > Reviewer: Robert Wilton
> > Review result: Almost Ready
> >
> > Comments on the document:
> >
> > 1) Please check the English grammar for the earlier paragraphs.
> > [Authors] fixed some editorial problems, and will do again by every
> > update;
> >
> > 2) If you change the prefix (as in the YANG comments below) then there
> > are references in the document that will also need to be updated (e.g.
> > section 3, and the IANA section).
> > [Authors] done in -05.
> >
> > 3) Security section, "onsidered" => "considered"
> > [Authors] done in -05.
> >
> > Comments on the YANG module:
> >
> > 1) I would suggest changing the YANG prefix to "l1-types" to help keep
> > it short (particularly for the identities).
> > [Authors] done in -05. The only problem is to recognize it correctly
> > as 'l1' instead of '11' or 'll', which has been raised before for
> > 'l1csm' in ccamp.
> 
> [RW]
> I think that generally the shorter prefix is better and will make modules
> that reference the types in this module more readable.
> [Authors2] noted, will use 'l1-types' as the prefix.
> 
> >
> > 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 -05.
> >
> > 3) As per my comments in the layer-0-types module, I would suggest
> > using a
> > decimal64 for the tributary-slot-granularity, or perhaps even a uint32
> > if it is specified in Mega rather than Giga.  Also, should the units be
> Ghz?
> > [Authors] The unit should be Gbps in layer 1 for rate; in the other
> > document (layer0-type) the unit GHz is used for spectrum width.
> > [Authors] There are many similar comments (identity->enum) in these
> > documents. The authors decided to reject some of the proposals because
> > of
> > 1) enumeration is not possible to extend, but there can be new values
> > in the future; 2) Specifically for this comment, the configuration of
> > tsg is a type rather than a number, so decimal is not a good
> representation.
> [RW]
> Enums are not fixed for all time.  New revisions of a YANG module can add
> new enum values:
> 
> Section 11 from RFC 7950:
> 
>    o  An "enumeration" type may have new enums added, provided the old
>       enums's values do not change.  Note that inserting a new enum
>       before an existing enum or reordering existing enums will result
>       in new values for the existing enums, unless they have explicit
>       values assigned to them.
> 
> 
> In terms of extensibility, identities allow vendors or other parties to
> define extra values without requiring a new revision of a base model.
> However, identities have a slight performance overhead (e.g. section 4.24
> of BCP 216).
> 
> If values are tightly tied to standard definitions, then enums are likely
> to be a better choice, with the expectation that the base model is updated
> if/when new enum values need to be added.
> 
> [Authors2] Thanks for clarifying our concerns on enumeration, it's solved
> now for standard version, but not easy for vendor to define their own
> characteristics. For our second concern, on the 'type configuration' with
> 'value configuration', we still have multiple places to negotiate. This
> also applies to the comment #7, #8 in this draft, and a few other places
> for layer0-types.
[RW] 
I would still suggest then using an enumeration is a better choice for tributary-slot-granularity rather than an identity.  E.g. it doesn't really make sense for two different vendors to both define their own 10G slot granularity.  It is better for them to use deviations.


> 
> >
> > 4) For all the ODU-type definitions, I would recommend splitting the
> > description from the reference.  I also don't think that the "which is
> > categorized as standards track is necessary/useful.  Or if you don't
> > want to keep it, then I would retain it only for types that are not
> standard."
> >
> > E.g.
> > OLD:
> >
> >  identity ODU0 {
> >    base odu-type;
> >    description
> >      "ODU0 protocol (1.24G), RFC7139/ITU-T G.709, which is
> >       categorized as standards track .";  }
> >
> > NEW:
> >  identity ODU0 {
> >    base odu-type;
> >    description "ODU0 protocol (1.24G)"
> >    reference "RFC7139/ITU-T G.709";
> >  }
> > [Authors] done in -05.
> > [Authors] Discussion need: We need to check with YANG doctor, on
> > whether make RFC7963/G.sup43 as informational or normative. Prefer to
> > be informational, but how should we specify in the model and in the
> > reference section?
> >
> [RW]
> My hunch is that they should probably be normative.
> [Authors2] Okay, let's make it normative now.
> 
> >
> > 5) Some of the ODU-types don't have references.  I would be good to
> > add references to everything that you can (e.g. also the client-signal
> > identities) [Authors] done in -05, for ODU-types and client-signal
> > identities.
> >
> > 6) For the description of ETH-10Gb-WAN, it might be helpful to also
> > specify the actual rate (9.95Gb/s) in the description, since it may
> > not be obvious.
> > [Authors] done for ETH-10Gb-WAN/ETH-10Gb-LAN.
> >
> > 7) Looking at how they are used, it might be better for
> > otn-label-range- type to be represented as a enum.
> > [Authors] We propose not to change, as enum is not good for extension.
> [RW]
> Do you anticipate that vendors will need to add other otn-label-range-
> types?
> [Authors2] probably not for the otn-label-range-type, the concern for
> enumeration would be if there is anything vendor-specific in future, not
> very likely.
> >
> > 8) In grouping otn-label-range-info:
> >  - I suggest making range type an enum rather than identity.
> > [Authors] We propose not to change, as enum is not good for extension.
> >  - Perhaps add a when statement to the "tsg" leaf, so that it can only
> > be populated when the enum is a "trib-slot"?  Or otherwise the
> > description is unclear. - I wasn't sure how familiar "tsg" is, and
> > perhaps it would be better  in its expanded form. - Please add more
> description to Priority.
> > [Authors] Discussion need: tpn-range/ts-range can both be different
> > for different TSG values, refer to section 4.3 in this document to see
> > detailed usage guidance.
> [RW]
> Does it make sense for the user to configure the type to be "label-range-
> trib-port" and also define a tributary-slot-granularity?
> [Authors2] Yes, the tsg is always needed because in some cases different
> tsg can support different tpn-ranges, refer to section 4.3 in this draft.
> 
> >
> > 9) In grouping otn-label-start-end:
> >  - Probably expand the "tpn" and "ts" names?
> > [Authors] as they are well-known term in OTN literature. Need to
> > understand the principle. As the terms are OTN-specific, it is
> > proposed to change to 'otn-tpn' and 'otn-ts' respectively. We also
> > expand in the description.
> [RW]
> If the terms are expected to be well known to a client using this
> configuration model then the short acronyms are fine (I'm not that
> familiar with the details of OTN ...).
> [Authors2] Okay, we will use 'otn-tpn' and 'otn-ts'.
> 
> >  - Probably define typedefs for "tpn" and "ts" uint16's, since they
> > are used in  multiple grouping definitions.
> > [Authors] done in -05.
> >
> > 10) In grouping otn-label-hop:
> >  - Expand "tpn" name and use the typedef (as per previous comment).
> >  - Expand "tsg" name
> > [Authors] changed accordingly to comments 9.
> >  - Expand the ts-list name, and perhaps enhance the description to
> > state that
> >  values must be in non-overlapping ascending ordering.   Or you could
> > borrow
> >  some text for section 9.2.4 of RFC 7950.
> > [Authors] Following proposal:
> > OLD:
> >         description
> >           "A list of available tributary slots ranging
> >            between 1 and 4095.
> >            For example 1-20,25,50-1000";
> > NEW:
> >         description
> >           "A list of available tributary slots ranging
> >            between 1 and 4095. If multiple values or
> >            ranges are given, they all MUST be disjoint
> >            and MUST be in ascending order.
> >            For example 1-20,25,50-1000";
> >
> [RW]
> Looks good.
> [Authors2] Okay.
> 
> >
> > 11) In grouping "otn-label-step" the "default" statements don't really
> > have any effect.  I think that either you need to add a default
> > statement to the choice, or you should delete the default statements
> > under the tpn and ts leaves.
> > [Authors] Discussion needed: the motivation is to set a default value
> > of tpn/ts in each branch to 1 in the otn-label-step grouping, with the
> > choice structure. Deleting the default statement would lose our
> > restriction. We don't understand the comments on the option 'add a
> > default statement to the choice'. Can you give more guidance?
> > Moreover, if we put a default value under choice, we are not sure where
> this default value goes.
> [RW]
> A default value is the one used if a client hasn't provided a value.  With
> a choice statement, only one of the case statements can apply, and the a
> case statement only takes effect if a value under that case statement has
> been provided.  Hence, in your current model a client must either
> explicitly provide a "tributary-port" value or a "tributary-slot" to
> choose which case statement applies, in which case the default statement
> has no useful effect because explicit values have to be provided anyway.
> [Authors2] We will remove the default value here, and see the next
> 'authors2' comments for more discussion.
> 
> > [Authors] Discussion needed: we find the choice on 'tpn' or 'ts' is
> > not determined in this grouping, instead it is specified in
> > 'otn-label-range- info'. Help requested for modeling this
> representation.
> [RW]
> I need to understand more about how these groupings are used.
> 
> - Probably need to split otn-label-step into two groupings, one for
> tributary-port, the other for tributary-slot.
> 
> - The usage of these grouping should probably be restricted via a when
> statement back to the type in the otn-label-range-info (but you can't do
> this abstractly in the grouping, you need to know the absolute or relative
> path).  So, either you need a higher level combined grouping, or some of
> the logic needs to be where the grouping is used.
> [Authors2] Thanks for the advice, we will decide after we look into the
> ietf-otn-topology. When the otn topology model augments the te-topology,
> this grouping is also intended to be used under another case choice, so we
> also need to figure out how to set the default value.
> See the new open issue on the github for tracking the problem:
> https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/54
[RW] 
Okay.

Thanks,
Rob


> 
> >
> > 12) identity coding-func.
> > - All of these identities should be before all of the groupings.
> > [Authors] done in -05, the indentation looks good so far.
> > - They also need to have their indentation fixed (e.g., "pyang -f yang
> > -- yang-line-length 69") - Are the references to MEF 63 the right
> > choice, or should these references be to IEEE Std 802.3?
> > [Authors] Discussion needed: Need to check the reference rule: the
> > MEF63 is the target we want to align, but IEEE 802.3 is the original
> > one to track. MEF63 is referencing to IEEE 802.3 with corresponding
> > clause, and it is propose not to repeat.
> [RW]
> Okay.
> 
> It might be worth having a small paragraph in the main body of the draft
> to explain this, and perhaps add 802.3 as an informative reference.
> [Authors2] okay, will add this in -05.
> >
> > 13) identity optical-interface-func
> > - Are the references to MEF 63 the right choice, or should these
> > references be to IEEE Std 802.3?
> > [Authors] Discussion needed: Need to check the reference rule: the
> > MEF63 is the target we want to align, but IEEE 802.3 is the original
> > one to track. MEF63 is referencing to IEEE 802.3 with corresponding
> > clause, and it is propose not to repeat.
> > - "base identity" => "Base identity"
> > [Authors] done in -05.
> > - Do you definitely want the "clause-XX" as part of each identity name?
> > Is it possible that these clauses could ever change or be renumbered?
> > [Authors] We adjusted as, "ETH-1000X-PCS-36" -> "ETH-1000X", "SX-PMD-
> > clause-38"-> "SX-PMD-1000" (need to specify the rate to avoid
> > duplication), refer to the updated model.
> [RW]
> Okay.
> 
> >
> >
> > 14) identity service-performance-metric:
> > - Rather than "list of service-specific ..." perhaps "Base identity
> > for service specific ..." - Perhaps change "One-way-..." to
> > "One-Way-...", it looks strange to have a single character not
> > capitialized. - Probably remove the hypens from the descriptions?
> > [Authors] done in -05, as most of the parameters in YANG is lower
> > case, so we changed everything to lower case.
> >
> > 15) identity network-performance-metric
> > - Should any identities be defined here?
> > - Rather than "list of network-specific ..." perhaps "Base identity
> > for network specific ..."
> > [Authors] This identity is removed as no identities defined here,
> > according to MEF63.
> [RW]
> Thanks,
> Rob