Subject: Re: [Netconf] closure on dynamic model changes

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Jul 2018 21:48:09 +0000

Hi Jeff,

Both RFC 7895 and rfc7895bis (almost RFC 8407) define a checksum a client can poll, as well as a notification a client can receive, to determine when a server's module set has changed.

Kent

On 7/11/18, 5:34 PM, "Netconf on behalf of Jeffrey Ladouceur (jladouce)" <[email-masked]<mailto:[email-masked]> on behalf of jladouce=[email-masked]<mailto:jladouce=[email-masked]>> wrote:

Hello netconf experts,

I’m trying to determine if there was closure on the topic of dynamic model changes and the impact on any connected netconf clients.

The last message appears to be 8 years ago:

https://www.ietf.org/mail-archive/web/netconf/current/msg05982.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg05982.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Z5JgjQUnS4iOxPJ2YqJzFJTEW4Pyl-q8NHvml9iW0kc&s=YawnPBrkjAh6mZNBG8fY0VN0Rl8hqYwz_4uxbQc7zCE&e=>

Has there been any standards agreement since the above post or any other discussions ?

Kindest regards,
Jeff

---

From: "Jeffrey Ladouceur (jladouce)" <[email-masked]>
Date: Wed, 11 Jul 2018 21:58:04 +0000

Hi Kent,

The client can receive notification and can poll the checksum to determine if the module set has changed.

I’m also trying to determine if there was acceptance with regards to returning an error app tag of “capabilities-changed” when a client sends an RPC which could potentially no longer work as expected.

Regards,
Jeff

From: Kent Watsen <[email-masked]>
Date: Wednesday, July 11, 2018 at 5:48 PM
To: Jeffrey Ladouceur <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] closure on dynamic model changes

Hi Jeff,

Kent

Hello netconf experts,

Kindest regards,
Jeff

---

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Jul 2018 22:43:05 +0000

Hi Jeff,

I'm not aware of such an error-app-tag.   I'm doubtful any such support to exists as the official stance is that YANG modules are forever backwards compatible (sans deviations).

Kent

On 7/11/18, 5:58 PM, "Jeffrey Ladouceur (jladouce)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Regards,
Jeff

Hi Jeff,

Kent

Hello netconf experts,

Kindest regards,
Jeff

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Thu, 12 Jul 2018 17:42:05 +0200

Hi Jeff, hi Kent,

Below some comments.

Regards,
Ariel

Quoting Kent Watsen <[email-masked]>:

> Hi Jeff,
>
> I'm not aware of such an error-app-tag.   I'm doubtful any such   
> support to exists as the official stance is that YANG modules are   
> forever backwards compatible (sans deviations).
If errors occur in the case you described, Kent, I would expect the  
base NETCONF protocol to raise them.
>
> Kent
>
>
> On 7/11/18, 5:58 PM, "Jeffrey Ladouceur (jladouce)"   
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Kent,
>
The name of that checksum is 'module-set-id'  
(https://tools.ietf.org/html/rfc7895#section-2.1.1). For example, this  
request,

<nc:rpc message-id="urn:uuid:11e17c21-1157-4d68-981f-5a3367a38ed0"  
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
   <nc:get>
     <nc:filter select="//module-set-id" type="xpath"/>
   </nc:get>
</nc:rpc>

Gives back,

<rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"  
message-id="urn:uuid:11e17c21-1157-4d68-981f-5a3367a38ed0"  
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <data>
     <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
       <module-set-id>326a180da22645fc532760d9d068e187</module-set-id>
     </modules-state>
   </data>
</rpc-reply>

>
> I?m also trying to determine if there was acceptance with regards to  
>  returning an error app tag of ?capabilities-changed? when a client   
> sends an RPC which could potentially no longer work as expected.
>
> Regards,
> Jeff
>
>
>
> Both RFC 7895 and rfc7895bis (almost RFC 8407) define a checksum a   
> client can poll, as well as a notification a client can receive, to   
> determine when a server's module set has changed.
>
> Kent
>
>
> On 7/11/18, 5:34 PM, "Netconf on behalf of Jeffrey Ladouceur   
> (jladouce)"   
> <[email-masked]<mailto:[email-masked]> on behalf  
>  of   
> jladouce=[email-masked]<mailto:jladouce=[email-masked]>>   
> wrote:
>
> Hello netconf experts,
>
> I?m trying to determine if there was closure on the topic of dynamic  
>  model changes and the impact on any connected netconf clients.
>

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

---

From: Kent Watsen <[email-masked]>
Date: Sat, 14 Jul 2018 20:27:36 +0000

> If errors occur in the case you described, Kent, I would expect the base NETCONF protocol to raise them.

I don’t believe capabilities changing is an error.  The NC/RC protocols do “raise” the event, in the form of a notification.  This seems better than waiting for the client to send an RPC. Agreed?

Kent

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Sun, 15 Jul 2018 00:48:47 +0200

Quoting Kent Watsen <[email-masked]>:

> I don’t believe capabilities changing is an error.  The NC/RC   
> protocols do “raise” the event, in the form of a notification.  This  
>  seems better than waiting for the client to send an RPC. Agreed?
>
Totally agreed.

I am wondering; what if, along with a checksum notification change,  
the servers send also a diff notification change?

It would state which module have changed; and, within each module,  
which list, container or RPC does the change impact.

Ariel