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" <[email protected]> wrote: ---- Original Message ----- From: "Jeff Tantsura" <[email protected]> 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 <[email protected]> on behalf of "Acee Lindem (acee)" <[email protected]> Date: Friday, August 17, 2018 at 13:09 To: "[email protected]" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr ------------------------------------------------------------------------ -------- > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
