Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

Martin Bjorklund <mbj@tail-f.com> writes:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
>> On Thu, 2019-09-26 at 11:04 +0000, Schönwälder, Jürgen wrote:
>> > On Thu, Sep 26, 2019 at 12:27:17PM +0200, Ladislav Lhotka wrote:
>> > > > Sure, one can discuss whether this feature is useful or harmful
>> > > > but the only way to officially remove this is to create a new
>> > > > specification and to run it through the IETF process.
>> > > 
>> > > I do insist that the wording in 7950 permits my interpretation, so I don't
>> > > propose any change.
>> > 
>> > It does not. You cannot cherry pick sentences.
>> 
>> I am not aware of any cherry-picking on my side. Can you show that my
>> interpretation is not possible?
>
> 8.2 says:
>
>    o  If a request modifies a configuration data node such that any
>       node's "when" expression becomes false, then the node in the data=
>
>       tree with the "when" expression is deleted by the server.
>
> This means that requests can modify config this way, otherwise this
> text wouldn't be there.  This is not just an intention, but follows
> from the text.
>
>>  Whatever the intent was, it is the text of the
>> spec that counts.
>
> With this logic, no client can be certain of anything; a server would
> be free to reject legal requests in any way it liked.  For example it
> would be perfectly fine for a server to only accept requests that
> modifies a single leaf at the time.
>

This is quite different. If a client tries to violate e.g. the "pattern" property, the request is rejected. So there is a reason for the server to do the same for the other items in the same list of properties that have to be true in all trees.

Again, I think the biggest problem is that YANG spec attempts to "hardcode" this (and other) protocol behaviour. Different protocols and different deployments clearly need different approaches, and I think we have to live with it. Our (NETMOD) priority should IMO be to make YANG as widely usable as possible, and enforcing arbitrary protocol policies certainly doesn't help.

Lada

>
>
> /martin
>
>
>
>> 
>> > 
>> > > What I propose instead is to remove such protocol-specific parts from the
>> > > specification of the YANG language, and clarify it in the specification of
>> > > individual protocols.
>> > 
>> > This is a different topic. Moving things around does not change the
>> > meaning (unless you change things as well while moving things around).
>> 
>> I wrote about clarification of protocols or server behaviour, which means
>> changes. It is also possible that different protocols use different approaches.
>> 
>> Lada
>> 
>> > 
>> > /js
>> > 
>> > -- 
>> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67