Re: [Netconf] YangPush now

[Juergen Schoenwaelder <[e-mail]>]

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?

> 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. 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.

> > I do not buy the IoT argument. What is wrong with requiring that a
> > NETCONF server must support at least the NETCONF transport and that a
> > RESTCONF server must support at the RESTCONF transport?
> 
> Ahh.  I thought you meant that there should be a default transport for SN alone.    SN in section 1.0 & the end of 5.3 points to transport documents for such guidance.
> 
> Then looking at Section 1.0 in draft-ietf-netconf-netconf-event-notification: 
> 
>    This document provides a binding for events streamed over the NETCONF
>    protocol [RFC6241] as per
>    [I-D.draft-ietf-netconf-subscribed-notifications].  In addition, as
>    [I-D.ietf-netconf-yang-push] is itself built upon
>    [I-D.draft-ietf-netconf-subscribed-notifications], this document
>    enables a NETCONF client to request and receive updates from a YANG
>    datastore located on a NETCONF server.
>

Yes. But this text does not say that 'if a NETCONF server supports
configured subscriptions, then it MUST implement the notification
transport as defined in section 5.2 (or whatever the section will be).
This way, a NETCONF client using configured subscriptions would know
one transport that actually works (if the details are fully worked
out). Perhaps this is not what people really want, so I will start
another thread to figure this out.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>