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

Hi Alex,

If the implementation calls for a method by which a receiver wants to subscribe to particular notifications, by all means you need to implement SN. However, if all you need to implement is a channel by which notifications can be send from the publisher to the receiver, however that channel is set up, why would you need to implement SN?

Subscription State Change Notification is central to the concept of being able to subscribe to events. It is not central to how notifications are sent.

M

> On Jul 28, 2020, at 3:19 PM, Alexander Clemm <alex@futurewei.com> wrote:
> 
> Hi Kent,
> I am getting a bit confused here.  Are you saying that you would only need to implement the augmentations, not the subscriptions model being augmented?  Subscription State Change Notifications are an integral part of the whole subscription concept.  
> Anyway, I agree this point needs clarification.
> --- Alex
>  
> From: netconf <netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org>> On Behalf Of Kent Watsen
> Sent: Tuesday, July 28, 2020 1:52 PM
> To: Eric Voit (evoit) <evoit=40cisco.com@dmarc.ietf.org <mailto:evoit=40cisco.com@dmarc.ietf.org>>
> Cc: netconf@ietf.org <mailto:netconf@ietf.org>
> Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt
>  
> 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.
> 
> 
>  
>  
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>