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.dun...@huawei.com> 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.dun...@huawei.com>; gen-art@ietf.org > Cc: draft-ietf-teas-yang-te-types....@ietf.org; i...@ietf.org; t...@ietf.org > 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:nore...@ietf.org] > Sent: Tuesday, May 14, 2019 6:41 PM > To: gen-art@ietf.org > Cc: draft-ietf-teas-yang-te-types....@ietf.org; i...@ietf.org; t...@ietf.org > 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@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
