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, 12 June 2019 15:46 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 82F5C1200A4; Wed, 12 Jun 2019 08:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.733
X-Spam-Level: *
X-Spam-Status: No, score=1.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, 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 nc4e9G0e2pkC; Wed, 12 Jun 2019 08:46:39 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DAE120058; Wed, 12 Jun 2019 08:46:38 -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=qcRnd7JbBZ62RHjg/prI93v++oLy3sKRotiRD//KRkY=; b=jXSf8EJlYhCtIhegyzBHiFe5rCF+sGQavuThePVp8nwrwI3U3/fE4XaUGiv5dTxajeKeYejw6QqBBnYp4joBerzXf1jLXGFZ0SAY1UhxOjgrOBPVJLIJqm47m3b+YMxJjCB8yRjhFPhTZONyg/rZnAfR+Dx3EcnO/ATVdTYh/pc=
Received: from DB7PR07MB5893.eurprd07.prod.outlook.com (20.177.194.220) by DB7PR07MB5980.eurprd07.prod.outlook.com (20.178.106.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.8; Wed, 12 Jun 2019 15:46:35 +0000
Received: from DB7PR07MB5893.eurprd07.prod.outlook.com ([fe80::88bf:ced4:d9c0:bca4]) by DB7PR07MB5893.eurprd07.prod.outlook.com ([fe80::88bf:ced4:d9c0:bca4%7]) with mapi id 15.20.2008.002; Wed, 12 Jun 2019 15:46:35 +0000
From: tom petch <ietfa@btconnect.com>
To: Tarek Saad <tsaad.net@gmail.com>, ietf <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: AQHVITYDbdIAH+mi2UGL51LY4hprow==
Date: Wed, 12 Jun 2019 15:46:35 +0000
Message-ID: <01c101d52135$6791f660$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0241.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::13) To DB7PR07MB5893.eurprd07.prod.outlook.com (2603:10a6:10:2b::28)
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: b51135aa-e7da-49ea-ecea-08d6ef4d262c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DB7PR07MB5980;
x-ms-traffictypediagnostic: DB7PR07MB5980:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <DB7PR07MB59800943D4A0AE1EB44315E7A2EC0@DB7PR07MB5980.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0066D63CE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(136003)(396003)(39860400002)(189003)(199004)(13464003)(53824002)(84392002)(54906003)(86362001)(81686011)(4720700003)(110136005)(316002)(6246003)(99286004)(966005)(14454004)(1556002)(25786009)(52116002)(186003)(14496001)(26005)(102836004)(81816011)(4326008)(6506007)(386003)(478600001)(9686003)(476003)(71190400001)(6436002)(81156014)(5660300002)(53936002)(8676002)(6512007)(66946007)(6306002)(66476007)(71200400001)(66446008)(64756008)(66556008)(229853002)(68736007)(61296003)(305945005)(66066001)(50226002)(7736002)(3846002)(8936002)(44736005)(6486002)(81166006)(2906002)(6116002)(44716002)(62236002)(5024004)(256004)(486006)(14444005)(73956011)(111480200001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5980; H:DB7PR07MB5893.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: Y24oB4m8GSZx9JO7dSpgYrOxsaApQJxcRbaVm6yB+3NMmVFE1SRmFT7b3sVZYuHq6cz9o9kQaHdvRArhkLaTPX4gtcRht4sAUPzUeb5ptPv0GwGpM8bOzuoOFYQtBtBSGFNkG2f0IFYnueWqqv3Zea4N9PorccLdnjY6DP5XkGLqj/1WhoZLIkyq8C8U0D/fFiw8vTwVTO206i0QjuSKGVp+Z/WaNHlo4ADgEC7+EBloaPU4AsAHmfEWgZkX60icdqeUdsbjciod99SKOl9drXIQ1cXurCXjezjIQnM0hQ93Dd3BhZIQzw4baYKXNWTkRo4pYcP6XyK/SwiVLDZ0EEBc96r3hI70vqTjbI7G/HUU6WtLRYMyg65M1MuUlP12Ez6Z+clTmXskdvLH772Gu/GWpzmBD3F+yGNe2eLF19E=
Content-Type: text/plain; charset="utf-8"
Content-ID: <39ACAD55410ADB4F9BA42F9D7B3CFD19@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b51135aa-e7da-49ea-ecea-08d6ef4d262c
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 15:46:35.5050 (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: DB7PR07MB5980
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/i_v3HowRfshUeWy5o6mmGDkNtJw>
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, 12 Jun 2019 15:46:43 -0000

And now it would appear  we have quadruplicate definitions with the
advent of
draft-ietf-ccamp-layer1-types
which has a comprehensive, and different, set of ODU (upper case) types.

Tom Petch

----- Original Message -----
From: "t.petch" <ietfa@btconnect.com>;
Sent: Thursday, June 06, 2019 4:43 PM


> Tarek
>
> 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
> of
> which are identical to this I-D, some not) and the LSR I-D
> draft-ietf-isis-yang-isis-cfg
> which contains definitions of switching capability which I see
> overlapping a part of this I-D.  I thought I saw an e-mail from
> Stephane,
> 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
> attention.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Tarek Saad" <tsaad.net@gmail.com>;
> To: "tom petch" <daedulus@btconnect.com>;; <ietf@ietf.org>;; "Igor
> Bryskin" <Igor.Bryskin@huawei.com>;
> Cc: <draft-ietf-teas-yang-te-types@ietf.org>;; <teas-chairs@ietf.org>;;
> <teas@ietf.org>;; <db3546@att.com>;
> 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
> opinion.
> > Please see more comments inline from me [TS]..
> >
> > On 5/15/19, 7:16 AM, "Teas on behalf of tom petch"
> <teas-bounces@ietf.org on behalf of daedulus@btconnect.com>; 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?
> >
> > 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 mailing list
> >     Teas@ietf.org
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >
>
>
> ----------------------------------------------------------------------
--
> --------
>
>
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
>