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: Sunday, October 25, 2009 11:01 AM
> Subject: Re: [netmod] use cases was: finish up 
>
> "Randy Presuhn" writes:
> >The problem is what the client is required to do.  If the server
> >cannot be relied on to supply required s-c values, equivalent,
> >or potentially more complex logic, which would otherwise not be
> >needed, must be implemented in clients.
> 
> I don't see that.  If the client doesn't care enough to give it a
> value when it creates the instance, and the server doesn't see a
> need to set it when it is validating the config, then neither side
> needs to set it.  There's no requirement that this logic must be
> implemented in the clients.

If "neither side needs to set it" then it's truly optional, and
the model should identify it as such.

If it's truly necessary, but the server can be relied to create it
if not supplied by the client - well, that seems a reasonable use of s-c.

If it's what other standards would call "conditionally mandatory",
then a compromise would be to say that the server MUST create it
when not supplied by the client *if* the conditions that make it
mandatory (presumably rigorously spelled out in description text)
are satisfied.  What I can't abide is just leaving it to
an implementation's whims, which is what the proposed "MAY"
language would do.

But I think this group needs to step back a bit and think about what
conditionally mandatory parameters really mean architecturally.  Usually
their presence corresponds to the selection of a particular capability
or package of capabilities.  In such case, at least at a conceptual level,
they're mandatory bits within an optional presence container.

Randy