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

From: Randy Presuhn <[email-masked]>
Date: Fri, 1 May 2015 16:06:57 -0400 (EDT)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: May 1, 2015 10:48 AM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help?
>
>On Fri, May 1, 2015 at 10:25 AM, Randy Presuhn
><[email-masked]> wrote:
>> 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?
>>
>
>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.
...

Though I agree the conclusion that any sort of non-determinism in
version selection is broken, other parts of the reasoning to get to
that conclusion give me heartburn.

RFC 6020 describes augment in structural terms rather than semantic
ones.  Consequently, arguments about augment based on semantics
rather than structure seem to me to be based on assumptions external
to the specification.

>From the perspective of *structure*, there's nothing wrong with
admitting possibility that an instance of a datatype resulting
from an augmentation might be of a different version from some
other instance of that dataype in the augmented node.
It's possible to figure out deterministically and unambiguously
what version to use for each instance, so it seems to me that
these objections must be based on an assumed tighter coupling
between the underlying implementation of the augmented node and the
augmentation than would be required by 6020.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 1 May 2015 14:27:09 -0700

> rather than structure seem to me to be based on assumptions external

But augment is often used with the "when-stmt".
The when and must statements allow ad-hoc interactions
between objects. IMO we cannot look at some YANG statements
and ignore others when considering how modular integration
is designed into the data model.

> augmentation than would be required by 6020.

The must/when statements go beyond structure.
These can impact any object and they are tied to
the semantics of the model, not the structure.

> Randy

Andy

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