Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
Andy Bierman <andy@yumaworks.com> Mon, 27 November 2017 16:26 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 9DBD3126C3D for <netconf@ietfa.amsl.com>; Mon, 27 Nov 2017 08:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-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 3KWZvHS_NV0Q for <netconf@ietfa.amsl.com>; Mon, 27 Nov 2017 08:26:13 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 2506D12426E for <netconf@ietf.org>; Mon, 27 Nov 2017 08:26:12 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id y2so32509937lfj.4 for <netconf@ietf.org>; Mon, 27 Nov 2017 08:26:12 -0800 (PST)
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=z6eAhkVZYHHFUypsxJ3gPY2hchVlWsQCzsrJ846Gk8s=; b=hydAVfw1Vqsn/z+EKl7YdQUGQ/d4OyfU5hkFAwjvf3qzZdssBy4rbsONurJN0LH/Dm Hys+tEfxKD9NIZw1GqXQYk7ZkzUrRjiwehJLts2FT4l6HzwvwdB1qSbYctzuy17nNBOQ zpsTkFbtji3uDjpdFO/DGBF1js6XD2XSFDF43ozlLnIdGyLLeGpgw0yyvew+3C32q+7h FpxutUMk96drhKdSh5/RohrcgGVzZ/MTE3i6iWWMPHYIPvv2FynkxF5yo6mRH5Tkvgth rVc/GOjm/6UUpQCFaLDLDW19l6nLCUVp/fi7ySTLG9XmfQ+/dbLNPCTBcYtqvCtlxWMh +1qw==
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=z6eAhkVZYHHFUypsxJ3gPY2hchVlWsQCzsrJ846Gk8s=; b=RoIQyrTTLdckaXSq0TCK9bTSW0u8pCsX4COd71jtxTaX/861s/MGtuSrzw0RklD4xl G4ONFeQSomA0ie36PQsSgFIkDytCzV4yUO2Os8Z8Ghy+dqUBYeoDrv9Nx15ef6byBJwA DGx1lHL0gdUTjeZt2Ame67mrcuvIR/BfS/mtzIY1lpdQ3hW3S0/uzfHlnZ2vA6mIJL/c L7XDy/yLJaRgyBcblHaNIBA2pE0gVC5CUc2qxnWNTHcB/40LGU4U7QdHLfX8W2Edkbef wBrxr4ESxiMIrBUyqeaisn6O/7EatT5R/OACR4Zrd1POXiefVa7mCTb7PHBLAdbzghI0 qQBg==
X-Gm-Message-State: AJaThX7XJ9f0Aksu9k8epkD0mA0mge7Xcf2RiqI4pCFsu9c5qiAZ/5+Z qpO6I+llKGWA7hY3gSG0FKGEaZj6o570BCMOgUUavA==
X-Google-Smtp-Source: AGs4zMbQxMVPOL9juFOFE7gA4ZZSTc4sxxIvnF84P+j7Mwy3QBkBCrNRR2vFhq5JqqixpU89/2wYbqYxpSg72MUcosQ=
X-Received: by 10.46.57.10 with SMTP id g10mr3539319lja.77.1511799970101; Mon, 27 Nov 2017 08:26:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Mon, 27 Nov 2017 08:26:08 -0800 (PST)
In-Reply-To: <b8b8c99b-4a4b-8c50-355e-724554bb5f23@cisco.com>
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <CABCOCHT_5zHWf3mdNM+8uUd8sqZMKKiwVtr=O4C4BhNrbygNzw@mail.gmail.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <CABCOCHSYYFrZxC11v_++adG2uCP7urxR=VOKX-+8zXA-qiBCTA@mail.gmail.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> <CABCOCHTEXwhAq6NzoAGHcC-EE19bXJ0kbqPS0hwJB5_+RtOfyg@mail.gmail.com> <e418e007-fbac-029d-9c77-ed33df3d233b@cisco.com> <c2663103-70c2-0f52-f24f-852462509e27@cisco.com> <e41c2a8f-5ed7-9f3e-6dc1-85182c66adbf@cisco.com> <CABCOCHQrSOgGEAPdz5TdGBCGBSPzgAspGRQkgQDr3=H4Xp9JSQ@mail.gmail.com> <d056fdcd-20a8-5459-24ea-81fcfe53e59b@cisco.com> <015101d36513$bba345e0$4001a8c0@gateway.2wire.net> <CABCOCHTg5x_3=u4fMVtF-Rn1T6+gH2ZLMKeo6z5iekUWNt3RXg@mail.gmail.com> <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net> <CABCOCHQHDB_9vQ0W5uA+u__=sezGrVgNtvt==DQhbK1r2MsPUw@mail.gmail.com> <eef4d5a8-4185-24d7-36a7-0f5958804be2@cisco.com> <CABCOCHR-KPG69Ngzc=fb6cmcU4q+SEOt51AX=iYGYJR=pECxPg@mail.gmail.com> <b8b8c99b-4a4b-8c50-355e-724554bb5f23@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 27 Nov 2017 08:26:08 -0800
Message-ID: <CABCOCHTRN4_UpDwKe6mjHs6V5dovZ7V0ZfBk=NG++Yru=3JU+w@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: "t.petch" <ietfc@btconnect.com>, NETCONF <netconf@ietf.org>, sec-ads@ietf.org
Content-Type: multipart/alternative; boundary="089e082f5ce4308f84055ef95c94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RUsoZU0Xhu_QUM_Qda6PWXc3iAo>
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
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: Mon, 27 Nov 2017 16:26:15 -0000
On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton <rwilton@cisco.com> wrote: > > > On 27/11/2017 15:12, Andy Bierman wrote: > > > > On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <rwilton@cisco.com> wrote: > >> I do get the point that Tom is making here, and have quite a lot of >> sympathy for it. E.g. by automatically allowing the side effects of >> when/choice statements then we are introducing a potential security hole >> here that operators may find hard to be aware of and mitigate. >> >> It also seems odd to me that a client is allowed to implicitly remove >> some configuration through the side effect of a when/choice statement that >> they are not allowed to delete explicitly. >> >> The alternative of requiring appropriate access for the side-effects, >> seems like an intuitively safer design, but I also get Andy's concern that >> security isn't useful if it become so unwieldy that nobody uses it. >> >> So, I guess the question here is, do we have some concrete examples using >> real data models where the extra NACM delete rules would be required? If >> not then perhaps requiring the explicit access for side effects would be >> better. >> > > > Yes -- please provide some examples where it is better to force the > operator > to provide extra "delete" rules to allow false-when data nodes to be > deleted. > > It seems to me that these rules would allow individual data structures to > be > removed by the client, that would not otherwise be possible. > > Yes, this is true. > > But it is still odd that they a client is allowed to delete the > configuration, just not explicitly. I.e. it is strange that they are not > allowed to put in a semantically equivalent request that explicitly deletes > the configuration, they are only allowed to do it if the delete is > implicit. This seems inconsistent. > > It is just as odd that a request to create /foo/case1 will work if nothing from the choice-stmt exists, but will fail if /foo/case2 has to be deleted in order to create /foo/case1. > If 3 data structures need to be in place "when /foo exists" then > deleting 1 or 2 of them directly may not be desirable. Deleting > them all together (i.e., via when-false deletion) may be the intended > usage. > > If there is a dependency that all three exist then that may be better > expressed with a must statement instead. > > > The vendor and operator need to be aware of the data model dependencies. > That said, how come CLI-based configuration does not have this problem? > > My experience of CLI based configurations do have these sorts of problems, > and many more :-) > > > (Or rather, why has this problem been ignored for so long? Maybe it not > that real?) > > This may be the real crux of the argument: > > It probably doesn't make sense to use when statements on disjoint parts of > the YANG schema (e.g. it does not make sense for the OSPF YANG model to > depend on whether an interface it runs over has an IP address configured). > Instead, a more normal usage would be a flag (e.g. like interface type) to > allow/prevent certain child nodes from being available. In these > scenarios, if a user is allowed to change the type of an interface then > they are most likely allowed to change the other settings on the interface > as well. > > So for 'normal' when statements, it probably doesn't make much difference > whether or not explicit NACM access is required to the nodes being > implicitly deleted because the client probably already has the necessary > access rights. > > But for the 'corner case' when statement scenario, that are unlikely to be > used, it still seems safer to require explicit access permissions than > implicitly accepting the side effect with no NACM validation. > This is fine, except there is no way to tell a normal when from a corner-case when. In all cases, the false-when evaluation means the node is not relevant to the model anymore. Same for a case that is being replaced by a different case. In order for this NACM threat to be real. the YANG modeler needs to be wrong about whether the false-when states are actually irrelevant to the model in its new state. > Thanks, > Rob > Andy > > > > Thanks, >> Rob >> > > Andy > > >> >> On 25/11/2017 15:53, Andy Bierman wrote: >> >> >> >> On Sat, Nov 25, 2017 at 4:42 AM, t.petch <ietfc@btconnect.com> wrote: >> >>> ----- Original Message ----- >>> From: "Andy Bierman" <andy@yumaworks.com> >>> To: "t.petch" <ietfc@btconnect.com> >>> >>> >>> > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <ietfc@btconnect.com> wrote: >>> > >>> > > <inline> >>> > > >>> > > Tom Petch >>> > > >>> > > ----- Original Message ----- >>> > > From: "Robert Wilton" <rwilton@cisco.com> >>> > > Sent: Thursday, November 23, 2017 10:44 AM >>> > > >>> > > > Hi Andy, >>> > > > >>> > > > On 22/11/2017 18:09, Andy Bierman wrote: >>> > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote: >>> > > > > >>> > > > > Hi Rob, >>> > > > > >>> > > > > At that points in time, if it clarifies the spec. and the >>> > > authors >>> > > > > agree with this, let's do the right thing. >>> > > > > >>> > > > > I will add the new text if that is what the WG wants. >>> > > >>> > > > Having read this draft, I was undecided what the intended behavior >>> > > > actually should be. >>> > > > >>> > > > The way that Yumapro and Tail-f have implemented this is >>> reasonable, >>> > > and >>> > > > is probably also the way that I would implemented it. >>> > > > >>> > > > But I also think that it would be a reasonable implementation for >>> a >>> > > > server to calculate the full change set (taking account of side >>> > > effects >>> > > > from when and choice statements) to the datastore before checking >>> the >>> > > > "write data node access control" against the resultant change set. >>> > > > >>> > > > My interpretation is that the RFC text is ambiguous on what the >>> > > correct >>> > > > behavior is, and one could make a reasonable argument that the >>> current >>> > > > RFC actually specifies that the alternative behavior is correct, >>> i.e. >>> > > > requiring delete access even if a node is implicitly changes as a >>> side >>> > > > effect. E.g. section 3.2.3 of RFC 6536 states: >>> > > > >>> > > > If the protocol operation would result in the deletion of a >>> > > datastore >>> > > > node and the user does not have "delete" access permission for >>> > > that >>> > > > node, the protocol operation is rejected with an >>> "access-denied" >>> > > > error. >>> > > >>> > > Rob >>> > > >>> > > I have been reading that paragraph since this thread started and >>> > > wondering how it could be thought unclear, what am I missing:-) >>> > > >>> > > To me it clearly states that the user must have the appropriate >>> access >>> > > for the consequences of whatever they do, be that 'when', 'choice' >>> or >>> > > anything else! Indeed, I see exactly that behaviour in operational >>> > > (non-network) databases of which I am a user with limited >>> privileges. >>> > > >>> > > >>> > >>> > This is not correct. >>> > The server is the entity that is cleaning up false when-stmt or >>> unselected >>> > cases >>> > for a choice-stmt. >>> > >>> > NACM does not prevent the sever from making any changes to the system. >>> > It only affects the operations requested by a client. >>> >>> Andy >>> >>> My model is slightly different, that the server is a black box, with an >>> interface through which I can make authorised changes. If something I >>> do causes the deletion of something I am not allowed to delete, may be >>> not even to read, well, we part company on the acceptability of that! >>> >>> I do accept, as Randy points out, that the situation is complicated. I >>> am reminded of the issues that came up relating to the 'when' statement >>> when preparing YANG 1.1. Yes, 'when' makes things possible and is very >>> useful but at the same time, its side effects can be troublesome. I >>> would like to wrap it up in a conceptual bubble so you could not have >>> the sort of fine-grained access control that allows the case that Rob >>> postulates to occur but have no idea what that might look like. And I >>> don't know how much 'when' is used in that way in existing YANG >>> modules - uh huh, more reading required. >>> >> >> >> When the access control is too complicated, it does not get used. >> Instead, the most likely access control is "everybody is the root user". >> The server pruning of false when/choice data nodes is considered cleanup. >> The pruned data is no longer relevant to the data model. This is the >> indended >> use, but when-stmt can easily be abused. >> >> The complex tangled web of dependencies is no worse >> than it has been with CLI for 30 years, where every dependency is ad-hoc >> and probably undocumented. The granularity of CLI-based access control >> is less granular than NACM. >> >> It is possible that vendors and operators are willing to spend hours and >> days >> figuring out how to tune the NACM rules to allow a specific edit to work. >> Of course the operator will not even be told by the server which nodes >> are blocking the edit. That would be a security risk. >> >> IMO NACM will be completely unusable if rules are needed to allow >> server cleanup of dead nodes. The additional NACM rules required >> might provide more access than intended (unless lots of delete-only >> rules are added). The huge jump in NACM rule management complexity is >> a new security vulnerability, which might even be worse than the >> vulnerability it is intended to fix. >> >> >> >>> Tom Petch >>> >>> > >>> > Andy >>> > >>> >>> >>> >>> >> Andy >> >> >> >>> >>> >>> >>> >>> >>> >>> > > My other thought was that given all the complexities of 'when' that >>> > > emerged during the specification of YANG 1.1, perhaps, were I an >>> > > implementor of this, I would take the easy option and ignore the >>> side >>> > > effects of 'when'; but I might feel guilty about doing so. >>> > > >>> > > If the new paragraphs go in as proposed, then I think that the two >>> > > paragraphs you quote need changing else that section looks to me >>> like an >>> > > oxymoron. >>> > > >>> > > Tom Petch >>> > > >>> > > > An <edit-data> request that causes a when constraint to evaluate >>> > > > differently does result in a deletion of those data nodes from the >>> > > > datastore, and hence according to the text above, requires >>> explicit >>> > > > "delete" access permission to accomplish that. >>> > > > >>> > > > Clearly it would be an interop issue if different servers >>> implemented >>> > > > the NACM path based filtering differently. >>> > > > >>> > > > Hence why I think that it would be prudent for the draft to be >>> more >>> > > > explicit on when and choice statement handling. >>> > > > >>> > > > Rob >>> > > > >>> > > > > There have not been any comments on this issue. >>> > > > > >>> > > > > Andy >>> > > > > >>> > > > > Regards, Benoit. >>> > > > >> >>> > > > >> Hi Benoit, >>> > > > >> >>> > > > >> There is also one further, unrelated change that I am >>> proposing >>> > > > >> is made the draft before it is published, to help better >>> > > clarify >>> > > > >> the expected behavior. It isn't the end of the world if >>> this >>> > > > >> doesn't go in, but I think that it prevents sometime taking >>> a >>> > > > >> different, but IMO reasonable, interpretation of how "when" >>> > > > >> statements are considered, and then having a future >>> argument >>> > > > >> about what behavior it specified in the standard. >>> > > > >> >>> > > > >> If we clarify it now, then it closes that door :-) >>> > > > >> >>> > > > >> I've proposed text to Andy and Martin on Monday, but I've >>> not >>> > > > >> heard back yet. >>> > > > >> >>> > > > >> Netconf email with proposed text attached. The text doesn't >>> > > > >> necessarily have to match this, but personally I think that >>> it >>> > > is >>> > > > >> useful if the draft says something on this. >>> > > > >> >>> > > > >> Thanks, >>> > > > >> Rob >>> > > > >> >>> > > > >> >>> > > > >> On 22/11/2017 13:25, Benoit Claise wrote: >>> > > > >>> On 11/10/2017 7:23 PM, Andy Bierman wrote: >>> > > > >>>> Hi, >>> > > > >>>> >>> > > > >>>> Here are some proposed edits to make the data rule >>> consistent >>> > > > >>>> with the examples. >>> > > > >>>> Note that this issue is not related to the edit in the >>> > > original >>> > > > >>>> 1-week change. >>> > > > >>> That's right, but we found a source of misinterpretation >>> in >>> > > the >>> > > > >>> draft and you have rightly corrected it in the github v9. >>> > > > >>> >>> > > > >>> Regards, Benoit >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> sec. 3.3.5: >>> > > > >>>> >>> > > > >>>> OLD: >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> data node rule: controls access for a specific data >>> > > > >>>> node, identified >>> > > > >>>> by its path location within the conceptual XML document >>> > > > >>>> for the >>> > > > >>>> data node. >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> NEW: >>> > > > >>>> >>> > > > >>>> data node rule: controls access for a specific data node >>> > > > >>>> and its descendants, >>> > > > >>>> identified by its path location within the conceptual XML >>> > > > >>>> document for the >>> > > > >>>> data node. >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> sec 3.4.5, step 6, bullet 2: >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> OLD: >>> > > > >>>> >>> > > > >>>> * The rule does not have a "rule-type" defined or the >>> > > > >>>> "rule- >>> > > > >>>> type" is "data-node" and the "path" matches the >>> > > > >>>> requested >>> > > > >>>> data node, action node, or notification node. >>> > > > >>>> >>> > > > >>>> NEW: >>> > > > >>>> * The rule does not have a "rule-type" defined or the >>> > > > >>>> "rule- >>> > > > >>>> type" is "data-node" and the "path" matches the >>> > > > >>>> requested >>> > > > >>>> data node, action node, or notification node. A path is >>> > > > >>>> considered to match if the current data node is the >>> > > > >>>> data node >>> > > > >>>> specified by the path, or is a descendant data node >>> > > > >>>> of this data node. >>> > > > >>>> appendix B.4: (2 bugs in explanation) >>> > > > >>>> OLD: >>> > > > >>>> deny-nacm: This rule denies the "guest" group any access >>> to >>> > > the >>> > > > >>>> <nacm> subtree. Note that the default namespace is only >>> > > > >>>> applicable because this subtree is defined in the same >>> > > > >>>> namespace as the <data-rule> element. >>> > > > >>>> NEW: >>> > > > >>>> deny-nacm: This rule denies the "guest" group any access >>> to >>> > > the >>> > > > >>>> <nacm> subtree. >>> > > > >>>> Andy >>> > > > >>>> >>> > > > >>>> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton >>> > > > >>>> <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote: >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> >>> > > > >>>> On 10/11/2017 16:33, Andy Bierman wrote: >>> > > > >>>>> >>> > > > >>>>> >>> > > > >>>>> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton >>> > > > >>>>> <rwilton@cisco.com <mailto:rwilton@cisco.com>> >>> wrote: >>> > > > >>>>> >>> > > > >>>>> >>> > > > >>>>> >>> > > > >>>>> On 10/11/2017 15:49, Andy Bierman wrote: >>> > > > >>>>>> >>> > > > >>>>>> >>> > > <snip> >>> > > >>> > > >>> > >>> >>> >> >> > >
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Kent Watsen
- [Netconf] draft-ietf-netconf-rfc6536bis: one week… Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Per Hedeland
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Martin Bjorklund
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Martin Bjorklund
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Randy Presuhn
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Randy Presuhn
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise