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 protected]> Sent: Tuesday, August 3, 2021 11:17 PM To: Alexander Clemm <[email protected]> Cc: Mahesh Jethanandani <[email protected]>; Netconf <[email protected]>; netmod <[email protected]> Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC modify-subscription 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7950%23section-7.9.4&data=04%7C01%7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JNWOC8ym9j%2FNJ90oSRNyHCMSdEv%2FoLDru%2FRnsUozFGo%3D&reserved=0 > 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://nam11.safelinks.protection.outlook.com/?url=h > ttps%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-16&data=04% > 7C01%7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8 > ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C1000&sdata=SVPLR4GRtZC6U%2FaJu5c0Yf9jhRjHocOhtRp7Mtzt6tM > %3D&reserved=0> > > 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 protected]> On Behalf Of Alexander Clemm > Sent: Tuesday, August 3, 2021 11:21 AM > To: Mahesh Jethanandani <[email protected]>; Netconf > <[email protected]> > Cc: netmod <[email protected]> > Subject: Re: [netmod] ietf-subscribed-notifications RPC > modify-subscription > > 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 protected]<mailto:[email protected]>> > On Behalf Of Mahesh Jethanandani > Sent: Tuesday, August 3, 2021 10:14 AM > To: Netconf <[email protected]<mailto:[email protected]>> > Cc: netmod <[email protected]<mailto:[email protected]>> > Subject: Re: [netmod] ietf-subscribed-notifications RPC > modify-subscription > > [Cross posting to netconf] > > On Aug 3, 2021, at 6:01 AM, Michal Vaško > <[email protected]<mailto:[email protected]>> wrote: > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > rfc-editor.org%2Frfc%2Frfc8639%23page-53&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&res > erved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2 > F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-53&data=04%7C01%7Cal > ex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C1000&sdata=Af%2FoGGiRESrrd4PzdNp5PvII4%2BQ54rwToLe1%2FrvJH%2BE%3D > &reserved=0> [2] > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > rfc-editor.org%2Frfc%2Frfc8639%23page-48&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&reserve > d=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Frfc%2Frfc8639%23page-48&data=04%7C01%7Calex%4 > 0futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c > 753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 > 0&sdata=psIuBfJ%2BIoKGcky%2F8LJZmK1MtKhaUPynUtO1Y7vODdk%3D&res > erved=0> > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[email protected]> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=04%7C01%7Calex%40futur > ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d > 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > sdata=5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&reserved=0< > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=04%7C01%7Calex%40futur > ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d > 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > sdata=5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&reserved=0> > > Mahesh Jethanandani > [email protected]<mailto:[email protected]> > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
