Hi Acee,
please see inline.
On Mon, 2018-01-08 at 19:28 +0000, Acee Lindem (acee) wrote:
> Hi Lada,
>
> Apologies for the delay. We somewhat got hung up on 4 and 6. See inline.
>
> On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lhotka@xxxxxx> wrote:
>
> > Reviewer: Ladislav Lhotka
> > Review result: Ready with Issues
...
> >
> > 3. Maybe the draft could mention that implementations should supply a
> > default routing domain as a system-controlled resource.
>
> Isn’t this more of an RFC8022BIS statement? I guess we could state this as
> an assumption.
Probably, but it is not a YANG issue, so I'd leave it to you routing folks to
decide.
>
>
> > 4. In "when" expressions, the module uses literal strings for
> > identities. This is known to be problematic, the XPath functions
> > derived-from() or derived-from-or-self() should be used instead.
>
> Why is this problematic? Is it because the types can be extended?
That's one reason: derived identities should often also satisfy the constraint.
But the more serious problem is that things like
when "../../../../../../../rt:type = 'ospf:ospfv3'"
rely on plain string comparison that depends od the actual prefix used for the
"rt:type" value. For one, according to RFC 7951 the JSON encoding of this value
would be "ietf-ospf:ospfv3" so the above expression is always false.
> >
> > 6. The types of LSA headers are modelled as integers. While OSPF gurus
> > probably know these numbers by heart, it is not very
> > reader-frienly. So at least some references to documents defining
> > these numbers should be provided, but my suggestion is to consider
> > implementing them with identities. It seems it might also be useful
> > to define some "abstract" identities for these types. For example,
> > if "opaque-lsa" is defined, then the definition of container
> > "opaque" could simply use
> >
> > when "derived-from(../../header/type, 'ospf:opaque-lsa')";
> >
> > instead of
> >
> > when "../../header/type = 9 or "
> > + "../../header/type = 10 or "
> > + "../../header/type = 11";
>
> I guess I don’t see the identities as always being better. We will
> consider this one.
In what situations could the numbers be better?
...
Thanks, Lada
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67