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

From: Jeff Tantsura <[email-masked]>
Date: Fri, 17 Aug 2018 13:14:44 -0700

Acee,

The draft is in good shape, support.

Cheers,

Jeff

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Friday, August 17, 2018 at 13:09
To: "[email-masked]" <[email-masked]>
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-masked] https://www.ietf.org/mailman/listinfo/lsr

---

From: tom petch <[email-masked]>
Date: Wed, 22 Aug 2018 15:41:32 +0000

---- Original Message -----
From: "Jeff Tantsura" <[email-masked]>
Sent: Friday, August 17, 2018 9:14 PM

Acee,

<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-masked]> on behalf of "Acee Lindem (acee)"
<acee=[email-masked]>
Date: Friday, August 17, 2018 at 13:09
To: "[email-masked]" <[email-masked]>
Subject: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

Given the size of the model and the US Labor Day Holiday, we’re allowing
a full 3 weeks.

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-masked] https://www.ietf.org/mailman/listinfo/lsr

------------------------------------------------------------------------
--------

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 22 Aug 2018 09:23:41 -0700

Tom,

Many thanks, great comments (as always)!

Regards,
Jeff

> On Aug 22, 2018, at 08:41, tom petch <[email-masked]> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 22 Aug 2018 23:23:02 +0000

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-masked]> wrote:

    ---- Original Message -----
    From: "Jeff Tantsura" <[email-masked]>
    Sent: Friday, August 17, 2018 9:14 PM
    
    Acee,

    <tp>

    

    

I agree.
    
    - the YANG module as
    version 1.1
    
    - the YANG module has

Yup. 
    
    - the YANG module has

    

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

    

    

    

    
    Thanks,
    Acee

---

From: tom petch <[email-masked]>
Date: Thu, 23 Aug 2018 11:56:59 +0000

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)" <[email-masked]>
To: "tom petch" <[email-masked]>; "Jeff Tantsura"
<[email-masked]>; <[email-masked]>
Sent: Thursday, August 23, 2018 12:23 AM
Subject: Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang

>                 +
"../../../../../areas/area[area-id=current()/../area-id]/"
> 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.