Thanks Acee.
It remains up to the WG and AD whether to pursue publication of an
unimplemented YANG model.
> I'm not sure where you've been over the last ten years,
Not wasting my time writing YANG models that I don’t want to implement :-)
> but the IETF
> YANG models have not been widely implemented. In LSR, we have chosen to
> publish them without requiring implementation.
That’s what I wanted to hear. Thanks.
I, of course, still have concerns that the models may be “not quite right” in
ways that would be detected during implementation but which don’t show up even
with careful review.
But if this is a conscious and mindful decision by the WG, that is fine.
> Luckily, vendors and others
> have chosen to copy parts of them (although often without acknowledgment).
I suspect there is no luck about it! The models have provided a useful scratch
pad.
== Management Considerations ==
Failure cases are covered by a single Notification for flex-algo not supported.
There is no equivalent for metric not supported, although that is a less
critical issue. There are no controls available to turn the reporting on or
off, and to throttle reporting.
== Major Issues ==
iana-igp-metric-types has
identity bandwidth-metric {
base metric-type;
description
"Bandwidth metric.";
reference
"draft-ietf-lsr-flex-algo-bw-con";
}
There is a set of codepoints for "user-defined metrics" and "flexible
algorithms". I don't think we want them to appear in the IANA registry (for
example, as user-metric-128, user-metric-129, etc.
> I don’t see anywhere in the model where it implies that we are going to define
> Identities for the user metric. It is simply a range unavailable for
> assignment
> of new metric.
Exactly. Like I say, I don’t think we want to do that.
I see leaf algo-number, but nothing equivalent for metrics.
But I also don't understand how algo-number, metric-type, and calc-type are
used. Surely algo-number and calc-type are complementary with only one of them
having meaning at once? Don't you need a Bool to say whether to use algo-number
or calc-type? (and similarly for metric-type or the new user-defined-metric
type)
> After a conversation with the RFC 9350 authors, I confirmed again that
> flex-algo and calc-type
> are independent. While it is unfortunate that both are drawn from the same
> IANA registry,
> this isn't something that we're going to fix with the YANG model.
Agreed that the YANG model should not (cannot) try to fix this.
Maybe adding a note in a description clause somewhere. But maybe users are
supposed to have fully grokked 9350.
Further, shouldn't algo-number have a range clause?
> It does have a range for the configuration.
>
> One normally wouldn’t have a range on the read-only leaves in OSPF TLVs.
Further, the description for calc-type is surely wrong. algo-type is a base
identity not an integer.
> calc-type and algo-type are independent. Having said that, this is good catch
> that the
> wrong base identity is used for calc-type. We will fix.
OK
Lastly, in flex-algo-not-supported, the leaf algo-number is a uint8 which
clashes with the use of the identity.
> There are no identities for flex algo-number - only the range 128-255.
Yeah. Like you said :-)
When I see a Notification defined, I expect to see some way to turn on and off
the generation of notifications, and ideally a way to control the rate of
generation.
> You expect to see this done per unique notification? Please point me to a
> YANG model where this is done? A better solution would to define a generic
> YANG
> group for referencing and controling notifications so this is done uniformly
> across
> notifications in IETF YANG models.
Well,, it’s almost like someone might have written RFC 8639 and RFC 8641 :-) I
quite like the security considerations in 8639.
Is there anything for the authors to do? Not sure. Personally, from an
operational point of view, I would like some hints about what implementations
or users of the model should do.
8347 is not a bad example of talking about notifications, even though it
doesn’t provide any cautions.
What happens if more flags are added to the SABM registry? Shouldn't you be
using an IANA-managed registry for that, too?
> Then the draft the adds the flag(s) should add the IANA registry. This is
> clearly
> out of scope for these YANG models.
Ah, your answer is: 9492 did not define a registry for the bits, so there is no
way to have an IANA YANG model.
I buy that. No point in grumbling to you about what 9492 did.
== Minor Issues ==
While the tree diagrams are useful, it is a shame that there is no text
describing the two OSPF models and how they are used.
We do have descriptions of the modules. For example:
This document defines a YANG module for OSPF Flexible Algorithm as
defined in [RFC9350]. It is an augmentation of the OSPF base model.
The module augments OSPF router configuration with support flexible
algorithms. In addition, both the OSPFv2 and OSPFv3 link-state
databases are augmented to include the TLVs defined in[RFC9350]
> What more would you expect?
>
> I think it is more important to have ccturate "description" statements
> in the YANG model than redundant repletion of the contents.
cf RFC 8347
It’s not a lot of text, but it is helpful.
But, like I say: it’s a shame. Not “this needs to be fixed.”
You have a number of imports from other modules. While your reference clauses
are clear with their pointers to the relevant RFCs, those RFCs don't appear in
the References section. What you need to do is either provide a table of
imports (as is often done - for example, section 1.3 of RFC 9731), or some text
above each module saying "This module imports from RFCwxyz". Then you can add
the documents to the References section. I think they are all Normative
references.
I see, at least:
RFC 8665
RFC 9843 (once you update from draft-ietf-lsr-flex-algo-bw-con)
RFC 9587
RFC 8294
RFC 8776
draft-ietf-teas-yang-te (this is already Pub Req so a normative reference is
safe)
> We''ll add any that are missed. We have a way to do that, e.g.,
> https://datatracker.ietf.org/doc/html/rfc9129#name-ospf-yang-module.
Excellent.
== Nits ==
All good. Thanks.
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
