Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

Tom,

Many thanks, great comments (as always)!

Regards,
Jeff

> On Aug 22, 2018, at 08:41, tom petch <ietfc@btconnect.com> wrote:
> 
> ---- Original Message -----
> From: "Jeff Tantsura" <jefftant.ietf@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)
> 
> - 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
> 
> - 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.
> 
> Tom Petch
> 
> Cheers,
> 
> Jeff
> 
> 
> 
> From: Lsr <lsr-bounces@ietf.org> on behalf of "Acee Lindem (acee)"
> <acee=40cisco.com@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
>> 
> 