----- Original Message -----
From: "Ladislav Lhotka" <[email protected]>
Sent: Friday, December 28, 2018 7:47 AM
> tom petch <[email protected]> writes:
>
> > ----- Original Message -----
> > From: "Martin Bjorklund" [email protected]
> > Sent: Thursday, December 27, 2018 12:08 PM
> >
> >> tom petch <[email protected]> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
