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

Linda Dunbar <> Wed, 15 May 2019 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94B95120147; Wed, 15 May 2019 13:51:58 -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 508rXM9ffJSd; Wed, 15 May 2019 13:51:55 -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 A1AC31200FD; Wed, 15 May 2019 13:51:55 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id B26EAFBC3302328996CF; Wed, 15 May 2019 21:51:53 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 15 May 2019 21:51:53 +0100
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Wed, 15 May 2019 13:51:43 -0700
From: Linda Dunbar <>
To: Igor Bryskin <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Genart last call review of draft-ietf-teas-yang-te-types-09
Thread-Index: AQHVC0nrDYXX4Yt/rE6SKT8fFnREOqZsphtA
Date: Wed, 15 May 2019 20:51:42 +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 20:51:59 -0000


Thank you very much for the reply. 
Are you saying that all the "common TE types" in this document have been validated? If yes, then it is good. Thank you. 

Just as a Gen-Art Directorate reviewer, I did my due-diligence to check the common types defined in your draft are actually from the referred RFCs to make sure they are consistent. But I can't easily cross check them.  I understand it can be a lengthy job to validate all of them. 

If the WG has checked the consistency, then it is all good. 

Thank you very much for the explanation. 


-----Original Message-----
From: Igor Bryskin 
Sent: Wednesday, May 15, 2019 1:13 PM
To: Linda Dunbar <>om>;
Subject: RE: Genart last call review of draft-ietf-teas-yang-te-types-09

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 .