Subject: [netmod] followup on YANG conformance

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Aug 2012 12:43:45 -0700

Hi,

The WG is not very interested in this topic, but I strongly suggest
that all NETMOD WG modules in progress be split into
2 modules if there are any reusable typedefs, groupings, extensions,
features, and/or identities.  These should go in a separate YANG module
so a server and YANG designer can reuse this meta-data without
advertising the 'main' module with mandatory objects, rpcs, and notifications.

This simple workaround should cover most use-cases and may
prove to be better organization in the long-run.  It has proven
to be effective in SMIv2-land.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 26 Aug 2012 07:36:34 +0200

Hi Andy,

Can you give an example of what you are proposing using one of the YANG
modules currently in progress? I am not sure that I understand exactly
what you are proposing, in SMIv2 we (try to) separate the reusable TCs,
we do not separate conformance clauses. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Andy Bierman
> Sent: Thursday, August 23, 2012 10:44 PM
> To: [email-masked]
> Subject: [netmod] followup on YANG conformance
> 
> Hi,
> 
that
> all NETMOD WG modules in progress be split into
> This simple workaround should cover most use-cases and may prove to be
> better organization in the long-run.  It has proven to be effective in
> SMIv2-land.
> 
> 
> Andy
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Aug 2012 08:20:55 -0700

> we do not separate conformance clauses.

We have no explicit module conformance mechanisms in NETCONF/YANG,
other than the YANG module capability in the <hello> message.

So if I want to use the 'crypt-hash' typedef in 1 of my modules (or
another IETF module), then I have to import ietf-system.
In order to tell the client which 'ietf-system' (remember YANG module names
are not even intended to be unique) I have to advertise ietf-system in
the server <hello>.

The client will think I implement the /system container, which is not correct.

So if the crypt-hash typedef was in the ietf-system-types module instead,
I would not have to import ietf-system -- I could import ietf-system-types.
That way the client will not see ietf-system advertised unless the
server really implements the /system container.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Aug 2012 08:51:07 -0700

> we do not separate conformance clauses.

I picked the simplest example -- typedefs.

If you consider top-level groupings, then YANG conformance gets really murky.
Where is the conformance applied?  In module A which defines the grouping
but does not use it anywhere, or in module B which imports the grouping
and uses it?  Or in module B, which imports and uses it with refinements?

Seems to me that meta-data in YANG (features, typedefs, extensions,
identities, groupings) have no conformance requirements whatsoever
until they are used in a data-def-stmt.

Even if module B imports a data-def-stmt from module A
in order to augment it, it is not clear that module B inherits
all the conformance requirements for all of module A.

There is a perception that the NETCONF <hello> tells
the client all it needs to know about the server schema inventory
and conformance levels, but this far from accurate.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 27 Aug 2012 10:26:15 +0200

So the solution that you are proposing is to break away typedefs in separate YANG modules for each standard module? 

Dan

> From: Andy Bierman [mailto:[email-masked]]
> Sent: Sunday, August 26, 2012 6:51 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [netmod] followup on YANG conformance
> 
> > Can you give an example of what you are proposing using one of the
> > YANG modules currently in progress? I am not sure that I understand
> > exactly what you are proposing, in SMIv2 we (try to) separate the
> > reusable TCs, we do not separate conformance clauses.
> >
> 
> Where is the conformance applied?  In module A which defines the
> grouping but does not use it anywhere, or in module B which imports the
> grouping and uses it?  Or in module B, which imports and uses it with
> refinements?
> 
> identities, groupings) have no conformance requirements whatsoever until
> they are used in a data-def-stmt.
> 
> Even if module B imports a data-def-stmt from module A in order to
> augment it, it is not clear that module B inherits all the conformance
> requirements for all of module A.
> 
> There is a perception that the NETCONF <hello> tells the client all it
> needs to know about the server schema inventory and conformance levels,
> but this far from accurate.
> 
> 
> > Thanks and Regards,
> >
> > Dan
> 
> Andy
> 
> >
> >
> >
> >> This simple workaround should cover most use-cases and may prove to
> >> be better organization in the long-run.  It has proven to be
> >> effective in SMIv2-land.
> >>
> >>
> >> Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Aug 2012 11:09:58 +0200

> are not even intended to be unique) I have to advertise ietf-system in

I think in this case ietf-system is not advertized and the client should be able to find out which version of ietf-system was imported from the importing module (which is advertised).

> server really implements the /system container.

So how would the client determine which version of ietf-system-types was imported?
I don't see any difference.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 27 Aug 2012 11:20:10 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> >> YANG
> I think in this case ietf-system is not advertized and the client
> should be able to find out which version of ietf-system was imported
> from the importing module (which is advertised).

But if the importing module did not use import by revision, the client
does not know which version the server used.  This can be solved by
checking the /netconf-state/schema/schema list.

This works for typedefs, groupings, extensions, but not identities.
In order for a server/client to be able to recognize an identity, the
module where the identity is defined must be advertised.

> I don't see any difference.

B/c the ietf-system-types module would be advertised, together with
its revision.

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 27 Aug 2012 11:55:33 +0200

Dne 27.8.2012 11:09, piše Ladislav Lhotka:
> On Aug 26, 2012, at 5:20 PM, Andy Bierman<[email-masked]>  wrote:
>
>> other than the YANG module capability in the<hello>  message.
>>
>> the server<hello>.

I disagree. A server MUST advertise all revisions of all modules it 
implements (RFC6020 5.6.4.1).

When you import a module into another module as a modeler, you are 
currently creating a union of them, automatically saying that an 
implementer must implement both of them entirely, unless the imported 
module makes smart use of features. "Partial advertising" cannot be done.

Jernej

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 27 Aug 2012 11:58:12 +0200

> to be effective in SMIv2-land.

An alternative to making a "header" and an "implementation" version of 
each standard module would be to put a feature in them which would 
enable or disable a module's data tree. It would be clear whether a 
module is just being used for definitions or for it's data tree when 
advertised in the hello message. This would be a pure YANG solution.

With

feature implementation;

the following

http://example.com/some-module?module=some-module&revision=2008-04-01&feature=implementation

would indicate that the entire module is implemented on server, and the 
following

http://example.com/some-module?module=some-module&revision=2008-04-01

would mean that some other module just imports this module for it's 
definitions. I believe this would be a far more elegant solution that 
having a module split into two. Not sure if this is backwards compatible 
for existing modules though. Also it could be problematic to impose such 
a requirement on each top-level data definition statement.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Aug 2012 14:04:08 +0200

> module makes smart use of features. "Partial advertising" cannot be done.

No. This is pretty counter-intuitive, but see

http://www.ietf.org/mail-archive/web/yang/current/msg00455.html

Lada

>>>>> The WG is not very interested in this topic, but I str

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Aug 2012 15:56:53 +0200

> does not know which version the server used.  This can be solved by

Yes, but the same problem is with include - and submodules cannot be advertised in <hello>. 

> checking the /netconf-state/schema/schema list.

Right, perhaps this "RESTful" approach is best - each client can decide which conformance info has to be checked.

> B/c the ietf-system-types module would be advertised, together with

But then the import statement seems redundant, perhaps useful only as a way for declaring an abbreviation (prefix) for a module name within the importing module.

I think Andy has a point, but I am not sure that splitting the modules is the right solution - for one, it would double the number of modules, namespaces and prefixes.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Aug 2012 07:10:38 -0700

On Mon, Aug 27, 2012 at 2:58 AM, Jernej Tuljak <[email-masked]> wrote:
> An alternative to making a "header" and an "implementation" version of each
> standard module would be to put a feature in them which would enable or
> disable a module's data tree. It would be clear whether a module is just
> being used for definitions or for it's data tree when advertised in the
> hello message. This would be a pure YANG solution.
>

This would make all YANG objects optional-to-implement as well.
A YANG feature is advertised at the whim of the server developer.
YANG conformance needs something more like the when-stmt
for conformance, not an arbitrary AND-expr.

The "expressiveness" of YANG conformance is already extremely
limited.  I would not want to make that even worse.

Import/include by revision is mostly broken, and if you don't
understand why, just use it in your own YANG modules for awhile.
Every time you update the imported YANG module, you have
to go change all the import-stmts to the new date.  Otherwise
you end up using and advertising multiple revisions of the same YANG module,
instead of just the latest revision.  There are corner-cases where
you might want multiple revisions, but they are rare -- almost always
you want just the latest revision supported by the server.

Andy

> definitions. I believe this would be a far more elegant solution that having
> a module split into two. Not sure if this is backwards compatible for
> existing modules though. Also it could be problematic to impose such a
> requirement on each top-level data definition statement.
>
> Jernej
>
>>
>> Andy

---

From: Xiang Li <[email-masked]>
Date: Mon, 27 Aug 2012 09:45:31 -0500

> The client will think I implement the /system container, which is not correct.

Can this be solved by adding an additional attribute to the advertised 
hello.

RFC6020

        5.6.4 <http://tools.ietf.org/html/rfc6020#section-5.6.4>.
        Announcing Conformance Information in the <hello> Messag

    The namespace URI MUST be advertised as a capability in the NETCONF
    <hello> message to indicate support for the YANG module by a NETCONF
    server.  The capability URI advertised MUST be of the form:

      capability-string   = namespace-uri [ parameter-list ]
      parameter-list      = "?" parameter *( "&" parameter )
      parameter           = revision-parameter /
                            module-parameter /
                            feature-parameter /
                            deviation-parameter /
                            implementation-parameter  ==>Add this flag?

For example,  if you are just using the typedefs in foo-module,
instead of advertising:

http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01

Can we do
http://www.xyz.com/ns/foo-module?module=foo-module&revision=2010-06-01&implementation=false

This way, the client knows foo-module is only needed and advertised for 
name access?

--Xiang

-- 
--Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610
Mobile: 1 (217) 472-4108

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Aug 2012 07:59:10 -0700

> Can this be solved by adding an additional attribute to the  advertised

You mean like "conform=true|false"?
Perhaps you saw my slides that we did not have time for in Vancouver?
This is 1 option I proposed in my slides.

Since the default is 'true' you would really only see conform=false added
to module capabilities that are advertised for imports identification only.

The <conform> leaf could also be added to the ietf-netconf-monitoring
module /netconf-state/schemas/schema list.  Adding the leaf is easy.
Changing the module capability URI format is not, so when YANG 2.0
gets done someday, it will be on the wish-list.  I don't want to change
YANG for this (or any other proposed tweaks so far).

Andy

>
> RFC6020
>
> 5.6.4.  Announcing Conformance Information in the <hello> Messag
>
> This way, the client knows foo-module is only needed and advertised for name
> access?
>
>
> --Xiang
>
>
>
>
> features, and/or identities.  These should go in a separate YANG
>
> module
>

---

From: Xiang Li <[email-masked]>
Date: Mon, 27 Aug 2012 10:26:02 -0500

> You mean like "conform=true|false"?

I did not read the slides you mentioned.
I think "implementation=true/false" or "implemented=true/false" is not 
exactly same
as "conform=true/false". But it could be just  be different naming as 
"conform=true|false".

"implementation=true/false" or "implemented=true/false" just tells if 
the device
implements the module or  it is advertised only for name access.

I think if it is "conform=false"  one could interpret it as "the device 
does implement this
module, but is not 100%  conformant to the contract ". But that could 
just be me.

> module /netconf-state/schemas/schema list.  Adding the leaf is easy.

Yes if ietf-netconf-monitoring is mandatory for every implementation, I 
think this
should also work. We however need to make sure 
/netconf-state/schemas/schema
won't become another "sysORTable", where different implementations 
implement
it differently (if it gets implemented).

--Xiang

> YANG for this (or any other proposed tweaks so far).
Ok.

--Xiang

-- 
--Xiang Li
Web: www.seguesoft.com
Voice: 1 (872) 216-2610
Mobile: 1 (217) 472-4108