Subject: [netmod] YANG - question on module revision

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Thu, 15 Nov 2012 17:36:37 +0000

I have a question regarding this revision rule in RFC 6020 (Section 10. Update a Module):

      New data definition statements may be added if they do not add
      mandatory nodes (Section 3.1<http://tools.ietf.org/html/rfc6020#section-3.1>) to existing nodes or at the top
      level in a module or submodule, or if they are conditionally
      dependent on a new feature (i.e., have an "if-feature" statement
      that refers to a new feature).

Lets say we have a YANG module in revision1 that looks like this:

Container A {

    Leaf L1 { }

    Leaf L2 { }

}

In revision2 of this module, we decide to add a new data container B inside A and move those leaves inside that:

Container A {

    Container B {

         Leaf L1 { }

         Leaf L2 { }

    }

}

Now, this change would obviously break revision1 implementation of the module.

However, it does not violate the revision rule stated in Section 10 of RFC 6020.

So are there any do's and don'ts on how one would go about introducing another level of hierarchy ?

One way is to retain both leaf nodes at both levels in the hierarchy.. Something like this:

Container A {

    Leaf L1 { }

    Leaf L2 { }

    Container B {

         Leaf L1 { }

         Leaf L2 { }

    }

}

Thanks,

- muthu

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Nov 2012 09:52:29 -0800

On Thu, Nov 15, 2012 at 9:36 AM, Muthumayan Madhayyan (muthu) <
[email-masked]> wrote:

>       mandatory nodes (Section 3.1 <http://tools.ietf.org/html/rfc6020#section-3.1>) to existing nodes or at the top
I think this paragraph apples:

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

You are deleting leafs.  That is a semantic change.

> One way is to retain both leaf nodes at both levels in the hierarchy.. Something like this:

yes -- mark the old leafs 'status deprecated;'
There is no specific amount of time they need to be
present in the implementation before you can mark them obsolete
and actually delete them from your server.  I suggest a year at least.

Not sure if there are interactions between the old and new nodes.
This could get messy in some corner-cases.

> - muthu

Andy

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