Re: [Netconf] SSE and HTTP/2 in restcon-notif

Qin Wu <> Fri, 28 September 2018 03:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01A75130DD3 for <>; Thu, 27 Sep 2018 20:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 83VFvZQvr5CK for <>; Thu, 27 Sep 2018 20:40:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C6051271FF for <>; Thu, 27 Sep 2018 20:40:32 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 83E92721ECD70 for <>; Fri, 28 Sep 2018 04:40:28 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 28 Sep 2018 04:40:29 +0100
Received: from ([]) by ([]) with mapi id 14.03.0399.000; Fri, 28 Sep 2018 11:40:25 +0800
From: Qin Wu <>
To: Andy Bierman <>, Martin Bjorklund <>
CC: Netconf <>, "" <>
Thread-Topic: [Netconf] SSE and HTTP/2 in restcon-notif
Date: Fri, 28 Sep 2018 03:40:25 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B055E63nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Netconf] SSE and HTTP/2 in restcon-notif
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Sep 2018 03:40:35 -0000

>    I envision the variation being relatively
>    minor, something along the line of:
>      if 1.1, then SSE.
>      if 2.0, client MAY open a stream first.
> 3) resource URIs
>    This is likely where we need to spend the most time. We know that
>    establish-subscription returns a dynamically created URI, comparable
>    to what a client might get from ietf-restconf-monitoring:restconf-state\
>    /streams/stream/access/location.

But it is not quite comparable.  In the 8040 solution, the location
url is static, and then query parameters are provided by the client
in the POST to the SSE location.  Thus, the server can free any
resources associated with the filter when the connection is

The RESTCONF procedure starts with the client
examining /restconf-state/streams to determine stream and its location URL
How does this monitoring information relate to the new solution?
I assume both the old and new procedures can be supported by the same server.
Is it just ignored for a new subscription?

Since all SSE data is always media type test/event-stream, each stream entry indicates
its secondary encoding format. This leaf is type string, and only 'xml' and 'json' are supported
in RFC 8040. The establish-subscription RPC has its own leaf for this purpose.

[Qin]: I am lost, should resource URIs returned by establish-subscription same as location URL obtained from
My understanding is if SSE is supported, let’s say HTTP 1.1, we will use location URL returned from
as input parameter to trigger SSE. In case of SSE being supported, HTTP GET(URI) is not needed ? wrong?
But if SSE is not supported, let’s say HTTP/2, location URL is not needed. HTTP POST(URI) is required.
Please correct me, if I am wrong.