Subject: Re: [netmod] [Netconf] ietf-netconf.yang (2)

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Apr 2009 08:54:58 -0700

Andy Bierman wrote:
> Hi,
> 
> Here is the updated version based on Martin's comments.
> 

I did not get any comments on the YANG module
or the total lack of support for NETCONF capabilities.

There is a disconnect between how the NETMOD WG views
the data modeling world and how standard NETCONF data models
already in place are using capabilities.

The claim is that capabilities are not needed in YANG
because they are for the protocol layer, and features
are for the content layer.  This assertion has proven
to be false in 2 of the first 4 YANG standard data models.

The result is that any YANG file that tries to describe
capability-based constructs is really describing a superset
of all possible versions -- just like XSD, and just as worthless.

A schema that works for all possible implementations
but doesn't work for any specific implementation is
not that useful to real CM work.

I suggest that the NETCONF and NETMOD WGs think about
this problem some more.

Andy

> IMO, the total lack of support in YANG for NETCONF capabilities
> is a mistake.  It leaves a big hole in the tool automation chain,
> for a very basic feature of the NETCONF architecture.  It forces
> simple boolean logic into description statements, where it must
> be read by every single implementor, the English text understood
> correctly, and then manually implemented correctly.
> 
> This is not just some corner-case, because this module happens
> to be netconf.yang.  The ietf-partial-lock data model is designed
> to utilize the :xpath capability, and is only defined in description
> statements.  The ietf-netconf-state data model contains
> sections which are only relevant if :notifications is supported,
> or if :partial-lock is supported.  Again, only defined in
> description statements.
> 
> So, out of the 4 very first 'content layer' standard data models,
> (not counting netconf.yang) half of them need an 'if-capability'
> statement. That seems like a pretty solid use-case to me.
> 
> 
> 
> Andy
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Sun, 26 Apr 2009 22:56:58 -0400

[moving to a single mailing list (netmod); bcc'ing netconf]

>or the total lack of support for NETCONF capabilities.

You've mentioned this issue several times and I believe
it's been addressed, most recently by Martin, but by
others before and during the interim.

My quick summary would be:
(1) If we'd had features during the initial netconf
work, we would have used them.
(2) YANG can handle multiple capabilities using multiple
modules.
(3) Early YANG users wanted something less heavy/ more
light-weight for their models.  The disliked using
capabilities for this.
(4) We made features, which give a simple extension
mechanism for modelers to mark portions of the model
as only applying when a feature is present.
(5) This approach was approved at the interim and
subsequently on the mailing list.

If you want to use capabilities to model these bits instead of
features, I think that is a valid choice.  Other modelers may find
features more suitable.

I believe this is a closed issue.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Apr 2009 20:28:52 -0700

> I believe this is a closed issue.

I believe this is an ignored issue.
Modelers obviously want to use NETCONF capabilities
to partition content layer constructs, otherwise
they would not have designed partial-lock and netconf-state
data models that way.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sun, 26 Apr 2009 23:30:00 -0400

>they would not have designed partial-lock and netconf-state

These drafts predate features and don't contain normative YANG
modules.  Should these drafts be held until YANG is complete?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 26 Apr 2009 21:01:49 -0700

> modules.  Should these drafts be held until YANG is complete?

Yes.  These data models should use YANG if-feature
instead of capabilities and description clauses.

The partial-lock draft doesn't actually work
for all but a small number of use-cases.
The monitoring draft is mostly redundant data
already returned in <rpc-reply> PDUs.  The get-schema
RPC operation is really useful, though.

We need a clean 'YANG MIB' for NETCONF.
We should not rush out these particular drafts,
ignoring YANG features.

Andy