Re: [Teas] Genart last call review of draft-ietf-teas-yang-te-types-09

Igor Bryskin <> Wed, 15 May 2019 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BB0D1204FC; Wed, 15 May 2019 11:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EvypkBPfPabK; Wed, 15 May 2019 11:13:45 -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 1D9ED12013F; Wed, 15 May 2019 11:13:45 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 1ED0AEEF55A06C6E3AAE; Wed, 15 May 2019 19:13:43 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 15 May 2019 19:13:40 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 15 May 2019 19:13:40 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 15 May 2019 19:13:40 +0100
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Wed, 15 May 2019 11:13:27 -0700
From: Igor Bryskin <>
To: Linda Dunbar <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Genart last call review of draft-ietf-teas-yang-te-types-09
Thread-Index: AQHVCqYgP+JjvjvSDEKLDQvoId9xw6ZsbZLQ
Date: Wed, 15 May 2019 18:13:26 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Teas] Genart last call review of draft-ietf-teas-yang-te-types-09
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: Wed, 15 May 2019 18:13:47 -0000

Hi Linda,

Thank you for your comments.

Please, note that it was never a goal of this work to produce some sort of Oxford English Dictionary for Traffic Engineering with providing references illustrating basic and subtle usages of each ID of each defined TE related definition (as OED does).
No, our ambitions are far more modest. The work was triggered by realization that many exact same types required by te-topology model are also required by te-tunnel model. We could have (and initially started to) define the types twice (separately for each model), but later decided to put the common te types into a single module/document. This way the te-topo and te-tunnel model families and models directly depending on them (e.g. path computation and VN models) could use the common set of types. This is our primary objective. We also encourage using the te-types model in any other TE related model (if/when it proves useful) with understanding that some types/identities may not be found and hence need to be defined in addition to what has been defined in the te-types model.

Furthermore, in defining TE types and identities we tried to re-use as much as possible the definitions provided by IETF RFCs describing signaling and routing protocols and their management. Although this, strictly speaking, is not necessary, such an approach is far less confusing and more convenient for the model implementers and readers (as compared to independent definitions). This said, on some occasions we have added IDs to cover additional use cases, which understandably were never covered by older RFCs.

I believe your understanding “This document defines all the "Identity" (or types) for TE data types)” is incorrect. Nor I think the cross-check on completeness you mentioned is a requirement.


-----Original Message-----
From: Linda Dunbar via Datatracker [] 
Sent: Tuesday, May 14, 2019 6:41 PM
Subject: Genart last call review of draft-ietf-teas-yang-te-types-09

Reviewer: Linda Dunbar
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-teas-yang-te-types-??
Reviewer: Linda Dunbar
Review Date: 2019-05-14
IETF LC End Date: 2019-05-16
IESG Telechat date: Not scheduled for a telechat

This document defines all the "Identity" (or types) for TE data types.
Therefore, it is hard to tell if all the types are completely specified without cross reference to the TE specification drafts. For example, I tried to cross reference to RFC3209 on "identity local-protection-desired", the words are not completely matched in RFC3209.

(e.g. identity local-protection-desired { base session-attributes-flags; description "Fastreroute local protection is desired."; reference "RFC3209"; }

It would make it much easier to validate the YANG model if the page number of the referenced RFC is listed in the Reference, or the actual TLV being referenced are described.

Major issues:

Minor issues:

Nits/editorial comments:
Add the page number of the referenced RFC  to make it easier to validate the correctness of the "types", or describe the actual TLV being referenced .