Hi Joel, Thank you for clarifiying. Actually, we do have a list of networks, each composed by a list of nodes. In order to unambiguously identify an ac, we need to supply the specific network and specific node ids. These ids are provided using "nw:node-ref" (rfc8345) and passing them in the path expression. FWIW, this construct is similar to tp-ref in RFC 8345. Cheers, Med > -----Message d'origine----- > De : Joel Halpern <jmh.direct@xxxxxxxxxxxxxxx> > Envoyé : mardi 3 septembre 2024 14:56 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; > jmh@xxxxxxxxxxxxxxx; rtg-dir@xxxxxxxx > Cc : draft-ietf-opsawg-ntw-attachment-circuit.all@xxxxxxxx; last- > call@xxxxxxxx; opsawg@xxxxxxxx > Objet : Re: Rtgdir last call review of draft-ietf-opsawg-ntw- > attachment-circuit-12 > > > Thank you Med. > > On the issue of References, the tree diagram, and nesting. One > example. grouping attachment-circuit-reference in section 5.2 > lists three children, ac-ref2, node-ref2, and network-ref2. > > However, the actual yang for attachment-circuit-reference has one > leaf, ac-ref, with type leafref, and a path. If I follow that > path, I will find a leaf node-ref, with a path, which in turn > points to a network-ref. Thus, in the YANG, it is what I would > describe as nested, which is not the same as the tree diagram. I > don't know that it matters, but I found it confusing. > > Yours, > > Joel > > On 9/3/2024 8:11 AM, mohamed.boucadair@xxxxxxxxxx wrote: > > Hi Joel, > > (apologies for the delay to reply as I was out of office) > > > > Thanks for the review. > > > > An attempt to address your review can be seen here: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauth > > or- > tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fboucadair.g > it > > hub.io%2Fattachment-circuit-model%2Fdraft-ietf-opsawg-ntw- > attachment-c > > > ircuit.txt%26url_2%3Dhttps%3A%2F%2Fboucadair.github.io%2Fattachme > nt-ci > > rcuit-model%2FJoel-Halpern-Review%2Fdraft-ietf-opsawg-ntw- > attachment-c > > > ircuit.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cdecedb > e30c2 > > > 840a06fb208dccc17cd7f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C638 > > > 609649816696734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI > joiV2 > > > luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LnFs6bGUR > fhGQz > > OeaCNPBMycdZNOhvpYluOPX0oJjhY%3D&reserved=0 > > > > Please see more inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Joel Halpern via Datatracker <noreply@xxxxxxxx> Envoyé : > jeudi > >> 15 août 2024 04:30 À : rtg-dir@xxxxxxxx Cc : > >> draft-ietf-opsawg-ntw-attachment-circuit.all@xxxxxxxx; last- > >> call@xxxxxxxx; opsawg@xxxxxxxx Objet : Rtgdir last call review > of > >> draft-ietf-opsawg-ntw- > >> attachment-circuit-12 > >> > >> Reviewer: Joel Halpern > >> Review result: Ready > >> > >> Hello, > >> > >> I have been selected as the Routing Directorate reviewer for > this > >> draft. The Routing Directorate seeks to review all routing or > >> routing-related drafts as they pass through IETF last call and > IESG > >> review, and sometimes on special request. The purpose of the > review > >> is to provide assistance to the Routing ADs. > >> > >> Although these comments are primarily for the use of the > Routing ADs, > >> it would be helpful if you could consider them along with any > other > >> IETF Last Call comments that you receive, and strive to > resolve them > >> through discussion or by updating the draft. > >> > >> Document: draft-name-version > >> Reviewer: your-name > >> Review Date: date > >> IETF LC End Date: date-if-known > >> Intended Status: copy-from-I-D > >> > >> Summary: > >> Choose from this list... > >> > >> No issues found. This document is ready for publication. > >> I have a few minor comments that should be considered. > >> > >> This is a truly impressive piece of work. The editors have > pulled > >> together information from a myriad sources into a usable (if > massive) > >> YANG module that addresses the range of needs very well. > > [Med] Glad to hear that. > > > >> Major Issues: N/A > >> > >> Minor Issues: > >> I note that section 5.1 in discussing parent > relationships > >> specifies that > >> if a parent AC is deleted, all the child ACs MUST be > deleted. > >> Given that > >> there is no reference from a parent to its children > (unless I > >> missed it), > >> it seems to this reader that it would really help > implementors > >> to tell them > >> how this is to be done? Are all children to be delted > first, > >> and the > >> client give an error if there are any active children? > Is the > >> client to > >> silently find and delete all ACs which point to the > deleted AC > >> as a parent? > >> Or some other means? > > [Med] Good point. Updated the model so that a parent AC can > maintain references to its child ACs. The tree structure is > updated with the following: > > > > NEW: > > +--ro ac-child-ref > > | +--ro ac-ref* leafref > > | +--ro node-ref? leafref > > | +--ro network-ref? -> /nw:networks/network/network- > id > > > > Added also a sentence to refer to that in the narrative text. > > > > Thanks for catching this. > > > >> In section 5.2 (References) in describing the groupings > the tree > >> diagram > >> shows a number of peer entities. However, unless I am > misreading > >> the YANG, > >> they are, in almost all cases, actually nested. Was this > a > >> deliberate > >> simplification, on artifact of the tree generation tool, > or an > >> error in my > >> reading? > > [Med] I'm not sure to get the point (especially, the "peer > entities"). These groupings are actually independent but are > grouped in the same figure for convenience. > > > >> I note that the document refers to RIP in multiple > places. > >> Unless I missed > >> something, this references RIPv2, but not RIPng (RFC > 20808). > >> I can imagine > >> reasons for such an omission. If there is a good reason, > then > >> please state > >> it. Otherwise, sorry, please also cover 2080. > >> > > [Med] We do cite 2080 in 5.6.5. > > > > I suspect that you were referring to the module itself. Updated > it accordingly. > > > _________________________________________________________________ > _____ > > ______________________________________ > > Ce message et ses pieces jointes peuvent contenir des > informations > > confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce > message > > par erreur, veuillez le signaler a l'expediteur et le detruire > ainsi que les pieces jointes. Les messages electroniques etant > susceptibles d'alteration, Orange decline toute responsabilite si > ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they > should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the > sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages > that have been modified, changed or falsified. > > Thank you. > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
