Re: [netmod] use cases was: finish up

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Phil Shafer" <phil at juniper.net>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: <netmod at ietf.org>
> Sent: Friday, October 23, 2009 11:23 AM
> Subject: Re: [netmod] use cases was: finish up 
>
> "Randy Presuhn" writes:
> >You're only looking at part of the problem.  The difference is in how
> >the value is allocated.  With the "MAY" behaviour, the client needs
> >to replicate whatever allocation logic the server should have had, in
> >case the server didn't feel like allocating one that day.  With the "MUST"
> >behaviour, client implementors don't need to replicate that logic unless
> >they have some other compelling reason to.
> 
> Consider the following slightly faked-up scenario:  an IDP detection
> policy is shared between a set of chassis.  To be shared, the policy
> needs a unique number, but some policies (based on the needs of the
> policy) are not shared and do not need this number.  The system MAY
> create the "number" leaf if the policy needs it, but won't bother
> creating it if it does not need it.
> 
> I guess this leaf could be made irrelevant by using a "must" statement
> that discards it unless the policy needs it.

This dives into the question of "optional" configuration data that isn't
really optional - there is a (potentially complex) presence condition,
in this case the semantics of the policy's "payload" that determins
whether the policy is or is not shareable. Slightly different ways
to look at the handling of "conditionally mandatory" stuff include
(1) subclassing, though this gets messy when there are multiple
"conditionally mandatory" bits; (2) packaging this stuff into aspects,
though I don't see a terribly tidy way for yang to handle these;
(3) wrapping the conditionally mandatory bits into types that permit
"N/A" as a potential value.

(To the specifics of the example, however, I think the computational
burden of figuring out whether a policy would need a number would
probably be greater than unconditionally assigning one.  :-)

However, recognizing that there are cases where s-c behaviour is
useful, the conditionally mandatory case seems to me to be a corner
case.  I think some more experience with actual models and implementation
might be needed to figure out how to do it right.  For example,
to what extent should the representation of the conditions be machine-
readable in the model?  On the other hand, this question doesn't even
arise for the "MUST" interpretation.

I'm not arguing that we need to do the s-c at this time.
Rather, I'm arguing that if we do do s-c at this time,
the MUST approach is much more tractable than the MAY
approach.  The MAY approach may have its legitimate uses,
but doing it right means (at least to me) going through
the exercise of figuring out the limits of conditionally
mandatory elements in models, which in your example goes
far beyond what can reasonably be expressed today.

Randy