Linda, thanks for your review. Igor, thanks for your response. I’ve entered a No Objection ballot. Alissa > On May 15, 2019, at 4:51 PM, Linda Dunbar <linda.dunbar@xxxxxxxxxx> wrote: > > Igor, > > 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. > > Linda > > > > -----Original Message----- > From: Igor Bryskin > Sent: Wednesday, May 15, 2019 1:13 PM > To: Linda Dunbar <linda.dunbar@xxxxxxxxxx>; gen-art@xxxxxxxx > Cc: draft-ietf-teas-yang-te-types.all@xxxxxxxx; ietf@xxxxxxxx; teas@xxxxxxxx > 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. > > Regards, > Igor > > > > > -----Original Message----- > From: Linda Dunbar via Datatracker [mailto:noreply@xxxxxxxx] > Sent: Tuesday, May 14, 2019 6:41 PM > To: gen-art@xxxxxxxx > Cc: draft-ietf-teas-yang-te-types.all@xxxxxxxx; ietf@xxxxxxxx; teas@xxxxxxxx > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > 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 > > Summary: > 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 . > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
