Re: [Netconf] configuration models status and timeline

Hi Ariel,

To quote RFC 6241 Section 6.4.2:

6.4.2. Empty Filter
An empty filter will select nothing because no content match or
selection nodes are present. This is not an error. The <filter>
element's "type" attribute used in these examples is discussed
further in Section 7.1.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
</filter>
</get>
</rpc>

<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
</data>
</rpc-reply>

My understanding is that a <get> without a subtree filter will retrieve the whole configuration, but a <get> with an empty subtree filter will return nothing.
This is exactly the behaviour we see in our NETCONF server. This is lightweight and requires no protocol changes. Or am I missing something?

Regards
Nick

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ariel Otilibili Anieli
Sent: Sunday, July 29, 2018 10:49 PM
To: Beauville, Yves (Nokia - BE/Antwerp)
Cc: netconf@ietf.org
Subject: Re: [Netconf] configuration models status and timeline

Hi Yves,

Below my comments.

Regards,
Ariel

Quoting "Beauville, Yves (Nokia - BE/Antwerp)" <yves.beauville@nokia.com>:

> Kent, Andy and Rohit,
>
> Could we use a get request with an empty filter, as defined in section
> 6.4.2 <https://tools.ietf.org/html/rfc6241#section-6.4.2<https://tools.ietf.org/html/rfc6241#section-6.4.2>> of RFC6241?
>
> This looks like the smallest and less impacting RPC defined in the RFC.
>
> Isn't it a good candidate for an aliveness check?
An empty filter retrieves the whole configuration; which can take a
lot space and time.

I would rather use, as filter of the RPC 'get', the 'current-datetime'
or the 'boot-datetime'.

[1] https://tools.ietf.org/html/rfc7317#section-3.2<https://tools.ietf.org/html/rfc7317#section-3.2>
>
> Yves
>
> On 19-07-18 05:20, Rohit R Ranade wrote:
>>
>> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy Bierman
>> *Sent:* 18 July 2018 23:32
>> *To:* Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
>> Kent Watsen <kwatsen@juniper.net>; netconf@ietf.org
>> *Subject:* Re: [Netconf] configuration models status and timeline
>>
>> <snip>
>>
>> Ideally, the keep alive would just be handled at the session
>> layer. I am
>> not sure where the NC spec allows
>>
>> C: <rpc message-id="101"
>> C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
>> S: <rpc-reply message-id="101"
>> S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
>>
>> otherwise one could define a noop RPC (I am not sure invoking a fake
>> edit-config is necessarily a good idea).
>>
>> I prefer an <no-op> RPC for this purpose.
>>
>> It would be better if the session counters were not affected,
>>
>> but that would require protocol changes.
>>
>> Causing error counters to increment for keep-alives is bad.
>>
>> */[Rohit R Ranade] /*+1
>>
>> Andy
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr<http://webmail.eurecom.fr>

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<https://www.ietf.org/mailman/listinfo/netconf>