Acee Tweaking the subject line slightly since this is a more generic point.
My point about refine "version/ospfv2/ospfv2" { must "derived-from-or-self( " + "../../../../../../../../../../" + "rt:type, 'ospf:ospfv2')" { description "OSPFv2 LSA."; was more about the difficulty of validating these conditionals in YANG. It could be worse e.g. augment "/nw:networks/nw:network/nt:link/tet:te/" + "tet:te-link-attributes/" + "tet:max-resv-link-bandwidth/" + "tet:te-bandwidth/tet:technology" { when "../../../../../../nw:network-types/tet:te-topology/" + "otntopo:otn-topology" { occurring 100 or so times in an I-D. Tools can check the syntax, they can (almost) never check the semantics. It takes something more intelligent, more knowledgeable than a tool to spot that e.g. RFC 5178 - OSPFv3 Graceful Restart"; is wrong and I think the same of complicated YANG expressions. If complicated expressions occur once, I could check them; 100 times, no way. Every other language (almost) I have used allows me to say must "derived-from-or-self( " + "../../../../../../../../../../" + "rt:type, 'ospf:ospfv2')" { is equivalent to ospfv2 {type boolean} so I need check the complicated expression once, subsequent uses being just ospfv2 which is then obviously right or wrong. You only have any one 'complicated' expression occurring half a dozen times or so, but then there are a number of them, conditional on OSPF version, LSA type and so on. If one instance of one expression was syntactically valid but not quite right, perhaps missing 'or-self' or /.. or some such, would anyone ever notice? I see this as the biggest single defect in YANG that has only become apparent with the use it is put to in the Routing Area; and it is YANG that needs to change (IMHO). Tom Petch ----- Original Message ----- From: "Acee Lindem (acee)" <a...@cisco.com> To: "tom petch" <ie...@btconnect.com>; "Jeff Tantsura" <jefftant.i...@gmail.com>; <lsr@ietf.org> Sent: Thursday, August 23, 2018 12:23 AM Subject: Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang > Hi Tom, > > Thanks much Tom - I agree with your comments. See one inline. > > I will likely work on these prior to the end of the WG last call period. > > On 8/22/18, 11:41 AM, "tom petch" <ie...@btconnect.com> wrote: > > ---- Original Message ----- > From: "Jeff Tantsura" <jefftant.i...@gmail.com> > Sent: Friday, August 17, 2018 9:14 PM > > Acee, > > The draft is in good shape, support. > > <tp> > > Mmm that sounds like a good challenge. I had a quick look and noticed: > > - NMDA gets discussed in s.2.1; I like to see support for it mentioned > earlier, in Abstract and Introduction, something I have seen the IESG > request recently > > - there is no explanation of the legend used in the tree diagrams; if > appropriate, this can be fixed with an Informative Reference to RFC8340 > > - s.2.4 NSR needs expanding IMHO > > - s.2.4 I would like a list of features, all 20 of them, not just > "such as NSR, max-LSA, etc" > so I don't have to reverse engineer the YANG module to find them; as and > when new features come along, I expect there will be a delay before they > make it into YANG so a clear list for those supported by this module > would be useful > > - sometimes it is 'link state database ', sometimes 'Link State > Database', sometimes 'Link State database'; I would like consistency > (and prefer the capitalised version) > > I agree. > > - the YANG module as > version 1.1 > but RFC7950 is not mentioned or referenced; odd > > - the YANG module has > RFC 5178 - OSPFv3 Graceful Restart"; > which I think should be RFC 5187 > > Yup. > > - the YANG module has > "RFC XXXX - YANG Data Model for Bidirectional Forwarding Detection > (BFD)"; > "RFC XXXX: A YANG Data Model for OSPF."; > "RFC XXXX - SPF Back-off algorithm for link state IGPs"; RFC8405 > reference "draft-ietf-bfd-yang-xx.txt: > > I suggest using a larger namespace than 'XXXX'; perhaps 'XXXX' and > 'YYYY' (since "RFC XXXX - SPF Back-off algorithm for link state IGPs" > is in fact RFC8405 and is already in the Normative References) along > with a note to the RFC Editor telling them what 'YYYY' and 'XXXX' should > be replaced with. > > reviewing the technical bits is going to be a challenge; I struggle to > interpret such as > when "derived-from(" > + "../../../../../areas/area[area-id=current()/../area-id]/" > + "area-type, 'stub-nssa-area')" { > or > refine "version/ospfv2/ospfv2" { > must "derived-from-or-self( " > + "../../../../../../../../../../" > + "rt:type, 'ospf:ospfv2')" { > description "OSPFv2 LSA."; > > I note the use of "derived-from-or-self " as opposed to "derived-from " > but it will take me longer to work out if the usage is appropriate. > > In cases where the leaf should take on a specific identity rather than the general identity, It should simply be derived-from(). I'll revisit these. > > Thanks, > Acee > > Tom Petch > > Cheers, > > Jeff > > > > From: Lsr <lsr-boun...@ietf.org> on behalf of "Acee Lindem (acee)" > <acee=40cisco....@dmarc.ietf.org> > Date: Friday, August 17, 2018 at 13:09 > To: "lsr@ietf.org" <lsr@ietf.org> > Subject: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang > > > > This begins an LSR WG last call for the subject draft. Please send your > > comments to this list prior to 12:00 AM GMT, September 8th, 2018. > > > > Given the size of the model and the US Labor Day Holiday, we’re allowing > a full 3 weeks. > > > > For your convenience, here is a URL: > > > > https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ > > > > Note there is one obsolete reference left as an exercise for the > reviewers. Note that the document has already been through a couple YANG > doctor reviews. > > > > Thanks, > Acee > > _______________________________________________ Lsr mailing list > Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr > > > > > ------------------------------------------------------------------ ------ > -------- > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr