Re: [Netconf] LC on subscribed-notifications-10

Martin Bjorklund <mbj@tail-f.com> Wed, 14 March 2018 08:39 UTC

Return-Path: <mbj@tail-f.com>
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 51AAA12785F; Wed, 14 Mar 2018 01:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 UmZAOzQu9AWB; Wed, 14 Mar 2018 01:39:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC5127871; Wed, 14 Mar 2018 01:39:01 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 941911AE034E; Wed, 14 Mar 2018 09:39:00 +0100 (CET)
Date: Wed, 14 Mar 2018 09:39:00 +0100 (CET)
Message-Id: <20180314.093900.1449292548839197417.mbj@tail-f.com>
To: evoit@cisco.com
Cc: rwilton@cisco.com, kwatsen@juniper.net, netconf@ietf.org, draft-ietf-netconf-subscribed-notifications@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <8d4f4193c6694fe387d284d7b74c9b09@XCH-RTP-013.cisco.com>
References: <DA8A1569-826D-4744-B780-90CDA064D0BD@juniper.net> <f9096b71-26b7-eda3-6ddc-2983b693a2f5@cisco.com> <8d4f4193c6694fe387d284d7b74c9b09@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ZHQxs9cPrVW3jDj1cU-_fZi62Wc>
Subject: Re: [Netconf] LC on subscribed-notifications-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing 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: Wed, 14 Mar 2018 08:39:35 -0000

Hi,

"Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > From: Robert Wilton -X, March 12, 2018 12:41 PM
> > 
> > Hi,
> > 
> > Some minor comments on this draft.  I've not read/reviewed all of it
> > yet, so
> > some more comments may follow.  But generally I am supportive of
> > publishing
> > this draft.
> 
> Thanks Robert.   
> 
> I have incorporated tweaks as-per below.  These updates can be seen
> within the working draft -v11 at:
> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-11.txt
> 
> >    I'm happy to leave it to the authors discretion on whether and how
> >  they
> > want to address these.
> > 
> > 1. I noted that neither the title nor abstract mention YANG or network
> > configuration.  Nor do they mention that they define a YANG data
> > model.
> 
> This is true, and I think ok.  Just like RFC-5277, it is possible to
> subscribe to non-YANG streams.

Perhaps "A YANG Data Model for Event Stream Subscriptions"?

Or something along these lines in the abstract.

Even though the streams may not be YANG-defined, the subscription
mechanism is YANG based.

[...]

> > - State change notification => "Subscription state change
> > - notifications"?
> 
> Every time "state change notification" is used, the word subscription
> is easily matched up.  So it seems to me to be more readable to use a
> shorter term versus a longer one.

I think that in most cases you are right.  But I suggest you clarify
this the first time the term is used, in 1.1:

OLD:

   o  state change notifications (e.g., publisher driven suspension,
      parameter modification)

NEW:

   o  subscription state change notifications (e.g., publisher driven
      suspension, parameter modification)


[...]

> > I wasn't sure how this tied in with YANG push where a client may not
> > have access to read some nodes.  In that case, nodes that can't be
> > read are left
> > out (e.g. like a NETCONF GET request).  I know that YANG push covers
> > this is
> > more detail, but didn't know whether this paragraph correctly stands
> > on its
> > own?
> 
> Current paragraph is correct.  The idea is you shouldn't allow someone
> to subscribe to a stream containing any content they are not allowed
> to see.  Access control is to the stream rather than the content.

But it seems that YANG push filters out the nodes that you don't have
access to.

Your statement:

  Access control is to the stream rather than the content.

seems to imply that in order to subscribe to changes to the datastore,
you need full access to all nodes covered by the filter.


/martin