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

["Eric Voit (evoit)" <[e-mail]>]

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.

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

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