[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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
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)
- [netconf] YANG Push drafts comments William Lupton
- Re: [netconf] YANG Push drafts comments Eric Voit (evoit)
- Re: [netconf] YANG Push drafts comments William Lupton
- Re: [netconf] YANG Push drafts comments Eric Voit (evoit)
- Re: [netconf] YANG Push drafts comments William Lupton