Subject: Re: [netconf] leafrefed data item in YANG Push

From: Qin Wu <[email-masked]>
Date: Wed, 18 Dec 2019 01:34:39 +0000

Thanks Martin for clarification, I understand the dependency between subscription is different from dependency between two leafs.
But still not clear what is the real case for dependency? Should parent subscription and child subscription point to same leafs in the 
same modules requested by the same subscriber?
If not, how a set of data defined by parent subscription and child subscription are put together? Is this related to object correlation?

-Qin
-----邮件原件-----
发件人: Martin Bjorklund [mailto:[email-masked]] 
发送时间: 2019年12月16日 16:33
收件人: Qin Wu <[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Re: [netconf] leafrefed data item in YANG Push

Hi,

Qin Wu <[email-masked]> wrote:
> Thanks Jason for clarification, 2 leafs associated with each other via 
> leafref can be defined in the same module, can be defined in two 
> separate modules (see example module below), I am wondering whether 
> these two cases are treated by the server in the same way.

Yes they are, in the sense that a leafref is not treated different than e.g. a string by the  YANG Push server.

> RFC8639 provides a dependency parameter to describe the relationship 
> between two subscriptions, I am wondering whether this dependency 
> parameter is designed to address the case where two leafs are 
> associated with each other via leafref in two different modules.
>
> Take the below modules as an example,
> We may have two subscriptions, one subscription A is used to 
> subscribed to leaf aa in module foo, the other subscription B is used 
> to subscribed to leaf cc and bb in module bar. So the subscription A 
> will use dependency parameter to indicate leaf bb is associated with 
> leaf aa in subscription B, right?

No the dependency parameter is not used by a subscriber to "indicate"
(to whom?) that two leafs are associated.

> If the answer is no, what is the real case for dependency parameter 
> defined in RFC8639?

From RFC 8639, section 2.3:

   If a subscription has the "dependency" parameter set, then any
   buffered notification messages containing event records selected by
   the parent subscription MUST be dequeued prior to the notification
   messages of the dependent subscription.

It it used to control the order in which the notifications are sent.

/martin

> 
> -Qin
> 发件人: Sterne, Jason (Nokia - CA/Ottawa) [mailto:[email-masked]]
> 发送时间: 2019年12月14日 3:20
> 收件人: Qin Wu <[email-masked]>; [email-masked]
> 主题: RE: leafrefed data item in YANG Push
> 
> Hi Qin,
> 
> For subscriptions, I don't think it matters if 2 leafs are associated 
> with each other via a leafref.  When you subscribe to each of those 
> leafs, it is just like subscribing to any other 2 leafs (that aren't 
> associated with eachother).
> 
> About the 'dangling reference': that should be accepted into the 
> running datastore. It would fail validation. So it can only exist in 
> the candidate.
> 
> Jason
> 
> From: netconf
> <[email-masked]<mailto:[email-masked]>> On Behalf 
> Of Qin Wu
> Sent: Thursday, December 12, 2019 11:09 PM
> To: [email-masked]<mailto:[email-masked]>
> Subject: [netconf] leafrefed data item in YANG Push
> 
> Hello:
> Can I subscribe to specific data item that refer to data item in 
> another YANG module with other data item in the same subscription?
> Module bar {
> import foo {prefix ex;}
>      leaf cc{type int8;}
>      leaf bb {
>        type leafref {
>          path "../ex:aa";
>        }
>      }
> }
> 
> Module foo {
>      leaf aa {
>        type int8;
>      }
> }
> In addition, If there is dangling reference, e.g., leaf bb refer to 
> leaf aa which doesn’t exist, how this failure is handled by the server 
> and exposed to the client?
> 
> -Qin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 18 Dec 2019 22:34:40 +0000

> From: netconf <[email-masked]> On Behalf Of Qin Wu
> Sent: Tuesday, December 17, 2019 8:35 PM
> To: Martin Bjorklund <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netconf] leafrefed data item in YANG Push
> 
> Thanks Martin for clarification, I understand the dependency between
> subscription is different from dependency between two leafs.
> But still not clear what is the real case for dependency? Should parent
> subscription and child subscription point to same leafs in the same modules
> requested by the same subscriber?
> If not, how a set of data defined by parent subscription and child
> subscription are put together? Is this related to object correlation?

Hi Qin,

I know you are aware of this, but I wanted to be sure people on the thread follow.  "/subscriptions/subscription/dependency" is for figuring out which from a set of buffered event records should be transmitted first.   This could be a fairly common problem in some deployment scenarios which need to prevent head-of-line blocking.  A good resource to understand the behavior of dependency is to look at HTTP2 stream dependency:  https://tools.ietf.org/html/rfc7540#section-5.3.1

Right now anything related to "/subscriptions/subscription/dependency"  is independent from inter-subscription correlation and pruning of any redundancy in pushed objects spanning multiple subscriptions.

Eric

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