Subject: Re: [Netconf] [netmod] staying in synch on data model discovery

From: "Mark Scott" <[email-masked]>
Date: Wed, 16 Sep 2009 14:41:13 -0400

Andy,

Pardon my delayed response on this.

To address your points below.

1.  NETCONF and NETMOD collaboration:  per WG consensus we have updated
the monitoring draft to use YANG as the normative data model.  I won't
speak for other NETCONF drafts but this is a positive step for this one.

2.  <get-schema> mandatory parameters:  Initially <identifier> was the
only mandatory parameter in the <get-schema> operation, however after we
agreed to expand the key definition in the schema list we made <version>
and <format> mandatory parameters in the operation.  My preference would
be to keep this alignment between the key and <get-schema> mandatory
parms.  I agree in cases where only 1 revision and/or 1 format exists
this is heavy-handed but it protects against agents returning schema a
manager may not have intended since <identifier> is not unique in schema
list and the logic on agent to select the default revision may differ
from what the manager would have selected (esp. if more than 1 version
exists).

3.  Agree on the benefit of this and will add it to latest version which
we will be posting shortly.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andy Bierman
Sent: Sunday, August 09, 2009 12:00 PM
To: NETMOD Working Group; NETCONF
Subject: [netmod] staying in synch on data model discovery

Hi,

I would like to see the NETCONF and NETMOD WGs act more
like they play for the same team regarding YANG and all
the YANG data models under development.

I mostly care about the ietf-netconf-state data model to
use the get-schema() operation with YANG.  If others want
XSD and RNG instead, then that's extra credit, but full
support for YANG is a must-have.

YANG modules, submodules, and deviation modules all need
to be listed in the <schemas> and retrievable with <get-schema>.

However, deviations have no revision that is advertised,
yet they clearly have a revision-date just like any other
YANG module.  This is somewhere between confusing and broken.

The <version> field in the <get-schema> operation is mandatory.
It should be optional, and if missing, then the
agent will pick whatever revision it wants (usually
there will just be 1 to pick from).

The <format> field in the <get-schema> operation is mandatory.
It should be optional, and the default should be 'YANG'.

IMO, the use of capabilities instead of YANG features needs
to stop.  Even more, ALL the data models under way in the
NETCONF WG should wait for YANG, and use YANG features,
not protocol capabilities to achieve.  That will eliminate
the possibility that there can be 16 valid variants of
the same leaf,and will help start out with a coherent set of
YANG modules using the same data types (e.g., ip-address issue).

I think the <schema> node should have another leaf:

   leaf moduleType {
     description
        "The type of data model file for this schema entry.";
     type enumeration {
        enum module {
          description
            "Indicates this entry is for a main module.";
       }
       enum submodule {
          description
            "Indicates this entry is for a sub-module.";
       }
       enum deviation {
          description
            "Indicates this entry is for a deviation module.";
       }
       enum other {
          description
            "Indicates this entry is for some other type of module.";
       }
    }
 }

This will help operators understand what all the 'extra' entries are
for,
and allow better filtering of the <schemas> subtree.

Andy

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

---

From: "Mark Scott" <[email-masked]>
Date: Wed, 16 Sep 2009 16:52:55 -0400

Andy (and Martin),

While updating the YANG module for point 3 below I wonder instead of
enumeration do we want to make this an identityref?  

Similar to what we did for schema-format to allow extensibility and
allows non-YANG formats to use something more meaningful the
moduleType='other'.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Scott, Mark (CAR:2N00)
Sent: Wednesday, September 16, 2009 2:41 PM
To: Andy Bierman; NETMOD Working Group; NETCONF
Subject: Re: [Netconf] [netmod] staying in synch on data model discovery

Andy,

Mark

-----Original Message-----

Hi,

   leaf moduleType {
     description

Andy

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

---

From: "Mark Scott" <[email-masked]>
Date: Tue, 22 Sep 2009 10:57:39 -0400

Andy,

After some discussion with Martin on #3 below once you exclude
'deviation' (not a valid type) and considering 'other' is
non-deterministic we seem to be left with only module and sub-module.
As such we don't think this adds much value beyond what you can derive
from the format value.  So we suggest this not be added to this draft at
this time.

Based on your description below perhaps this is more of a suggestion to
add new module types to YANG and is better suited to the netmod ML for
discussion?
	- Note:  I did not cc: this response to netmod ML

Mark

-----Original Message-----

Andy,

Mark

-----Original Message-----

Hi,

   leaf moduleType {
     description

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2009 08:23:28 -0700

> 	- Note:  I did not cc: this response to netmod ML

Martin is correct that there is no distinction
in YANG between different types of modules,
so a 'deviation module' is not needed.

I thought this issue was closed.
No need for this 'moduleType' parameter.

The YANG module capability URI doesn't support sub-modules,
so <get-schema> is the only way for a client to know
for sure that the 'include bar;' in [sub]module foo.yang
is really the bar.yang that the server is using.
But lots of NETCONF/YANG is pure guesswork on the part of the
client, so this is by no means the exception.

Andy