Subject: [netmod] features and capabilities

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Nov 2008 09:39:22 -0800

Hi,

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.  Yet NETCONF has already defined many
capabilities for protocol behavior which may impact data model
design, and none of them are visible in NETMOD.

This leaf is not possible in YANG because capabilities are ignored:

    leaf rollback-scope {
      if-capability nc:rollback-on-error;
      description
        "Protection scope for edit-config rollback-on-error";
      type enumeration {
        enum immediate;
        enum parent;
        enum root;
        enum namespace;
      }
      default parent;
    }

Since module features can be imported into other modules
for 'if-feature' statements, they are no longer a way of
partitioning modules (as originally billed) but rather
a complete duplication of capabilities, except in <hello> encoding.

By changing the URI encoding in the <capability> element,
NETMOD not only adds complexity to the NETCONF protocol <hello>
exchange, it also removes functionality.

The encoding 'foo-mod?features=a,b,c,d' does not
provide any extensibility for features (a,b,c,d).
This is the reason we use elements instead of attributes in NETMOD,
and it is just as valid for capability URIs (as demonstrated by the
features addition to the capability URI in the first place).

By saving some bytes in 1 NETCONF PDU, the WG is giving up
the ability (forever) to extend the feature advertisement.
This seems rather shortsighted to me.  Just like
ignoring capabilities and inventing features instead.

IMO, there should be a global substitution:
    * s/feature/capability
    * s/if-feature/if-capability
    * remove special capability encoding, just use <capability>

This would:
   *  allow modules to declare capabilities so they can be used
      in conditional schema definitions, including the standard
      capabilities such as 'validate' or 'startup'.
   * allow feature advertisements to include additional data,
     which could be vendor-defined or future standards
   * remove complexity and redundancy from the architecture

Andy

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

---

From: Phil Shafer <[email-masked]>
Date: Sun, 23 Nov 2008 15:56:23 -0500

Andy Bierman writes:
>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.

>    * remove special capability encoding, just use <capability>

Wasn't this suggested (and rejected) previously?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Nov 2008 13:57:28 -0800

> between modules and capabilities.

But this ignores protocol and vendor capabilities completely.
It leads to hacks like:

    feature rollback-on-error {
      description
         "This feature is enabled if the rollback-on-error
          capability in RFC 4741 is advertised.";
    }

> used them for many of the feature-like capabilties in NETCONF's

They are not more granular at all.
There is a flat QName list of features that are exported
to other modules like typedefs or objects.

There is a trivial 2 level hierarchy provided, which duplicates
the namespace:identifier hierarchy already supported.

> Wasn't this suggested (and rejected) previously?

I don't know -- I will consider it closed then,
but I don't think anything except redundancy has
been added to the mix.

Andy