Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Stephane,

Thanks for pulling in the fixes; just a few notes inline (and trimming)...

On Tue, Oct 08, 2019 at 10:33:49AM +0200, [e-mail] wrote:
> Hi Benjamin,
> 
> Thanks for your comment.
> Please find some inline answers.
> I'm doing the changes as part of the -41.
> 
> 
> Stephane
> 
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]> 
> Sent: mercredi 2 octobre 2019 03:17
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Yingzhen Qu <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS and COMMENT)
> 
[...]
> 
> 
> In the "protection-available" container, is there some sort of constraint that two of the alternate-metrics add up to the third?
> [SLI] It is not really a constraint from a YANG point of view, these are operational counters.

Sorry, I shouldn't have used the word "constraint", since that's a YANG
verb.  I was just asking if the description should reiterate to the reader
that in normal circumstances the two will add up to the third (and "no" is
a fine answer).

[...]
>        container delay-metric {
>          leaf metric {
>            type std-metric;
>            description "IS-IS delay metric for IPv4 prefix";
>          }
>          leaf supported {
>            type boolean;
> 
> Should the "metric" leaf be conditional on "supported" being true?
> (Same for the other flavors of metric, as well as when they appear later on in the "neighbor" grouping.)
> 
> 
> [SLI] This is not a configuration leaf, so I don't think that there is a need for enforcement at YANG level.

Oh, I had missed that it was config false; sorry about that.

[...]
> 
>        container unidirectional-link-delay-variation {
>          description
>            "Container for the average delay variation
>            from the local neighbor to the remote one.";
>          leaf value {
>            type uint32;
>            units usec;
>            description
>              "Delay variation value expressed in microseconds.";
> 
> Is this a standard deviation (variance), mean absolute error, ...?
> [SLI] We just mimic what is defined in RFC8570. As the reference is defined in the model. People should refer to it for more details.
> Moreover this is a pure operational state.

https://tools.ietf.org/html/rfc8570#section-4.3 still leaves me a little
unclear about what exactly is being reported (it sounds like it's just an
average link delay so the word "variation" confuses me), but I agree that
we should not say any more in this document.

>        container unidirectional-link-loss {
>          [...]
>          leaf value {
>            type uint32;
>            units percent;
>            description
>              "Link packet loss expressed as a percentage
>              of the total traffic sent over a configurable interval.";
> 
> This document is all about specifying configuration.  How do I configure the interval in question?
> [SLI] This is an operational state.

The leaf value is operational state, yes, but it reports a valid computed
"over a configurable interval".  How do I configure that interval?

Thanks!

-Ben