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 7/5/19, 12:30 PM, "tom petch" <[e-mail]> wrote:

    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.

See inline. 
    
    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.

This is defined in RFC 3630 for OSPFv2 Traffic Engineering LSAs. I've added separate opaque containers for the different opaque LSA types. 
I hope this makes things a lot clearer. 
    
    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 don't see this for RFC 8349 RPCs. Can you cite some examples? 
    
    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?

No - it is not held down - just cleared as the corresponding CLI command has done for 25 years. 
    
    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.

I think RPC is appropriate in this case as this is what we've implemented in other models. 
    
    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)

I've made all these consistent and added the ospf-link-metric type for the cases of the 16-bit link metric. 
    
    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

Fixed. 
    
    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

It depends on whether numeric values were previously provided in the OSPF MIBs.
    
    With priority
    e.g.  list unreserved-bandwidth {
         leaf priority {
    which is high and which is low?

I believe priority 0 is the highest. RFC 3630 doesn't state this explicitly. 
    
    Likewise with boolean e.g.
               leaf best { type boolean; description
                   "Indicates if the alternate is the preferred.";
    does true mean the alternate is preferred?

Yes - clarified the description.

Thanks,
Acee 



    
    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
    >