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

From: Randy Presuhn <[email-masked]>
Date: Fri, 1 May 2015 15:14:39 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: May 1, 2015 2:27 PM
>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 1:06 PM, Randy Presuhn
><[email-masked]> wrote:
>> 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.
>>
>
>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.

Are you arguing that the when or must statements cannot be
evaluated in a meaningful way?  That would be a serious problem.

Are you arguing that module designers can paint themselves into
a corner with when/must statements?  That's not solvable.  Any
language sufficiently powerful to do interesting things will
allow one to set up contradictions or nonsense.

>> >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.
>
>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.

Sure, and the dependency graphs resulting could potentially
be quite baroque.  But that reflects reality.

As long as there is no ambiguity/nondeterminism in how these
expressions are evaluated, the problem seems to be limited to
situations where what a system implements diverges from what
might be strictly inferred from what it advertises, and those
difficulties appear to be in the advertisement mechanisms,
not the modeling. If one were to constrain the language sufficiently
to prevent folks from saying anything silly, doing so would also
preclude useful things.

But I think we are in violent agreement that disregarding a request
for a specific revision is the wrong thing to do.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 02 May 2015 13:45:05 +0200 (CEST)

Randy Presuhn <[email-masked]> wrote:
> might be strictly inferred from what it advertises

I don't think this is correct.  If the server diverges from what it
advertises, the problem is in the server.

The disagreement seems to be around what conformance requirements the
import statement implies.

RFC 6020 is silent on this matter.  It just says that import-by
revision locks down typedefs etc, but it does not say anything about
augment.

The other confusion comes from this situation; suppose we have:

  module A {
    ...
    container a { ... }
  }

  module B {
    ...
    import A { prefix a;}
    container b1 { ... }
    augment /a:a {
      container b2 { ... }
    }
  }

and suppose a server advertises that it implements B (but not A).
What does this mean?

  1) This is an error - since it advertises B it MUST implement
     /a:a/b:b2, and the only way to do this is to also advertise A.

  2) This is fine - since it doesn't advertise A, the client knows
     that /a:a/b:b2 is not implemented.  However /b:b1 is
     implemented.

Again, RFC 6020 is silent on this.

I think we all have been thinking along the lines of 1 above, but maybe
we should decouple the language and module advertisement even more
from conformance, and go with 2 instead.  

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 2 May 2015 07:31:19 -0700

> revision locks down typedefs etc, but it does not say anything about

   When the optional "revision-date" substatement is present, any
   typedef, grouping, extension, feature, and identity referenced by
   definitions in the local module are taken from the specified revision
   of the imported module.  It is an error if the specified revision of
   the imported module does not exist.  If no "revision-date"
   substatement is present, it is undefined from which revision of the
   module they are taken.

   Multiple revisions of the same module MUST NOT be imported.

It is odd that nothing is mentioned about augment.
I do notice a MUST NOT that Y45 is trying to change.
IMO this MUST NOT needs to remain in place.

Andy

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 2 May 2015 10:19:50 -0700

> from conformance, and go with 2 instead.

I think I posted leafref and must/when-stmt examples before showing
it is not just augment that can reference data nodes from module A.
Not to mention the description-stmt.  IMO it is not possible to
specify which statements can just be silently ignored.

The only intuitive interpretation of import-by-revision
is that all the statements that appear in the specified revision are the
ones that will be used.

It is probably quite astonishing to users that the actual revision of
protocol-accessible
nodes may not be the same as the requested revision.

MUST be the specified revision:
  - typedef
  - grouping
  - extension
  - feature
  - identity

unknown revision:
  - data-def
  - augment
  - rpc
  - notification
  - deviation

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 3 May 2015 11:09:20 -0700

> Hi -
.......

> be quite baroque.  But that reflects reality.

I don't think I made it clear that my objection is to the server
advertising conformance to both "aug1" and "base@2014-01-01".
It is OK if the server implements back-revisions of "base",
but in order to claim conformance to "aug1", a certain minimum
revision needs to be supported.

I am willing to accept that the "minimum required revision"
is something the vendor can determine.  If the requirements
for the "group 2 (any revision)" statements are met by a
different revision, then the server can advertise conformance
for "aug1".

So I support Y45-03 (plus any bugfixes that are needed).
This solution does not attempt to undo the MUST NOT
import more than 1 revision of a module rule.  It does
not attempt to change the YANG syntax. This seems
most appropriate for a "1.1" minor release.

> for a specific revision is the wrong thing to do.

You have to read the fine print I guess ;-)

Andy