Re: [netconf] YANG Push drafts comments
William Lupton <wlupton@broadband-forum.org> Fri, 01 February 2019 19:53 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 2552F130E84 for <netconf@ietfa.amsl.com>; Fri, 1 Feb 2019 11:53:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level:
X-Spam-Status: No, score=-2.041 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, URIBL_BLOCKED=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 6_t0GrIW8U6d for <netconf@ietfa.amsl.com>; Fri, 1 Feb 2019 11:53:45 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 DF2FC128B01 for <netconf@ietf.org>; Fri, 1 Feb 2019 11:53:44 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id m62so11051198ith.5 for <netconf@ietf.org>; Fri, 01 Feb 2019 11:53:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iq7cZ9zPFbZKFskQZa7bQOpUPbCT7x2D7k7zr01uOt0=; b=u7gaQ1WB3xHiKJYAlK8jMBrceXT7NuCOj55gntVO+hBKpOOHxlL4R5HoFmr8XCPcmJ MJJQ+wnDuujz1QT5EpSS1OLjehwMD71w6kzcxMzAptaehMfVm0HGWndmoaqHlS0M9SkC tsAoRG3Q7DtK1jYW4q9P5Iaw0g5odDwMZuZ+/Jdjhay8e138IydRDLOdrxqT1BDUxURO 9VY82P2Uwf3FnDOKcYX8RaZM1Omje2Sg8/Wcn4Ja0NIXECR1tAN2YEjoOK2XSPthrf7v jcDHrBE4h3DkwHScRkzhrrExKE5kZbxegTVF2P6ZVl2Ktu7/SpvQk7nPgtfue3pjs+4D 04qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iq7cZ9zPFbZKFskQZa7bQOpUPbCT7x2D7k7zr01uOt0=; b=aoESoimwKLLFHN8R54ndysRzaHwT+Wlv+YF9syzczRwxa8MVRPlvdIxmUAlNhHhGtT WJaFVSKNWqu4iNmy3dyb1/YuQsEx77BwanDb2E8u/QaKm5J3rYaV9i/YquIrSNC4LGgA qasWCKACvdu4tzIrr1Z+SaWhiEIGzxRpHbSZwkNB/7U6zGyp1zrl4d/dhq1ipS2QGfqA cb8XbLDilR9M39FPhfcobyzEE1N5M8cNKCGAGkSCQRB85wOCGoljVwR1VLPiNqsmLrq8 jM84bEPKCFKbZkxufg7jKnGkJpgvdZV77Y7A/3PraT35z13m3M+fkMWzqmI2mvBaNyjM 9O5g==
X-Gm-Message-State: AHQUAuaDj26jdnnLNj4/JAy1OAWovCCIA4OyIy8sNUJNyXw3s6V4s1SM G9BWrT9AKJyAzb6KdvC1oG2FCFyIHUGJmnKjKMSK1CB5
X-Google-Smtp-Source: AHgI3IaMgwh6LLtTrLARkj4IR7pCLyOZkJrMXn+4SREaMhqeRYgT+BeVZSsvFnwnUpGKstqJSyxSHwaK1Lb1BnKvAwE=
X-Received: by 2002:a05:660c:da:: with SMTP id q26mr2417336itk.24.1549050824109; Fri, 01 Feb 2019 11:53:44 -0800 (PST)
MIME-Version: 1.0
References: <CAEe_xxgchMoE9UyR2LUDbMAyFVZfOWCfVwEFN0HFtsWOYgK3eg@mail.gmail.com> <8518c87f5ef24ba9ad851a52f28047dd@XCH-RTP-013.cisco.com> <CAEe_xxjkewpvPqA-Dzs3iRHXLbMQG=SSHMo-GBvF9ar60hGvUw@mail.gmail.com> <80b8fdb627c24950ab3e7f15f2f54a65@XCH-RTP-013.cisco.com>
In-Reply-To: <80b8fdb627c24950ab3e7f15f2f54a65@XCH-RTP-013.cisco.com>
From: William Lupton <wlupton@broadband-forum.org>
Date: Fri, 01 Feb 2019 19:53:33 +0000
Message-ID: <CAEe_xxgPGmg65cqRkxRt_XdjCJK1KyZNYgc4hquLT+9ruz5rTw@mail.gmail.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "alex@clemm.org" <alex@clemm.org>
Content-Type: multipart/alternative; boundary="0000000000001c60d70580da8063"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9y7o0ZGfo4mnqKwe_7o4_yBWYzY>
Subject: Re: [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: Fri, 01 Feb 2019 19:53:49 -0000
Thanks. No more questions or comments. Cheers, W. On Fri, 1 Feb 2019 at 17:18, Eric Voit (evoit) <evoit@cisco.com> wrote: > Thanks William. And some more thoughts back to you (and one to Alex)... > > > > *From:* William Lupton, January 30, 2019 4:54 AM > > Thanks Eric. Please see some follow-ups below (I've removed items where I > have no further comment). Cheers, W. > > > > On Tue, 29 Jan 2019 at 20:31, Eric Voit (evoit) <evoit@cisco.com> wrote: > > Hi William, > > > > Thanks for the interest, thoughts in-line... > > > > *From:* netconf <netconf-bounces@ietf.org> *On Behalf Of *William Lupton > *Sent:* Tuesday, January 29, 2019 6:41 AM > *To:* netconf@ietf.org > *Subject:* [netconf] YANG Push drafts comments > > > > 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? > > I assume you are referring to the pushed notification messages carrying > event records. The RFC-5277 one way notification doesn’t support a > subscription-id object in its current event schema, so we can’t embed this > object for subscribed-notifications. This is one reason that > draft-ietf-netconf-notification-messages was adopted. For YANG push, we do > have a subscription-id in the notification definition, which is then > carried within the RFC-5277 one-way notification. > > > > I would expect this question to arise in the minds of many readers. A note > might be useful? > > > > <Eric> Notes on this topic were included in earlier versions of the > document (e.g., version 10). However other reviewers asked to remove > these notes as they weren’t explicitly needed for this specification. In > the end, the work on draft-ietf-netconf-notification-messages will restart > after we get done these drafts, and hopefully will drive text back to this > document to cover this concern. > > > > 2. draft-ietf-netconf-subscribed-notifications: > > > > 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.) > > Subscribing to an event stream is different than a subscribing to a > datastore. [...] > > > > This was a terminology comment. I felt that it wasn't always clear which > terms were generic and would apply to all drafts. "event record", "event" > and "event stream" caused me particular problems. It was just a comment... > if people don't think there's a need for clarification (or greater rigor in > the use of terms) then that's fine. > > > > <Eric> The original “event” came from RFC-5277. But RFC-5277 didn’t > have a separate term for the entity against which filter was applied (i.e., > an event record). We also needed to tweak the definition of “event stream” > from the original RFC-5277 “stream”. This was needed because the original > definition was NETCONF specific. > > > > With that as a starting point, we then had terminology established where > any event could be documented via an event record, and placed on an event > stream. This includes a populating an event stream with the set of > notifications coming from a separate YANG push subscription. Event records > generated this way would look 100% identical what would come from original > YANG Push subscription. This was not accidental. And as a result it > becomes possible for a publisher implementation to internally populate an > event stream through the under-the-covers use of YANG push software. > > > > Based on this, the terminology was constructed not to exclude the > possibility that a push update could be an event record. But it was felt > these were internal publisher complexities on corner cases. And getting to > these details might confuse the casual reader. So as a result, we simply > avoided the use of ‘event records’ within YANG Push. I guess this is a > long way of saying that I hope the current text is sufficient. > > > > 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. > > I think event streams are useful. I don’t consider them legacy. > > > > I didn't mean "legacy" pejoratively. Reading the draft I was thinking "Ah, > event streams are a core concept that will be leveraged by the other > drafts". So I was surprised to discover that YANG Push doesn't use them. > Assuming that I'm correct here, I think that a note (either here or in YANG > Push) could be helpful. > > > > <Eric> If we do this, the right place would be YANG Push. I will leave > the call on this to Alex. (cc’ed) > > > > 3. So referring to them as sets of Events (rather than sets of Event > streams) seems inaccurate. > > I don’t see any text on either sets of events, or sets of event streams. > > > > Sorry, part of this got lost in translation. I intended to refer to the > fact that: > > - Event stream is defined (1.2) as "A continuous, chronologically > ordered set of events..." > - And then later (2.1) it seems to be suggested that an event stream > is a set of event records (rather than a set of events) > > (But re-reading it just now, I'm not sure whether it really says this! I > also note that you commented on this point later. So we can drop this one.) > > > > 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? > > I can’t find the exact text quote: "The time the event was generated by > the event source" . Where is this? > > > > Sorry. The actual text is from RFC 5277, describing eventTime. Obviously > I'm not suggesting that RFC 5277 be changed! > > > > <Eric> Yes, I never did like that text from RFC-5277. I checked into > why RFC-5277 was written this way several years a while ago. Basically > different implementations handled this in different ways, and they wanted > text which wouldn’t preclude different implementations. > > > > Eric >
- [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