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

[Benjamin Kaduk <[e-mail]>]

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