Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help?

From: Randy Presuhn <[email-masked]>
Date: Fri, 1 May 2015 10:25:56 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: May 1, 2015 9:43 AM
>To: Xiang Li <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help?
...
>I noticed that the example given in Y45-04 for why we need
>multiple imports of each module is somewhat flawed:
>
>import ietf-inet-types {
>  revision-date 2013-07-17;
>  prefix inet;
>}
>import ietf-inet-types {
>  revision-date 2010-09-24;
>  prefix inet6021;
>}
>leaf foo {
>  type inet:ip-address-no-zone;
>}
>leaf bar {
>  type inet6021:ip-address;
>}
>
>
>This example shows that author wants to use the new ip-address-no-zone
>typedef that was added to RFC 6991, but is going to keep using the
>old version of ip-address.
>
>   1) ip-address did not change at all from RFC 6021, so there is no
>        point in importing 2 revisions
>
>   2) even if the ip-address did change, is it really up the the author
>    of the importing module to decide the standard ip-address type?
>    Since the augmenting module is being updated anyway, it is OK
>    to update the typedef.  If it is the first version, then even worse
>    to pick the out-of-date typedef.
>
>If a typedef gets corrected (e.g., the pattern-stmt is wrong in the old
>revision), then why do we want to let other modules keep using
>the broken version?  Why make YANG complicated so the user can
>do the wrong thing?
>
>What if IPv7 gets added someday?  Is it up to each WG, each module
>to decide "We have no interest in supporting the new IP version.
>We will stick with the current typedef forever".  Is this OK, or
>should the set of IETF modules use consistent data types?

The design of the modeling language is entirely the wrong tool
to use to enforce such a policy.

As much as it is desirable for standards to be clean and consistent,
fielded products are not, especially when there are add-ons from
multiple vendors.   If this modeling language and protocol
are to be able to adequately represent whatever might be found in
deployed systems, they must be capable of representing some pretty
messy stuff.  That's life.

I have a feeling that there are differing understandings here of
what a Yang augmentation really *means*.  Are all of the versioning
assumptions folks are making truly consequences of the semantics
of augmentation, or are they consequences of specific implementation
strategies?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 May 2015 10:48:32 -0700

> of augmentation, or are they consequences of specific implementation

I don't understand the confusion.
Clearly, if new functionality has been added to rev N,
then in order to use that functionality, rev N needs to
be supported.

The deployment is a separate matter.
A vendor can add deviation-stmts as needed
to specify the messy product details.

Can the augmenting data assume any functionality in the augmented
module at all?  IMO it is not even possible to write a module that
integrates with an existing module, unless a specific minimum version
is selected.

Obviously I cannot import definitions that have not been added yet.
What is less obvious (I guess) is that the imported definitions
can interact with various statements to produce version-specific
dependencies. The simplistic logic of Y45-04 "it exists so it
must be OK to use any version of it" is broken.

> Randy

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod