Subject: [Netconf] Last Call on yang-push-17

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Mon, 27 Aug 2018 14:59:23 +0000

Greetings,

I support the forward motion of YANG-Push via yang-push-17. I have read the document, and have a number of comments. All of the comments are of the nit-picky type, and do not materially affect the document.

Thank you,

Tim

===

Comments on https://tools.ietf.org/html/draft-ietf-netconf-yang-push-17

1. Section 3.1, first '+' paragraph:

Sentence needs a change after the word 'exhaust':

"Such behavior has the potential to exhaust
            of resources in the publisher or receiver"

2. Section 3.1, last '+' paragraph:

Refers to "push-update" but that has not been defined or introduced yet. (First formally introduced in Section 3.7.)

3. Section 3.2, second paragraph, second sentence:

It feels like additional words should be added between the words "subscription" and "support", such as "... dynamic subscription *creation and modification* supports a simple negotiation ...".

4. The operation of the dampening period is described in multiple places:
-section 3.1, first '+' paragraph
-section 3.3, fifth paragraph (more complete)
-section 4.2, 3rd last paragraph (nice and brief here)

I recommend consolidating this to one location, perhaps with its own subsection and have other places refer to that.

Similarly, for the on-change refinements, but this is simpler so there is less overall duplication.

5. Section 3.3, paragraph 7:

Refers to "push-change-update" but that has not been defined or introduced yet. (First formally introduced in Section 3.7.)

6. Section 3.4:

Alludes to post-subscription creation handling of overload, but does not mention a solution for that case, while mentioning a solution at subscription creation. Should this section mention the use of the out of band notification to suspend a subscription?

7. Section 3.7, paragraph 2:

Suggest replacing "First it will be used" with "First, it is used"

Also, since the term "MAY" is used for describing the second use of "push-update", should the suggested change actually be "First, it MUST be used"?

8. Section 3.9, paragraph 3:

Change "A publisher MAY choose reject" to "A publisher MAY choose to reject".

9. Section 4.3.2, paragraph 3:

This sentence is not clear: "A receiver MAY assume that a publisher's objects have these pushed values at this point in time." Should it be "A receiver MAY assume that at this point in time a publisher's objects have the values that were pushed."?

10. Section 4.3.2, paragraph 4:

Change "(For example a
   datastore was unable to providing the full set of datastore nodes to
   a publisher process.)" to "(For example a
   datastore was unable to provide the full set of datastore nodes to
   a publisher process.)".

11. Section 4.4.1, paragraph 6ish:

Repeated description of negotiation. Perhaps consolidate this in one place?

12. Section 4.4.2, paragraph 3, sentence 3:

Should this sentence use "SHOULD" instead of "may" for consistency with section 4.4.1 paragraph 6ish?

13. Section 4.4.4, paragraph 1:

The resynch cannot apply to configured subscriptions? I would think the logic to apply its use would be independent of how the subscription is created. However, with multiple receivers, there may be issues with the use of this.

14. Section 4.4.5, paragraph 3:

What does "replicated publisher" mean?

--
Cisco Systems Canada Co.
2000 Innovation Drive
Kanata, ON, Canada, K2K 3E8
Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Aug 2018 17:03:22 +0000

Hi Tim,

thank you for your comments!  Responses inline, <ALEX>

Thanks
--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Tim Jenkins (timjenki)
Sent: Monday, August 27, 2018 7:59 AM
To: [email-masked]
Subject: [Netconf] Last Call on yang-push-17

Greetings,

Thank you,

Tim

===

<ALEX> removed “of” </ALEX>

<ALEX> introduced “push update” at the beginning of the section, now worded as follows:
“Subscriptions specify when notification messages (also referred to as "push updates") should be sent and what data to include in update records.”
</ALEX>

<ALEX> Added an “a” before “dynamic subscription”  Now it reads as follows:
“Therefore, in order to minimize the number of subscription iterations between subscriber and publisher,
        a dynamic subscription supports a simple negotiation between subscribers and publishers for subscription parameters.”
</ALEX>

<ALEX> Sure, there is some duplication; however, section 3.1 gives a brief overview, 3.3 explains in more detail, and 4.2 defines it as part of the model.  There is no contradiction and the text / structure flows reasonably well IMHO so at this point, I would prefer to leave as is.  </ALEX>

<ALEX> Isn’t it clear from the context what push-change-update refers to?  </ALEX>

6. Section 3.4:

<ALEX> I think it does that.  It states “For this
   reason, the solution that is defined in this document mandates that a
   publisher notifies receivers immediately and reliably whenever it
   encounters a situation in which it is unable to keep the terms of the
   subscription, and provides the publisher with the option to suspend
   the subscription in such a case
”
Not sure if anything else is really needed here, but let et me add the following text: “This includes indicating the fact that an update is incomplete as part of a push-update respectively push-change-update notification, and emitting a subscription-suspended notification as applicable.  ”.   Also, I am adding a forward reference to section 3.11.1 per Martin’s earlier comment.

<ALEX> Sure, done </ALEX>

<ALEX> Changed </ALEX>

<ALEX>Thank you, changed </ALEX>

Change "(For example a

<ALEX> done </ALEX>

<ALEX> well, this is here described at greater level of detail from earlier, where the general concept was layed out.  Since there are no inconsistencies in the description, prefer to leave as is.  </ALEX>

<ALEX> Changed to SHOULD </ALEX>

<ALEX> Let me table this for now and get back on this.  </ALEX>

<ALEX> Removed most of the paragraph and rephrased, per Martin’s earlier comment </ALEX>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 Aug 2018 18:14:45 +0000

Hi Tim,

From: Tim Jenkins, August 27, 2018 10:59 AM

<snip>

<Eric>  Allowing configured subscriptions to optionally support resynch RPC is possible, but it makes at least two things more complex:
(1) Right now the publisher doesn’t need to support any dynamic signaling interactions with a configured receiver.
(2) You are correct that the RPC would only be relevant per-receiver, rather than per subscription.  So the publisher will actually perform a slightly different behavior with a resynch request.

My suggestion therefore would be to tweak the text in 4.4.4 to “this RPC is supported for on-change subscriptions previously established using an "establish-subscription" RPC.”

And the definition in the YANG model would be tweaked:

OLD: This RPC can only be invoked on the same session on which the subscription was established (using an establish-subscription RPC).

NEW: This RPC can only be invoked on the same transport session on which a subscription is currently active.

This would allow future support of the resynch-subscription RPC for configured subscriptions if turns out people want that in the future.

Eric

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Aug 2018 18:44:51 +0000

Incorporated the suggested changes into the text.
--- Alex

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Tuesday, August 28, 2018 11:15 AM
To: Tim Jenkins (timjenki) <timjenki=[email-masked]>
Cc: [email-masked]; Alexander Clemm <[email-masked]>; [email-masked]
Subject: RE: [Netconf] Last Call on yang-push-17

Hi Tim,

<snip>

Eric