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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 03 May 2019 16:57:26 -0700

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.

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

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 6 May 2019 21:46:29 +0000

Hi Benjamin

> From: Benjamin Kaduk, May 3, 2019 7:57 PM
> 
> 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.)
> 
> 
> 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.

Fixed

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 May 2019 16:53:05 -0500

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

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

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