Subject: [netmod] import-no-revision breaks default

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Sep 2009 23:58:07 -0700

Hi,

Even with all the changed from MAY/SHOULD to MUST,
the <hello> message is still not deterministic.

In the example below, for leaf B_leaf and C_leaf
the client can determine that the default for
B_leaf == '10' and C_leaf has no default.
However, it is impossible for the client to
determine if there is a default for D_leaf.
This is because import-by-revision and include-by-revision
are optional-to-use.

Andy

--------------------------------------------------------------------

module A {
   ...

   revision 2009-01-01 {
      description "initial version";
   }

   typedef A_type {
      type int32;
   }
}

module A {
   ...

   revision 2009-05-01 {
      description "add default to A_type";
   }

   revision 2009-01-01 {
      description "initial version";
   }

   typedef A_type {
      type int32;
      default 10;
   }

}

module B {
  ...
   import A {
      prefix A;
      revision-date 2009-05-01;
   }

   revision 2009-06-01 {
      description "initial version";
   }

   leaf B_leaf {
      type A:A_type;
   }
}

module C {
  ...
   import A {
      prefix A;
      revision-date 2009-01-01;
   }

   revision 2009-06-01 {
      description "initial version";
   }

   leaf C_leaf {
      type A:A_type;
   }
}

module D {
  ...
   import A {
      prefix A;
   }

   revision 2009-06-01 {
      description "initial version";
   }

   leaf D_leaf {
      type A:A_type;
   }
}

---

From: Phil Shafer <[email-masked]>
Date: Fri, 4 Sep 2009 03:03:42 -0400

Deja vu:

>>The overriding rule is:
>>
>>   ... However, changes are not allowed if they have any potential
>>   to cause interoperability problems between a client using an
>>   original specification and a server using an updated specification.
>>
>>Proposals:
>>
>>(a) Default statements cannot be added in new revisions of a module.
>>
>>(b) Default statements cannot be added in new revisions of a module
>>unless that module contains a revision statement.
>>
>>(c) No changes can be made to a module unless it contains a revision
>>statement.
>>
>>(b) and (c) could be done with by changing:
>>
>>   For any published change, a new "revision" statement (^revision^)
>>-  SHOULD be included in front of the existing revision statements.
>>+  MUST be included in front of the existing revision statements.
>>
>>or making two classes of ways a module can be changed, and requiring
>>revisions for any changes with a potential to cause interoperability
>>problems.

So are you saying only (a) can work?

Thanks,
 Phil