Subject: [netmod] augment a leaf?

From: Phil Shafer <[email-masked]>
Date: Mon, 23 Jun 2008 11:39:29 -0400

MODsters,

So should I be able to augment a leaf?  Currently, I don't think
this is possible, but there are a number of circumstances where
it would be useful, such as:

- allow access to i18n/translation strings
- allow gui apps to augment with custom display info
- allow vendors to attach info needed for CLI display

Something like:

    augment ietf-bgp:group/ietf-bgp:peer/ietf-bgp:as {
        junos:populate-with protocols/bgp/group/peer/as-number;
        junos:i18n I18N_BGP_AS;
        junos:gui-hint display-as-dotted-number;
    }

(where ietf-bgp is the prefix for the IETF's bgp standard that
defined a leaf called "as", that I want to augment with vendor-specific
information.)

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Jun 2008 09:26:31 +0200 (CEST)

> - allow vendors to attach info needed for CLI display

This seems to something different than the current meaning of
'augment'.  I think you want to attach vendor-specific information to
a standard module.  IMO this is an implementation (or vendor specific)
issue.

This is something that I need to support as well, and we already
support it for our proprietary DML.  We do this through "annotation
files", where we attach implementation specific stuff to the schema
tree, like in your example.  My plan for YANG is to use the "overlay"
technique that I mentioned in the thread about implementation specific
defaults.

>         junos:gui-hint display-as-dotted-number;

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jun 2008 08:08:16 -0700

> a standard module.  IMO this is an implementation (or vendor specific)

This feature is exactly what 'extension' provides, not 'augment'.
But this must be inline with the YANG module, not remote
and certainly not a 1-of-N choice of extensions.

> technique that I mentioned in the thread about implementation specific

I like your 'extension overlay' idea.
This has great potential for platform-specific mappings,
callback registries, error registries, etc.
IMO, it is worth considering this as part of the standard.

We can never hope to configure or monitor everything with standards.
The goal of a standard is to "do common things in common ways".
NM costs more than it should because there aren't enough mechanisms
to auto-magically 'plug the holes' in an API for all the non-standard bits.

It seems to me no new syntax is needed, but rather an
algorithm to apply an overlay to a module, which seems
rather trivial.  (The hard work is implementing the various
extensions contained in the overlay.

There may need to be protocol extensions,
like a verb to allow an operator to apply an i18n overlay
of their choice to the internal NETCONF error message registry.

>>         junos:gui-hint display-as-dotted-number;

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jun 2008 17:19:33 +0200

On Wed, Jun 25, 2008 at 08:08:16AM -0700, Andy Bierman wrote:

> But this must be inline with the YANG module, not remote and
> certainly not a 1-of-N choice of extensions.

An 'extension' defines a new language construct; an augment defines
something that logically belongs somewhere else, e.g. into a standard
module you should not touch. Both things are needed and they do quite
different things.

> I like your 'extension overlay' idea.  This has great potential for
> platform-specific mappings, callback registries, error registries,
> etc.  IMO, it is worth considering this as part of the standard.

I first need to understand in more detail how this idea is going to
work before I can like it so much to believe it should be part of a
standard. Perhaps Martin can start a separate thread with a more
concrete proposal how "extension overlays" are supposed to work.

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jun 2008 09:16:14 -0700

> module you should not touch. Both things are needed and they do quite

I meant the specific list like i18n translation strings.
These are not part of YANG. You would need to define
an extension for this.

As for the overlay, I suppose any construct could be in
the overlay, so it is like augment-stmt in that respect.

> concrete proposal how "extension overlays" are supposed to work.

I said 'consider' not 'include', which just means discuss it on
the mailing list.

Andy