Re: [Lsr] LSR Working Last Call for draft-ietf-ospf-yang - YANG is too complicated

[tom petch <[e-mail]>]

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