Subject: Re: [netmod] YANG conformance idea -- take two

From: Gerhard Muenz <[email-masked]>
Date: Wed, 13 Aug 2008 12:00:38 +0200

Dear all,

I'm glad to see how you are addressing problems and questions we have in
the IPFIX WG.

Distinguishing two capability levels (support of entire modules and
support of optional features within a module) nicely solves one of our
problems. Phil has already given an example (collector capability). Here
is another one which stresses the advantage of features:

Several packet selection methods have been standardized. A typical IPFIX
device supports a couple of them. If a certain method is supported, it
is configured in a standardized way. The manager should be able to query
the supported selection methods.

With features, we can have a single module covering the configuration
data of all selection methods. The manager can query the supported
selection methods (features) without getting capability information of
other modules it is not interested in.

The example can be extended: an IPFIX device supporting a specific
selection method may allow only a limited number of Selection Processes
which make use of this method, e.g. because the packet selection is
performed by a blade in a router. A possible solution is to specify a
readonly parameter in the DM which returns the corresponding value and
to explain its meaning in the description clause. Do you have a better idea?

Regards,
Gerhard

> Andy Bierman <andy at netconfcentral.com> wrote:
>> I think min-access addresses a separate problem than
>> partitioning a module into features. Perhaps both are needed.
> 
> Yes, and maybe it is best to wait with the min-access until yang 2.0?
> 
>> Sharon likes in-line min-access
> 
> I like this approach as well.  But it solves just one part of the
> problem - it tells the module reader or client that an agent MAY
> implement a particular object read only.  The other part of the
> problem is how the manager can know the real access of a particular
> object (ACCESS in AGENT-CAPABILITIES).  I think both parts of the
> problem need to be solved simultaneously.
> 
> 
> /martin
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Wed, 13 Aug 2008 11:04:16 -0400

>to explain its meaning in the description clause. Do you have a better idea?

These are the "device deviations" Martin was talking about, and
is work we are trying to put off til the next phase of YANG.  But
basically, the application asks the device where the device deviates
from a specific module.  The device replies with a list of deviations
in the format:

    deviation <path> {
        <deviated-statement> <device-specific-value>;
        ...
    }
    ...

For example,

    deviation making/up/the/path/to/process-list {
        max-elements 4;
    }

The app learns the device only supports 4 elements in the process-list
and can use this knowledge to configure the device appropriately.

Thanks,
 Phil