Subject: Re: [Netconf] RFC 8030 on Generic Event Delivery Using HTTP Push

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Dec 2016 17:48:30 +0100

Hi,

this may be relevant for some of the discussions here.

/js

On Thu, Dec 08, 2016 at 08:42:03AM -0800, [email-masked] wrote:
> A new Request for Comments is now available in online RFC libraries.
> 
>         
>         RFC 8030
> 
>         Title:      Generic Event Delivery Using HTTP Push 
>         Author:     M. Thomson, 
>                     E. Damaggio,
>                     B. Raymor, Ed.
>         Status:     Standards Track
>         Stream:     IETF
>         Date:       December 2016
>         Mailbox:    [email-masked], 
>                     [email-masked], 
>                     [email-masked]
>         Pages:      31
>         Characters: 68069
>         Updates/Obsoletes/SeeAlso:   None
> 
>         I-D Tag:    draft-ietf-webpush-protocol-12.txt
> 
>         URL:        https://www.rfc-editor.org/info/rfc8030
> 
>         DOI:        10.17487/RFC8030
> 
> This document describes a simple protocol for the delivery of real-
> time events to user agents.  This scheme uses HTTP/2 server push.
> 
> This document is a product of the Web-Based Push Notifications Working Group of the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 8 Dec 2016 20:41:14 +0000

Thanks for the pointer Juergen,

The RFC does support common functional requirements such as:
- DDoS protection method for HTTP2
- Prioritized messages
- many subscriptions per transport session 
- others

But there were several reasons it doesn't match sufficiently for reuse with yang data stores.  Some deltas between the environments include:
- Push Service as a Subscriber proxy, with caching and possible push update aggregation (intended to save radio power)
- multiple resource targets within a single subscription
- configured subscription support
- content/event filtering
- yang
- event dampening, on-change, and periodic
- Use of GET to subscription resource (GRPC compatibility)
- negotiation

Therefore I see this as a useful reference and context rather than something normative that we can build upon.

We shouldn't forget this though as there are also items we might want to adopt at some future point:
- the Subscriber proxy model
- push update TTL
- tracked acknowledgement of push updates

Eric

> From: Juergen Schoenwaelder, December 8, 2016 11:49 AM
> 
> Hi,
> 
> > protocol for the Internet community, and requests discussion and
> > suggestions for improvements.  Please refer to the current edition of
> > the Official Internet Protocol Standards
> > (https://www.rfc-editor.org/standards) for the standardization state
> > and status of this protocol.  Distribution of this memo is unlimited.
> >
> > author of the RFC in question, or to [email-masked].
> > Unless specifically noted otherwise on the RFC itself, all RFCs are
> > for unlimited distribution.
> >
> >
> > The RFC Editor Team
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Dec 2016 14:27:57 -0800

On Thu, Dec 8, 2016 at 12:41 PM, Eric Voit (evoit) <[email-masked]> wrote:

> But there were several reasons it doesn't match sufficiently for reuse
> with yang data stores.  Some deltas between the environments include:
> - Push Service as a Subscriber proxy, with caching and possible push
> update aggregation (intended to save radio power)
> Therefore I see this as a useful reference and context rather than
> something normative that we can build upon.
>
>

I don't agree that all these things are needed or they cannot be done as
part of the application.
Not sure what YANG support means either.  This does not seem to affect the
bytes on the wire.

I prefer to separate the protocol layers.  The part that selects what
events to send and
other optimizations related to content selection should not be coupled to
how notifications
are delivered.

We shouldn't forget this though as there are also items we might want to
> adopt at some future point:

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 8 Dec 2016 22:43:42 +0000

I could have also answered that RFC 8030 is a proxy caching protocol optimized for intermittent/ low-power connectivity to smartphones.

It would be difficult to retrofit to this environment.  I would be intrigued to see the result if someone attempted this.

Eric

From: Andy Bierman, December 8, 2016 5:28 PM

On Thu, Dec 8, 2016 at 12:41 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the pointer Juergen,

I don't agree that all these things are needed or they cannot be done as part of the application.
Not sure what YANG support means either.  This does not seem to affect the bytes on the wire.

I prefer to separate the protocol layers.  The part that selects what events to send and
other optimizations related to content selection should not be coupled to how notifications
are delivered.

Eric

Andy

> On Thu, Dec 08, 2016 at 08:42:03AM -0800, [email-masked]<mailto:[email-masked]> wrote:
> >         Mailbox:    [email-masked]<mailto:[email-masked]>,
> >                     [email-masked]<mailto:[email-masked]>,
> >                     [email-masked]<mailto:[email-masked]>
> >         Pages:      31
> >         Characters: 68069
> > author of the RFC in question, or to [email-masked]<mailto:[email-masked]>.
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Dec 2016 15:19:49 -0800

On Thu, Dec 8, 2016 at 2:43 PM, Eric Voit (evoit) <[email-masked]> wrote:

> I could have also answered that RFC 8030 is a proxy caching protocol
> optimized for intermittent/ low-power connectivity to smartphones.
>
>
>
> It would be difficult to retrofit to this environment.  I would be
> intrigued to see the result if someone attempted this.
>
>
>
You are probably right.
I don't want to imply I support this approach for  NETCONF and RESTCONF.

Eric

Andy

>
>
> *From:* Andy Bierman, December 8, 2016 5:28 PM
>