Re: [Netconf] Draft Charter Proposal for NETCONF WG

[Ladislav Lhotka <[e-mail]>]

> On 22 Mar 2017, at 16:28, Eric Voit (evoit) <[e-mail]> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:[e-mail]]
>> Sent: Wednesday, March 22, 2017 5:36 AM
>> To: Jürgen Schönwälder <[e-mail]>
>> Cc: Eric Voit (evoit) <[e-mail]>; Mehmet Ersue
>> <[e-mail]>; Netconf <[e-mail]>
>> Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
>> 
>> 
>>> On 22 Mar 2017, at 09:47, Juergen Schoenwaelder
>> <[e-mail]> wrote:
>>> 
>>> On Wed, Mar 22, 2017 at 08:54:39AM +0100, Ladislav Lhotka wrote:
>>>> 
>>>>> There are two different needs:
>>>>> 
>>>>> (1) RESTCONF over HTTP2:  This is what you are asking for, and I would
>> love to see this as well.  As far as I know, nobody is currently defining this.
>>>> 
>>>> I wonder: is this needed? AFAIK, HTTP/2 methods are semantically
>> equivalent to those of 1.1. We have a working implementation of RESTCONF
>> over HTTP/2 (only) and I am not aware of any change in RESTCONF that was
>> be needed because of HTTP version.
> 
> HTTP2 has a superset of capabilities vs. HTTP1.1.   There are new elements which are quite useful to expose to RESTCONF.
> 
> We had a thread on this in 2015.  You can see some of the possibilities at:
> https://www.ietf.org/mail-archive/web/netconf/current/msg10426.html

All this seems to be related to the plumbing (TCP and SSL) whereas the RESTCONF spec is pretty much independent of it, perhaps except notifications.

Lada

> 
>>> 
>>> I _assume_ there is not much needed but someone has to go and check
>>> the details.
>>> 
>>>> Regarding HTTP/2 Server Push, its purpose is IMO different, so it cannot
>> serve as a replacement to SSE.
>>> 
>>> Is that just a feeling or a claim or is there additional technical
>>> detail why this would be the case?
>> 
>> It's used if the server expects some request from the client to follow, and the
>> PUSH_PROMISE frame sent by the server must contain the headers from the
>> expected request. With notifications there are no requests expected from the
>> client.
> 
> Yes.   And as HTTP2 allows different streams, the headers+notifications can go onto different streams so that higher priority notifications can avoid head-of-line blocking issues.   There is no RESTCONF interactions/encapsulation which is needed for this interaction.
> 
> Eric
> 
>> A more detailed explanation is here (search for SSE):
>> 
>> https://www.infoq.com/articles/websocket-and-http2-coexist
>> 
>> Lada
>> 
>>> 
>>> /js
>>> 
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   [phone]         <http://www.jacobs-university.de/>
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> 
>> 
>> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67