Re: [NGO] external module properties

Martin Bjorklund writes:
>The problem is when a vendor needs to implement A rev 2 in a device,
>and also B.  B imports A rev 1.  So the device needs to implement A
>rev 1 *and* A rev 2.   This is something that we have talked about
>before, and dismissed as being too complicated in general.

I'm hoping (having not implemented it yet ;^) that this won't be that
bad.  If I have a hierarchy in my C module that uses a grouping
from B that uses the original revision of A, and another place in
my C that wants to use the new A with a new leaf that has the content
I want, I just need to track the module inclusion and imports to
know which revision of A I am getting the grouping from.

>But you talk about behavioural changes.  In the current design of
>YANG, the idea has been that a module cannot be updated in a way that
>changes the behaviour for importers and includers.  Thus you don't
>have to rev B just b/c A is updated.

If I add a new leaf to a grouping in A that B doesn't know about,
B will break if I use the new A.  If I can't say which A I want,
then the grouping in A cannot be allowed to change.  This means
that the contents of groupings, types, etc are locked for all time,
which is a pretty strong limitation.

Thanks,
 Phil
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo