Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver

[Martin Bjorklund <[e-mail]>]

Hi,

"Eric Voit (evoit)" <[e-mail]> wrote:
> Martin, 
> one question specifically to you below. (search for **Martin)

See inline

> 
> Kent, 
> in line...
> 
> > From: Kent Watsen, June 26, 2018 9:47 PM

[...]

> > > So can we take out address and finally be done?   That would be a good
> > thing.
> > 
> > Yes, take out the address leaf but I think that, if we want to
> > progress the
> > SN draft along with a transport binding definition that doesn't depend
> > on
> > the ietf-*conf-server modules, then we might define something else
> > like:
> > 
> >   module ietf-netconf-no-crypto-subscribed-notifications {
> >     prefix nncsn;
> >     import ietf-subscribed-notifications { prefix sn; }
> > 
> >     container implicit-netconf-receivers {
> >       list implicit-netconf-receiver {
> >         key name;
> >         leaf name { ... }
> >         leaf address { ... }
> >         leaf port { ... }
> >       }
> >     }
> >     augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" {
> >       if-feature "subscription-support";
> >       when 'derived-from(../../../transport, "nsn:netconf")';
> >       leaf netconf-endpoint {
> >         type leafref {
> >           path "/nncsn:implicit-netconf-receivers/nnccs:implicit-netconf-"
> >                + "receiver/nnccs:name";
> >         }
> >       }
> >     }
> >     ...
> >   }
> 
> **Martin, are you ok with this.  If you are and there are no other
> **objections, I will add this and we can be done with this thread.
> **Which would be progress.  Otherwise, let's just leave things as they
> **are.

No, but it might be that I don't really understand what you propose.

What is "NETCONF no crypto"?  Comparing with "ietf-netconf-server"
model, you don't have the "server-identity".  How can this be secure?

Is the reason for this to avoid a dependency to
"draft-ietf-netconf-netconf-client-server" from
"draft-ietf-netconf-netconf-event-notifications"?

I would rather keep this dependency and ensure the WG finishes the
client-server model.  (This work was adopted by the WG in 2014 which
is even earlier than the notif drafts...)

> BTW: adding back address and port also solves the "how do we have a
> common transport across multiple configured receivers".
> 
> > I don't quite understand how the server is supposed to know how to
> > configure
> > the call-home parameters or the transport parameters, but at least
> > this
> > would be on par with what you had before.
> 
> Yes.
> 
> > >> <big snip/>
> > >> We agree above that the ietf-*conf-server module may not be
> > *implemented*, and
> > >> yet subscriptions still need to be configured

I think it is ok to require an implementation of configured
subscriptions that use the standard "nsn:netconf" transport to also
implement the ietf-netconf-server module.  If a vendor doesn't want
this, it can define another transport identity.



/martin

> > >> leafref-
> > ing
> > >> becomes the issue.   This is why I'm suggesting the netconf-notif YANG
> > module
> > >> *use* the netconf-server-group itself.  This way, when the
> > >> *netconf-notif
> > draft
> > >> is implemented, its own definition comes into play.  When done this
> > >> way,
> > the
> > >> flag would no longer be needed since the entire netconf-server
> > >> instance
> > would
> > >> be SN-specific.
> > >
> > > The NETCONF-Notif draft needs to be implemented now for dynamic
> > subscriptions.
> > 
> > From above, and I can't ascertain why this is, when dynamic
> > subscriptions
> > don't
> > appear to utilize the "netconf" identity in any way...
> 
> No, but non-YANG Sections 5, 7, & 8 is needed.  Plus many of the
> examples.
> 
> > > An update to NETCONF-notif for configured subscriptions is possible to
> > > insert
> > > the call-home leafref (or insert new grouping).  But this update
> > > becomes
> > > unnecessary if ietf-netconf-server.yang is augmented as described
> > > above.
> > 
> > Perhaps, but it seems unnatural to do it this way.  What makes sense
> > to me is
> > for the module that claims to be the transport-binding module to
> > provide the
> > configuration for binding the transport.
> 
> At this point we do have a relatively minor difference of option which
> need not impact the closing the current
> draft-ietf-netconf-netconf-event-notifications.
> 
> > >> >> That said, I have to say that I'm not entirely sure if I understand if
> > >> >> what is
> > >> >> planned is legal.  For instance, in a normal NETCONF call-home
> > >> >> situation,
> > the
> > >> >> NETCONF session begins with both sides sending <hello> messages and
> > then
> > >> >> the server waiting for the client to send RPCs, which might include a
> > 5277
> > >> >> <create-subscription>, after which the <notifications> begin to flow.
> > >> >> Is
> > >> >> this the same here, or are you expecting the <notification> messages
> > >> >> to
> > start
> > >> >> flowing immediately?
> > >> >
> > >> > A subscription started notification will be sent after the hellos are
> > successful.
> > >> > Can you point to something in RFC 6241 which says a <notification>
> > >> > can't
> > be
> > >> sent
> > >> > until an RPC is sent from the client?
> > >>
> > >> It's not a very good reference, but I found this (emphasis added):
> > >>
> > >>    o  client: Invokes protocol operations on a server.  In addition, a
> > >>       client can *subscribe* to receive notifications from a server.
> > >>
> > >> We should ask the WG.  All I know is that it's always been that the
> > >> client
> > does
> > >> something to initiate server behavior.  Admittedly, this is kind of a
> > >> new
> > thing,
> > >> and it might be okay, but I think it warrants review by others.
> > >
> > > You are welcome to make the request.
> > 
> > Eric, you are the Editor.  But beware, this could blow up and we
> > decide to
> > drop the netconf and restconf protocols bindings entirely and only
> > focus
> > on transport bindings for things like gRPC and udp-pub-channel.  If
> > NC/RC
> > are needed, then the server could configure a standard call-home
> > connection
> > (via the ietf-*conf-server modules) from which the client can issue a
> > start
> > a dynamic subscription.  Just thinking this might be a better win.
> 
> Things are far easier with HTTP based transports, because you must get
> an explicit OK from a subscription-started before sending any
> <notification>.  See RESTCONF-notif for configured subscriptions which
> used no RESTCONF at all for this function.
> 
> Eric
> 
> > > Eric
> > 
> > Kent // contributor
> > 
>