Subject: [Netconf] Review of subscribed notifications draft

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 8 Nov 2017 07:10:41 +0530

I have reviewed -05 version of the subscribed notifications draft. I know the authors have published a more updated version. If the comments in this review have been addressed in the later version of the draft, authors can indicate it so.

As some reviewers have already indicated, the document is hard to read. It would help if the authors could work on sentence construction and consistency in usage of terms. The other, and this has been conveyed to the authors by the chairs is the desire to see draft-ietf-netconf-netconf-event-notifications and draft-ietf-netconf-restconf-notif be reviewed and published along with this draft. We think they make for a nice fit together.

Comments.

Section 1.3
Why is configured subscription optional but dynamic subscription is not? At least it does not say so for dynamic subscription.
"For connection less or stateless transport like HTTP,  … that will terminate dynamic subscriptions" - Do not understand this statement. When is this session terminated if it is connection less and/or stateless?
Configured subscriptions can be modified by any configuration client. Is it not the case that that subscription is controlled by user/NACM more than whether the client has the write permission? Same is true for dynamic subscription.
Is there a graceful termination of a dynamic subscription? Does not seem apparent reading the paragraph.
Section 2.1
Are there no notifications over RESTCONF? If so, why are they not mentioned over here. And are notifications always encoded using XML? There is a reference to other forms of encoding in Section 4.1, under Dynamic Subscriptions. If it is true for configured subscriptions also, could it be stated up front?
Are publisher and system the same entity? If not, what is the difference? If they are the same, can we be consistent in the nomenclature?
Doesn't NACM define notification permissions on the publisher? The receiver may not have permission for every event generated by the publisher.
Section 2.2
Isn't the definition of filter just that. Do not understand the implication of the definition of Event Filter and how it is different from other filters.
Section 2.3
What constitutes an "asserted subscription to be externally visible"?
If the state machine is from the perspective of the publisher, then can the publisher unilaterally "start" a subscription? Or is that it sits in init state, waiting for a subscription request to be received?
Can a receiver suspend subscription to an event stream?
Section 3
Note the recent discussion around size of the tree traversing multiple pages. In general if a tree diagram spans multiple pages, it loses its readability. Consider breaking up the tree into multiple parts, particularly rpc and notifications parts of the tree. An explanation at the top of each part of the tree will go a long way towards readability. 
What does it mean to have a “filter inline for each subscription”? Could it be that “Filters” are just pre-defined set of filters, while everything else is specified at the time of subscription?

Section 4
This section repeats the fact how subscriptions can be modified, deleted, killed using the session that was used to establish the subscription. What happens if the session itself goes away?

Section 4.1 
Isn’t replay subscription and notification a function of the capability of the publisher in how many historical events it can hold? Would it not be simpler for the publisher all the events it has in its history buffer and let the subscriber throw away whatever it is not interested in? What happens if the subscription time is older than the oldest event in the history buffer?

Section 4.2
Can we use “configured subscriptions” consistently, instead of sometimes saying “Subscriptions created by configuration”. The term “configured subscriptions” seems to be re-introduced in Section 5, when it is defined in Section 1.2. Suggest removing the section definition.
Also if configured subscriptions cannot be modified, which BTW is not obvious why, then it would help to say that the configured subscription needs to be terminated by <delete-subscription> (??), and a new subscription be created.

More later. Thanks.

Mahesh Jethanandani
[email-masked]

---

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

Hi Mahesh,

Thanks so much for the thorough review.   Thoughts in-line...

From: Mahesh Jethanandani, November 7, 2017 8:41 PM

<Eric> Have indicated this

<Eric> It is possible to complete the two drafts together.  And as lead author of draft-ietf-netconf-restconf-notif, I hoped this would be the case.  However there are two issues which make it non-optimal:

(a) There is a dependency of draft-ietf-netconf-restconf-notif on draft-ietf-netconf-notification-messages.   This dependency is that an ‘ok’ must be sent after subscription-started notification for a Configured subscription to signal readiness to receive on-way notification messages.  But which one-way notification encoding to use for a receiver?   If ‘ok’ indicates support for draft-ietf-netconf-notification-messages, everything is clean.  Otherwise alternate HTTP response codes needed to signal the receiver desired use of the existing 5277 one way notification encoding.  (Note: If we want to start playing with HTTP response codes, we likely can address this, and remove the dependency.  But such a solution is a hack as HTTP success response codes aren’t design for use an encoding selection mechanism.)

(b) Despite a year of requests at various IETFs, we have never been able to get assistance on GRPC’s intersection with RESTCONF.  And sadly it doesn’t seem like RESTCONF is not a clean match with GRPC.   Specifically GRPC desires the use of POST rather than the GET used by RESTCONF.    I hoping some more time might clear this logjam, and we will get some help.  Or perhaps GRPC will easily support GET.  But right now, nobody is saying this is a valid approach.

So based on these two issues, it seems to me cleaner to wait.  And as there are not deployments of the draft-ietf-netconf-restconf-notif draft yet, no implementers seem adversely impacted.

Comments.

Section 1.3

  *   Why is configured subscription optional but dynamic subscription is not? At least it does not say so for dynamic subscription.
<Eric> We haven’t heard from anyone who wants to do just configured subscriptions.  (This includes the RFC-7923 requirements.)   Based on this, it would make for more complexity to indicate the interplay of optional features across the model and draft.

  *   "For connection less or stateless transport like HTTP,  … that will terminate dynamic subscriptions" - Do not understand this statement. When is this session terminated if it is connection less and/or stateless?
A connectionless dynamic subscription is terminated when there is loss detected by the publisher of information being sent to the receiver.  This can be the loss of either notification messages or transport keep-alives.  Specifics of how this is done is within each connectionless transport draft.   See proposed text with yellow highlighting below...

  *   Configured subscriptions can be modified by any configuration client. Is it not the case that that subscription is controlled by user/NACM more than whether the client has the write permission? Same is true for dynamic subscription.
NACM is certainly a good way to go to meet the requirement.  The text intend to allow for implementations without NACM.   I saw the words “write permissions” as a more general term which is trying to cover any such case where a configuration system is trying to make changes to the configuration tree. Do you have an alternative for this general case?

  *   Is there a graceful termination of a dynamic subscription? Does not seem apparent reading the paragraph.

   o  The lifetime of a dynamic subscription is bounded by the transport session used to establish it.  For connection-oriented stateful transport like NETCONF, the loss of the transport session will result in the immediate termination of associated dynamic subscriptions.  For connectionless or stateless transports like HTTP, some loss of traffic must be detected before the dynamic subscription should be terminated.  Such loss of traffic can be detected in ways such as the lack of receipt TCP acknowledgement of a sequential set of notification messages, or the loss of transport keep-alives.

   o   The lifetime of a configured subscription is driven by relevant configuration being present on the running configuration.  This implies configured subscriptions persist across reboots, and persist even when transport is unavailable.

   o  Configured subscriptions can be modified or terminated by any configuration client with write permission on the configuration of the subscription.  Dynamic subscriptions can be modified or terminated via an RPC request made upon the original subscribing transport session.

Section 2.1

  *   Are there no notifications over RESTCONF? If so, why are they not mentioned over here. And are notifications always encoded using XML? There is a reference to other forms of encoding in Section 4.1, under Dynamic Subscriptions. If it is true for configured subscriptions also, could it be stated up front?
The NETCONF event stream is a legacy name from RFC-5277 which this draft adopted for continuity’s sake.   RESTCONF may also subscribe to this event stream.  Do you want me to say “The NETCONF event stream is wholly separate from the use of NETCONF as a transport”

  *   Are publisher and system the same entity? If not, what is the difference? If they are the same, can we be consistent in the nomenclature?
Will change “System” to “Publisher”.

  *   Doesn't NACM define notification permissions on the publisher? The receiver may not have permission for every event generated by the publisher.
By definition, subscription to a stream means access to all events on a stream.  This is identical to current 5277 behavior.
Section 2.2

  *   Isn't the definition of filter just that. Do not understand the implication of the definition of Event Filter and how it is different from other filters.
Significant updates to the definition of “Stream filter” based on Martin’s comments.  No longer do we try to have a generic filter definition which also covers elements of the Selection filter from yang-push.   Each stands on its own now (with its own entry in each respective drafts’ terminology table.)
Section 2.3

  *   What constitutes an "asserted subscription to be externally visible"?
A “establish-subscription” needs a subscription-id to be assigned before it appears in the operational yang-tree.  A failed “establish-subscription” is never instantiated in the yang model.  Likely this is obvious, as any failed RPC will not result in the creation of new objects.   And if you feel this is obvious, we can just delete the sentence.  But if you want to keep something we could morph the statement into the followng text to clarify:
And subscription state does not become exposed via the YANG model until the state machine first reaches the “active” state.

  *   If the state machine is from the perspective of the publisher, then can the publisher unilaterally "start" a subscription? Or is that it sits in init state, waiting for a subscription request to be received?
Based on Martin’s comments, the state machine for configured subscription now is more fully documented.  It covers this case.

  *   Can a receiver suspend subscription to an event stream?
No.   Current text says “There are no external controls over suspend and resume.”
Section 3

  *   Note the recent discussion around size of the tree traversing multiple pages. In general if a tree diagram spans multiple pages, it loses its readability. Consider breaking up the tree into multiple parts, particularly rpc and notifications parts of the tree. An explanation at the top of each part of the tree will go a long way towards readability.
I could pull the RPC and notification trees under each respective section within this document without this document’s size exploding.  And I  would accept with doing that.  However there would be implications for the yang-push document as the yang-push document does not have similar sections re-explaining each augmented RPC and Notification.  And therefore there is no easy way to partition that even larger yang-push tree into small portions.   If you want to go down this path, we should validate this broadly as I believe it detracts as a whole from yang-push.   My preference is still for the existing document structure because it allows easy comparison with the yang-push draft.
The final choice I don’t recommend is to do a similar tree partitioning for yang-push as well.  Such a partitioning would significantly increase the yang-push draft size and text redundancy.

  *   What does it mean to have a “filter inline for each subscription”? Could it be that “Filters” are just pre-defined set of filters, while everything else is specified at the time of subscription?
You are correct.   How about the text saying  “ alternative to defining the full filter within each subscription.”

Section 4

  *   This section repeats the fact how subscriptions can be modified, deleted, killed using the session that was used to establish the subscription.
Yes.   The reason is that only the kill RPC can reference a subscription created from a different session.   So we can’t generalize this once at the front of section 4.

  *   What happens if the session itself goes away?
In all cases, the loss of a session deletes the subscription.  But loss of session is means different things for connection-oriented (NETCONF) or connectionless (HTTP).  As a result the specifics are in the transport drafts, but the general behavior is in this document in section 1.3.

Section 4.1

  *   Isn’t replay subscription and notification a function of the capability of the publisher in how many historical events it can hold?
Yes

  *   Would it not be simpler for the publisher all the events it has in its history buffer and let the subscriber throw away whatever it is not interested in?
That would drive a different (and less capable) behavior than currently in 5277.  For example, a larger buffer would result in lots of objects which a subscriber doesn’t want.

  *   What happens if the subscription time is older than the oldest event in the history buffer?
This section is significantly updated based on Martin’s comments.  The enhancements includes enhanced definitions in the yang model showing why it is important for dynamic subscriptions to reject a subscription which is set for older than what is in the event buffer.  It also discusses how a configured subscription can buffer and replay events recorded during a boot sequence.

Section 4.2

  *   Can we use “configured subscriptions” consistently, instead of sometimes saying “Subscriptions created by configuration”. The term “configured subscriptions” seems to be re-introduced in Section 5, when it is defined in Section 1.2. Suggest removing the section definition.
Yes.   Will make the change in section 4.2 and 5.

  *   Also if configured subscriptions cannot be modified, which BTW is not obvious why,
If you allow configuration operations to modify behavior of a dynamic subscription, you get several consequences such as:
(a) the subscriber is no longer agreeing to what the subscription contract includes
(b) complexity: how will the receiver know the subscription has changes without also implementing the subscription-modified state change notification.   If seems simpler just to kill the subscription, and let the subscriber renegotiate the parameters new.

  *   then it would help to say that the configured subscription needs to be terminated by <delete-subscription> (??), and a new subscription be created.
I will add that.

Thanks again!
Eric

More later. Thanks.

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>