Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
tom petch <ietfa@btconnect.com> Wed, 29 May 2019 16:06 UTC
Return-Path: <ietfa@btconnect.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72F41201B3; Wed, 29 May 2019 09:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKq1Cxbqoo5l; Wed, 29 May 2019 09:06:11 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80130.outbound.protection.outlook.com [40.107.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E559012016E; Wed, 29 May 2019 09:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BOAjdGw81ZPFHMDDFOYLR3nFMf8jrpDomjhEVIyrbyI=; b=Qu5IfmRARbcXxLAvRCSbtHymt9qjCm1UC6G2CdwawwxXxSNZvBeSYDEvzQ0vaTWJT1clZa4j3iRgr8P8Mu4PBrycZgXrQ5Oqte8sZ/kfRxTyTWu51Sx5qKvOKWy3T0iQ3ekV51R3BUwdMBpEQ1FCV+Jl6rOHAQP2EcTx4vgNiJY=
Received: from AM0PR0702MB3732.eurprd07.prod.outlook.com (52.133.51.25) by AM0PR0702MB3588.eurprd07.prod.outlook.com (52.133.48.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.13; Wed, 29 May 2019 16:06:07 +0000
Received: from AM0PR0702MB3732.eurprd07.prod.outlook.com ([fe80::38cd:6ef6:7d75:23c2]) by AM0PR0702MB3732.eurprd07.prod.outlook.com ([fe80::38cd:6ef6:7d75:23c2%7]) with mapi id 15.20.1943.007; Wed, 29 May 2019 16:06:07 +0000
From: tom petch <ietfa@btconnect.com>
To: Tarek Saad <tsaad.net@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>, Igor Bryskin <Igor.Bryskin@huawei.com>
CC: "draft-ietf-teas-yang-te-types@ietf.org" <draft-ietf-teas-yang-te-types@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "db3546@att.com" <db3546@att.com>
Thread-Topic: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
Thread-Index: AQHVFjhseuPLR17G8EykTnIx+Fy8ZA==
Date: Wed, 29 May 2019 16:06:07 +0000
Message-ID: <00cc01d51637$db1fbbc0$4001a8c0@gateway.2wire.net>
References: <155683002335.24918.14137794782361366345.idtracker@ietfa.amsl.com> <026801d50b0f$0c3f7d00$4001a8c0@gateway.2wire.net> <BN8PR06MB62899F9177011B426D06B877FC090@BN8PR06MB6289.namprd06.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0181.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::25) To AM0PR0702MB3732.eurprd07.prod.outlook.com (2603:10a6:208:26::25)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfa@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 80849be4-f566-40d8-6031-08d6e44f8efc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR0702MB3588;
x-ms-traffictypediagnostic: AM0PR0702MB3588:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <AM0PR0702MB3588987BC92B25133A202C9FA21F0@AM0PR0702MB3588.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0052308DC6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(136003)(39860400002)(396003)(51444003)(53824002)(13464003)(189003)(199004)(6436002)(50226002)(4720700003)(6486002)(73956011)(3846002)(305945005)(7736002)(6246003)(5660300002)(14454004)(8936002)(486006)(53936002)(66446008)(64756008)(66946007)(386003)(66476007)(66556008)(229853002)(81166006)(81156014)(8676002)(44716002)(102836004)(81816011)(76176011)(81686011)(6506007)(62236002)(66066001)(52116002)(54906003)(110136005)(14496001)(25786009)(44736005)(6116002)(186003)(26005)(68736007)(71200400001)(476003)(446003)(71190400001)(966005)(2906002)(256004)(6512007)(6306002)(4326008)(9686003)(86362001)(5024004)(14444005)(84392002)(316002)(478600001)(1556002)(61296003)(99286004)(2501003)(111480200001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3588; H:AM0PR0702MB3732.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: RRcZ/8Qi2yccY5VgkXydoYdvC6Iynk4AGTU7bjR2uoLLYrLt8AmhiqJRDe8s8nmcKV/RoiuzTzF1dzOiM/uG35JBqsdOyyxzF5f0BMDXzVz10s+JBJrsa7tGTKGayviFiYtop5oepGZYr+qI4Q1iQcfthgFLluyhOyvsuiA/LeDnUiv0ik0zo4j9CFXNGMX+xVO3Oxtt/g8kFauks0mTriBP3f3LgyDzkfh7uZLtcFqoqqPGtEbQiVX9cJcGmCZRqckR1sB4zJn65bAp9/vDlzSM8BP08sgC7tylLF2fUIH+WKm24NAFK8p7flx3egseVFqONETYvbLZpR+EKI29kxzB0XI+c2V3XHVeTYLJ50tJH2vTs63DXudWhE8xufWjZ8TJnRhZbB3XNWUMJ7EPwLlSKp8JDri+Rm8OPkdD3J0=
Content-Type: text/plain; charset="utf-8"
Content-ID: <724EB00008200641892FF208CD4ADAD2@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 80849be4-f566-40d8-6031-08d6e44f8efc
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 16:06:07.6305 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ietfa@btconnect.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3588
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/EKk0Q-RJFekAou_yU2UxyRohCcI>
Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 16:06:15 -0000
<at the end> Tom Petch ----- Original Message ----- From: "Tarek Saad" <tsaad.net@gmail.com> Sent: Wednesday, May 15, 2019 10:13 PM > Hi Tom, > > Thanks for sharing your feedback. > I'm attaching Igor's response on this topic -- which I share his same opinion. > Please see more comments inline from me [TS].. > > On 5/15/19, 7:16 AM, "Teas on behalf of tom petch" wrote: > > The approach taken by this I-D worries me. > > It provides YANG identities for a wide range of values used in TE, such > as encoding types and switching capabilities; so far, so good. > [TS]: As mentioned in abstract, the module is not strictly identities. It is a collection of re-usable YANG groupings, types and identities. > > These definitions were needed, and were in a large part created by > RFC3471, in 2003. When the management of GMPLS was specified, in MIB > modules, these definitions were put under IANA control and they remain > there to this day. They were updated by e.g. RFC8330 (February 2018) > and RFC8363 (May 2018) so these IANA registries are not some dusty old > relic but a current, living specification. > > These YANG definitions have much in common with the IANA SMI registries > but they are not the same. A comparison of e.g. switching capabilities > suggests that this YANG module is out-of-date compared with the IANA SMI > registry (as with RFC8330, RFC8363) and omits several values for no > stated reason ( the deprecated 2,3,4, 40 PBB-TE, 151 WSON-LSC). > [TS]: it was not the intention to be exhaustive in covering all IANA defined entities. However, the objective was to model enough that would make TE feature (modelled in other modules) usable and to leverage the power of YANG augmentation for any extensions that may not be covered in a base model. Specifically, the authors favored the use of YANG identities over enums to allow for the extensibility of augmentation. > > The approach taken by other WG has been to take a IANA registry and > provide a parallel YANG module under common IANA control as has been > done for e.g. interfaces with both MIB module and YANG module being > updated in parallel as appropriate. > > Here something seems to have gone wrong. We have a parallel set of > definitions not acknowledging the existing ones and being out-of-date > compared with the existing ones. > > Furthermore, some of these definitions are duplicated in the work of the > LSR WG giving us (at least) three definitions. > [TS]: it would help to point to the duplication or thread that this was discussed in. However, we believe that this document covers TE data and hence LSR module(s) would need to eliminate duplication of any TE data (if any).. LSR module can always import TE types to use the TE definitions. > > I raised this issue before Christmas 2018 and was told that the chairs > of TEAS and LSR would get together and get back to me. Nothing appears > to have changed. > > In passing, IANA has separate SMI registries for e.g.LSP encoding, > Switching Types and so on, which seems a sound engineering approach, > allowing more flexible evolution compared to the 60-page monolith of > this single YANG module. > [TS]: In this effort, we've followed similar approach to RFC8294, RFC6021. Etc.. Do you see the same concerns there too? I think that the difference is the sheer size of this I-D and the likely future evolution of it. The IANA SMI registries each form a logical set each of which can proceed independently and I think that that is spot on; RFC8294 is much smaller and so less of a concern, and is also more a loose aggregation of related objects with no natural subdivisions. Here you have replicated the objects in. identity lsp-encoding-types { exactly AFAICT and so that is an obvious candidate to turn the SMI into SMI and YANG. With identity switching-capabilities { the SMI is more up-to-date than the YANG and I would see the SMI as the starting point With identity wdm-spectrum-type you have replicated the objects but seem to have got the reference wrong; you have identity flexible-grid { base wdm-spectrum-type; description "Flexible grid."; reference "RFC6205"; whereas SMI has 3, ITU-T Flex, [RFC7699] which I think correct (now if you had used the SMI as a basis, .....:-) Tom Petch > > Regards, > Tarek > > ..Tom Petch > > ----- Original Message ----- > From: "The IESG" <iesg-secretary@ietf.org> > Sent: Thursday, May 02, 2019 9:47 PM > > > The IESG has received a request from the Traffic Engineering > Architecture and > > Signaling WG (teas) to consider the following document: - 'Traffic > > Engineering Common YANG Types' > > <draft-ietf-teas-yang-te-types-09.txt> as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2019-05-16. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > > the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document defines a collection of common data types and > groupings > > in YANG data modeling language. These derived common types and > > groupings are intended to be imported by modules that model Traffic > > Engineering (TE) configuration and state capabilities. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-types/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-types/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. >
- [Teas] Last Call: <draft-ietf-teas-yang-te-types-… The IESG
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Tarek Saad
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Tarek Saad
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Belotti, Sergio (Nokia - IT/Vimercate)
- [Teas] 答复: Last Call: <draft-ietf-teas-yang-te-ty… Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Xufeng Liu
- [Teas] 答复: Last Call: <draft-ietf-teas-yang-te-ty… Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… tom petch
- Re: [Teas] Last Call: <draft-ietf-teas-yang-te-ty… Tarek Saad