[netconf] YANG Push drafts comments

[William Lupton <[e-mail]>]

All,

I'm sorry that the comments below are so late. I did ask the chairs what I
should do with them, and they said to send them to the list despite the
lateness from a process perspective.

The comments are based on the four WG consensus drafts as of late November.
I haven't revisited them to see which may have been addressed by subsequent
discussion.

Nearly all of the comments relate to
the draft-ietf-netconf-subscribed-notifications draft, plus there are some
general remarks, so it didn't seem worth splitting them into a message per
draft.

Cheers,
William

----

   1. General:
      1. Why is the subscription id optional? Without it, will the receiver
      always be able to tell how to handle an event message?
      2. YANG Push is not referred to consistently across the document set
      (presence or absence of hyphen, "yang" capitalization, "push"
      capitalization). There should be a single, consistently-used term.
   2. draft-ietf-netconf-subscribed-notifications:
      1. I wonder why it was decided that dynamic subscriptions wouldn't
      allow the receiver to be different from the subscriber. It seems like two
      different concepts are being mixed: dynamic/configured subscription and
      embedded/external receiver.
      2. Event occurrence time: This isn't quite clear. What if there was
      already a timestamp (from a lower-level system) when the event was
      identified? Should that be used?
      3. Event record:
         1. So does the "event record" term apply to all the drafts? If so,
         does "event" apply to all the drafts? (This note is in the
context of a
         later note about the fact that "event stream" appears to be
specific to
         this draft.)
         2. YANG notifications are explicitly defined in YANG models (e.g.
         the ietf-hardware YANG module defines a hardware-state-change
         notification). I thought that a major part of YANG Push is to
effectively
         allow notifications to be defined dynamically.
            1. Later: I think perhaps the point is that event streams are
            indeed restricted to YANG notifications, but that other
drafts (e.g. YANG
            Push) define mechanisms beyond event streams. Section 2.4 (dynamic
            subscriptions) says "These RPCs have been designed
extensibly so that they
            may be augmented for subscription targets beyond event streams".
            2. Even later: Ah! YANG Push defines generic "push-update" and
            "push-change-update" notifications. So it's all OK.
            4. Event stream:
         1. Having now read most of the YANG Push draft, I realize that
         "Event streams" are a legacy thing and are not used by YANG Push. This
         could be made clear. Otherwise it looks like these are a base
concept that
         will be built on.
         2. Perhaps the truly cleanest solution would be to move the legacy
         aspects to a separate document, or clearly indicate they're
legacy, or use
         less "core" names, or move this material to an Annex or Appendix.
         3. So referring to them as sets of Events (rather than sets of
         Event streams) seems inaccurate.
         5. Notification message:
         1. I don't find "The time the event was generated by the event
         source" quite clear. Is it the time at which the change
occurred or was
         detected (event occurrence time), or the time at which the message was
         created? Probably the former?
         6. Subscription:
         1. The section 2.2 description is very unclear. It appears that
         filters are on subscriptions, refer to records, and cause
"event messages"
         to be excluded from delivery. But "event message" isn't a defined term.
         3. draft-ietf-netconf-yang-push:
   1. YANG Push defines a new "datastore" subscription target that's
      independent of the existing "stream" subscription target. (Assuming that
      this is correct, I'd have liked some explanation of _why_ YANG Push isn't
      able to extend the base mechanism.)
      4. Editorial (there might be some duplication with earlier comments):
      1. Some YANG descriptions have incorrect indentation on the second
      and subsequent lines (such lines should begin under the first
character of
      the first line, i.e. one character to the right of the opening double
      quote). No doubt the YANG Doctors will catch such things!
      2. draft-ietf-netconf-subscribed-notifications-18
         1. Event stream definition: "Event stream: A continuous,
         chronologically ordered set of events" ... but should this be
"...of event
         records"
         2. s/intantiation/instantiation/ (two occurrences)
         3. The "subscription state change notifications" section name may
         have been subject to a s/Subscription/subscription/ edit?
Should capitalise
         "subscription" both here and where it's used at the start of sentences
         (there's at least one case of this)
      3. draft-ietf-netconf-yang-push-20
         1. There's a reference to "Custom Subscription to Event Streams".
         Is this the old title of "Subscription to YANG Event
Notifications"? If so,
         it needs to be updated
         2. Spurious "6 record" in the YANG (should be "record")
         3. In the data model introductory section, the "sn:" prefix isn't
         explained (I know it's sort of obvious, but the "yp:" prefix
(also obvious)
         _is_ explained)