Hi Mirja,
On 8/20/19, 11:52 AM, "Mirja Kuehlewind" <[email protected]> wrote:
Hi Acee,
Thanks for these changes/additions.
One comment below.
> On 20. Aug 2019, at 17:05, Acee Lindem (acee) <[email protected]> wrote:
>
> Hi Mirja,
>
> On 8/19/19, 12:25 PM, "Mirja Kühlewind via Datatracker"
<[email protected]> 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
>
>
>
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
