-----Original Message-----
From: Jürgen Schönwälder <[email protected]> 
Sent: Wednesday, March 23, 2022 1:34 AM
To: Mohideen, Kaja (Nokia - IN/Chennai) <[email protected]>
Cc: NetMod WG <[email protected]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

On Thu, Mar 17, 2022 at 07:11:36AM +0000, Mohideen, Kaja (Nokia - IN/Chennai) 
wrote:
> 1/ I understand that clients may/may-not be yang aware, not using 
> hello/yang-lib and may have hard-coded requests, response processing to get 
> its job done using the server. Such a client when encountering ‘unknown’ 
> nodes can either fail or ignore those nodes. It’s the client choice. But, 
> with expanded range of ‘enum and bits’, there is no choice but to fail as the 
> ‘value’ is now unknown. OK.
>

I do not agree that an expanded value space necessarily implies that clients 
have to fail.

[R Kaja Mohideen] What else the client can do? How can the client map the new 
value to one of the old values it recognize? Whatever the scenario the client 
is trying to get done, at least the specific step cannot be considered 
'successful'.

> 2/ If I understand right, RFC 7950 – Section 11 is talking about ways to 
> update yang module so the existing data in the server doesn’t gets 
> invalidated. That’s why the new data definition to be optional or conditional 
> using if-feature. Not about clients at all. Thank you for making this clear. 
> Shouldn’t the RFC text capture this so readers are informed?
>

The update rules defined in Section 11 try to guarantee that server updates do 
not break existing clients. This requires that clients play nicely with data 
that they do not understand and it requires that updates are done in a way to 
maintain backwards compatibility with existing clients. I wonder what makes you 
believe this would be different.

[R Kaja Mohideen] Sure. It's helping the existing client assuming there is only 
one set of clients and those are all updated at same time OR there is no new 
client using the updated module co-existing with old clients.

I am trimming the CC list since we already concluded that this is not an errata.

/js

-- 
Jürgen Schönwälder              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/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to