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

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
 
> 
> 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&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
> 
> > 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&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>
> > 
> > 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&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>
> > 
> > _______________________________________________
> > netmod mailing list
> > [email protected]<mailto:[email protected]>
> > 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
> > [email protected]<mailto:[email protected]>
> > 
> > 
> > 
> >

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

Reply via email to