Re: [Netconf] LC on netconf-event-notifications-08

[Kent Watsen <[e-mail]>]

Abstract:
  - too terse.  Also, what does "binding" really mean?  I suggest rephrasing
    and expanding.

Introduction:
  - again, what does "binding" really mean?  - can you be more concrete
    about what all is included?
  - does this document actually "enable" something?
  - are the events "from" a datastore, or "for" a datastore?

Section 2:
  - missing reference to RFC 8174

Section 3:
  - the 2nd sentence is not needed, remove?
  - the last sentence seems odd, and perhaps unnecessary, as this builds
    on top RFC5277 notifications, for which the :interleave capability already 
    specifies this behavior.  I think that you might be trying to say it in a
    way that extends to notification-messages, but it doesn't read that way
    to me.  Do you mean "operations"?

Section 4:
  - the first sentence compares apples to oranges (a draft vs an RPC)
  - in first sentence, "this support" should be reworded
  - the first bullet point confuses me.  I get the gist of what it's trying
    to say, but the word "subscription" is ambiguous in this context
  - is the second bullet point needed? I mean, how could this happen?
  - again, the word "subscription" is ambiguous in this context

Section 5:
  - why is the first sentence a normative statement?  isn't it given from
    RFC 6241?  Maybe rephrase to indicate from which RFC it comes from?
  - for the second sentence, already 5277 comes with NETCONF stream, so 
    is this trying to cover the case when 5277 is NOT supported? - but 
    then I think there needs to be more normative text to extend this
    definition.
  - for the third sentence, is the same true for any publisher
    supporting [I-D.ietf-netconf-yang-push]?

Section 6:
  - the section is called "transport connectivity", but has subsections for
    configured/dynamic *subscriptions*.   As such, it makes me think this
    section should be called "Subscription Types".  Perhaps the subsection
    titles should be renamed (e.g., Related to --- Subscriptions?)
  - a segue sentence before Section 6.1 would help.

Section 6.2:
  - I'm expecting this info to be in subscribed-notifications.  However, 
    searching for "8071" in subscribed-notifications finds nothing.  Even
    if there is a good reason for why it's not normative in subscribed-
    notifications, that draft should say something like "bindings must
    enable publishers to proactively establish connections with subscribers
    (e.g., RFC8071).
  - second to last paragraph, why is "Transport" capitalized here?
  - the second to last paragraph is not needed.  It's already a SHOULD in
    RFC 8071, S7.  Perhaps you want to make a non-normative statement, or
    clearly indicate that the normative statement is coming from RFC 8071?
  - in this whole section, when referring to the ""connecting" state", it
    would help if the text indicated that this is from the subscribed-
    notifications draft.

Section 7:
  - what does "NETCONF" mean here?  - the protocol, the stream, the WG?

Section 8: 
  - first sentence, isn't it just subscribed-notifications, per what's in
    the introduction?   Also, are there specific sections that can be
    referenced?
  - 1st bullet point, s/"error-type"/an "error-type" node/?
  - 2nd bullet point, s/"error-tag"/an "error-tag" node/?
  - 3rd bullet point, s/Optionally,//
  - 4th bullet point, a wall of text, consider formatting (bullet points),
    and the ", respectively" at the end is not needed.
  - 5th bullet point, s/optionally, "error-info"/ optionally, an 
    "error-info" node/.   Another wall of text, consider formatting 
    (bullet points)
  - "These yang-data that is" - what is "yang-data" here?  also s/is/are/
    and s/"error-info"/the "error-info" node/?
  - last sentence, s/"error-path"/an "error-path" node/?

Section 9:
  - 3rd paragraph, what does this mean, since this draft doesn't define
    a module?  Perhaps instead say "this draft does not define a YANG
    module and therefore doesn't have any YANG-related Security 
    Considerations."?   - and remove the rfc6536bis reference.
  

Appendix A.
  - the text should state if the section is normative or non-normative.
  - as I don't see any RFC 2119 language, I'll assume non-normative
    and stop my review here.  Given the number of issues found above, I
    suggest reviewing this section carefully.
  - looking forward to the YANG Doctor and the Shepherd reviews, please
    post a script that validates each example listed in this document.


Kent



===== original message =====

WG,

The authors of netconf-event-notifications have indicated privately that they believe this document is now ready for Last Call.

This starts a 2.5-week Last Call on draft-ietf-netconf-netconf-event-notifications-08 [1]
The LC will end on March 17, or when active threads peter out.

Please send your comments on this thread. Reviews of the document, and statement of support, are particularly helpful to the authors.  If you have concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.


[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dnetconf-2Devent-2Dnotifications-2D08&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=GTTYeioeUTd_V-M93k5RNRCFhoaoNiS4kY-v-pIV0kE&s=1UJkiYEXB-cdME1VDg8JuvfeiHrpo6wjx4FWOJUTR28&e=


Kent & Mahesh




_______________________________________________
Netconf mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=GTTYeioeUTd_V-M93k5RNRCFhoaoNiS4kY-v-pIV0kE&s=XTJIg4iBdppRM_RXJCeh51GZFGMJD2S66B2uPmHtx0E&e=