Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
Kent Watsen <kwatsen@juniper.net> Mon, 18 June 2018 22:13 UTC
Return-Path: <kwatsen@juniper.net>
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 EB87B130E35; Mon, 18 Jun 2018 15:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_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=juniper.net
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 tTg7Pw8sS3GJ; Mon, 18 Jun 2018 15:13:27 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E312129385; Mon, 18 Jun 2018 15:13:27 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5IM8Oqq018595; Mon, 18 Jun 2018 15:13:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=e1QJzDiIZxhCMZl9MMGfLE056oinFAwyvHVlyNfvkis=; b=zyVk1QvEBZvhcPJzDQ6tW2J6YbYQnoaM67+wWRfIQByk/IrvLbF5DM7UyZI5ob3MTAPd yd5JDFEM5varxqaL864uxbXx6jWs9wuYyAuv2YN4hsuXRDv01oa9b5Bq304XN/hu8UZP eoPkACSGktM84vHRW2zF0X/cNcszSXkv0qQ/Ro9oyYtmfAkd48B9Lh0Jt2eujjcKOqnL opcye4hVEZr0fCJgcZeBM0cb+0n4+44lXSdmO8ACcG0xyolHWE8eOn3bxmF55X/cq3/D L+2y7lQMAZrBtUVCEsxfCsqLi6puslqNhD5aGLhqkA+q4MVRmp73Ajr/20ibNL9Ir7wW 0w==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0087.outbound.protection.outlook.com [207.46.163.87]) by mx0b-00273201.pphosted.com with ESMTP id 2jpm5u82ny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Jun 2018 15:13:20 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4776.namprd05.prod.outlook.com (52.135.233.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.12; Mon, 18 Jun 2018 22:13:18 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0884.010; Mon, 18 Jun 2018 22:13:18 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Rohit R Ranade <rohitrranade@huawei.com>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>, "draft-ietf-netconf-nmda-netconf@ietf.org" <draft-ietf-netconf-nmda-netconf@ietf.org>
Thread-Topic: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
Thread-Index: AdP5cHGIUfFqVxlzSpC0uX7jp7wZ7gAVELkAAIolOgAAAYmwAAGVpb+AAC3FYYAAAdnbgAABp1gAAQg5loA=
Date: Mon, 18 Jun 2018 22:13:18 +0000
Message-ID: <8AEB4F37-A148-428F-A5C0-1AB836F0733E@juniper.net>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com> <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com> <20180604.121748.1873023460220711310.mbj@tail-f.com> <224028b2-59c5-6859-0e2a-331ed48121ec@cisco.com> <D42566D9-0C25-468E-B90F-B15589A7FB6D@gmail.com> <20180613102721.tnqufeommaojdwm2@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBBD928@dggeml510-mbx.china.huawei.com> <20180613120742.7xfgwy66jq6qxsmf@anna.jacobs.jacobs-university.de>
In-Reply-To: <20180613120742.7xfgwy66jq6qxsmf@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4776; 7:z/1hbOdy9fePObpVacNOEgamUxYYfCPBKLkkA/QSp4kerpZ+wyJrm7+mjnGi4A6PbjGQAOuEAY80xY4MKCgaIgrhZHRr+pkLvZ/wEziiIAV1f2KErzAkNoourPZTqOG/TPRSusz5ByM6aCi83zYO47G+6FVglAaQ+EbITrffTdBmih3AFt1r2hiv5O1fglQBqWSGN9yNrD66v6uMmlkfZ1mmHIcHCZNmGfu8sZdMTV6QMEXbqVrRfXlbe5sXhkUw
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1ffc3f40-8705-43fd-bcf8-08d5d568b217
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4776;
x-ms-traffictypediagnostic: BYAPR05MB4776:
x-microsoft-antispam-prvs: <BYAPR05MB477664791FAB6727C192B8E2A5710@BYAPR05MB4776.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(85827821059158)(95692535739014);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4776; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4776;
x-forefront-prvs: 0707248B64
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(396003)(346002)(366004)(51444003)(53754006)(189003)(199004)(13464003)(82746002)(3846002)(6116002)(229853002)(5660300001)(54906003)(58126008)(110136005)(2906002)(316002)(93886005)(39060400002)(99286004)(53936002)(4326008)(106356001)(105586002)(6246003)(66066001)(966005)(97736004)(2900100001)(53546011)(476003)(486006)(59450400001)(6506007)(68736007)(25786009)(14454004)(2616005)(478600001)(3280700002)(83716003)(6486002)(446003)(11346002)(305945005)(5250100002)(3660700001)(7736002)(33656002)(36756003)(8676002)(102836004)(81166006)(26005)(86362001)(575784001)(6512007)(186003)(81156014)(6436002)(8936002)(76176011)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4776; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: t1wUsfstxqd2W97/M2+ytHFVcOZZA3FhaS338HQbtmxr0Zt3x5KBg6RiNjM39QdM5Km58qyMNjjw5bLMsbl2c+UI436ou9PMLa+2unep/rydhYedEkkbD6ux5WwLTLoO+EaEbAPRPRoc4Z8BRHIscfFCHbIpUZuIboI3Ele2ipnvkZeIfyF3mu3rs3RBYtvE7Uq1f08HYG7sSXObNoRZgzQOLSyc5mOBFwEn8LGYBHDGNzL9lGyKd+9nR7dMxtWiGXQVrXwc28icuT6Jp5sdIf5e4jmYCrti7B7pR0mYt0wAHMUMmeBrh0yDf314V2WaO+pmERGav9XOa9phmJQidA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <C87BF0342B64D943ABB6DD363CD388F1@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ffc3f40-8705-43fd-bcf8-08d5d568b217
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 22:13:18.2747 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4776
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-18_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806180250
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/SZSNwUPRJ5pJqnJtJunVUac-lLo>
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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, 18 Jun 2018 22:13:31 -0000
Let's conclude this thread and push an update (or updatres) to GitHub, so the update doesn't get lost as we head into the IESG LC. Two items: - "origin-filter" parameter - <get-data> usage example Kent and Mahesh ===== original message ===== Yes, for bgp there is no namespace defined in the example in RFC 8342. Using ietf-netconf-nmda clearly is misleading, a fictional example namespace will be better. I think the lexical representation of the value 'intended' requires to be namespace qualified, i.e. 'ds:intended'. The with-origin is defined to be of type empty - there is no 'true' value or something like that, its just <with-origin/>. /js On Wed, Jun 13, 2018 at 11:20:21AM +0000, Rohit R Ranade wrote: > Hi Juergen, > > Can you please identify the namespaces which are not OK so that we can fix them. > For want of a namespace for "bgp", I re-used the ietf-netconf-nmda namespace as it is just an example. We can use the "https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_ns_example&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=tm-DrFSVrRkMzAH-DiWECrNBbWhSmbKnBauKdzx3J-k&e=" namespace instead. > > With Regards, > Rohit R Ranade > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: 13 June 2018 15:57 > To: Mahesh Jethanandani <mjethanandani@gmail.com> > Cc: Netconf <netconf@ietf.org>; draft-ietf-netconf-nmda-netconf@ietf.org > Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf > > I am not sure an example is needed but if we include one, we need one which is correct. I think the namespaces are a bit messed up in Rohit's example. > > /js > > On Tue, Jun 12, 2018 at 08:36:47AM -0400, Mahesh Jethanandani wrote: > > Have the authors agreed on the final set of edits for this document? How about the example that Rohit mentioned in the original e-mail? > > > > > On Jun 4, 2018, at 7:01 AM, Robert Wilton <rwilton@cisco.com> wrote: > > > > > > > > > > > > On 04/06/2018 11:17, Martin Bjorklund wrote: > > >> Hi > > >> > > >> Two comments inline. > > >> > > >> Robert Wilton <rwilton@cisco.com> wrote: > > >>> Hi Rohit, authors, > > >>> > > >>> I think that these are valid clarifications. I've reworded them > > >>> slightly, and moved the ancestor node text to the YANG module > > >>> instead. I also think that the ancestor node text generically > > >>> covers the config filter clarification that you raised previously. > > >>> > > >>> Hence, I propose the following diff to the NETCONF NMDA draft: > > >>> > > >>> rwilton@rwilton-lnx:~/netconf-wg/netconf-nmda$ git diff --staged > > >>> diff --git a/ietf-netconf-nmda.yang b/ietf-netconf-nmda.yang index > > >>> f2929b9..72a674a 100644 > > >>> --- a/ietf-netconf-nmda.yang > > >>> +++ b/ietf-netconf-nmda.yang > > >>> @@ -105,6 +105,9 @@ module ietf-netconf-nmda { > > >>> by get-data must satisfy all filters, i.e., the filter > > >>> criteria are logically ANDed. > > >>> > > >>> + Any ancestor nodes (including list keys) of nodes matched by > > >>> + the filter are included in the response. > > >>> + > > >>> The 'with-origin' parameter is only valid for an operational > > >>> datastore. If 'with-origin' is used with an invalid datastore, > > >>> then the server MUST return an <rpc-error> element with an > > >>> @@ -193,7 +196,7 @@ module ietf-netconf-nmda { > > >>> description > > >>> "Filter based on the 'origin' annotation. A node matches > > >>> the filter if its 'origin' annotation is not derived > > >>> - from and not equal to all of the given filter values."; > > >>> + from and not equal to any of the given filter > > >>> + values."; > > >>> } > > >>> } > > >>> > > >>> diff --git a/nmda-netconf.org b/nmda-netconf.org index > > >>> e44e2c7..100e173 100644 > > >>> --- a/nmda-netconf.org > > >>> +++ b/nmda-netconf.org > > >>> @@ -129,14 +129,17 @@ The "config-filter" parameter can be used to > > >>> retrieve only "config true" or "config false" nodes. > > >>> > > >>> The "origin-filter" parameter, which can be present multiple > > >>> times, -selects nodes matching any of the given values. The > > >>> -"negated-origin-filter", which can be present multiple times, > > >>> selects -nodes that do not match all given values. The "origin-filter" > > >>> -and "negated-origin-filter" parameters cannot be used together. > > >>> +selects nodes with origins matching, or derived from, any of the > > >>> given > > >> I would prefer: > > >> > > >> selects nodes with origins equal to, or derived from, any of the > > >> given > > >> > > >> > > >> IMO, the term "match" in the original text means "equal to or > > >> derived-from", as explained in the data model. > > >> > > >> The term "match" is problematic unless it is explained, b/c some > > >> people will think it means "equal to". (Noone will think that > > >> "matches the regular expression" means "equal to the regular > > >> expression" though...) > > >> > > >> Conclusion: always avoid the term "match". > > > OK. > > > > > >> > > >>> +values. The "negated-origin-filter", which can be present > > >>> +multiple times, selects nodes with origins that do not match, and > > >>> +are not derived from, any of the given values. The > > >>> +"origin-filter" and "negated-origin-filter" parameters cannot be used together. > > >>> > > >>> The "max-depth" parameter can be used by the client to limit the > > >>> number of sub-tree levels that are returned in the reply. > > >>> > > >>> Note to the authors, for the negative-origin-filter, I've also > > >>> changed "all" to "any" (which changes the semantics, but I think > > >>> it was wrong before). > > >> Agree that "any" is correct. > > >> > > >> But does it really change the semantics? "all" sounds quite odd, > > >> but isn't the end result the same? > > > I think that it is confusing, and probably depends on how you read it. > > > > > > But, if you are OK with "any" then I think that reads better and is more intuitive. > > > > > > Thanks, > > > Rob > > > > > > > > > > > >> > > >> > > >> /martin > > >> > > >> > > >>> Similar updates will need to also be done to RESTCONF, but let's > > >>> agree the NETCONF text first. > > >>> > > >>> Thanks, > > >>> Rob > > >>> > > >>> > > >>> On 01/06/2018 10:10, Rohit R Ranade wrote: > > >>>> Hi All, > > >>>> > > >>>> Section 3.1.1 > > >>>> > > >>>> OLD: > > >>>> > > >>>> The "origin-filter" parameter, which can be present multiple > > >>>> times, > > >>>> > > >>>> selects nodes matching any of the given values. The > > >>>> > > >>>> "negated-origin-filter", which can be present multiple times, > > >>>> selects > > >>>> > > >>>> nodes that do not match all given values. > > >>>> > > >>>> NEW: > > >>>> > > >>>> The "origin-filter" parameter, which can be present multiple > > >>>> times, > > >>>> > > >>>> selects nodes which are derived from or matching any of the > > >>>> given values. The > > >>>> > > >>>> "negated-origin-filter", which can be present multiple times, > > >>>> selects > > >>>> > > >>>> nodes which are not derived from and do not match all given values. > > >>>> > > >>>> When a data-node matching the filter is selected, the > > >>>> configuration ancestors > > >>>> > > >>>> (if any) and list key leafs (if any), even if they do not match > > >>>> the filter, are also returned. > > >>>> > > >>>> Consider two origins such as “learned” and “derived-from-learned”. > > >>>> > > >>>> “derived-from-learned” is derived from learned origin. > > >>>> > > >>>> Using the origin filters it is not possible to get nodes > > >>>> belonging to “learned” > > >>>> > > >>>> only as the nodes of derived origin are automatically selected. > > >>>> > > >>>> Notes: > > >>>> > > >>>> The text in 3.1.1 did not include the “derived-from” logic for > > >>>> selection , while in the data-model definition it was present. > > >>>> > > >>>> We can also add clarification about the ancestor and key being > > >>>> output, even if though they do match the filter, since the leaf > > >>>> > > >>>> matches the filter. > > >>>> > > >>>> Example : We can use the RFC 8342 Appendix C.2 BGP Example > > >>>> > > >>>> <rpc message-id="101" > > >>>> > > >>>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > >>>> > > >>>> <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda" > > >>>> > > >>>> xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> > > >>>> > > >>>> <datastore>ds:running</datastore> > > >>>> > > >>>> <subtree-filter> > > >>>> > > >>>> <bgp > > >>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"/> > > >>>> > > >>>> </subtree-filter> > > >>>> > > >>>> <negated-origin-filter>intended</negated-origin-filter> > > >>>> > > >>>> <with-origin>true</with-origin> > > >>>> > > >>>> </get-data> > > >>>> > > >>>> </rpc> > > >>>> > > >>>> <rpc-reply message-id="101" > > >>>> > > >>>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > >>>> > > >>>> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"> > > >>>> > > >>>> <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > > >>>> > > >>>> or:origin="or:intended"> > > >>>> > > >>>> <peer> > > >>>> > > >>>> <name>2001:db8::2:3</name> > > >>>> > > >>>> <local-as or:origin="or:default">64501</local-as> > > >>>> > > >>>> <peer-as or:origin="or:default">64502</peer-as> > > >>>> > > >>>> <local-port or:origin="or:system">60794</local-port> > > >>>> > > >>>> <remote-port or:origin="or:default">179</remote-port> > > >>>> > > >>>> <state>established</state> > > >>>> > > >>>> </peer> > > >>>> > > >>>> </bgp> > > >>>> > > >>>> </data> > > >>>> > > >>>> </rpc-reply> > > >>>> > > >>>> With Regards, > > >>>> > > >>>> Rohit R Ranade > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Netconf mailing list > > >>>> Netconf@ietf.org > > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e= > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e= > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=VZh0-GgZ6GpKnZhdi09mezzyPA62WEHUd5wPYbUVCI4&e=> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e= -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=VZh0-GgZ6GpKnZhdi09mezzyPA62WEHUd5wPYbUVCI4&e=>
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Mahesh Jethanandani
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Juergen Schoenwaelder
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Rohit R Ranade
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Rohit R Ranade
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Juergen Schoenwaelder
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Kent Watsen
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Mahesh Jethanandani
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Juergen Schoenwaelder
- [Netconf] Editorial change-2 for draft-ietf-netco… Rohit R Ranade
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Robert Wilton
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Rohit R Ranade
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Martin Bjorklund
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Robert Wilton
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Rohit R Ranade
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Mahesh Jethanandani
- Re: [Netconf] Editorial change-2 for draft-ietf-n… Martin Bjorklund