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
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 > > >
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- [Netconf] IETF 101 SN Question 1: Proper designat… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Martin Bjorklund
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Kent Watsen
- Re: [Netconf] IETF 101 SN Question 1: Proper desi… Eric Voit (evoit)