Re: [Netconf] YangPush now

["Eric Voit (evoit)" <[e-mail]>]

Hi Juergen,

> From: Juergen Schoenwaelder, July 18, 2018 9:32 AM
> 
> On Wed, Jul 18, 2018 at 03:41:19AM +0000, Eric Voit (evoit) wrote:
> > From: Andy Bierman, July 17, 2018 5:06 PM
> >
> >
> > Hi,
> >
> > I agree with Juergen that there are TBD features in SN.
> >
> > I also agree with the co-authors that it would be too much work to
> refactor now.
> > It should be faster to complete SN then split it and start over.
> >
> > The main issues here seem to be:
> >  1) no end-point for the configured receiver
> >
> > <Eric> There should not be any endpoint in SN.   Endpoint specifics would
> need to be exposed in the transport document.
> >
> > Note that we tried for years to have something transport independent for
> receivers in SN.   I.e., there was an endpoint “address” in the SN from 00-
> v13.   Kent and Martin argued it out of the SN draft.  For more on this, there
> is plenty extensive email alias archive on this subject.   As a result, with v14,
> “address” is gone.
> >
> > To summarize Kent & Martin’s argument which led to the v14 change:
> current endpoint “address” might be confused with call home.  We won’t
> agree with anything that might conflict with call home.  It is better to do
> nothing if we can’t agree on something.  By doing nothing, vendors can
> augment in what is needed.
> 
> So the standard is unusable without vendor augmentations, 

Every solution needs to define boundaries to its scope.  Here it is reasonable to spit subscription configuration from transport connection / keystore configuration.   We have designed the solution so that transport implementations can layer in what they need.   I think it would be great if the industry implements draft-ietf-netconf-netconf-client-server when that document completes.   Until then, reality is that solutions must integrate with embedded vendor embodiments RFC-8071. 

> which are likely then not interoperable.

Yes.  Vendor model based configuration is needed until IETF model based configuration completes its definition and implementation. 

> If you go forward with this, I think this needs to be
> spelled out clearly in the document writeup so that the IESG can think
> about this.

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

> > For v14 we didn’t just ignore the hole removing “address” made of
> course.  Many email iterations over the last several months have proposed
> YANG augmentation code for those people who *do* want a leafref to
> netconf-server.yang now.  So if it makes this “endpoint completeness” issue
> go away, I would happily put an informational appendix into NETCONF-
> notif.  This appendix would include the necessary augmentations to the
> leafref which Kent and I worked through.
> >
> > But we should go no farther than an informational appendix on this.  The
> current solution of doing nothing is actually a far more compelling answer
> than the inserting a mandatory (but then deviated away) leafref to an
> unimplemented ietf call home model.   This would allow the “solution is
> complete” answer to match to what dominates the industry: vendors who
> have their own key and call home infrastructure.
> 
> Clearly, an address alone is not sufficient. What is needed is a concrete link
> to the configuration models. Right now we have:
> 
>    The method of identifying the targeted recevier 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 am not sure this is concrete enough. What exactly does one have to
> augment in?

Either the IP address, port, and security credentials, or a leafref pointing to these objects.
 
> >  2) CallHome procedures and server requirements such as
> >      processing normal NC or RC requests on the session
> >
> > This is described in draft-ietf-netconf-netconf-event-notifications, section
> 5.2.
> 
> And I commented that I disagree with the solution and there was discussion
> on the mailing. Ignoring comments does not make them go away. I believe
> you can't simply overwrite call-home steps 

I don't recall that the issue of this solution not being permitted to refine call-home steps being raised before. 

> I believe after call-home NC
> starts and NC starts with a <hello> exchange. 

Agree. 

> And then, is it reasonable to
> throw notifications at the client without having its consent? A poor client
> not expecting to receive notifications will likely close the session and you
> likely call the poor client again, potentially forming an ugly loop.

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.

 
> >  3) no MUST or SHOULD implement values for transport
> >
> > This is on purpose.  IoT is not going to want a NETCONF transport default.
> The current draft allows identities to be added for transports supported by
> a platform.  It is not possible to configure a transport the platform doesn’t
> have.
> >
> 
> 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.

Eric
 
> /js
> 
> PS: There were also issues raised concerning the "RESTCONF transport"
>     which really is not a RESTCONF transport but some new HTTP/2
>     transport. I think this also needs to be resolved before that
>     document can move.
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>