---- 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)
- 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 <[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
