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

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jan 2015 15:33:43 +0100

The 2014-12-03 virtual interim meeting proposal is to adopt Y16-03.
Please speak up by Wednesday 2015-01-14 if you disagree with this
proposal.

For more details, see the issues list and the virtual interim meeting
minutes available here:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/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/>

---

From: [email-masked]
Date: Thu, 8 Jan 2015 09:08:00 +0800

Hi,

        Why not use draft-frank-netconf-conformanc-00 ? It's very similar 
with Y16-03.

        http://datatracker.ietf.org/doc/draft-frank-netconf-conformance/

Frank Feng   冯冲
BN Product Team
BN产品团队

Add: ZTE Corporation, 50 Software Avenue, YuHuaTai District, Nanjing, P.R. 
China,210012
南京市雨花台区软件大道50号中兴通讯
Mp:+86-18913852612
E-mail: [email-masked]

Juergen Schoenwaelder <[email-masked]> 
发件人:  "netmod" <[email-masked]>
2015-01-07 22:33
请答复 给
Juergen Schoenwaelder <[email-masked]>

收件人
[email-masked], 
抄送

主题
[netmod] VRFY :Y16: module advertisement optimization

/js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jan 2015 09:13:34 +0100

>         http://datatracker.ietf.org/doc/draft-frank-netconf-conformance/

No, this I-D is similar to Y16-02. During the discussions, we observed
that it is not necessary to introduce a new RPC to retrieve the data -
the standard NETCONF/RESTCONF operations are good enough to retrieve
the data. Hence the motion to adopt Y16-03.

/js

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Fri, 9 Jan 2015 21:01:36 +0000

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>.

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.

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, January 07, 2015 9:34 AM
To: [email-masked]
Subject: [netmod] VRFY :Y16: module advertisement optimization

The 2014-12-03 virtual interim meeting proposal is to adopt Y16-03.
Please speak up by Wednesday 2015-01-14 if you disagree with this proposal.

For more details, see the issues list and the virtual interim meeting minutes available here:

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Jan 2015 13:45:43 +0100

> 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 ser…

There is netconf-capability-change defined in RFC 6470.

/js

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Mon, 12 Jan 2015 14:40:01 +0000

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 ?

Jason

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, January 12, 2015 7:46 AM
To: Sterne, Jason (Jason)
Cc: [email-masked]
Subject: Re: [netmod] VRFY :Y16: module advertisement optimization

This makes sense to me.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Jan 2015 07:15:47 -0800

> 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…

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