Re: [netconf] leafrefed data item in YANG Push

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: Eric Voit (evoit) [mailto:[e-mail]] 
发送时间: 2019年12月19日 6:35
收件人: Qin Wu <[e-mail]>; Martin Bjorklund <[e-mail]>
抄送: [e-mail]
主题: RE: [netconf] leafrefed data item in YANG Push

> From: netconf <[e-mail]> On Behalf Of Qin Wu
> Sent: Tuesday, December 17, 2019 8:35 PM
> To: Martin Bjorklund <[e-mail]>
> Cc: [e-mail]
> 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

[Qin]: This reference is one I visited before, thanks Eric, you address my comment.

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

> -Qin
> -----邮件原件-----
> 发件人: Martin Bjorklund [mailto:[e-mail]]
> 发送时间: 2019年12月16日 16:33
> 收件人: Qin Wu <[e-mail]>
> 抄送: [e-mail]; [e-mail]
> 主题: Re: [netconf] leafrefed data item in YANG Push
> 
> Hi,
> 
> Qin Wu <[e-mail]> 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:[e-mail]]
> > 发送时间: 2019年12月14日 3:20
> > 收件人: Qin Wu <[e-mail]>; [e-mail]
> > 主题: 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
> > <[e-mail]<mailto:[e-mail]>> On Behalf
> > Of Qin Wu
> > Sent: Thursday, December 12, 2019 11:09 PM
> > To: [e-mail]<mailto:[e-mail]>
> > 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
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf