Re: [Netconf] Draft Charter Proposal for NETCONF WG

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 21 March 2017 21:58 UTC

Return-Path: <evoit@cisco.com>
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 65A49127058 for <netconf@ietfa.amsl.com>; Tue, 21 Mar 2017 14:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 VQbWvL-dIPKq for <netconf@ietfa.amsl.com>; Tue, 21 Mar 2017 14:58:56 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61157129A4B for <netconf@ietf.org>; Tue, 21 Mar 2017 14:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3005; q=dns/txt; s=iport; t=1490133536; x=1491343136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mT44xPDuXYBO6CV8CsbeHOCeIIK1atkiUCJfwfGQjAI=; b=CxLO2wWGKLOyoBWYlgcOLcHetokNlELuCgHX9aCEhLMYBJxEn5AQVCwP +e1X6S8IhazYFH2vGRJI52zcbT7zzG5aNA0EGfnM/5FU4aljZdayTW8gb 52wCdSgRVkmC2v7szXlgxGQvXQS4hc6+cXf/9iWPMAAPgavZGLypBelF6 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AUAQBLodFY/5RdJa1bAxkBAQEBAQEBAQEBAQcBAQEBAYMnKmGBCgeNa5FelUSCDh8LhS5KAoMXPxgBAgEBAQEBAQFrKIUVAQEBAQIBAQE4NAsFBwICAgEIDgIFAx4QGwwLJQIEAQ0FCIl0CA6tFopFAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWGSYRvhD43JoUeBZxQAZI8kTaTXgEfOIEEWBVBhld1iDSBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.36,201,1486425600"; d="scan'208";a="221068304"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2017 21:58:55 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2LLwt7u013789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Mar 2017 21:58:55 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Mar 2017 17:58:54 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Tue, 21 Mar 2017 17:58:54 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Mehmet Ersue <mersue@gmail.com>
CC: 'Netconf' <netconf@ietf.org>
Thread-Topic: [Netconf] Draft Charter Proposal for NETCONF WG
Thread-Index: AQHSohv/7XgFhfmC527VzIToNP21LaGf0wcQ
Date: Tue, 21 Mar 2017 21:58:54 +0000
Message-ID: <0f17c698ae2645988692ba1eef007d79@XCH-RTP-013.cisco.com>
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>
In-Reply-To: <20170321082015.GC35044@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.41.34.58]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/rZAXKjb1CG8lgF8ZYdMe3R0sa4w>
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: Tue, 21 Mar 2017 21:58:58 -0000

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. 

(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