Re: [netmod] draft-ietf-softwire-yang-13

[Ladislav Lhotka <[e-mail]>]

On Fri, 2018-12-28 at 11:35 +0000, tom petch wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" <[e-mail]>
> Sent: Friday, December 28, 2018 7:47 AM
> > tom petch <[e-mail]> writes:
> > 
> > > ----- Original Message -----
> > > From: "Martin Bjorklund" [e-mail]
> > > Sent: Thursday, December 27, 2018 12:08 PM
> > > 
> > > > tom petch <[e-mail]> wrote:
> > > > > Martin
> > > > > 
> > > > > The Acknowledgements for
> > > > > draft-ietf-softwire-yang-13
> > > > > thank you for your work on this I-D (on the IESG Telechat for
> 10th
> > > > > January 2019) so can you tell me where my YANG is going wrong.
> > > > > 
> > > > > The module has
> > > > >   augment "/if:interfaces/if:interface" {
> > > > >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> > > > > and defines aplusp as a tunnel type in section 10.
> > > > > 
> > > > > A suggestion I made last October was to have a base for the three
> > > > > protocols covered here - MAP-E, MAP-T, Lw406 - and then derive
> three
> > > > > separate entities therefrom for the three protocols; I can see no
> > > > > derivation.  In which case, when is
> > > > > 
> > > > >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> > > > > 
> > > > > going to be true?
> > > > 
> > > > Right; either they have to define derived identities as you
> suggested,
> > > > or this need to change to 'derived-from-or-self'.
> > > 
> > > ... or drop the 'derived' altogether; if there is only 'aplusp', as
> at
> > > present, then I see no need for 'derived' and inserting one
> > > unnecessarily leaves scope for a future addition to be true when it
> is
> > > not wanted.  I can see it either way.
> > 
> > Do you mean writing something like
> > 
> >     when "if:type = 'iana-tunnel-type:aplusp'";
> > 
> > ?
> > 
> > This is brittle and shouldn't be used because it is a plain string
> > equality test and the result depends (in XML representation) on the
> > prefix that is declared for the namespace URI of the iana-tunnel-type
> > module.
> > 
> > It is true that derived-from/derived-from-or-self leaves scope for
> > future additions. However, if ever an identity is defined that
> > is derived from 'iana-tunnel-type:aplusp', then it IMO makes sense
> only
> > if the properties of the latter are inherited, so the "when" test
> > should still be true (and the augment applicable).
> 
> Lada
> 
> Thanks for that; I did indeed have the string equality test in mind,
> even though RFC8407 says otherwise.  I think that all this is too
> complicated, for me if not for the authors of I-D coming out of the

I agree it is complicated. On the other hand, using the string equality for
identities can lead to mysterious failures.

> Routing Area - I-D such as this one have already have several makeovers,
> courtesy of such as Martin and I, and for this in its present form to be
> on the next IESG Telechat - well, par for the course.
> 
> 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.

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
> > > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67