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

From: Andy Bierman <[email-masked]>
Date: Sun, 09 Aug 2009 09:00:14 -0700

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

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Aug 2009 12:17:07 +0200

Hi Andy, Martin,

I think we should bring the discussion related to NETCONF Monitoring
draft to the NETCONF maillist.

Since we believed the monitoring draft was nearly final I would
appreciate if you guys post clear requests possibly with a text
proposal. 
I think this will help the authors of the monitoring draft and the
NETCONF WG a lot.

One other question though as a contributor:

NETCONF WG developed "capabilities" and introduced several of them.
Is it your proposal they shouldn't be used?
I am wondering whether we need a WG decision or BCP-like statement
saying it shouldn't be used.
It would be interesting if you elaborate a bit why YANG features should
be used instead of NETCONF capabilities.
(I know some of the reasons but might be missing others. At the end we
need a record on the maillist if we want to push such a decision.)

Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Martin Bjorklund
> Sent: Wednesday, August 12, 2009 9:01 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netmod] staying in synch on data model discovery
> 
> Hi Andy,
> 
> Andy Bierman <[email-masked]> wrote:
> I agree.
> Yes.  That is the intention of the current design.
> 
> What makes you think that modules with deviation statements are not
> advertised with their revision?
> 
> I agree that these two parameters should be made optional, but I think
> that an error should be returned if there are multiple revisions
> and/or formats.  In most cases there will be just one revision and one
> format so that's the one that will be returned.
> 
> > to stop.
> Agreed.  For the current drafts, I think this applies to partial-lock
> which we don't want to change at this point, and with-defaults which I
> believe Juergen commented on in some other thread.  I think the
> monitoring draft is fine.
> 
> I don't think this is necessary, and in any case, there is no such
> thing as a 'deviation' module.  In theory, any module / submodule can
> have deviation statements.
> 
> 
> /martin
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Aug 2009 13:32:52 +0200

On Wed, Aug 12, 2009 at 12:17:07PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
 
> Is it your proposal they shouldn't be used?  I am wondering whether
> we need a WG decision or BCP-like statement saying it shouldn't be
> used.  It would be interesting if you elaborate a bit why YANG
> features should be used instead of NETCONF capabilities.  (I know
> some of the reasons but might be missing others. At the end we need
> a record on the maillist if we want to push such a decision.)

I believe we did not communicate this well...

NETCONF provides a capability exchange mechanism which uses URIs to
identify capabilities. The NETCONF protocol defines some core
capability URIs but otherwise leaves the format of capability URIs
pretty much open. YANG uses the NETCONF capability exchange and
imposes a format on the URIs to communicate among other things data
model defined features. The common format of the URIs allows to write
generic code to analyse these URIs. So everything is actually pretty
fine in the sense that NETCONF provides a mechanism and YANG uses and
further restricts the mechanism in order to enhance interoperability.

All we want to achieve is to do away with handcrafted URI formats
(often miscommunicated as "avoid capabilities") and instead use the
YANG feature mechanisms. The existing NETCONF URIs of course won't be
changed - but for new URIs, we like to use the YANG format.

Does this help?

/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/>