Re: [Netconf] YangPush now

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 17 July 2018 19:32 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 54BB212F295 for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 12:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 MgzKGP3vDmpp for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 12:32:26 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id D45E7124BE5 for <netconf@ietf.org>; Tue, 17 Jul 2018 12:32:25 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 2F036234DC76; Tue, 17 Jul 2018 21:32:24 +0200 (CEST)
Date: Tue, 17 Jul 2018 21:32:24 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Tim Jenkins (timjenki)" <timjenki@cisco.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20180717193224.acctssedwfatgcl5@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Tim Jenkins (timjenki)" <timjenki@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <2E1BAD12-EFF2-4E35-B232-57A4C4490989@cisco.com> <20180717055030.7bmzlychtznf3mso@anna.jacobs.jacobs-university.de> <18622ABD-DB9F-406C-836F-64649F3D8FF6@cisco.com> <20180717172036.hhuoq6fzs7ctblpf@anna.jacobs.jacobs-university.de> <1DDEF716-343F-4DF9-AE2C-CBC7B6E0DBD1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1DDEF716-343F-4DF9-AE2C-CBC7B6E0DBD1@cisco.com>
User-Agent: NeoMutt/20180622
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/BcKnKg0ctGbFBWjPIPu6w6_AQA0>
Subject: Re: [Netconf] YangPush now
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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, 17 Jul 2018 19:32:29 -0000

On Tue, Jul 17, 2018 at 06:53:08PM +0000, Tim Jenkins (timjenki) wrote:
> Please see embedded, with prefix [Tim]. Note some editing of the original to separate the questions.
> 
> 
> On 2018-07-17, 1:21 PM, "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de> wrote:
> 
>     I see several pieces but I do not see how the pieces give me a
>     workable solution nor do I see how such a solution gives me
>     interoperability.
> 
> [Tim] Even with your questions below, it's still not clear to me what would be missing. 
>     
>     If I configure a subscription, how does the flow of notifications work
>     over NC and RC?
> 
> [Tim] NETCONF message flows are described in draft-ietf-netconf-subscribed-notifications, Appendix A.3.   RESTCONF is not in WGLC yet, but can be seen at draft-ietf-netconf-restconf-notif, Appendix B.2

There is no A.3 in draft-ietf-netconf-subscribed-notifications. Perhaps
you mean draft-ietf-netconf-netconf-event-notifications-10. No, this
example does not help me understand how notification messages flow. It
only shows how I create a configured subscription.
 
>     How do I configure where the connection goes?
> 
> [Tim] Since we don't implement netconf-server.yang, we do vendor specific stuff to link each receiver to our local call home/dial-out configuration.  There are lots of moving parts here, and we don't expect interoperability for quite a while.  This lack of interoperability is not a result of these subscription drafts though, so waiting for or making a model dependency to pending IETF work in this space will only make things more confusing and add further unnecessary delay to the process.

So you agree that the solution is incomplete.
 
>     What is
>     the RC resource that provides me the notification stream?
> 
> [Tim] Current NETCONF implementation doesn't need this.  RESTCONF isn't used for configured subscriptions.

Well, I do not really know how NETCONF notifications flow. There were
comments raised concerning the use of call home and the need to have a
<hello> exchange etc. There are pieces, but not a workable solution.
 
>    How will
>     all of this work if the endpoints in the future want to negotiate
>     different encodings?
> 
> [Tim] Configured subscriptions aren't negotiable. However, negotiation is defined in the drafts for dynamic subscriptions. I think you can find more on that using a search of the text "configurable-encoding" within the YANG model of draft-ietf-netconf-subscribed-notifications.

So this again seems to depend on transports that are not ready yet. I
am also not sure that you want to replace negotiation of encodings in
the protocols with explicit configuration in the first place but that
is at the end just a minor inconvenience issue. In RC, the client can
easily send an Accept header to negotiate the encoding. If NC does
ever support multiple encodings, this will likely be negotiated
dynamically via the <hello> exchange.

/js

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