Re: [netconf] push-update and push-change-update w/o mandatory id in ietf-yang-push

["Eric Voit (evoit)" <[e-mail]>]

> From: Alexander Clemm, November 28, 2022 5:56 PM
> 
> Hi Jason,
> 
> OK.  So, to Jernej's original question, I do not recall and am no longer
sure of the
> reasons why the subscription-ID shows as optional as opposed to mandatory
in
> the update notifications.  I did mention the 5277 discussion, as it did
factor into
> the discussion at the time regarding push-update notifications to be sent
per
> RPC 5277.  Looking at the archive, subscription-ID was mandatory until
rev-09
> and became optional on -10.

I believe I remember why.

At the time we had draft-ietf-netconf-notification-messages in flight.  This
draft was able to bundle many notifications into a single grouping.  In
fact, it was possible to have a single notification which could be
associated with multiple subscriptions.

By leaving subscription-id as optional within YANG Push, it wouldn't need to
be redundantly added within the notification-contents of this more robust
structure.

Eric

> --- Alex
> 
> -----Original Message-----
> From: Jason Sterne (Nokia) <[e-mail]>
> Sent: Monday, November 28, 2022 2:29 PM
> To: Alexander Clemm <[e-mail]>; Jernej Tuljak <jernej.tuljak@mg-
> soft.si>; Netconf <[e-mail]>
> Subject: RE: [netconf] push-update and push-change-update w/o mandatory id
> in ietf-yang-push
> 
> OK thx Alex.
> 
> Then I'm not sure how 5277 factors into this discussion (since 5277 format
is
> always used for push updates). E.g. what this might be about:
> 
> > > I do remember
> > > that there was a distinction that had to be made in case when
> > > notification encoding per RFC 5277 was used and I suspect this will
> > > be related to that case.
> 
> Jason
> > -----Original Message-----
> > From: Alexander Clemm <[e-mail]>
> > Sent: Monday, November 28, 2022 3:13 PM
> > To: Jason Sterne (Nokia) <[e-mail]>; Jernej Tuljak
> > <[e-mail]>; Netconf <[e-mail]>
> > Subject: RE: [netconf] push-update and push-change-update w/o
> > mandatory id in ietf-yang-push
> >
> > Hi Jason,
> > No, indeed, the intention was always to use RFC 8641 with the RFC 8639
> > subscription mechanism - i.e., use <establish-subscription>, not
> > <create-
> > subscription>.  This is clearly explained in section 3.8 of RFC 8641.
> > --- Alex
> >
> > -----Original Message-----
> > From: Jason Sterne (Nokia) <[e-mail]>
> > Sent: Thursday, November 24, 2022 4:13 PM
> > To: Alexander Clemm <[e-mail]>; Jernej Tuljak
> > <[e-mail]>; Netconf <[e-mail]>
> > Subject: RE: [netconf] push-update and push-change-update w/o
> > mandatory id in ietf-yang-push
> >
> > Hi Alex,
> >
> > You mentioned 5277 below.
> >
> > I believe YANG PUSH just uses the 5277 notification
model/format/encoding.
> > As per section 1.4 of RFC 8639:
> >     The <notification> message of [RFC5277], Section 4 is used.
> >
> > Maybe you were thinking of the fact that RFC 8639
> > <establish-subscription> returns an id while the RFC 5277 <create-
> subscription> doesn't return an id.
> >
> > But can <create-subscription> be used with YANG PUSH? In other words,
> > is there a way to subscribe and receive <push-update> notifications
> > without using the RFC 8639 subscription mechanisms (which return an ID)
?
> >
> > Jason
> >
> > > -----Original Message-----
> > > From: netconf <[e-mail]> On Behalf Of Alexander
> > Clemm
> > > Sent: Friday, November 18, 2022 12:13 PM
> > > To: Jernej Tuljak <[e-mail]>; Netconf
> > > <[e-mail]>
> > > Subject: Re: [netconf] push-update and push-change-update w/o
> > > mandatory id in ietf-yang-push
> > >
> > > You are correct in that one would generally expect the parameter to
> > > be provided as part of a push-update notification, and I assume that
> > > in in general this will indeed be the case.  I don't recall the
> > > actual reason for that one; I checked older version and it was
> > > indeed mandatory at one point, to revert to being optional.  I do
> > > remember that there was a distinction that had to be made in case
> > > when notification encoding per RFC 5277 was used and I suspect this
> > > will be
> > related to that case.
> > >
> > > I am not sure I understand your second comment; the id clearly
> > > refers to the subscription.
> > >
> > > --- Alex
> > >
> > > -----Original Message-----
> > > From: netconf <[e-mail]> On Behalf Of Jernej Tuljak
> > > Sent: Friday, November 18, 2022 12:39 AM
> > > To: Netconf <[e-mail]>
> > > Subject: [netconf] push-update and push-change-update w/o mandatory
> > id
> > > in ietf-yang-push
> > >
> > > Hi,
> > >
> > > why is the "id" leaf not mandatory in the YANG model for these?
> > >
> > >          notifications:
> > >            +---n push-update
> > >            |  +--ro id?                   sn:subscription-id
> > >            |  +--ro datastore-contents?   <anydata>
> > >            |  +--ro incomplete-update?    empty
> > >            +---n push-change-update {on-change}?
> > >               +--ro id?                   sn:subscription-id
> > >               +--ro datastore-changes
> > >               |  +--ro yang-patch
> > >               |     +--ro patch-id    string
> > >               |     +--ro comment?    string
> > >               |     +--ro edit* [edit-id]
> > >               |        +--ro edit-id      string
> > >               |        +--ro operation    enumeration
> > >               |        +--ro target       target-resource-offset
> > >               |        +--ro point?       target-resource-offset
> > >               |        +--ro where?       enumeration
> > >               |        +--ro value?       <anydata>
> > >               +--ro incomplete-update?    empty
> > >
> > >
> > > RFC8641, Section 4.3.2.:
> > >
> > >     Along with the subscribed content, there are other objects that
> > > might
> > >     be part of a "push-update" or "push-change-update" notification.
> > >
> > >     o  An "id" (that identifies the subscription).  This object MUST
> > > be
> > >        transported along with the subscribed contents.  It allows a
> > >        receiver to determine which subscription resulted in a
> > > particular
> > >        update record.
> > >
> > >
> > > Is  [an "id"] referring to [the "id" leaf] in the model? The text
> > > seems oddly unspecific.
> > >
> > > Jernej
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > [e-mail]
> > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > >
> > w.ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=05%7C01%7Calex%
> > >
> > 40futurewei.com%7Cc1b89d5b08b041d8b29108dac9406021%7C0fee8ff2a3b2
> > >
> >
> 40189c753a1d5591fedc%7C1%7C0%7C638043575599628089%7CUnknown%7C
> > >
> > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > >
> > CJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=hf08f54i%2Bq1qF8b2hJN
> > > hZsZzZx8I%2B74fkjImiTHi2F8%3D&amp;reserved=0
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > [e-mail]
> > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.
> > >
> > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=05%7C01%7Calex%40
> > futu
> > >
> >
> rewei.com%7C0bacd90b20fe444e2d7708dace79e1e4%7C0fee8ff2a3b240189c
> > 753a1
> > >
> > d5591fedc%7C1%7C1%7C638049320121309254%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjo
> > >
> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C20
> > 00%7C%
> > >
> > 7C%7C&amp;sdata=%2BQEuvkC1Ke4OaJqgf7%2BbE4kv%2FZxx2KdDp8vNdh
> > Q%2B2LM%3D
> > > &amp;reserved=0
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf