Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 27 June 2018 03:59 UTC

Return-Path: <mjethanandani@gmail.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 73FBD12785F; Tue, 26 Jun 2018 20:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dY5YQD-6Wk8y; Tue, 26 Jun 2018 20:59:43 -0700 (PDT)
Received: from mail-pl0-x243.google.com (mail-pl0-x243.google.com [IPv6:2607:f8b0:400e:c01::243]) (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 A3ABB130E10; Tue, 26 Jun 2018 20:59:43 -0700 (PDT)
Received: by mail-pl0-x243.google.com with SMTP id w8-v6so370518ply.8; Tue, 26 Jun 2018 20:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kI7va0W/z0ayKkOM7Pu0GFkHpiWBVbTy+q2ydz4KzsQ=; b=K3AmoPEeQhCw5VO4viIsL41CWyvC3VibxQuVcxU2XvmOEhofCcsPzXVw5rsjRpcfUo oWOjWiQzLTV2QlJzwMHF52im0Fmcc8HBghK8X7lsG8SktV6qNt5U9H6cynCl9rqBLWSn t5wEG9yBsroFAFjmGwi9QqZCJ1Y/lU5UKq+bWsdQDI90qEHkXzcqmZkmJypdQJjwXun+ +dkdHWm/yvD6HwDDIv1Ex8yUm5k7mIJO+CGso3cPYALiosd5aayOTCoLOpirKhGr3477 JGT035joatmQ6ujC9uJAEnJ15HRpog5Gh29hogWW2yoySVYM+9bF5q2PwFjsAEML1cGq iGGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kI7va0W/z0ayKkOM7Pu0GFkHpiWBVbTy+q2ydz4KzsQ=; b=qahKkAW8eVaKnC/bc2almh4lOgohFEvAEw5X2MB2Ji5DByi7hzKOujvxUEBzPDcR46 61GoG727nA9+GM60Sfncb/0C2nxlhEQmFLZdotBeP+qV4A4ClynDoURSvxDll5tTvrde EaLlNz2Y6+e6WeYs5Xmw/0/AQpta+w2LosyElZjco6W1M97N+tfNHIVwtjvdzVfEzd4c IogOmrqKXWPuCsBQduZdHhUn3YO58eHk0eAkDoGit4F4qaQlzWInXK+eh5RMC2d3a0Xr Jbdsj9CvDXqT/hZrRgNYau7TApiDy19oNeWVH0/PeT/qsPF8JcG/SiIcSQGeTzea3PM2 VCkQ==
X-Gm-Message-State: APt69E0lFGBXlFDEFz1Jj99bPdn7ZXHtDjT/QUatb3ZlAD37te1NCdm4 FvotCA4mVmrmj2yzyBknb1E=
X-Google-Smtp-Source: ADUXVKLnqMH6MTQq5somUVXC3Bju1j8Xg2PadUediV/57tMjiDFMwiPGqUYXurJlOy2/Tr3Z+vhmAw==
X-Received: by 2002:a17:902:42e4:: with SMTP id h91-v6mr4363477pld.27.1530071983102; Tue, 26 Jun 2018 20:59:43 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:f5be:fec2:aa7a:7407? ([2601:647:4700:1280:f5be:fec2:aa7a:7407]) by smtp.gmail.com with ESMTPSA id e81-v6sm7307893pfb.62.2018.06.26.20.59.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 20:59:42 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <20180625080714.kg2h66mxc7kpgtgs@anna.jacobs.jacobs-university.de>
Date: Tue, 26 Jun 2018 20:59:41 -0700
Cc: Rohit R Ranade <rohitrranade@huawei.com>, Kent Watsen <kwatsen@juniper.net>, Netconf <netconf@ietf.org>, "draft-ietf-netconf-nmda-netconf@ietf.org" <draft-ietf-netconf-nmda-netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <31C8508F-1035-4CBC-B6EC-1218DEAD2172@gmail.com>
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> <8AEB4F37-A148-428F-A5C0-1AB836F0733E@juniper.net> <991B70D8B4112A4699D5C00DDBBF878A6BBC062A@dggeml510-mbx.china.huawei.com> <20180625080714.kg2h66mxc7kpgtgs@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Wtk8nME2rw9q_pnAStpmDXbjXOc>
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: Wed, 27 Jun 2018 03:59:48 -0000

Hi Juergen,

> On Jun 25, 2018, at 1:07 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> This seems to be correct as far as I can tell. I am not sure what
> exactly the changes are (i.e., where this is supposed to go)

Appendix?

> and I
> think the document shephered should probably coordinate this as we
> are now moving to IETF last call (once the details have been worked
> out, we could for example treat this as IETF last call comment).

BTW, there are corresponding changes for the clarification in nmda-restconf. Right?

> 
> /js
> 
> On Tue, Jun 19, 2018 at 05:25:37AM +0000, Rohit R Ranade wrote:
>> I agree with Juergen's comments. Only exception is that "intended" for " negated-origin-filter" will be qualified by the ietf-origin namespace.
>> Please find the updated 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"
>>               xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>>       <datastore>ds:running</datastore>
>>       <subtree-filter>
>>         <bgp xmlns="http://example.com/ns/example"/>
>>      </subtree-filter>
>>       <negated-origin-filter>or:intended</negated-origin-filter>
>>       <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="http://example.com/ns/example" 
>>          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
>> 
>> -----Original Message-----
>> From: Kent Watsen [mailto:kwatsen@juniper.net] 
>> Sent: 19 June 2018 03:43
>> 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
>> Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
>> 
>> 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.o
>>>>>>>> rg_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBX
>>>>>>>> eMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdc
>>>>>>>> Zo&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-nd
>>>>> b3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Ehfh
>>>>> Srolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjt
>>>>> eIxUz56Qf08hiQBzQ3I&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_mail
>>> man_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXc
>>> WzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObT
>>> fkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBz
>>> Q3I&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=>
>> 
>> 
> 
> -- 
> 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/>

Mahesh Jethanandani
mjethanandani@gmail.com