Re: [netconf] YANG Push drafts comments

William Lupton <> Wed, 30 January 2019 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAF47130F2D for <>; Wed, 30 Jan 2019 01:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.04
X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UQN2oohVtqwr for <>; Wed, 30 Jan 2019 01:54:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A887130F21 for <>; Wed, 30 Jan 2019 01:54:14 -0800 (PST)
Received: by with SMTP id b16so18912994ior.1 for <>; Wed, 30 Jan 2019 01:54:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FN6hA42vu+xdf0lRzx1J2Dw8s+53WoTbv95LPeYEcK4=; b=sNXUNgZsv6Nd8e9gskwhJarF5zqxYDkUh1kKHkUzLABJ8yMg5pB9oHsGSJ0+LtzDXo B5NndeMPK9Lyb6bTsCfF63cJSqpQTCAkzD+svwZhflaX1UySl7KpXDEPZc68RcL1mtPZ 0kUmguMEMzYhzX8RaleEIUWWqSfCMChg7LIfiD2GefpGcc6JyQQ6Max1DsWMCglpHDyw ydYRQ5G5LtsFrtQ7FiPFROmnO+Gyc77NzHDeo7KlaT5DbNOpOvhPuNXtMbiFC2oyc0cE FvOR94LpJ5w7gwIaldyeCcf7a9L1ztD5eO4Lf4OLeWEhrvKMkv/sowVcRDUPzDRmf9HT nK+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FN6hA42vu+xdf0lRzx1J2Dw8s+53WoTbv95LPeYEcK4=; b=TKXskcB7w1dA61VauW28bjC9ChkRjYr0L2DtiBxbp/xw9TfQwbOgmX4ThSwsckhwjQ W/9T7X3IAdStr/d9fEYFfcvD5O4WRi0WS5SzPeMMCf8Nz3KC73YoO9MVReMN71Cmg1eG zWzWekTIkzMDPySB9o2ZErkM6+FdUGkJrk9c9xG9tkVbw8Cqs7N9EbUgzwaAj7gkCdEX 1/CSKpg2fxJiPcKljNBbTVBbtJAhVmw1LF81rBCCsBSuB5DbbXuUjl6rec0o/BnsAgCo zUN0oTCXyEOtyICWPrRJoe+SI5VwKEKKi/KjQfexAihDOQNvjc6N+ElkjzsGNcWj5Trw 4E1Q==
X-Gm-Message-State: AHQUAuZhaoyfqzLRRWUKFzMkvSYTsheae30Cf+qHjmRo0Nf4hmzAc81A N0+k5/X6TVyk40xZY5rEG53y0RacJxZujKjxEKQeOg==
X-Google-Smtp-Source: ALg8bN5Zg+43bMlM0fJ4iiD4NV1cmCuQkGr/9TGd42qMm8JHKEelxCSVqPKJOQfYzudH1DCHigXqHiQt0V2+pIXtEVY=
X-Received: by 2002:a6b:fb08:: with SMTP id h8mr17606839iog.212.1548842052916; Wed, 30 Jan 2019 01:54:12 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: William Lupton <>
Date: Wed, 30 Jan 2019 09:54:01 +0000
Message-ID: <>
To: "Eric Voit (evoit)" <>
Cc: "" <>
Content-Type: multipart/related; boundary="000000000000615ae90580a9e43f"
Archived-At: <>
Subject: Re: [netconf] YANG Push drafts comments
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jan 2019 09:54:18 -0000

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) <>; wrote:

> Hi William,
> Thanks for the interest, thoughts in-line...
> *From:* netconf <>; *On Behalf Of *William Lupton
> *Sent:* Tuesday, January 29, 2019 6:41 AM
> *To:*
> *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?

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

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

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