Re: [Lsr] Last Call: <draft-ietf-ospf-yang-23.txt> (YANG Data Model for OSPF Protocol) to Proposed Standard

["Acee Lindem (acee)" <[e-mail]>]

Hi Tom, 

On 8/1/19, 11:47 AM, "tom petch" <[e-mail]> wrote:

    I have been looking some more at this I-D and have some more doubts and
    queries.
    
    s.2.2
    OLD
       The area and area/interface containers respectively define the OSPF
       configuration and operational state for OSPF areas and interfaces.
    
    NEW
       The area and area/interface containers define the OSPF
       configuration and operational state for OSPF areas and interfaces
    respectively.

It seems to me that either of these is correct. However, I don't feel that strongly and will move "respectively" in the -25 version. 
    
    The current text suggests area corresponds to configuration and
    area/interface to operational state!
    
    OLD
           "WG Web:   <http://datatracker.ietf.org/group/lsr/>
    NEW
           "WG Web:   <https://datatracker.ietf.org/group/lsr/>

This will be fixed in the -25 version.
    
    
    I am puzzled by the use of derived-from...
    
          container router {
             when "derived-from-or-self(../../header/type, "
                 + "'ospf:ospfv2-router-lsa')" {
    why is this derived-from-or-self when I can see nothing derived from the
    base type?
    
           container network {
             when "derived-from-or-self(../../header/type, "
                 + "'ospfv2-network-lsa')" {
    ditto
I'm going to leave these as they are correct since "or-self" is included and there is no strictly (self()) identity-ref function (reference RFC 7950, section 
    
           container summary {
             when "derived-from(../../header/type, "
                + "'ospfv2-summary-lsa-type')" {
    why is this not derived-from-or-self when there are derivations from the
    base type?

There are two types of summary LSA - network summaries (type 3) and router summaries (type 4). So the type is always derived. 
    
             when "derived-from(../../header/type, "
                + "'ospfv2-external-lsa-type')" {
               description
                 "Only applies to AS-external LSAs and NSSA LSAs.";
    Yes, since they are derived-from external-lsa but external-lsa per se
    will be excluded which I assume is intended

Yes. 
    
    
         identity operation-mode { description  "OSPF operation mode.";
    I cannot see any explanation of where this is used or what it is

This was removed from the model but we neglected to remove the identity. It will be removed in the -25 version. 
    
    router capabilities (RFC7770) appears in the YANG but is not itself a
    feature; is there an assumption that all current routers will support
    RFC7770?

This is simply read-only data returned by a router. Hence, a router not recognizing it will simply return it as an unknown opaque type. It would be very strange for an implementation to support the OSPF YANG model but not opaque LSAs. 
    
    lsa-id
    sometimes dotted-quad, sometimes uint32, sometimes both; why?

For OSPFv3, the LSA Identifier has no topological significance and unit32 is correct. 
    
         grouping ospfv2-lsa {
    ...
           container header {
             must "(derived-from(type, "
    ...
               description
                 "Opaque type and ID only apply to Opaque LSAs.";
    The must and the description match but why are they part of container
    header and  not part of  the leaves?

I split out the opaque types in the -24 version.

Thanks,
Acee 

    
    Tom Petch
    
    ----- Original Message -----
    From: "tom petch" <[e-mail]>
    Sent: Friday, July 05, 2019 5:30 PM
    
    I think that this could do with a few tweaks.
    
    RFC 7884 is in the YANG module but not in the I-D references nor in the
    body of the I-D.
    
    The names of the TLV are not quite the same as in IANA and since new TLV
    are not regarded as updates to RFC7770, then precision is called for in
    order to find them with confidence via IANA
    
    I cannot find router-address-tlv in IANA nor is there a YANG reference
    clause and since there was some confusion over router-id in 2018, this
    is one I want to check against its RFC, whatever that is.
    
    The RPC can disrupt routing; elsewhere I have seen such actions limited
    by a default
    nacm:deny all
    so users have to be positively configured to invoke the RPC.
    
    I am unclear about rpc clear-neighbor.  Yes, it clears the adjacency but
    what then?  Is it held down, allowed to come back up or what?
    
    rpc or action?  I have yet to work out the pros and cons of each but was
    rather expecting action as opposed to rpc for these.
    
    leaf cost {type uint16
    mostly have a range, but some do not; should they?
    
     typedef ospf-metric { type uint32 {  range "0 .. 16777215";
    but
     leaf cost { type ospf-metric {  range "0..16777214";
    looks odd; if intended, I suggest adding a note of explanation
    
    some leaf metric are type ospf-metric others are type uint16; again
    looks odd (but may be intended)
    
    references to bfd-yang are not consistent
     RFC YYYY - YANG Data Model for Bidirectional
             Forwarding Detection (BFD).
     draft-ietf-bfd-yang-xx.txt:
         YANG Data Model for Bidirectional Forwarding Detection (BFD)";
    I think the former clearer
    
    I notice that many of the YANG enumeration have numeric values, others
    do not, which makes me curious; not wrong but since YANG does not put
    them on the wire, I think that having no numeric value is commoner
    
    With priority
    e.g.  list unreserved-bandwidth {
         leaf priority {
    which is high and which is low?
    
    Likewise with boolean e.g.
               leaf best { type boolean; description
                   "Indicates if the alternate is the preferred.";
    does true mean the alternate is preferred?
    
    This I-D is big - 125pp - and I will not finish reviewing it by July
    17th but expect to do so some time later in the month - I will post
    again when I have.
    
    Tom Petch
    
    ----- Original Message -----
    From: "The IESG" <[e-mail]>
    To: "IETF-Announce" <[e-mail]>
    Cc: <[e-mail]>; "Stephane Litkowski"
    <[e-mail]>; <[e-mail]>;
    <[e-mail]>; <[e-mail]>
    Sent: Tuesday, July 02, 2019 5:55 PM
    Subject: [Lsr] Last Call: <draft-ietf-ospf-yang-23.txt> (YANG Data Model
    for OSPF Protocol) to Proposed Standard
    
    
    >
    > The IESG has received a request from the Link State Routing WG (lsr)
    to
    > consider the following document: - 'YANG Data Model for OSPF Protocol'
    >   <draft-ietf-ospf-yang-23.txt> as Proposed Standard
    >
    > The IESG plans to make a decision in the next few weeks, and solicits
    final
    > comments on this action. Please send substantive comments to the
    > [e-mail] mailing lists by 2019-07-17. Exceptionally, comments may
    be
    > sent to [e-mail] instead. In either case, please retain the
    beginning of
    > the Subject line to allow automated sorting.
    >
    > Abstract
    >
    >
    >    This document defines a YANG data model that can be used to
    configure
    >    and manage OSPF.  The model is based on YANG 1.1 as defined in RFC
    >    7950 and conforms to the Network Management Datastore Architecture
    >    (NDMA) as described in RFC 8342.
    >
    >
    >
    >
    > The file can be obtained via
    > https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/
    >
    > IESG discussion can be tracked via
    > https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ballot/
    >
    >
    > No IPR declarations have been submitted directly on this I-D.
    >
    >
    > The document contains these normative downward references.
    > See RFC 3967 for additional information:
    >     rfc4973: OSPF-xTE: Experimental Extension to OSPF for Traffic
    Engineering (Experimental - Independent Submission Editor stream)
    >     rfc1765: OSPF Database Overflow (Experimental - IETF stream)
    >
    >
    >
    > _______________________________________________
    > Lsr mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/lsr
    >