Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard

tom petch <> Thu, 06 June 2019 16:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9060D120072; Thu, 6 Jun 2019 09:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.247
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OU0bwBumP603; Thu, 6 Jun 2019 09:15:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4993E120025; Thu, 6 Jun 2019 09:15:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3zUocnuexR5PODTDzVSFRKDuPxe9ArssK/j+0Hvf/DU=; b=neMusOrdYkTXWc12pt6NwWkXcpm29yYPuLWijGynJfqzfVgMhVUKtx07vfZxE84Vjfgzfw8johkhvgqjlFgGUfyvSjSJIk2Cvay8gPKNYFOG561obGKIsTqaPfEgEXH5Xm6YOpWMB6gaTYTA/NgJO5WQ2hox33hk+h7kXgYtOqs=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Thu, 6 Jun 2019 16:15:22 +0000
Received: from ([fe80::38cd:6ef6:7d75:23c2]) by ([fe80::38cd:6ef6:7d75:23c2%7]) with mapi id 15.20.1965.011; Thu, 6 Jun 2019 16:15:22 +0000
From: tom petch <>
To: Tarek Saad <>, ietf <>, Igor Bryskin <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
Thread-Index: AQHVHH6NeuPLR17G8EykTnIx+Fy8ZA==
Date: Thu, 6 Jun 2019 16:15:22 +0000
Message-ID: <013101d51c82$7353dde0$>
References: <> <026801d50b0f$0c3f7d00$> <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-clientproxiedby: LNXP265CA0054.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::18) To (2603:10a6:208:26::25)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: faa37a3d-3949-4966-9cb0-08d6ea9a2d30
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM0PR0702MB3522;
x-ms-traffictypediagnostic: AM0PR0702MB3522:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00603B7EEF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(366004)(376002)(396003)(13464003)(53824002)(199004)(189003)(186003)(8936002)(81156014)(81166006)(50226002)(14444005)(66946007)(8676002)(256004)(53936002)(6486002)(2906002)(26005)(1556002)(3846002)(6116002)(66476007)(66556008)(64756008)(66446008)(73956011)(84392002)(14496001)(446003)(486006)(71200400001)(71190400001)(476003)(7736002)(81816011)(305945005)(4326008)(44716002)(62236002)(6306002)(316002)(5024004)(66066001)(229853002)(966005)(25786009)(6436002)(478600001)(6246003)(14454004)(6512007)(9686003)(44736005)(76176011)(68736007)(54906003)(86362001)(110136005)(4720700003)(102836004)(81686011)(6506007)(5660300002)(99286004)(386003)(52116002)(61296003)(111480200001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3522;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: e/LF01H1+o4EwTrAZuuAicD7AqsEX5UMygVhVztZzJpVgFYFcGWdsY7fgTu8oxgFRTBcllq327W15249Bh2iiFpb/5RQSlxk2ltQfvJDl/RrA3c6xnTZot+cxv1yPf3FtE+CTCAxZ5oOn9kaL6QNmLSjCeiJSpvzohDyjceCClGOem9m4Hplar+2yBRppubwj2RgUxlh+9mMmGyB+HmfvDojbQmqEkKcGAfbbp13bxc+422PQCVGapql2oUaGwVHDCO1EjkWDwH4M5MiFmbWd1RjaBvZq2YyI95kJNkjrWxDixDdYi3upMxOOJguQy7dJtBOV8m+RsNavwAXRBD+iAmu1xId+Wx7+4jqURXG7s5f/0smLtCjsm54dcYABYXZ+aKmdlS52urWfvAiL9pisgUSTCG9TAjiMcS+Bq7h5j4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: faa37a3d-3949-4966-9cb0-08d6ea9a2d30
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2019 16:15:22.7335 (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-Transport-CrossTenantHeadersStamped: AM0PR0702MB3522
Archived-At: <>
Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jun 2019 16:15:29 -0000


You asked about my reference to definitions in triplicate which my later
response did not expand on.

The three I was counting were this I-D, exisiting IANA registries (some
which are identical to this I-D, some not) and the LSR I-D
which contains definitions of switching capability which I see
overlapping a part of this I-D.  I thought I saw an e-mail from
around Christmas, saying he would discuss this with other chairs but
cannot now find it so perhaps the wish was father to the thought.

The LSR I-D is now in AD review on the LSR list and so may get more

Tom Petch

----- Original Message -----
From: "Tarek Saad" <>
To: "tom petch" <>om>; <>rg>; "Igor
Bryskin" <>
Cc: <>rg>; <>rg>;
<>rg>; <>
Sent: Wednesday, May 15, 2019 10:13 PM
Subject: Re: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt>
(Traffic Engineering Common YANG Types) to Proposed Standard

> Hi Tom,
> Thanks for sharing your feedback.
> I'm attaching Igor's response on this topic -- which I share his same
> Please see more comments inline from me [TS]..
> On 5/15/19, 7:16 AM, "Teas on behalf of tom petch"
< on behalf of> wrote:
>     The approach taken by this I-D worries me.
>     It provides YANG identities for a wide range of values used in TE,
>     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
>     modules, these definitions were put under IANA control and they
>     there to this day.  They were updated by e.g. RFC8330 (February
>     and RFC8363 (May 2018) so these IANA registries are not some dusty
>     relic but a current, living specification.
>     These YANG definitions have much in common with the IANA SMI
>     but they are not the same.  A comparison of e.g. switching
>     suggests that this YANG module is out-of-date compared with the
>     registry (as with RFC8330, RFC8363) and omits several values for
>     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
>     provide a parallel YANG module under common IANA control as has
>     done for e.g. interfaces with both MIB module and YANG module
>     updated in parallel as appropriate.
>     Here something seems to have gone wrong.  We have a parallel set
>     definitions not acknowledging the existing ones and being
>     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
>     I raised this issue before Christmas 2018 and was told that the
>     of TEAS and LSR would get together and get back to me.  Nothing
>     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
>     allowing more flexible evolution compared to the 60-page monolith
>     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?
> Regards,
> Tarek
>     ..Tom Petch
>     ----- Original Message -----
>     From: "The IESG" <>
>     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: -
>     > 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
>     final
>     > comments on this action. Please send substantive comments to the
>     > mailing lists by 2019-05-16. Exceptionally,
comments may
>     be
>     > sent to 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
>     >    groupings are intended to be imported by modules that model
>     >    Engineering (TE) configuration and state capabilities.
>     >
>     >
>     >
>     >
>     > The file can be obtained via
>     >
>     >
>     > IESG discussion can be tracked via
>     >
>     >
>     >
>     > No IPR declarations have been submitted directly on this I-D.
>     >
>     >
>     >
>     >
>     _______________________________________________
>     Teas mailing list


> _______________________________________________
> Teas mailing list