Re: [Netconf] Draft Charter Proposal for NETCONF WG

Ladislav Lhotka <lhotka@nic.cz> Wed, 22 March 2017 07:54 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C401813145B for <netconf@ietfa.amsl.com>; Wed, 22 Mar 2017 00:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mW6PXH76N4w2 for <netconf@ietfa.amsl.com>; Wed, 22 Mar 2017 00:54:45 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267BC13145A for <netconf@ietf.org>; Wed, 22 Mar 2017 00:54:44 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:58a4:d470:9e82:39e0] (unknown [IPv6:2001:718:1a02:1:58a4:d470:9e82:39e0]) by mail.nic.cz (Postfix) with ESMTPSA id E0AA260129; Wed, 22 Mar 2017 08:54:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490169282; bh=pYsNBaTQTOX1omYo505GkRGMwlUMg+JN3YpdomqSFQE=; h=From:Date:To; b=qphg98Khh+0ZbK8ZBjPwNUQmj4Zv22oLBb4KGWNu7vsttX1hDamGe80vjqao6P0cN 9JY7ft51N8PF3flV3ykm7x6s3nFkU4Lfalc+VE6UQ3SxgWUM3Ta3IESf3WTKuIwEJ5 idODGltL/YBPreRwQ4WhukUJm+G7QGtTwF63wqjQ=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <0f17c698ae2645988692ba1eef007d79@XCH-RTP-013.cisco.com>
Date: Wed, 22 Mar 2017 08:54:39 +0100
Cc: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>, Mehmet Ersue <mersue@gmail.com>, Netconf <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <37950223-F83B-40FD-8CA4-9A790D0A917E@nic.cz>
References: <00b201d2942b$32395b50$96ac11f0$@gmail.com> <014701d29753$bb651790$322f46b0$@ndzh.com> <CABCOCHSacn15vfo8MR0K-UJJo6E0AZ14Gwj3M43KYkgbtwK8Kg@mail.gmail.com> <005101d2975f$ae87ac20$0b970460$@ndzh.com> <017d01d29769$0df70b20$29e52160$@gmail.com> <010701d29771$a45f66e0$ed1e34a0$@ndzh.com> <026601d2977f$8d059600$a710c200$@gmail.com> <685B9088-7557-4C6E-9A8F-54C3208DB312@juniper.net> <7217bc23-0e1e-c250-929d-e18c3f0a800f@cisco.com> <07b601d2a197$9865d5b0$c9318110$@gmail.com> <20170321082015.GC35044@elstar.local> <0f17c698ae2645988692ba1eef007d79@XCH-RTP-013.cisco.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
X-Mailer: Apple Mail (2.3259)
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/puFwNk1pIut_LHbxkoYUpHLKGbE>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2017 07:54:49 -0000

> On 21 Mar 2017, at 22:58, Eric Voit (evoit) <evoit@cisco.com> wrote:
> 
> Hi Juergen,
> 
>> -----Original Message-----
>> From: Juergen Schoenwaelder, March 21, 2017 4:20 AM
>> 
>> On Mon, Mar 20, 2017 at 05:32:41PM +0100, Mehmet Ersue wrote:
>>>   - Definition of notifications sent over NETCONF and how YANG
>>>     notifications are encoded in XML and JSON. Include considerations
>>>     for parallel support / implementation compatibility with RFC-5277.
>>> 
>>>   - Definition of notifications sent over RESTCONF and HTTP2 and how
>>>     YANG notifications are encoded in XML and JSON. Include specifics
>>>     of call-home and heartbeat for subscriptions.
>> 
>> I believe we do have specifications how YANG defined notifications are
>> encoded in XML and JSON. Do we plan to redo this? I do not think so.
> 
> No plans to redo this.  The only thing this shows is that there are plans to provide examples which match to the Network Subscriptions space.
> 
>> Perhaps it needs to be state more clearly what the scope of this work is and
>> what it is not.
>> 
>> And what is HTTP2 doing here? I assume this is about replacing the Server-
>> Sent Events (SSE) mechanism with HTTP/2 push. I checked RFC
>> 8040 and it specifically says:
>> 
>>   This document defines a protocol based on HTTP [RFC7230] called
>>   "RESTCONF", for configuring data defined in YANG version 1 [RFC6020]
>>   or YANG version 1.1 [RFC7950], using the datastore concepts defined
>>   in the Network Configuration Protocol (NETCONF) [RFC6241].
>> 
>> Note that RFC 7230 is HTTP/1.1. I think the WG really needs to write a
>> document that defines RESTCONF over HTTP/2 and not just notifications over
>> HTTP/2. Such a document may very well say that almost nothing needs
>> changes to run over HTTP/2 except the notification delivery being done
>> differently. But I think the scope should be RESTCONF over
>> HTTP2 and not RESTCONF notifications over HTTP2.
> 
> 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.

Regarding HTTP/2 Server Push, its purpose is IMO different, so it cannot serve as a replacement to SSE.

Lada

> 
> (2) Notifications over HTTP2:  for Configured Subscriptions, there is no need for any RESTCONF involvement when the resulting stream of Notifications is delivered over HTTP.  In addition, there are multiplexing, QoS, and other benefits if the Notifications are delivered over HTTP2.   I believe the NETCONF WG has an interest in this issue the same notification structures can be used as would also be used with does Dynamic Subscriptions established using RESTCONF control plane messages.
> 
> Eric
> 
> 
>> /js
>> 
>> --
>> 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/>
>> 
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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