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

tom petch <daedulus@btconnect.com> Wed, 15 May 2019 11:16 UTC

Return-Path: <daedulus@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 0D45312004B; Wed, 15 May 2019 04:16:05 -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 EwS2ryH0VWAi; Wed, 15 May 2019 04:16:03 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10120.outbound.protection.outlook.com [40.107.1.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91678120033; Wed, 15 May 2019 04:16:02 -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=UiPTxDGNqvN7eD/WKS1PRciaFrJDyUORhi6l7mFxyaw=; b=MAEpV2z1Lc39B1sSSzdROO/1IOc8ED3GjKLFAOTgqncX3jhN1/pV67wnkpPpCvYA8d7/x5LO720QEa7lL+OhQak4tV42zKfCNLGYEEI0pz5MAhJl1kYUlCKC0AeEg9lhT/J1LB0RL8zs9YsdQeUjlyT8fHMMEjM8l/OFIcUxU2g=
Received: from HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) by HE1PR0701MB2377.eurprd07.prod.outlook.com (10.168.128.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.9; Wed, 15 May 2019 11:15:59 +0000
Received: from HE1PR0701MB3004.eurprd07.prod.outlook.com ([fe80::9150:105f:a3ea:edae]) by HE1PR0701MB3004.eurprd07.prod.outlook.com ([fe80::9150:105f:a3ea:edae%2]) with mapi id 15.20.1900.010; Wed, 15 May 2019 11:15:59 +0000
From: tom petch <daedulus@btconnect.com>
To: "ietf@ietf.org" <ietf@ietf.org>
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: Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
Thread-Index: AQHVCw+SOv5TGNMS/Em8YV7FYU9bGA==
Date: Wed, 15 May 2019 11:15:59 +0000
Message-ID: <026801d50b0f$0c3f7d00$4001a8c0@gateway.2wire.net>
References: <155683002335.24918.14137794782361366345.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P123CA0024.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::36) To HE1PR0701MB3004.eurprd07.prod.outlook.com (2603:10a6:3:4d::10)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@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: 0e17e677-64e4-46aa-64ea-08d6d926b50f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2377;
x-ms-traffictypediagnostic: HE1PR0701MB2377:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <HE1PR0701MB2377CD758DDE693820886A6BC6090@HE1PR0701MB2377.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0038DE95A2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(136003)(346002)(13464003)(189003)(199004)(53824002)(9686003)(6306002)(25786009)(6512007)(4720700003)(44736005)(1556002)(54906003)(66946007)(2501003)(6246003)(66476007)(66556008)(64756008)(66446008)(99286004)(7736002)(305945005)(6486002)(68736007)(5660300002)(6116002)(14496001)(14444005)(256004)(2351001)(316002)(86362001)(2906002)(3846002)(8936002)(14454004)(81156014)(4326008)(446003)(81686011)(6506007)(386003)(966005)(66066001)(44716002)(62236002)(50226002)(84392002)(73956011)(52116002)(26005)(53936002)(102836004)(478600001)(76176011)(81816011)(476003)(6916009)(86152003)(6436002)(5640700003)(71200400001)(71190400001)(8676002)(61296003)(1730700003)(186003)(81166006)(229853002)(486006)(111480200001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2377; H:HE1PR0701MB3004.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: oPqT6KgNo1n+wL/F0kayzm2adLwbgx9UFydjO4K5cexyYjWtq6JRtdAYa9cI/Pvjeetg02ALRfYDv7SqE+KAEk8ojKkRzMSWz5LV8OyC1dICP2usKKi1HPVjQ5hMQav7EYcOnapRoED+zQsThXO7Dirtym7NxccQbTHHSayesSJrPCRjekqfJz/W+IJnpvyi32GD+nix7IwB3Cy4saSl+3y4o1h8oEIM5mkdFPO9c9FyRslBQv+yv0zDMQll2BHmBGmJehW6Sc8LEfCk85x1ZypWGvUWPHU0lCdnLoxvM7pHBV0g3IO1sbRe8EZV7udnaeamcOTdWIhmExRZdZqJClbyPQtDhSCDBXxtqsAF/BUG5ohG8pRSyuPPkZA6Nf80F3DrOnL8foV6xUfLThhA5UBs3FfwVNXNj4Nh0yEHZBQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <F59805605121794C90D31311BA87F545@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e17e677-64e4-46aa-64ea-08d6d926b50f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2019 11:15:59.4297 (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: HE1PR0701MB2377
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2HtS3ut7WWcoIbLaoQJaQQwzoIc>
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, 15 May 2019 11:16:05 -0000

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.

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).

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.

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.

.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.
>
>
>
>