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

[tom petch <[e-mail]>]

----- 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
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.
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?
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.

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