tom petch <[email protected]> writes:
> ----- Original Message -----
> From: "Martin Bjorklund" <[email protected]>
> To: <[email protected]>
> Cc: <[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
>
> 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
