Re: [netmod] use cases was: finish up

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

Hi -

> From: "Phil Shafer" <phil at juniper.net>
> To: "Ladislav Lhotka" <lhotka at cesnet.cz>
> Cc: <netmod at ietf.org>
> Sent: Friday, October 23, 2009 9:34 AM
> Subject: Re: [netmod] use cases was: finish up
>
> Ladislav Lhotka writes:
> >> Can you explain what extra information "MUST" would denote
> >> to either the client or the server?  The server will know
> >The client has a guarantee that the server will supply a value.
> 
> But I'm trying to understand why the guarantee matters to the client
> and how it changes any behavior on the part of the client.  If
> the client wants post-s-c config, it knows that it needs to refetch
> it, and that post-s-c config may still not contain the s-c leaf.

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.

For the cases of "s-c" that I'd care about, the only times a client would
supply an s-c value would be in a configuration restore from archive,
or to ensure parameter consistency across systems after initially
allocated on a "master".

> >As I wrote before, the server needn't be a monolithic application and
> >for processes that cooperate through the configuration datastore it is
> >important know that the configuration is valid and all values are in
> >their places.
> 
> If the server didn't see the need to set the s-c leaf, we
> know that the description must allow this.  Our client
> can rest assured that all config is valid and in the right
> place, even if that means an s-c leaf does not exist.

But that means the data wouldn't be merely s-c.  From an information
modeling perspective, it is truly optional.  What's happening here looks
like an attempt to to ram two closely-related models together and pretend
that they are a single model.  The implementation which requires the
s-c bit of information and the implementation which does not require that
bit of information are clearly working with different information models,
even if the only difference between the two models is the optionality
of that bit of information.

Randy