Subject: Re: [netmod] features and capabilities

From: Balazs Lengyel <[email-masked]>
Date: Wed, 03 Dec 2008 14:30:55 +0100

Hello,
I like Andy's idea. IMHO capabilities and features are too similar.

Capabilities are modular: Nothing prevents me even today from having a capability that modifies 
the behavior of a single leaf element.

If-capability is needed: E.g. the XPath capability should have been included in the data model 
both in the notifications RFC and the partial-locking draft. Vendors can easily define their 
own fine-grain capability

Capabilities are dual-use already today. Advertising complete modules and advertising slight 
behavior changes (usually but not strictly protocol related).

Balazs

Phil Shafer wrote:
> Andy Bierman writes:
>> It is not clear at all in the YANG draft how NETCONF capabilities
>> are managed.  Actually, they are ignored completely and features
>> are introduced instead.
> 
> Capabilites are discuseed in the draft.  There's a one-to-one mapping
> between modules and capabilities.
> 
> Features allow a more granular approach than capabilities.  They
> are a mechanism for introducing hiearchy into the mix.  IMHO if
> features were available during the NETCONF design, we would have
> used them for many of the feature-like capabilties in NETCONF's
> base operations.
> 
>> IMO, there should be a global substitution:
>>    * s/feature/capability
>>    * s/if-feature/if-capability
>>    * remove special capability encoding, just use <capability>
> 
> Wasn't this suggested (and rejected) previously?
> 
> Thanks,
>  Phil
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Dec 2008 10:20:48 -0500

Balazs Lengyel writes:
>Capabilities are dual-use already today. Advertising complete
>modules and advertising slight behavior changes (usually but not
>strictly protocol related).

This is exactly the duality features address.  Fine-grained
control over the features in a module allows these features
to be scoped inside the module.

Consider your partial lock draft, which reuses the :xpath
capability from 4741.  If I support :xpath in the basic
netconf operations, I cannot support partial locks without
fully supporting it's xpath needs.  If your module used a
"feature xpath", the two could be supported independently.

Also consider this was part of the requests from both of
the early yang users (dns and ipfix).

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 03 Dec 2008 16:44:25 +0100

Hello Phil,
> to be scoped inside the module.

BALAZS: But capabilities are already dual use, and this wont change with adding features.
> "feature xpath", the two could be supported independently.

BALAZS: I could do that with introducing a new xpath-for-partial-lock capability. It is not 
more difficult to handle, then introducing "feature xpath" in the partial lock module. (On the 
other hand I don't want to control XPath handling for partial locking separately. It would be 
confusing.)
> the early yang users (dns and ipfix).

BALAZS: We could serve the needs of ipfix and dns with if-capability as well.

We introduce a new concept "feature", with the following main differences:
- inherently scoped to a module - is this good? needed?
- using simpler QNames instead of the hierarchical URNs

Is this worth the complication?

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Dec 2008 08:55:01 -0800

> BALAZS: But capabilities are already dual use, and this wont change 

Capabilities already do everything that features do,
except a feature is implicitly coupled to a namespace.

One could easily encode the module as parameter in
a regular capability URI like:

   http://example.com/feature-X?module=foo

Instead of encoding the feature as a parameter of the module URI:

   http://example.com/module-foo?feature=X

Protocol capabilities should be visible to the YANG DM designer
but they are ignored instead.

Features are not confined to a single module either.
You can reference features in any module:

    leaf A {
      if-feature bar:Y;
      type string;
   }

But to me the biggest issue with features is the notion that
the features that will be supported will be supplied
at YANG module compile-time.
This is a seriously broken tools architecture.

There are no #ifdefs in YANG.  All the symbols are visible
all the time in the YANG module.   The if-feature and when
conditionals are set by the agent implementation and the
running configuration.  A YANG module must be valid syntax
regardless of the if-feature or when conditionals present.

For example, a mandatory leaf inside the default case is
still an error, whether there are if-feature-stmts in the case-stmt
or not.

> BALAZS: I could do that with introducing a new xpath-for-partial-lock 
> capability. It is not more difficult to handle, then introducing 
> "feature xpath" in the partial lock module. (On the other hand I don't 
> want to control XPath handling for partial locking separately. It 
> would be confusing.)
>>

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Dec 2008 12:45:59 -0500

>> BALAZS: But capabilities are already dual use, and this wont change 

Hopefully it will.  By providing a mechanism more tailored to the
needs of the modelers, I expect to see this dual use of capabilities
disappear.  (IMHO If we had the feature mechanism during the original
xmlconf/netconf design work, there would have been no dual use.)

>at YANG module compile-time.

If I compile a YANG module for a box that does not support
the "xpath" feature, the tools can trim this knowledge from
the meta-data they put on the box.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Dec 2008 12:49:11 -0500

>other hand I don't want to control XPath handling for partial locking separately. It wou

Confusing .vs. not implementable.  In your current scheme, you
force devices that do one to do both.

I feel we're beating the same horse again.  Do we need a concensus
call to move forward?  Didn't we already have (at least) one?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Dec 2008 10:05:46 -0800

> call to move forward?  Didn't we already have (at least) one?

I support Phil on this one.
We do not want to force vendors to remove their :xpath advertisement
for their compliant 4741 implementations, because they choose to
implement :partial-lock but cannot adhere to all the bells and whistles
that the partial lock draft adds to the :xpath capability.

To be more clear:

   A new capability MUST NOT add any requirements to an existing capability.
 
This rule is being violated by the partial-lock draft.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2008 09:52:27 +0100 (CET)

> This is a seriously broken tools architecture.

There's nothing in the draft that says when an implementation chooses
to enforce its features.  This is an implementation issue.  One
implementation might to it dynamically in run time, and another can do
it when it generates code from the model (i.e. it can choose to not
generate code for the unsupported features).

> A YANG module must be valid syntax

Absolutely!

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2008 10:24:55 +0100 (CET)

I moved the part of the thread that discussed :partial-lock and :xpath
to the netconf ML.

But read on.

>  This rule is being violated by the partial-lock draft.

If this is the case, then you're suggestion to introduce a
'if-capability' statement will not work, since if you use e.g.

   leaf select {
     if-capability ":xpath";
     ...
   }

you really add a requirement to an existing capability.

Continuing this logic, we should do the same for feature, and not
allow a feature to be exported/imported from another module, as was
suggested by Andy earlier.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Dec 2008 07:42:32 -0800

> you really add a requirement to an existing capability.
Yes.  But that has nothing to do with YANG.
The protocol if-capability variables would be used in netconf.yang
to describe existing RPCs.  I agree this is not a priority for the WG.

I think if-feature is probably fine, and we just have a disconnect on
the term 'compile-time'.  I don't want if-feature and if-capability both,
and there are plenty of work-arounds available for capability checking.

   feature confirmed-commit {
      if-feature candidate;
   }

   leaf confirm-timeout {
       if-feature confirmed-commit;
       type uint32 { range "1..max";  }
       default 600;
       units seconds;
       reference "RFC 4741, sec. 8.4.5.1";
   }

Andy