Re: [Netconf] YangPush now
Andy Bierman <andy@yumaworks.com> Thu, 26 July 2018 03:21 UTC
Return-Path: <andy@yumaworks.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 D0816130F7E for <netconf@ietfa.amsl.com>; Wed, 25 Jul 2018 20:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 KVQvQYUFfxhB for <netconf@ietfa.amsl.com>; Wed, 25 Jul 2018 20:21:37 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2ECC130F46 for <netconf@ietf.org>; Wed, 25 Jul 2018 20:21:36 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id g6-v6so168384lfb.11 for <netconf@ietf.org>; Wed, 25 Jul 2018 20:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hxtALU4zN5dJiExft1spNr/2GagLfzkuVHm/1QmPq7w=; b=pwawEAmWJvsqZf/aYbSXlDWejc0q97hYJx4mXS8wRmRaz5pJaSR2umwdUo9NM6w6qi fRXmzo1dvLu4WkHW8a6tR2gBaNZbBi5elGg4M+nJSB1Q6JrinCXYS8Qgm42giUZxzJP2 KneIxj6Kf7w2eGChRbPz2o4bi12X08kBJUtmtIaBafq2Wv+MBIDn1VGfQ90ma3AMUt+J TWfo6WtCfO2c/M5McaQ3476PuNg6OhBbUKO68LAYwd8akKNQDO8nxr74wXllwN8b613u SbhNdKKgcQ+Qb71Og7eYgJ/Raks03ZEU6+w59jPttMvVwhoYccB55Ld/ZjHMM2vSgypF +2+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hxtALU4zN5dJiExft1spNr/2GagLfzkuVHm/1QmPq7w=; b=bDlsy7NUQpbE5KQ/NIpyliSy5od78LC8gYh2P2VBPpPTYcC0P5CViibh+4EDpf41eA bSOddrC8rDc3TMOAnsO27xSb98vB1WzuoOi8TWcaMHf+Q1lrUhW5n9cRdLE2DwyPNnaa AiepJLtwwZxjNN9TjxQwwOSrmrrOIvfJMk+A2km2D5z+uVSdHe69XAmglkoAlsY530JF x5K20l03lqYtKOx+iYFecmXDWleOeaqb/R3S56cNW0sMOFft3W673Dd1En90cwi0YBeH 7Hi+mf+1UXh1lWOOPLno34M/QVlOrVS7WblUSZIZPPY/JsvHUjzj5CBxDck6pgSQXlDh TuLw==
X-Gm-Message-State: AOUpUlFVwWE/N4CNpBc7qHQZhi3Mgt9iR4Llb809+1pkzwdBM/VguI2C kxRsKn/eCZtzj7cB64NxVmlVr3+7mZsyLQXgSzr/7A==
X-Google-Smtp-Source: AAOMgpcNG90fINCPXQMPYdCXYJ0c5o/QVASJ0lQZdB82XdbQUTgEyji27E3mJvRjktFoZRyaYfbehHB5WEC7Wr5QNQA=
X-Received: by 2002:a19:d819:: with SMTP id p25-v6mr95438lfg.36.1532575294970; Wed, 25 Jul 2018 20:21:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 20:21:33 -0700 (PDT)
In-Reply-To: <406f2a12fdd745c18e0f11dd9fbb26eb@XCH-RTP-013.cisco.com>
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> <CABCOCHS8cfqKLaQe9M4tu-2zkZ5=6-a2FEv+idJwZiW_btx_Zw@mail.gmail.com> <a54850668bfb4483b89f4c2b15bf5f44@XCH-RTP-013.cisco.com> <20180718133200.u7fpsv3xanb2nosr@anna.jacobs.jacobs-university.de> <6707abca9924442083ef165ce1345b7e@XCH-RTP-013.cisco.com> <20180720101419.7chri56rzgyidxmw@anna.jacobs.jacobs-university.de> <3b194cc7276b4e888c4e8b808d1c356a@XCH-RTP-013.cisco.com> <20180723141416.mdzwa53nganbadbu@anna.jacobs.jacobs-university.de> <406f2a12fdd745c18e0f11dd9fbb26eb@XCH-RTP-013.cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 25 Jul 2018 20:21:33 -0700
Message-ID: <CABCOCHRmuCQtkzN4u43Gi4kfLifUoAcNYZg2K1ZR5Rg60L_u9g@mail.gmail.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Tim Jenkins (timjenki)" <timjenki@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000c6fa90571de7e2f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/jYZPe0mXuwuaFYVs17-CxoD3w54>
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: Thu, 26 Jul 2018 03:21:42 -0000
Hi, IMO there is a good enough plan in place to complete the configured subscriptions. The co-authors have done enough revisions. It is time to finish the drafts. We should let vendors experiment and also try to create a standard binary protocol. Andy On Tue, Jul 24, 2018 at 4:56 PM, Eric Voit (evoit) <evoit@cisco.com> wrote: > Hi Juergen, > > > From: Juergen Schoenwaelder, July 23, 2018 10:14 AM > > > > On Fri, Jul 20, 2018 at 06:47:48PM +0000, Eric Voit (evoit) wrote: > > > Hi Juergen, > > > > > > > From: Juergen Schoenwaelder, July 20, 2018 6:14 AM > > > > > > > > On Thu, Jul 19, 2018 at 09:41:00AM +0000, Eric Voit (evoit) wrote: > > > > > > > > > That is what I was hoping would be accomplished with the text: > > > > > > > > > > The method of identifying the targeted receiver IP address, > port, and > > > > > security credentials are left up to implementers of this > > > > > specification. For implementation guidance and a YANG model for > > this > > > > > function, please look to > > > > > [I-D.draft-ietf-netconf-netconf-client-server]. > > > > > > > > I said this is to vague for me to understand. Repeating the pointer > > > > does not help me to understand. If this I-D has a clear solution, > > > > why not put it in place? > > > > > > The recommended solution is for vendors to augment in their own > > leafrefs into existing vendor specific call home configurations. > > Alternatively, solutions can be integrated within non-YANG based > > configuration structures. This is how our configured subscription > > implementation works. > > > > > > To clarify the recommended solution, I have updated the reference above > > to: > > > > > > The method of identifying the targeted receiver IP address, port, and > > security credentials are left up to implementers of this specification. > For > > implementation guidance on how a leafref might constructed to accomplish > > this function, consider the following augmentation which would need to be > > made if the necessary connection parameters are maintained with ietf- > > netconf-client.yang as specified by [I-D.draft-ietf-netconf- > netconf-client- > > server]. > > > > > > import ietf-netconf-client { prefix ncc; } > > > import ietf-subscribed-notifications { prefix sn; } > > > import ietf-netconf-subscribed-notifications { prefix nsn; } > > > > > > augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" > { > > > when 'derived-from(../../../transport, "nsn:netconf")'; > > > leaf netconf-endpoint { > > > type leafref { > > > path "/ncc:netconf-client/ncc:initiate/ncc:netconf- > > server/ncc:endpoints/ncc:endpoint/ncc:name"; > > > } > > > description > > > "Points to a remote NETCONF client intended to support a > particular > > configured subscription."; > > > } > > > } > > > > So why do we create a _standard_ that says take the other standard and > > then roll your own non-standard module to make them work together? > > My reading of your request was to make the current draft text less vague. > Hopefully providing an example augmentation based on a referenced > standard-in-progress removes this ambiguity. > > I would hope that when the other standard is ready, it doesn't take > something non-standard to bind them. There are earlier threads on how this > might be done. > > > > > > To cover this, there is the following text in Section 5 of > > > > > draft-ietf-netconf- > > > > netconf-event-notifications: > > > > > > > > > > publisher SHOULD place the receiver into the > > > > > "timeout" state after a predetermined number of either failed > call > > > > > home attempts or NETCONF sessions remotely terminated by the > > > > > receiver. > > > > > > > > > > Until NETCONF transport with a receiver has been established, > and a > > > > > "subscription-started" state change notification has been > > > > > successfully sent for a configured subscription, that > subscription's > > > > > receiver MUST remain in either the "connecting" or the "timeout" > > > > > state. > > > > > > > > <-- call home --> > > > > C: <hello> > > > > S: <hello> > > > > S: <notification> > > > > <-- session terminated --> > > > > > > > > The server believes 'notification has been successfully sent'. The > > > > other alternative would be a client that throws away notification > > > > messages not > > > > expected: > > > > > > > > <-- call home --> > > > > C: <hello> > > > > S: <hello> > > > > S: <notification> // -> discarded > > > > S: <notification> // -> discarded > > > > S: <notification> // -> discarded > > > > [...] > > > > > > > > Both scenarioes are problematic. > > > > > > Agree that there are these two scenarios. > > > > > > The first scenario isn't elegant, but I don't see it as problematic. > Per SN, > > transport loss places all receivers back into their connecting state. > And the > > NETCONF-Notif text quoted above shows that multiple session terminations > > places the subscription into "timeout" so that something can figure out > > what is wrong. > > > > > > The second scenario requires that NETCONF Call home is successfully > > configured with the right credentials on both sides of the connection, > and > > that the receiver's NETCONF client implementation is unable to terminate > a > > session receiving unwanted notification traffic. This is a concern, but > an > > implementer at least has some protections by controlling the call home > > connectivity parameters tied to a specific receiver. (See continue > reasoning > > below) > > > > There is nothing in NETCONF that requires a client to terminate a > session if > > the client receives an unexpected message. The control of call home > > parameters is no answer (first this is out of hands for the implementor > and > > second the problem is likely a misconfiguration in the first place that > leads > > to something not useful). I do not think your answers provide a solution > - I > > am not interested in justifications. > > A solution based on the correct call home parameter configuration does > work. But other than that, I agree with you: the current NETCONF > configured subscription solution does take some valid error conditions out > of the hands of implementers, and places them in the hands of operators. > > The biggest question I see is whether implementers want to do the leg-work > needed to building out the client capability advertisement capability to > protect against these failure scenarios. It would be great if NETCONF > implementers signaled they are ready to pick this up. > > > > > This is why I suggested that there needs to be some mechanism that > > > > tells the server that the client is willing to receive configured > > > > subscriptions before the server throws <notification> messages at > > > > the client. You will find differnet ideas in the mailing list > archive. > > > > > > In talking about this issue in the past, suggestions were made that the > > NETCONF client could advertise its capabilities for supporting configured > > subscriptions as part of the hello exchange. And that can be a > partial(*) > > solution to the problem. However there was pushback to this based on > > NETCONF client to server implementations not typically exchanging and > > interpreting the results of NETCONF client asserted capabilities. > > > > > > (*) the reason it is partial is that even if the client advertises > support for > > NETCONF configured subscriptions, there is still the possibility that > > something goes wrong with the receiver's receiving process with the > second > > scenario above. In which case you still need to have a way to terminate > the > > incoming notification stream by pulling down the NETCONF session. Still, > > there are obviously benefits of client capability signaling as an extra > layer of > > misconfiguration protections included. > > > > Simply pushing data to a receiver before checking that the receiver is > willing > > and able to consume the data is in my view not good protocol design. > There > > are cases where this is unavoidable but here we do have a client and > server > > talking to each other that can do better. > > > > > Looking at what is in the v10 draft, there are some protections for > both > > your scenarios above. But certainly it is not robust. And certainly > having > > the client advertise configured receiver support would be nice, but this > > would require more development. As based on the amount of > > development, we used the design philosophy of "it is better to start > with > > an 80% solution than a 120% solution :-)." > > > > There was also another proposal, namely to have the client request the > > start of notifications (like you would do with RC and SSE). I do not buy > the > > 80% solution argument for an excuse of poor protocol design. > > The other proposal is absolutely a valid way to do this. And as Andy and > others have pointed out, the current dynamic <establish-subscription> RPC > can be kicked off by such a process. > > However the call flow has more error conditions. As a result, three > years ago during scoping of the current suite of IETF subscription drafts, > this proposal was determined to be out-of-scope. This decision was not > necessarily a bad choice as I have seen proprietary non-NETCONF configured > subscription deployments thrive without a publisher requesting that a > client invoke the <establish-subscription>. > > As a result of the decision several years ago, no one has proposed an IETF > standards based call flow to invoke a client based > <establish-subscription>. It would be excellent if someone wanted to > propose a draft for this. > > > > I agree that the current protection could have an improved description. > > So I have placed the following text into the NETCONF-Notif security > > considerations section: > > > > > > " For a configured subscription, if NETCONF call home has been > configured > > with the working credentials, yet that the receiver's NETCONF client > > implementation is both unable to process inbound notifications and unable > > to terminate a session receiving unwanted traffic, then the receiver may > > receive unwanted event records. To minimize this risk, a publisher > > implementation should use dedicated call home connectivity port numbers > > and credentials specific to configured subscriptions. This will > minimize the > > chance that an unplanned NETCONF receiver will receive configured > > subscription notifications unexpectedly." > > > > Well, I would rather fix the issue than pushing the problem ultimately to > > operators. > > Your position is a valid one for sure. I have not yet heard of operator > wanting to attempt these more robust configuration protection mechanisms > yet. And as noted above, this is not a key use case for the deployments I > am seeing yet. > > Eric > > > /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/> >
- Re: [Netconf] Anyone want just Configured Subscri… Balazs Lengyel
- [Netconf] YangPush now Balazs Lengyel
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Qin Wu
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Henk Birkholz
- [Netconf] Anyone want just Configured Subscriptio… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Martin Bjorklund
- Re: [Netconf] Anyone want just Configured Subscri… Juergen Schoenwaelder
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Martin Bjorklund
- Re: [Netconf] Anyone want just Configured Subscri… Juergen Schoenwaelder
- Re: [Netconf] Anyone want just Configured Subscri… Martin Bjorklund
- Re: [Netconf] Anyone want just Configured Subscri… Martin Bjorklund
- Re: [Netconf] Anyone want just Configured Subscri… Martin Bjorklund
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Martin Bjorklund
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Martin Bjorklund
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Alexander Clemm
- Re: [Netconf] Anyone want just Configured Subscri… Tianran Zhou
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Juergen Schoenwaelder
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Juergen Schoenwaelder
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Juergen Schoenwaelder
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Eric Voit (evoit)
- Re: [Netconf] Anyone want just Configured Subscri… Juergen Schoenwaelder
- Re: [Netconf] Anyone want just Configured Subscri… Kent Watsen
- Re: [Netconf] Anyone want just Configured Subscri… Juergen Schoenwaelder
- Re: [Netconf] Anyone want just Configured Subscri… Andy Bierman
- Re: [Netconf] Anyone want just Configured Subscri… Lou Berger
- Re: [Netconf] YangPush now Robert Wilton
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Henk Birkholz
- Re: [Netconf] YangPush now Igor Bryskin
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Henk Birkholz
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Kent Watsen
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Alexander Clemm
- Re: [Netconf] YangPush now Kent Watsen
- Re: [Netconf] YangPush now Alexander Clemm
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Robert Wilton
- Re: [Netconf] YangPush now Henk Birkholz
- Re: [Netconf] YangPush now Alexander Clemm
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Reshad Rahman (rrahman)
- Re: [Netconf] YangPush now Kent Watsen
- Re: [Netconf] YangPush now Henk Birkholz
- Re: [Netconf] YangPush now Juergen Schoenwaelder
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Balazs Lengyel
- Re: [Netconf] YangPush now Tim Jenkins (timjenki)
- Re: [Netconf] YangPush now Juergen Schoenwaelder
- Re: [Netconf] YangPush now Tim Jenkins (timjenki)
- Re: [Netconf] YangPush now Juergen Schoenwaelder
- Re: [Netconf] YangPush now Tim Jenkins (timjenki)
- Re: [Netconf] YangPush now Juergen Schoenwaelder
- Re: [Netconf] YangPush now Tim Jenkins (timjenki)
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Juergen Schoenwaelder
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Tim Jenkins (timjenki)
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Kent Watsen
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Kent Watsen
- Re: [Netconf] YangPush now Juergen Schoenwaelder
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Juergen Schoenwaelder
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Robert Wilton
- Re: [Netconf] YangPush now Kent Watsen
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Kent Watsen
- Re: [Netconf] YangPush now Eric Voit (evoit)
- Re: [Netconf] YangPush now Martin Bjorklund
- Re: [Netconf] YangPush now Andy Bierman
- Re: [Netconf] YangPush now Juergen Schoenwaelder