Subject: [netmod] ietf-subscribed-notifications RPC modify-subscription

From: Michal Vaško <[email-masked]>
Date: Tue, 03 Aug 2021 15:01:10 +0200

Hi,

it seems the "modify-subscription" RPC [1] includes a mandatory choice "target" [2]. In effect, it is not possible to modify a subscription for it to be without a filter. I do not understand the reason for this, is it intentional or an error in the module?

Regards,
Michal

[1] https://www.rfc-editor.org/rfc/rfc8639#page-53
[2] https://www.rfc-editor.org/rfc/rfc8639#page-48

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 3 Aug 2021 10:13:51 -0700

[Cross posting to netconf]

> On Aug 3, 2021, at 6:01 AM, Michal Vaško <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
[email-masked]

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 3 Aug 2021 18:21:15 +0000

Hi,
When you modify the subscription, you need to specify the subscription parameters that you want to modify the subscription to - i.e.  the subscription parameters that you want to be in effect after modifying the subscription. If you want nothing to be filtered, just specify a "null" filter.
--- Alex

From: netmod <[email-masked]> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, August 3, 2021 10:14 AM
To: Netconf <[email-masked]>
Cc: netmod <[email-masked]>
Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscription

On Aug 3, 2021, at 6:01 AM, Michal Vaško <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,
Michal

[1] https://www.rfc-editor.org/rfc/rfc8639#page-53<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-53&data=04%7C01%7Calex%40futurewei.com%7C5f2a3c1598c74c1bdd1d08d956a21b51%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636076509385451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2F2xsGxFUIAYKdsMbrrUYCsy18xFQcAZAbCRlKQC5icA%3D&reserved=0>
[2] https://www.rfc-editor.org/rfc/rfc8639#page-48<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-48&data=04%7C01%7Calex%40futurewei.com%7C5f2a3c1598c74c1bdd1d08d956a21b51%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636076509385451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NU6F6s7fz4ph3h7Mqn3rLOcRDjaPEemMDBZJ0EqhEMw%3D&reserved=0>

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

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 3 Aug 2021 18:45:22 +0000

I am just rereading this (sorry, it's been a while since we wrote this).

When you look at the modify-subscription RPC, the "case stream" itself is optional, even if the choice "target" is mandatory.  So, it is in fact optional to include, no need to specify a null filter.  (However, when present, then parameters of the individual choices need to be present as well.)  In effect, you have a mandatory choice, but can select a case whose nodes are optional.  This is depicted in the Tree Diagram here: RFC 8639: Subscription to YANG Notifications (rfc-editor.org)<https://www.rfc-editor.org/rfc/rfc8639#page-16>

What may also be confusing at first is the fact that the choice "target" itself has "stream" as the single case (in RFC 8639).  So, why put a choice there in the first place? The reason why it is there is so that it can be augmented, and RFC 8641 specifies a second case, namely "datastore".
--- Alex

From: netmod <[email-masked]> On Behalf Of Alexander Clemm
Sent: Tuesday, August 3, 2021 11:21 AM
To: Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>
Cc: netmod <[email-masked]>
Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscription

Hi,

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, August 3, 2021 10:14 AM
To: Netconf <[email-masked]<mailto:[email-masked]>>
Cc: netmod <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscription

Hi,

Regards,
Michal

[1] https://www.rfc-editor.org/rfc/rfc8639#page-53<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-53&data=04%7C01%7Calex%40futurewei.com%7Ccbb0046e0a654512c58b08d956ab8596%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636116962301470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PmSz%2FtI%2FjkbFYDu0xB%2BOuXyMoYGdwdeNNLZnP%2FEcJrY%3D&reserved=0>
[2] https://www.rfc-editor.org/rfc/rfc8639#page-48<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-48&data=04%7C01%7Calex%40futurewei.com%7Ccbb0046e0a654512c58b08d956ab8596%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636116962311427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y2%2Bl02Gft87VlpN60LHWyrECFro2o21c%2FCIWSCnR4qw%3D&reserved=0>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=04%7C01%7Calex%40futurewei.com%7Ccbb0046e0a654512c58b08d956ab8596%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636116962311427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nwF%2BFtX2xAQmMO2KLolx7g8wQvfq5XGBsnSUGR2lCdU%3D&reserved=0>

Mahesh Jethanandani

---

From: Michal Vaško <[email-masked]>
Date: Wed, 04 Aug 2021 08:16:42 +0200

Hi Alex,

thanks for the reply and I see that I should have included more details. I understand the design (but it was confusing at first) in general because we have implemented YANG Push as well. However, I do not think

> you have a mandatory choice, but can select a case whose nodes are optional

applies. YANG 1.1 clearly defines [1] that some data nodes must exist in a mandatory choice. In this case it can be "stream-filter-name", "stream-subtree-filter", or "stream-xpath-filter" (clearly seen from the tree snippet you referenced) but I think it should be allowed to not include any of these. Please, provide a valid example of "modify-subscription" invocation that uses no filter, I could not come up with any.

In my opinion, there should be a refine on the "subscription-policy-modifiable" grouping in this case and change the mandatory to "false". Provided that it should not be allowed to change the stream of a subscription, which I guess it should not.

Regards,
Michal

[1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.9.4

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 4 Aug 2021 17:17:14 +0000

Hi Michal,

I think in part there is a YANG question here - can you define a mandatory choice, for which you have multiple cases, each of which (or even, just one of which) contains only nodes that are optional - which allows for the scenario that despite a mandatory choice, there are no data nodes from that choice included.  I think the answer here is yes. 

As for the use of this in modify-subscription, one question is why you would invoke this in the first place if you didn't want to modify something - so generally you would include a data node anyway.  One possibility to do this without changing the filter would be if you wanted to simply change the stop time, which is outside the target choice. Now, could we have made  a different design choice to make the target choice optional? Possibly, but in the end I don't think it matters as at the end of the day you can make the same modifications.  (Or is there something that you think this does not allow you to do, which it should be able to?)  So, I do not think this constitutes an error in the module, but a design choice that IMHO at this point should simply be accepted.  

Kind regards
-- Alex

-----Original Message-----
From: Michal Vaško <[email-masked]> 
Sent: Tuesday, August 3, 2021 11:17 PM
To: Alexander Clemm <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>; netmod <[email-masked]>
Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC modify-subscription

Hi Alex,

Regards,
Michal

[1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7950%23section-7.9.4&amp;data=04%7C01%7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=JNWOC8ym9j%2FNJ90oSRNyHCMSdEv%2FoLDru%2FRnsUozFGo%3D&amp;reserved=0

> When you look at the modify-subscription RPC, the "case stream" itself 
> is optional, even if the choice "target" is mandatory.  So, it is in 
> fact optional to include, no need to specify a null filter.  (However, 
> when present, then parameters of the individual choices need to be 
> present as well.)  In effect, you have a mandatory choice, but can 
> select a case whose nodes are optional.  This is depicted in the Tree 
> Diagram here: RFC 8639: Subscription to YANG Notifications 
> (rfc-editor.org)<https://nam11.safelinks.protection.outlook.com/?url=h
> ttps%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-16&amp;data=04%
> 7C01%7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8
> ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C1000&amp;sdata=SVPLR4GRtZC6U%2FaJu5c0Yf9jhRjHocOhtRp7Mtzt6tM
> %3D&amp;reserved=0>
> 
> [1] 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Frfc%2Frfc8639%23page-53&amp;data=04%7C01%7Calex%40fut
> urewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> p;sdata=Af%2FoGGiRESrrd4PzdNp5PvII4%2BQ54rwToLe1%2FrvJH%2BE%3D&amp;res
> erved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2
> F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-53&amp;data=04%7C01%7Cal
> ex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240
> 189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C1000&amp;sdata=Af%2FoGGiRESrrd4PzdNp5PvII4%2BQ54rwToLe1%2FrvJH%2BE%3D
> &amp;reserved=0> [2] 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Frfc%2Frfc8639%23page-48&amp;data=04%7C01%7Calex%40fut
> urewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> p;sdata=psIuBfJ%2BIoKGcky%2F8LJZmK1MtKhaUPynUtO1Y7vODdk%3D&amp;reserve
> d=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-editor.org%2Frfc%2Frfc8639%23page-48&amp;data=04%7C01%7Calex%4
> 0futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c
> 753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&amp;sdata=psIuBfJ%2BIoKGcky%2F8LJZmK1MtKhaUPynUtO1Y7vODdk%3D&amp;res
> erved=0>
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;data=04%7C01%7Calex%40futur
> ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d
> 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
> sdata=5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&amp;reserved=0<
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;data=04%7C01%7Calex%40futur
> ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d
> 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
> sdata=5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&amp;reserved=0>
> 
> Mahesh Jethanandani

---

From: Michal Vaško <[email-masked]>
Date: Thu, 05 Aug 2021 10:11:02 +0200

Hi Alex,
 
> I think in part there is a YANG question here - can you define a mandatory choice, for which you have multiple cases, each of which (or even, just one of which) contains only nodes that are optiona…

Per the reference to the YANG 1.1 specification I have included in my last email I am quite certain the answer is no, you cannot have a mandatory choice without any data nodes. That is exactly what is written in the RFC:

If  "mandatory" is "true", at least one node from exactly one of the
choice's case branches MUST exist.

> As for the use of this in modify-subscription, one question is why you would invoke this in the first place if you didn't want to modify something - so generally you would include a data node anyway.  One possibility to do this without changing the filter would be if you wanted to simply change the stop time, which is outside the target choice.

Yes, that is exactly the use-case. Are you saying changing the stop-time of a subscription without a filter is not supported?

> Now, could we have made  a different design choice to make the target choice optional? Possibly, but in the end I don't think it matters as at the end of the day you can make the same modifications.  (Or is there something that you think this does not allow you to do, which it should be able to?)

See my previous comment.

> So, I do not think this constitutes an error in the module, but a design choice that IMHO at this point should simply be accepted. 

Not sure why I am the first to bring this up, but I do think the design includes an error or is simply based on wrong YANG-related assumptions.

Regards,
Michal