Hi Acee,

Thanks for these changes/additions.

One comment below.

> On 20. Aug 2019, at 17:05, Acee Lindem (acee) <a...@cisco.com> wrote:
> 
> Hi Mirja, 
> 
> On 8/19/19, 12:25 PM, "Mirja Kühlewind via Datatracker" <nore...@ietf.org> 
> 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? 

Mirja



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

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to