Subject: [Netconf] Feedback on subscribed-notifications and yang-push

From: "Elbokl, Walid (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 16 Nov 2017 03:43:26 +0000

Hi All,

I have reviewed:
-       draft-ietf-netconf-subscribed-notifications-07
-       draft-ietf-netconf-yang-push-11
and have the following mix of comments/questions:

1.      subscribed-notifications draft: What is the background/reason for not having dscp with notifications (i.e. same as with yang push)?
2.      subscribed-notifications draft: In figure 1/page 8, it implies that a modification to a suspended subscription would get the subscription to be active first before the server decides to keep it active or suspend it again. I would have thought a modification can be considered by the server while the subscription is still suspended then it could either become active or stay suspended
3.      subscribed-notifications draft: Fully agree with having replay with notifications only and not yang-push
4.      subscribed-notifications draft: In "modify-subscription", though a subscriber-id is writeable (i.e. to be able to specify which subscription to modify) but the server should not allow changing it on a suspended/active subscription
5.      subscribed-notifications draft: In "modify-subscription", why not modify "replay-start-time"? i.e. purge whole/part of the replay buffer
      Use case: purging whole/part of the replay buffer in scenarios where it may have been a reason to suspend a subscription
      The argument that the operator can cancel the subscription and re-establish another one applies to modifying everything and would mean no need for modify-subscription from the first place. Also, an operator may consider purging part of the buffer and not all.
6.      Yang push draft: page 11/Figure 1, </push-change-update> should be </push-update>
7.      Yang push draft: section 7:
   If the access control permissions on subscribed YANG nodes change
   during the lifecycle of a subscription, a publisher MUST either
   transparently conform to the new access control permissions, or must
   terminate or restart the subscriptions so that new access control
   permissions are re-established.

      The draft allows authorization either at subscription time or at send time. IMO, authorization @ send time should be the way to go.
Regards,
Walid

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 16 Nov 2017 12:38:07 +0800

Hello,

I have been part of the design team and I am mostly happy with the 
results. I would like to see the drafts progress as soon as possible.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: "Elbokl, Walid (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 16 Nov 2017 06:02:48 +0000

Just to clarify, I do think that the drafts are ready to go to last call. Any questions/concerns I listed below can be addressed then.

Regards,
Walid

_____________________________________________
From: Elbokl, Walid (Nokia - CA/Ottawa)
Sent: Thursday, November 16, 2017 11:43 AM
To: [email-masked]' <[email-masked]>
Cc: 'Eric Voit (evoit)' <[email-masked]>; [email-masked]
Subject: Feedback on subscribed-notifications and yang-push

Hi All,

I have reviewed:

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 16 Nov 2017 06:47:16 +0000

Thanks for the comments on the two drafts Walid.  Thoughts in-line...

From: Elbokl, Walid, November 15, 2017 10:43 PM

Hi All,

I have reviewed:
*        draft-ietf-netconf-subscribed-notifications-07
*        draft-ietf-netconf-yang-push-11
and have the following mix of comments/questions:

1.      subscribed-notifications draft: What is the background/reason for not having dscp with notifications (i.e. same as with yang push)?
<eric> Current 5277 event streams haven't shown need for QoS.   So for simplicities sake, we bundled all QoS elements together in YANG push where we knew there was demonstrable need.
2.      subscribed-notifications draft: In figure 1/page 8, it implies that a modification to a suspended subscription would get the subscription to be active first before the server decides to keep it active or suspend it again. I would have thought a modification can be considered by the server while the subscription is still suspended then it could either become active or stay suspended
<evoit> The result is pretty much the same.  When the configuration change is made, an immediate attempt should be made apply this to all receivers (active and suspended).  This way allows for explicit kick-starting of receivers suspended, and another suspension despite the modification will be shown in the logs, or in an on-change subscription made on this subscription table itself.
3.      subscribed-notifications draft: Fully agree with having replay with notifications only and not yang-push
4.      subscribed-notifications draft: In "modify-subscription", though a subscriber-id is writeable (i.e. to be able to specify which subscription to modify) but the server should not allow changing it on a suspended/active subscription
<eric> I think this is a diagrammatic convention that all RPC input fields are writeable.  Certainly we don't want the behavior you describe.
5.      subscribed-notifications draft: In "modify-subscription", why not modify "replay-start-time"? i.e. purge whole/part of the replay buffer
Use case: purging whole/part of the replay buffer in scenarios where it may have been a reason to suspend a subscription
The argument that the operator can cancel the subscription and re-establish another one applies to modifying everything and would mean no need for modify-subscription from the first place. Also, an operator may consider purging part of the buffer and not all.
<Eric> This is possible to cover, but to me it seems a corner case to modify a replay in flight.  Deleting a subscription and restarting accomplishes the same.  Do other people have a desire to modify a replay in flight?
6.      Yang push draft: page 11/Figure 1, </push-change-update> should be </push-update>
<Eric> Good catch, thanks!
7.      Yang push draft: section 7:
If the access control permissions on subscribed YANG nodes change
during the lifecycle of a subscription, a publisher MUST either
transparently conform to the new access control permissions, or must
terminate or restart the subscriptions so that new access control
permissions are re-established.

<Eric> I agree, but Andy B. asked for this option as he didn't want to build the more complex send-time capability.  Considering he wrote much of NACM, I listened :-)

Eric
Regards,
Walid

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Nov 2017 03:20:28 -0500

Balazs and netconf:

I hoped to be at netconf and say this in person.  The design team allowed me
to be an I2RS WG chair observer and commenter.  Like Balazs, I'm happy with
the results.   It's running in code.  We're seeing it starting to go to
different types of boxes - security and routing as well as management.

Sue Hares 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Balazs Lengyel
Sent: Wednesday, November 15, 2017 11:38 PM
To: [email-masked]
Subject: Re: [Netconf] Feedback on subscribed-notifications and yang-push

Hello,

I have been part of the design team and I am mostly happy with the results.
I would like to see the drafts progress as soon as possible.

regards Balazs

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