----- Original Message -----
From: "Ladislav Lhotka" <[email protected]>
Sent: Friday, December 28, 2018 1:03 PM

> On Fri, 2018-12-28 at 11:35 +0000, tom petch wrote:
> > ----- Original Message -----
> > From: "Ladislav Lhotka" <[email protected]>
> > Sent: Friday, December 28, 2018 7:47 AM

<snip>

 On a different tack, I was looking at teas-types and seeing
> > uses path-objective-function_config
> > Hang on, is underscore valid? Yes, but why use it? RFC8407 suggests
do
> > not.
>
> Maybe the use of the underscore has some meaning? I personally woudn't
be so
> strict regarding naming conventions, as long as it makes sense to the
module
> authors and users. And as Randy Presuhn recently explained, there may
in fact be
> no practical difference between RFC 2119 terms MAY and SHOULD in cases
like
> this.
>
> > or
> >     type union {
> >         type string {  length 0; // empty string      }
> >         type string {  pattern ...
> > and thinking why?  With no length restriction on the pattern, what
does
> > the complexity of a YANG union add?
>
> It is either an empty string or a string matching the pattern. Of
course, it
> would be possible to make the pattern match an empty string.
>
> > or
> >   description  "Then index of the label restriction list entry."; }
> >     container label-start {
> >       must "not(../label-end/te-label/direction) or "
> >         + "not(te-label/direction) "
> >         + "or ../label-end/te-label/direction = te-label/direction"
{
> >         error-message "label-start and label-end must have the same
> > direction.";
> > where the error message tells me what is going on (not the
description)
> > but I wondered about the second 'not'  which I asssume is to cater
for
> >  "(te-label/direction) "
> > not having a value.  All they want is
> > 'start direction must = end direction'
> > but it seems you need to be a contortionist to get there.
>
> A simpler way to express this could be
>
>     must "not(../label-end/te-label/direction != te-label/direction)"
>
> The inequality test turns false if either of the terms doesn't exist.

Ah yes, thanks for that; I was missing the fact that non-existent terms
make the inequality false.

Tom Petch

> Lada
>
> >
> > I would appreciate any comment on this last - is there a simpler way
of
> > doing it?   After which, I shall return to lurking.
> >
> > Tom Petch
> >
> > > Lada
> > >
> > > > Tom Petch
> > > >
> > > > > /martin
> > > > >
> > > >
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to