Subject: [netmod] Augmenting an unimplemented module

From: Christian Hopps <[email-masked]>
Date: Fri, 03 Feb 2017 08:40:06 -0500

Hi,

Is it allowed for a server to implement a module that augments another
module that it does not implement? My thinking was that the augment
would simply not be implemented in this case. Is that true or must the
server implement any and all augmented modules referenced by a module?

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Feb 2017 14:59:02 +0100

> server implement any and all augmented modules referenced by a module?

There are modules that only consists of augmentations. It would be
really odd if an implementation claims to have implemented such a
module without implementing the module that has been augmented.  For
example, it would be odd to claim an implementation of ietf-ip without
implementing ietf-interfaces.

I think the proper thing to do is to write explicit deviations if a
portion of a module is not implemented (regardless whether the portion
is an augmentation or not).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 03 Feb 2017 11:30:42 -0500

> is an augmentation or not).

Well sure it's odd for an augmenting only module. In my case I'm adding
a feature to another module that is not required for my module to be
useful. My module is quite simple, conversely the module it augments
(yang library) isn't. I didn't want to force the implementer to have to
implement yang library, but I do want to add to it if they do.

In any case is there anything explicit in the standard to indicate that
a deviation must be indicated if an augmented module is not present?
Might be nice to have an ability to tag the augmentation as optional.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Feb 2017 17:43:23 +0100

> Might be nice to have an ability to tag the augmentation as optional.

What about tagging the augmentation as a feature if the augmentation
is not essential for your module?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Feb 2017 09:45:03 -0800

> is not essential for your module?
This seems like the correct approach.
If module A considers module B optional, then any augment of module B
within module A must also be optional.

Seems like this should be mentioned in 6087bis.

> /js

Andy

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 03 Feb 2017 12:45:44 -0500

Is it cleaner/preferable to do this or to have two models, one with the 
core definitions and one with the augmentations?

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Feb 2017 20:05:21 +0100

On Fri, Feb 03, 2017 at 12:45:44PM -0500, Lou Berger wrote:
> Is it cleaner/preferable to do this or to have two models, one with the core
> definitions and one with the augmentations?

I do not think there is a clear cut rule for this.

/js

---

From: Christian Hopps <[email-masked]>
Date: Sat, 04 Feb 2017 11:59:48 -0500

> is not essential for your module?

This seems like a solution. From a client perspective at first it seems
like 6 of one or 1/2 dozen of the other. With my earlier assumption the
client would check for the yang library (augmented) module being
supported, and with your suggestion the client checks for the feature
which then implies the augmented module is present. Using feature does
allow for implementing both modules but not the augmentation which I
would prefer to not allow in my case, but you can't always get what you
want. :)

How does one check whether a feature is implemented or not? I couldn't
quite figure this out from reading the STD.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 4 Feb 2017 18:27:04 +0100

> quite figure this out from reading the STD.

Since YANG 1.1, features are announced in /modules-state/module/feature
in ietf-yang-library defined RFC 7895. YANG 1 features were announced
as part	of capability URIs during the NETCONF hello exchange, see RFC
6020 section 5.6.4. RESTCONF uses teh ietf-yang-library.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 4 Feb 2017 10:17:11 -0800

> 6020 section 5.6.4. RESTCONF uses teh ietf-yang-library.
We are doing both in our server: the YANG library is fully implemented and
module capabilities for all modules are advertised, not just YANG 1.0
modules.
It may take a couple years before the client tools adjust to the library
cache approach.

/js

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 7 Feb 2017 17:32:05 +0100

My earlier problem was that if I do not implement the augmented module 
(modA) even if the augment is switched off by a feature, I still need to 
have the NOT implemented augmented module (modA)  in yang-library to 
satisfy the import statement of the augmenting module (modB). So I 
decided to follow Lou's suggestion and separate the core and the 
augmenting definitions of (modB-core and modB-augment). This way if the 
augmented module (modA)  is absent I can exclude the augmenting 
parts(modB-augment), but still use the core parts (modB-core).

regards Balazs

On 2017-02-03 18:45, Lou Berger wrote:
> Is it cleaner/preferable to do this or to have two models, one with 
> the core definitions and one with the augmentations?
>
> Lou
>
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Wed, 08 Feb 2017 09:06:19 -0500

We also went with the split route with our tags draft.

https://datatracker.ietf.org/doc/draft-rtgyangdt-netmod-module-tags/

Features like deviations were not liked internally by the group. 2
modules seemed like the KISS approach.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Feb 2017 15:51:04 +0100

> modules seemed like the KISS approach.

I wonder why your define add-tags, remove-tags, and reset-tags
operations given that we have generic primitives to edit datastores.

Also note that draft-ietf-netmod-yang-model-classification-04.txt
distinguishes 'element' and 'service' modules, not as your ID says
'service' and 'entity' modules.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Feb 2017 16:11:01 +0100 (CET)

> operations given that we have generic primitives to edit datastores.

I think (hope) they mean that these operations affect only the tags in
yang-library, not the config container 'modules-tags' in the module
itself.

But I think it would be better to only have these tags in the
yang-library, and not in the module itself.  (In that case the rpcs
are required).

Also, it might be useful if the module designer could tag modules
at design time, using an extension:

  mt:module-tag "ietf:element-model";
  mt:module-tag "vendor:native";

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Feb 2017 16:15:33 +0100

>   mt:module-tag "vendor:native";

We should perhaps start a separate thread but I fail to see why tags
require new editing primitives. In fact, there seem to be system
supplied tags and configured tags. It is unclear whether I can remove
a system supplied tag. It is unclear what the persistence of added
tags is. If NC/RC clients can tag modules, then these tags are just
more config I would say.

/js

---

From: Lou Berger <[email-masked]>
Date: Wed, 08 Feb 2017 10:29:03 -0500

On February 8, 2017 10:16:14 AM Juergen Schoenwaelder 
<[email-masked]> wrote:
...
> require new editing primitives.

It was an intentional design choice/preference by one of the authors. 
Basically, Chris thought it was easier from a client perspective.  He's the 
user, so he won:-)

Lou
(Co author)

---

From: Christian Hopps <[email-masked]>
Date: Wed, 08 Feb 2017 13:22:01 -0500

> Basically, Chris thought it was easier from a client perspective.  He's the

The tags in the library and the tags in a module are updated at the same
time and represent logically the same list of tags. Its clear this
happens with an RPC. It seems a lot less clear this would (or should)
happen if one edited only once location.

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Wed, 08 Feb 2017 13:28:57 -0500

> 'service' and 'entity' modules.

I've fixed this locally and will get updated in next rev, thanks for
catching this.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Feb 2017 21:29:23 +0100

> happen if one edited only once location.

I am not convinced by the design. We have lots of other resources
where we have configured and system determined values. I do not see
that tags are any different.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Feb 2017 21:34:30 +0100 (CET)

> that tags are any different.

I agree.  *If* you want a config true datastructure, it should be
modified with the normal edit operations, not special RPCs.  There are
several reasons for this.  For example, how would your new RPCs interact
with locks?  With candidate?  With startup?

Also I am not sure it is a good idea to add configuration meta-data
that really should be common across all modules into the modules
themselves.  Another approach is to keep a separate list with the
tags, indexed by modulename and revision.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Feb 2017 22:09:30 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> 
> 
> On 2/8/2017 3:34 PM, Martin Bjorklund wrote:
> I defer to Chris on us of RPCs in general, but an interesting use case
> that is supported with RPCs is tag modification in RO modules.

Yes, but we are talking about configuration data.

> This is what the library augmentation is aimed at.

Yes that is needed, but if you also want to let clients configure
tags, you need another list.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Feb 2017 22:36:27 +0100

> that is supported with RPCs is tag modification in RO modules.

No, you are simply hiding configuration data behind RPCs. Somewhere
the tags need to be stored.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 09 Feb 2017 15:03:02 +0100

> a deviation must be indicated if an augmented module is not present?

RFC 7950 says in sec. 5.6.5:

   If a server implements a module A that imports a module B, and A uses
   any node from B in an "augment" or "path" statement that the server
   supports, then the server MUST implement a revision of module B that
   has these nodes defined.  This is regardless of whether module B is
   imported by revision or not.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67