Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt

[Kent Watsen <[e-mail]>]

Hi Eric,

> There are many downsides to *not* including the Subscription State Change Notifications, including the DOS attacks listed below.   As several people mentioned during the session, the draft isn't clear on which elements of https-notif require SN, and which do not. 

Disagree, as it’s obvious that *implementing* the modules requires SN, while not implementing them doesn’t.  But, per your comment below, it would be good to float this point towards the beginning.


> Additionally, the intro section of https-notif isn't clear here: 
>      This document defines two YANG 1.1 [RFC7950] data
>     modules, one for augmenting the Subscription to YANG Notifications
>      [RFC8639] to add a transport type, and another for configuring and
>     managing HTTPS based receivers for the notifications.
> The first time I understand all of SN isn't mandatory is Section 8.2.

Ack, see above.


> If there are mandatory SN elements which are sometimes optional, could you explicitly list these in the draft?

This draft does not “update” RFC 8639.  No change to RFC8639 normative text exists in the draft.


> Also could you list what the potential downsides of excluding mandatory might be, and when these potential downsides can be safely discounted?

An enumerated list would be overkill.  A passing comment is sufficient.  The following seems about right:  

  “Using the 'https-notif’ transport outside of RFC 8639 MAY be desirable in cases where a simple notification-delivery mechanism is sufficient for the intended use.  When advanced delivery features are needed (e.g., replay, QoS), RFC 8639 is SHOULD be used.”


K.