[netconf] YANG Push drafts comments

William Lupton <wlupton@broadband-forum.org> Tue, 29 January 2019 11:40 UTC

Return-Path: <wlupton@broadband-forum.org>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9AF47129508 for <netconf@ietfa.amsl.com>; Tue, 29 Jan 2019 03:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kBRG9leo505z for <netconf@ietfa.amsl.com>; Tue, 29 Jan 2019 03:40:42 -0800 (PST)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4471294FA for <netconf@ietf.org>; Tue, 29 Jan 2019 03:40:42 -0800 (PST)
Received: by mail-it1-x12d.google.com with SMTP id a6so3960641itl.4 for <netconf@ietf.org>; Tue, 29 Jan 2019 03:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=MjXefGoxzVqkSVMy+fYghqoGKcvPiY5iZSpO/L0svfE=; b=pbdCA2xReDXvmpsSWJ7m4ZiPbkshal7VSN0vG9toX6vi0+Edff4vLcSWNjjDA68ba2 pm7eUIxXYmeTa+kmBD5gWxhz4pdJvExNuOi/9CY9583B4xNTW6fyZfJ4nG1iLUVNQ9bL 21Atqw3b5PQ9UpqOP2nH/6NI5VFb8amKpNwyY622U2T7ehFEvnWsDYvja/axMYmA1fdk 1pBw/O9sy5bfjkAXTrMG4WIi1v86HE7mmafsUfSA+bXT4PHLgMLPxBE9bm64RZuEs4BD b1do9acFJrMHOGR6QbrfifCzmHHPtoAngI9CI+cu8VGSP7wKw8c7tuf2qRC5iHIl9CzH RhJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MjXefGoxzVqkSVMy+fYghqoGKcvPiY5iZSpO/L0svfE=; b=JVC9lr9J+m9rglemhIgWRgCYsCbH61c0ZIH1aZvyjXnv1z8Gstu74FGq6mNtMpSbe+ TX9xl8Zka64sdY7XzG4b/L5Pz4ctH7bUzK9ORlxScXw3CZaL3s7nmcdS9jiu0GWbFFkp caRm2tBb57SJ3b8iJ0qhpS512WyDlpYlrCGcH3z3EKwqX+PWKw+4aDSFvi4+NzVDgh8J 9skl98gPc/WVHwUXQhD6KDU703SC6FyMpgxO3qcv7sRxSm1wPCKnaMwh672LCezRSOaJ yA+vk65JDYObobp+GX49whYOy1jy/9ZQBfpDUto8C31BjeUmuXuAQWq/mdhTEwyNInXd Cq/A==
X-Gm-Message-State: AJcUukf38eq296IVz8YnP/xS9lqTN+ZaQhlyetAflj1jqASNrSak2Ycj QuyofIPgGTcTTHy5FEDCFw8x/GRmv6udn0BIcjBg9vt3ZU4=
X-Google-Smtp-Source: ALg8bN4jelEtEAgg1W/IWD4OV0PH4dhA9f8F9NZfynXgBhyg0G64psFY+I+w7DTeuBglrniFQxkco15W5ovHb6VjkVc=
X-Received: by 2002:a05:660c:da:: with SMTP id q26mr12362171itk.24.1548762041152; Tue, 29 Jan 2019 03:40:41 -0800 (PST)
MIME-Version: 1.0
From: William Lupton <wlupton@broadband-forum.org>
Date: Tue, 29 Jan 2019 11:40:30 +0000
Message-ID: <CAEe_xxgchMoE9UyR2LUDbMAyFVZfOWCfVwEFN0HFtsWOYgK3eg@mail.gmail.com>
To: netconf@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004e0c8d05809743e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/gV2_ZS9G2NJEnJuhx4NBgoiBsrk>
Subject: [netconf] YANG Push drafts comments
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2019 11:40:46 -0000


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

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



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