Re: [NGO] external module properties

Hi -

> From: "Martin Bjorklund" <mbj@tail-f.com>
> To: <randy_presuhn@mindspring.com>
> Cc: <ngo@ietf.org>
> Sent: Thursday, May 01, 2008 2:31 PM
> Subject: Re: [NGO] external module properties
...
> 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.

Too complicated for what?   The only case I can think of would be if some
tool were blindly trying to re-use the same code for Arev1 and Arev2, or if some
tool failed to account for the possibility that the same identifier might show
up in different modules.  These are just two ways of describing the same
kind of broken-ness, and are easily handled by scoping (whether in one's
symbol table management or the way one generates labels for use in code).

> 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 an update to a module can't change behaviour (where behaviour includes
signatures / interface definitions), then why does it matter?

Randy

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