Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 06 May 2019 21:53 UTC

Return-Path: <kaduk@mit.edu>
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 F32C912002F; Mon, 6 May 2019 14:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 mDaSVH1P9t9o; Mon, 6 May 2019 14:53:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBCD12001E; Mon, 6 May 2019 14:53:11 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x46Lr6tF013884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 May 2019 17:53:08 -0400
Date: Mon, 6 May 2019 16:53:05 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-netconf-subscribed-notifications@ietf.org" <draft-ietf-netconf-subscribed-notifications@ietf.org>, Kent Watsen <kent+ietf@watsen.net>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190506215305.GR19509@kduck.mit.edu>
References: <155692784695.7217.908270903914526669.idtracker@ietfa.amsl.com> <e20edefac3174473a89c012cad4847ec@XCH-RTP-013.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e20edefac3174473a89c012cad4847ec@XCH-RTP-013.cisco.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4rl2Gc319UoKxWIEOrPBjKh-WAY>
Subject: Re: [netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)
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: Mon, 06 May 2019 21:53:14 -0000

On Mon, May 06, 2019 at 09:46:29PM +0000, Eric Voit (evoit) wrote:
> Hi Benjamin
> 
> > From: Benjamin Kaduk, May 3, 2019 7:57 PM
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netconf-subscribed-notifications-25: Discuss
> > 
> > When responding, please keep the subject line intact and reply to all email
> > addresses included in the To and CC lines. (Feel free to cut this introductory
> > paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > It looks like the description of filter-failure-hint in modify-subscription-stream-
> > error-info needs the same treatment that establish-subscription-stream-error-
> > info  received.
> 
> Done.  You will see in the next update.  I will post after I get a set of thoughts back from Magnus on his DISCUSS.

Sounds good; I've cleared in the datatracker so I can stop paying attention
:)

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > [original comment section replaced]
> > 
> > In the updated security considerations:
> > 
> >    The replay mechanisms described in Sections Section 2.4.2.1 and
> >    Section 2.5.6 provides access to historical event records.  By
> >    design, the access control model that protects these records could
> >    enable subscribers to view data to which they were not authorized at
> >    the time of collection.
> > 
> > Looks like there's some xml2rfc redundancy ("Sections Section").
> 
> Fixed
> 
> >    o  "excluded-event-records": leaf can provide information about
> >       filtered event records.  A network operator should have
> >       permissions to know about such filtering.  Improper configuration
> >       could provide a receiver with information leakage consisting of
> >       the dropping of event records.
> > 
> > In mail I had proposed "Improper configuration could allow a receiver to learn
> > that event records were dropped due to an ACL when the existence of that ACL
> > would otherwise be transparent."; repeating it here just in case it got missed
> > (but this  remains the non-blocking comment section).
> 
> I had thought your other sentence was for information purposes rather than suggested text to include.  Thinking about it, I prefer just sticking with the current 'information leakage' text without explicitly using the word ACL.  

I'm happy that you have considered it and made your decision; you have a
better sense of how things work than I do.

> Thanks again Benjamin for really giving this a good look,

You're welcome!

-Ben