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

From: [email-masked]
Date: Mon, 27 Jul 2020 08:39:11 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : An HTTPS-based Transport for Configured Subscriptions
        Authors         : Mahesh Jethanandani
                          Kent Watsen
	Filename        : draft-ietf-netconf-https-notif-04.txt
	Pages           : 27
	Date            : 2020-07-27

Abstract:
   This document defines a YANG data module for configuring HTTPS based
   configured subscription, as defined in RFC 8639.  The use of HTTPS
   maximizes transport-level interoperability, while allowing for
   encoding selection from text, e.g.  XML or JSON, to binary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 27 Jul 2020 08:45:37 -0700

This version of the document addresses comments received from Eric, and updates to the ietf-truststore module.

> On Jul 27, 2020, at 8:39 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani (as co-author)
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 27 Jul 2020 16:52:43 +0000

Hi Mahesh,

Thanks for updating the text.  One question, are you sure you need the
statement:

                 This example shows the flow assuming that	
 	   Subscribed Notifications is used and therefore a <subscription-

 	   started> notification is sent before sending the first
notification.	
 	   The example would be the same for when Subscribed Notification is
not	
 	   used by removing the first POST message for
<subscription-started>.

I am guessing that you mean "Subscription State Change Notifications" here
rather than "Subscribed Notifications".   As RFC-8639 Subscription State
Change Notifications are mandatory, is this statement necessary here?

Perhaps you could add a non-normative appendix which shows the implications
of dropping specific Subscription State Change Notifications If an
implementation desires this simplification?  E.g., issues with supporting
replay, issues with understanding what subscription is sending traffic, no
ability to see if the terms of the subscription changed, no awareness of
subscription suspend, no way to signal the end/termination of a
subscription, etc.  

All of these might be absolutely ok in an implementation, but it might be
worth addressing in aggregate in a place which is outside the bounds of the
normative text.

Eric

> -----Original Message-----
> From: netconf <[email-masked]> On Behalf Of Mahesh
> Jethanandani
> Sent: Monday, July 27, 2020 11:46 AM
> To: [email-masked]
> Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt
> 
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> tools.ietf.org.
> >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 Jul 2020 12:00:53 +0000

Hi Mahesh,

What I was trying to ask during the IETF session was the following:

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

If there are mandatory SN elements which are sometimes optional, could you
explicitly list these 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?

Thanks,

Eric

> From: netconf <[email-masked]> On Behalf Of Eric Voit (evoit)

> Sent: Monday, July 27, 2020 12:53 PM

> To: Mahesh Jethanandani <[email-masked]>; [email-masked]

>                The example would be the same for when Subscribed
Notification

> is

>                used by removing the first POST message for <subscription-

> started>.

> Perhaps you could add a non-normative appendix which shows the

> implications of dropping specific Subscription State Change Notifications
If

> an implementation desires this simplification?  E.g., issues with
supporting

> > From: netconf < <mailto:[email-masked]>
[email-masked]> On Behalf Of Mahesh

> > To:  <mailto:[email-masked]> [email-masked]

> > Subject: Re: [netconf] I-D Action:

> > draft-ietf-netconf-https-notif-04.txt

> > This version of the document addresses comments received from Eric,

> > and updates to the ietf-truststore module.

> > > On Jul 27, 2020, at 8:39 AM,  <mailto:[email-masked]>
[email-masked] wrote:

> > > A New Internet-Draft is available from the on-line Internet-Drafts

> > directories.

> > >        Title           : An HTTPS-based Transport for Configured

> Subscriptions

> > >   This document defines a YANG data module for configuring HTTPS

> based

> > >  <https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/>

> > >  <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04>

<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif>
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif

> > > -0

> > > 4

> > >  <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-04>

> > >  <ftp://ftp.ietf.org/internet-drafts/>

> > >  <mailto:[email-masked]> [email-masked]

> > >  <https://www.ietf.org/mailman/listinfo/netconf>

> >  <mailto:[email-masked]> [email-masked]

> >  <mailto:[email-masked]> [email-masked]

> >  <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 28 Jul 2020 20:52:28 +0000

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: 

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.

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Jul 2020 22:19:23 +0000

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 <[email-masked]> On Behalf Of Kent Watsen
Sent: Tuesday, July 28, 2020 1:52 PM
To: Eric Voit (evoit) <evoit=[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt

Hi Eric,

Ack, see above.

K.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 28 Jul 2020 15:33:14 -0700

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 <[email-masked]> wrote:
> 
> Hi Kent,
> From: netconf <[email-masked] <mailto:[email-masked]>> On Behalf Of Kent Watsen
> To: Eric Voit (evoit) <evoit=[email-masked] <mailto:evoit=[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 28 Jul 2020 22:35:27 +0000

Hi Mahesh,
thank you for your explanation.  Let’s put that separation and clarification in the draft.
--- Alex

From: Mahesh Jethanandani <[email-masked]>
Sent: Tuesday, July 28, 2020 3:33 PM
To: Alexander Clemm <[email-masked]>
Cc: Kent Watsen <[email-masked]>; Eric Voit (evoit) <evoit=[email-masked]>; [email-masked]
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt

Hi Alex,

M

On Jul 28, 2020, at 3:19 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Kent Watsen
Sent: Tuesday, July 28, 2020 1:52 PM
To: Eric Voit (evoit) <evoit=[email-masked]<mailto:evoit=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt

Hi Eric,

Ack, see above.

K.

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7Calex%40futurewei.com%7C944e59ccecff415bfaf608d8334639a6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315724011722182&sdata=0lkOxGpZVfMNO6ae3JXpzHD26Im5Pni2UGspP%2BEmtfs%3D&reserved=0>