Subject: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-07

From: Balazs Lengyel <[email-masked]>
Date: Mon, 4 Dec 2017 17:14:47 +0100

Hello,

Sorry if some of the comments are already resolved. I did not
have time to scan through all the mails.

1.3)

Should we formally state some transport requirements? This
chapter seems to assume:

- transport is either connection-oriented and reliable

- or connectionless/stateless, but has acknowledgement for the
notifications

so the publisher can determine whether the receiver actually got
the notification or not.

"The lifetime of
a configured  subscription is driven by relevant

configuration being present on the running
configuration."

Is it really the "running" config? IMHO it should be the
operational.

"Dynamic subscriptions can only be modified via an RPC request
made upon the original subscribing transport session."
How does this work in case of Restconf? The transport session can be very brief.
Shouldn't we discuss restconf and "same transport session" generally somewhere?

2.2)
"A subset of information is never stripped from within the event record."
I don't fully understand this. Maybe reword it to
"A filter always removes a complete event record; a subset of
information is never stripped from an event record. "

If a filter removes 2 out of 3 event records will the notification still be sent? Is that a realistic situation?

2.3)
Figure 1) IMHO a state transition from suspended to suspended on modify-subscription is missing.

The state diagram for configured subscriptions is not really clear.
- does the subscription have a state/state-machine or the individual receivers?
The model suggest its the receivers.
- the described states do not correspond to the states defined in
/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver/sn:status
- buffer overflow is mentioned. Is it an overflow at the receiver or the publisher?

4.1.1) s/a event/an event/

4.4) s/associated the transport/associated with the transport/

5) 3rd sentence reword!

5.1)
here it is written that:
"Note that is possible to configure replay on a configured subscription."
In 4.1.1 it is written that
"Replay is only viable for dynamic subscriptions."
One of the two statements must be changed!

5.3) merge with chapter 6

8.4, 8.5)
Suspensions are notified to the subscriber (...) and all receivers ...
Already described in chapter 8. Remove

10)
anydata subtree-filter) event-filter: Is this applied against the full
notification or against an event-record? It is not clear! A notification may contain multiple event records.
In the two cases the top level element should be different.
If against the event records, is it the full notification or only the
individual event record that is not sent? If all event records are not sent the notifications shall not be sent.
IMHO this would deserve a few sentences somewhere. The same question is valid for XPath. Which is the correct format?
- /notification/myNotification/eventRecord[type='typeA'] or
- /eventRecord[type='typeA']

stop-time) "If replay-start-time doesn't exist, stop-time must be for a future time."
This may be required at subscription establishment, but later when the
subscription state becomes concluded, this will become false.

dependency both substrees) shouldn't this be a leafref with require-instance=false?
/subscription-config/subscription/sn:stream and
/subscriptions/subscription/sn:stream and
/establish-subscription/input/sn:stream) shouldn't these be a leafrefs

11)
s/or nor subscribed/or subscribed/

11.2)
"A publisher MUST NOT include any content in a notification message
for which the user has not been authorized."
Clarify if the user is the subscriber or the receiver.

"Subscribers that do not want notification messages need only terminate or refuse
any transport sessions from the publisher."
IMHO the first word should be receivers.
Also in the case of a configured subscription can we get into a cycle?
- publisher tries to send a notification
- receiver receives a notification it does not want
- receiver closes transport session
- start from the top

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 8 Dec 2017 19:03:22 +0000

Hi Balazs,

Thanks for the comments.  In-line...

From: Balazs Lengyel, December 4, 2017 11:15 AM
To: [email-masked]
Subject: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-07

Hello,

Sorry if some of the comments are already resolved. I did not have time to scan through all the mails.

1.3)

Should we formally state some transport requirements?

This chapter seems to assume:
- transport is either connection-oriented and reliable
- or connectionless/stateless, but has acknowledgement for the notifications
so the publisher can determine whether the receiver actually got the notification or not.

<eric> There is no explicit requirements that Subscribed notifications must be used with some form of acknowledgement.   And with NETCONF, RESTCONF, HTTP2, and UDP transport drafts already adopted by the WG, the majority of the transport requirements are there.  Is there anything specific you don’t see which can be called out?

"The lifetime of a configured  subscription is driven by relevant
configuration being present on the running configuration."
Is it really the "running" config? IMHO it should be the operational.

<eric> I believe running is correct.   I believe such a subscription alive if it can be seen on the system, even if no receivers are active.

<Eric> Yes, identification of the same transport session at a high level becomes tricky for connectionless transport.  At a minimum, the proper lifecycle always needs to be determined/included in the transport drafts.  For RESTCONF, in draft-ietf-netconf-restconf-notif there is Appendix A.2 which describes how to handle this with a TLS Heartbeat.  In lieu of that optimization, a TCP connection initiated from the receiver which is lost will at some point be recognized by the publisher (e.g., see flows in sections 3.1).    Coming back to subscribed-notifications, what if I just say “...an RPC request made from the original subscriber”?

2.2)

<Eric> Change made.

<Eric> As each notification would be its own event record, yes and yes.

2.3)

<Eric> Yes, it is per-receiver.

<Eric> As shown now, the state machine reflects the view of the receiver connection from the point of view of the receiver.  I.e., the receiver is not automatically sent all aspects of internal state which need to be reportable to a publisher’s operator who is managing this subscription.

That said, you are correct that an easy mapping between the two would be useful.

If I change “create” to “configuration operation” , and make the following change to the bottom of the diagram, then the diagram can accomplish both internal states, and states:

      '---------------------------------------------'

             |              |              |

         Stop-time:      error:          config delete:

         subscription-   subscription-   subscription-

         completed       terminated      terminated

              |              |              |

              V              V              V

       .-----------.    .----------.     .-----.

       | concluded |    | in-error |     | end |

      '-----------'    '----------'     '-----'

What do you think?

<Eric> Publisher.   Have changed the text to the “a publisher buffer overflow”.

<Eric> Fixed

<Eric> Fixed

5) 3rd sentence reword!

<Eric> How about:

The lower half the “identifier” object in the subscriptions container SHOULD be used when the “identifier” is selected and assigned by an external entity (such as with a configured subscription).   And the upper half SHOULD be used for subscription identifiers dynamically chosen and assigned by the publisher.

5.1)

here it is written that:

<Eric>  Yes, I caught that earlier.   The second sentence was removed.

<Eric>  Yes, duplication caught earlier.

8.4, 8.5)

<Eric> I think I caught this in the latest version.  Let me know if you have any questions

10)

notification or against an event-record?

<Eric> Changed to singular, not plural.  So it is applied against “an individual, delineated event record”.  Note:

It is not clear! A notification may contain multiple event records.

<Eric> I see a single RFC-7950 YANG Notification as being a single indivisible record.  But a notification-message (as per draft-ietf-netconf-notification-messages) allowing the bundling of multiple event records.

<Eric> Not sure if I cover this with other responses.  Let me know if I am missing something.

individual event record that is not sent?

<Eric> Per above, I think an RFC-7950 YANG Notification as being a single indivisible record.   As event streams can come with different delineations,

If all event records are not sent the notifications shall not be sent.

IMHO this would deserve a few sentences somewhere.

<Eric> I have put the following Yellow in the streams section.

The NETCONF event stream contains all NETCONF XML event record information supported by the publisher, except for where it has been explicitly indicated that this the event record MUST be excluded from the NETCONF stream.  An [RFC7950] YANG notification will be sent to this stream, and each such notification MUST be considered as a single indivisible event record.

The same question is valid for XPath. Which is the correct format?

<Eric> I prefer the first.  I am sure someone could create simpler more generally applicable xpath expressions which accomplish the same thing.

<Eric> Have changed it to: “stop-time (at the time it is set) must be ...”

<Eric> Based on the way HTTP2 RFC-7540 Section 5.3.4 does QoS, stream dependencies can be quite transient.     With HTTP2 “dependencies can be moved to become dependent on the parent of the closed” subscription.

Translating that to YANG behavior is something I have no idea how to do.   I.e., how do you encode rules that say “if a subscription with a leafref pointing to it is being deleted: take its own dependency leafref (if it exists) and place it into the leafref of the dependent subscription”.

Since I didn’t know how to do it, I figured it could be up to applications to maintain that dependency tree.  If someone has another proposal which can keep up with subscriptions in-flight, I would be very interested.

<Eric> Alex and I chatted about this previously.   It is fine either way.  But as you prefer leafref, I have changed it to that.  This makes it consistent with the way VRFs are now referenced.

11)

<Eric> Fixed.

11.2)

<Eric> Updated to receiver in that section a few times.

<Eric> Fixed.

- start from the top

<Eric>  This can be the case, but it is avoidable.   It is up to the transport documents to define how to avoid that loop.  Of course there are more granular mechanisms available for fixing this with transports vs. others.   This is one place where HTTP2 has a real advantage.

For NETCONF, you only manage the one transport session between publisher and receiver, and there are not very granular options.   Relevant text in draft-ietf-netconf-netconf-event-notifications says:

  “If the call home fails to establish for any other reason, the

   publisher MAY leave the receiver in a "connecting" status, and retry

   the call home at a future time.  Alternatively, the publisher MAY

   place the receiver into a "suspended" status after a predetermined

     number of call home attempts.”

Perhaps this could be tweaked to say:

  “If the call home fails to establish for any other reason, the

   publisher MAY leave the receiver in a "connecting" status, and retry

   the call home at a future time.  Additionally, the publisher SHOULD

   place the receiver into a "suspended" status after a predetermined

     number of either failed call home attempts or NETCONF sessions remotely terminated by the receiver.”

Would this work for you?

Eric

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>