Re: [netmod] use cases was: finish up
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [netmod] use cases was: finish up
Phil Shafer wrote:
> 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.
>
If the client can rely on the server to create a reasonable
value, then the client developer does not need to write code
to set that leaf. (MUST)
Since the client developer cannot rely on the server
to create a reasonable default (MAY), the developer can either
ignore that leaf or write code to support it.
If the client ignores the leaf (at its own peril),
then it doesn't really matter who creates that leaf,
i.e., server or some other application.
If there is code to set the leaf explicitly,
then the client will use it every time,
and not guess/wait-and-see what the server will do.
Either way, the s-c boolean has no real value to the client
developer.
>> 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.
>
>> If the server only MAY set the value, it's also possible the leaf in the
>> re-fetched config will contain nothing, right?
>
> Yes.
>
> Thanks,
> Phil
Andy
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.