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

Tarek Saad <tsaad.net@gmail.com> Wed, 15 May 2019 21:13 UTC

Return-Path: <tsaad.net@gmail.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 A04671200FB; Wed, 15 May 2019 14:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FVoC8dHCf7gb; Wed, 15 May 2019 14:13:35 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA02120021; Wed, 15 May 2019 14:13:34 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id j53so1427305qta.9; Wed, 15 May 2019 14:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=NKgdQb2EC9GTE2hpnhDuaQzK5+A/f+F4gUnk5RvPcN4=; b=g1t/vX5A7yoLCaPjDG4J0PwW5sGrPV5h/idYbKXzFYy1Xykp/k6NS2VLiTTewgBd+o GN7oKoghLqZ/A+8z5lU0O8o9DBgKeevq2uFEyYBspJIKssnJWwY/7Jrb7dmP0FPuz/2J evGGEmK+BkHwjFWUKJrQ0ChrCObsARkY44P15WFrobyEPJGuVch/iQ9MTZCRP/HE7z0R NLJ/dxkLQdVuE4gHEgCAZQnoFfQj9TprghzbeIf7P5sfV3n3PYA0EpU1SJbgO/qGHeCM 2LSER2O3mYVokfp5PFTXiFubr62ZA3aWygWAPMLRtOVtiwZaUzDKsDvDNBc4pWqxBbfL S8zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=NKgdQb2EC9GTE2hpnhDuaQzK5+A/f+F4gUnk5RvPcN4=; b=BrH6wzQg9H2NcoZn0oWtNtdMMZTzIUg5rzpBFemo1jVg30HCieVwMMt44dDRq1aPrg vd/CDdX7GHayy3/2oStwjobl7haX+F0ph9vF3Uykvf3Gw4olNubNed5+YZDNDVr97A4r qp2YKK8D8eNciO3Kmayb1ULDptafat8m5waRxlCYhx+mw2ncXgzXcNk/XArHL/FQr6Rc 21gWoqltZrq1eJrKaO5SLs2/g90cJOuUNPVLrkyPn1hSp6nwTPCYUkifzBgJOteOwzYK CnhfAaQzqOgtsF9KhGjau1Sm16NczTSpRhTzYiLC7pPQ1UkLPTZmIXhTRuLxphdXjYfJ Wdqw==
X-Gm-Message-State: APjAAAURBPPpU1rMrZtD4vyur+7N6Se2QPYkB7Knk9txOX1QvwXbPzRv FEEopIXWZj/sQQU3JHfe0x0=
X-Google-Smtp-Source: APXvYqyuJp9GkYDdzxlvQXcLoyU3Xs52g8TVjA3U3jS6o05P01ITvjhuU/sD7PCkHrVSpIwpBo3f9g==
X-Received: by 2002:ac8:1ad2:: with SMTP id h18mr15908193qtk.273.1557954813844; Wed, 15 May 2019 14:13:33 -0700 (PDT)
Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id k127sm1477982qkb.96.2019.05.15.14.13.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 14:13:33 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: tom petch <daedulus@btconnect.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>, "db3546@att.com" <db3546@att.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Last Call: <draft-ietf-teas-yang-te-types-09.txt> (Traffic Engineering Common YANG Types) to Proposed Standard
Thread-Index: AQHVCw+eznFxGmRurE+zr4u+z8rDKqZsr/lT
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 15 May 2019 21:13:32 +0000
Message-ID: <BN8PR06MB62899F9177011B426D06B877FC090@BN8PR06MB6289.namprd06.prod.outlook.com>
References: <155683002335.24918.14137794782361366345.idtracker@ietfa.amsl.com> <026801d50b0f$0c3f7d00$4001a8c0@gateway.2wire.net>
In-Reply-To: <026801d50b0f$0c3f7d00$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/mixed; boundary="_002_BN8PR06MB62899F9177011B426D06B877FC090BN8PR06MB6289namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/IjqtsFM02aGLztakSFP-5CWMjps>
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 21:13:38 -0000

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