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

Martin Bjorklund <mbj@tail-f.com> Fri, 29 June 2018 09:05 UTC

Return-Path: <mbj@tail-f.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 AEFEE130E15 for <netconf@ietfa.amsl.com>; Fri, 29 Jun 2018 02:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 CrVUojCWgdjR for <netconf@ietfa.amsl.com>; Fri, 29 Jun 2018 02:05:57 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B63E9128BAC for <netconf@ietf.org>; Fri, 29 Jun 2018 02:05:57 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id ADD561AE02F0; Fri, 29 Jun 2018 11:05:56 +0200 (CEST)
Date: Fri, 29 Jun 2018 11:05:56 +0200 (CEST)
Message-Id: <20180629.110556.2237400478562295884.mbj@tail-f.com>
To: evoit@cisco.com
Cc: kwatsen@juniper.net, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <89a99290a9ff4addb3d8c537aae89dbf@XCH-RTP-013.cisco.com>
References: <c034b39204074d36abdc9f57a6d7537b@XCH-RTP-013.cisco.com> <BD5235E8-596A-40A8-ACDE-3AD947E6D8D9@juniper.net> <89a99290a9ff4addb3d8c537aae89dbf@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0cMjc06UxH8FDeXs6zpKJZJ4wAI>
Subject: Re: [Netconf] IETF 101 SN Question 1: Proper designation of receiver
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: Fri, 29 Jun 2018 09:06:00 -0000

Hi,

"Eric Voit (evoit)" <evoit@cisco.com> 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
> > 
>