Re: [Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-yang-26: (with COMMENT)

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

Hi Mirja,

On 8/20/19, 11:52 AM, "Mirja Kuehlewind" <[e-mail]> wrote:

    Hi Acee,
    
    Thanks for these changes/additions.
    
    One comment below.
    
    > On 20. Aug 2019, at 17:05, Acee Lindem (acee) <[e-mail]> wrote:
    > 
    > Hi Mirja, 
    > 
    > On 8/19/19, 12:25 PM, "Mirja Kühlewind via Datatracker" <[e-mail]> wrote:
    > 
    >    Mirja Kühlewind has entered the following ballot position for
    >    draft-ietf-ospf-yang-26: No Objection
    > 
    >    When responding, please keep the subject line intact and reply to all
    >    email addresses included in the To and CC lines. (Feel free to cut this
    >    introductory paragraph, however.)
    > 
    > 
    >    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    >    for more information about IESG DISCUSS and COMMENT positions.
    > 
    > 
    >    The document, along with other ballot positions, can be found here:
    >    https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/
    > 
    > 
    > 
    >    ----------------------------------------------------------------------
    >    COMMENT:
    >    ----------------------------------------------------------------------
    > 
    >    Just two quick questions about references:
    > 
    >    - Is there no reference for mtu-ignore (see section 2.4)? If not, can you
    >    further describe what exactly would be disabled?
    > 
    > I added "specified in section 10.6 of [RFC2328]." to the sentence. 
    > 
    > 
    >    - Also is there no reference for OSPF Non-Stop Routing (NSR) (see section
    >    2.4)...?
    > 
    > While many vendors have implemented this feature, there is no standard as the goal is to restart without other OSPF routers being impacted. We did add the additional text to describe the feature and differences with OSPF Graceful Restart. 
    > 
    >    And one more comment:
    > 
    >    In the interface-common-config part (p76 and p77) you provide example or
    >    default values for various intervals and delays. Where does those values come
    >    from? Would it be possible to provide a reference/RFC that specifies actual
    >    default values? Especially when you specify something normatively ("The value
    >    MUST be greater than 'hello-interval'.") it would be good to provide a
    >    reference!  Do any specification maybe also specify min and max value? If so,
    >    you should mention them here as well! If not would it make sense to recommend
    >    min and max values? If possible I would strongly support to describe min and
    >    max values as well!
    > 
    > The whole question of defaults generated quite a lot of discussion as there isn't really any one-size-fits all default and the sample values are very conservative. This is how we ended up with sample values in the text rather than YANG defaults. Since the protocol specification doesn’t specify min and max values, we were hesitant to specify them in the YANG model more than 20 years later. Also, many vendors have supported sub-second hellos. This wasn't a good idea and it has been supplanted by BFD. I will add RFC 2328 Appendix C as a reference for the sample values. 
    
    Good to hear that this was discussed! I understand the problem and a YANG is not the right place to “change” the spec. Adding a reference would be good!
    
    One more question regarding the sentence with normative language above: Is that already specified in some other spec and it would make sense to not use normative language here but provide the reference?
In this case, the YANG model enforces the constraint. However, it is not stated explicitly in RFC 2328 so I'll make it a lower case "must". 

Thanks,
Acee
    
    Mirja
    
    
    
    > 
    > Thanks,
    > Acee
    > 
    > 
    > 
    > 
    > 
    >