Re: [netmod] VRFY :Y16: module advertisement optimization

On Mon, Jan 12, 2015 at 6:40 AM, Sterne, Jason (Jason)
<jason.sterne@alcatel-lucent.com> wrote:
> Thanks.
>
> We could consider referencing that RFC 6470 netconf-capability-change in whatever text we use for this id-of-module-set concept and discussing interactions with it.
>
> I suppose we don't really want to go back and change the netconf-capability-change in RFC6470 to include the id-of-module-set so maybe we recommend that the client do a <get-yang-module-capabilties> request if a server sends a netconf-capability-change notification ?
>

I have some concerns with Y19.
The netconf-capability-change notification is for a change to any NETCONF
capability, not just YANG module capabilities.

The module-set-id could augment the existing notification if needed.

Seems like there are 2 options:

1) define a new notification just for YANG module-set-id changes
    The netconf-capability-change will also be generated because it
    is a NETCONF capability change

 2) augment netconf-capability-change with the module-set-id and
      the client needs to check (maybe a NETCONF capability like :candidate
      changed so the module-set-id will not change)

> Jason

Andy

>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Monday, January 12, 2015 7:46 AM
> To: Sterne, Jason (Jason)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] VRFY :Y16: module advertisement optimization
>
> On Fri, Jan 09, 2015 at 09:01:36PM +0000, Sterne, Jason (Jason) wrote:
>> Is there a potential race condition between receiving the <id-of-module-set> and the results of the <get-yang-module-capabilties> ?
>>
>> I suppose this is pretty unlikely in most servers but if any future servers have capabilities that can change somewhat dynamically then we may want to include the <id-of-module-set> in the response to the <get-yang-module-capabilties> request (to bind the capabilities to a signature) so the client can do a double check that they are still working with the same <id-of-module-set>.
>>
>> The hello should still include the <id-of-module-set>.
>
> This makes sense to me.
>
>> On another note -> is there any need out there to allow a server to advertise (async) to a client that it's capabilities have changed ?   I could imagine, for example, a system that supports in service upgrades (and manages to keep the NETCONF session going during the upgrade) could suddenly have some different capabilities.
>>
>
> There is netconf-capability-change defined in RFC 6470.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod