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

[Alexander Clemm <[e-mail]>]

Hi Tim,

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

Thanks
--- Alex

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

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"

<ALEX> removed “of” </ALEX>

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.)

<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>

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 ...".

<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>

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.

<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>

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.)

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

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?


<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.


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"?


<ALEX> Sure, done </ALEX>

8. Section 3.9, paragraph 3:

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

<ALEX> Changed </ALEX>

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."?

<ALEX>Thank you, changed </ALEX>

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.)".

<ALEX> done </ALEX>

11. Section 4.4.1, paragraph 6ish:

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

<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>

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?

<ALEX> Changed to SHOULD </ALEX>

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.

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

14. Section 4.4.5, paragraph 3:

What does "replicated publisher" mean?

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

--
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>