Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)

Andy Bierman <andy@yumaworks.com> Thu, 05 July 2018 20:21 UTC

Return-Path: <andy@yumaworks.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 BF78D130DE3 for <netconf@ietfa.amsl.com>; Thu, 5 Jul 2018 13:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 JzUQR2OqWMj6 for <netconf@ietfa.amsl.com>; Thu, 5 Jul 2018 13:21:14 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D1E12E039 for <netconf@ietf.org>; Thu, 5 Jul 2018 13:21:14 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id a134-v6so7986682lfe.6 for <netconf@ietf.org>; Thu, 05 Jul 2018 13:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ca7RpbQW7//Cs9Ard/BiUYlFiddIsnWuv5Jr7y2x96E=; b=weeZc1iu2eW881LFBX7EA/KFohthS68Dow+v3ApRNuKr+eZ4rd0O4Muk/VTgN7crW3 HLHOmCaGev30AiW9elH3V5izZxNJzvg9cXgjqVmIbc1qTmPao7bFINjTem4oegnplMjv UeKh9KjU0dOgZnBNzdODf+TWdBNpjsTCFLzo3aEvBWkWqnM22wcFchKYKRnBRTbvb3Hg ToMYwBdBns63na1Y1qNMX2iFd8qrOPpfxQ+r0TKkmA2djiBaMyG35qq4X3yR6QzGegkE P8AvXAW+lFNj4AJqTfnQNVs3KEIJJ5T1zv8R41GBYSxTxneGX+kZ8i0njKY5uiXS25AW vPsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ca7RpbQW7//Cs9Ard/BiUYlFiddIsnWuv5Jr7y2x96E=; b=RX/odLItXckOW5hS1Hw0Pop3YOgAJHhwkScbF3Y+fXt0AOD3D/U+3ZFlQ3rphV+9Y1 0q2+wxENCgG6D75GB469RTr7PIwGj3qzxll/e3GEiPN3t5KODYxteinqPt8FfdvjlVTA xiasu8zghz07pJtWpFGO/gSa+Pbs3dOHRFgPj5NrkT7xx+rDV6mR85xnJaB1b4lYRqP6 qVcBTyvNspTvhW1HHr/U5gSADPNkeC5Yr8pO/eBcNq/VFOTWIsr1AEgL01xv9tNJ/W7P nM4CI3LYYJgi7n3BPhR0fHc48OtfxhyItd+G5Tdax1ehEdwJ41E7EKK2LErVHYuQiNIx iNyw==
X-Gm-Message-State: APt69E3qlAVPL4nXXv3VHeOL/0e9ZHeztkf/wcHFAXAMuzT7WelVrvKa Qckrh1k3gYyzlrreZSnvghtqD//rL/UywJhuCTcXmg==
X-Google-Smtp-Source: AAOMgpdHnqxdHgM4HtaZaXe/2hI4o0+PjCnviD1t3pCZP63euy6rHxBPXLecqJCrRSneojuBoGGdgvBZpNXIYcGPNes=
X-Received: by 2002:a19:518a:: with SMTP id g10-v6mr5265127lfl.78.1530822072455; Thu, 05 Jul 2018 13:21:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 13:21:11 -0700 (PDT)
In-Reply-To: <9ac13af1919c4abc8428398a17ad940b@XCH-RTP-013.cisco.com>
References: <4df95162a0a8464b884c4e88268df8ca@XCH-RTP-013.cisco.com> <DBD6B0CC-FE74-4C5A-A318-C96C8FBE11FE@sit.fraunhofer.de> <858F63BA-37A2-4925-B340-4DD79CEBEEF9@juniper.net> <CABCOCHTux6+pW=0xhPsgVKWqAr5uNKTNW-Qgv5CpV06Ki1hd-g@mail.gmail.com> <8c68a8ce85d946579f325e311a8e67a9@XCH-RTP-013.cisco.com> <D9AB67AB-A0B2-4D04-8672-76B704800C86@juniper.net> <CABCOCHQjYHYomj1ES+0bH2pOaJZ4Wa_z3suQiJpASmDXP35teg@mail.gmail.com> <b202abf5-359e-ec1a-3251-9599924d4f4f@ericsson.com> <a8dfdce9e6c04721ab9e5cdb8534bc04@XCH-RTP-013.cisco.com> <CABCOCHRQoRuX+=OtM50VHg8MCco65osCy=PWDHYuy_gvjNjEkA@mail.gmail.com> <b7c65965cf3b43e3b898c5c2f9519573@XCH-RTP-013.cisco.com> <CABCOCHTfkNtBoXU7XMk3yxif1DXBH5m4QVP0YF1yPhHYJu0fKQ@mail.gmail.com> <C6F8149F-A9CD-4A75-A32D-6C6DDDFADBD8@juniper.net> <CABCOCHTBuNnY973Le++xunf8ZZ4T+vEEfCAA1DwSO_BCi=e0KQ@mail.gmail.com> <9ac13af1919c4abc8428398a17ad940b@XCH-RTP-013.cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 5 Jul 2018 13:21:11 -0700
Message-ID: <CABCOCHSEDwpQi5ZyDNOLJMoWDs1EpNPZr_aBWDSAikJNPijZJQ@mail.gmail.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
Cc: Kent Watsen <kwatsen@juniper.net>, Balazs Lengyel <balazs.lengyel@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7e9cc0570464930"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/S9nxIq6oLRUlx3E4YNyBsSX5qwY>
Subject: Re: [Netconf] Anyone want just Configured Subscriptions? (was RE: LC on subscribed-notifications-10)
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: Thu, 05 Jul 2018 20:21:17 -0000

On Thu, Jul 5, 2018 at 1:03 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> *From:* Andy Bierman, July 5, 2018 3:17 PM
>
> On Thu, Jul 5, 2018 at 11:41 AM, Kent Watsen <kwatsen@juniper.net> wrote:
>
>
> >>> Why does there need to be a dependency on the client-server module?
> >>> The only things missing from the "receiver" list are 2 leafs (host,
> port).
> >>
> >> <Eric>  This is what was there initially.   But several people have
> >> asserted that host and port interacts poorly with call-home.
>
> The issue isn't call-home, per se, the issue is that a
> transport-independent
> draft should leave all transport-specific details to the transport drafts.
>
>
>
>
>
> The current "receiver" list is not usable as a standard.
>
> IMO the need for a (host, port) tuple is not enough to require new modules,
>
> but I do not object to removing the configured subscriptions because
>
> they have to wait for other YANG modules.
>
>
>
>
> > Of course it interacts poorly with CallHome, because the receiver list is
> > used INSTEAD of CallHome, not with CallHome. CH is for initiating a new
> NC
> > or RC session, so a "special" version of it that doesn't initiate a
> session
> > would be a misuse.
>
> I don't follow this comment.  For configured subscriptions, the device is
> definitely initiating the underlying transport connection and, in the case
> of NC/RC, we've determined that the ietf-*conf-server's call-home mechanism
> is appropriate.
>
>
>
>
>
> CallHome is for initiating the NETCONF or RESTCONF protocol.
>
> It applies to dynamic subscriptions. E.g., our server initiates a CH
> session
>
> and the controller starts the session and decides what operations to send
>
> (such as establish-subscription).
>
>
>
> CH does not allow the client to use the TCP connection for any other
> purpose.
>
>
>
> <Eric> Initiating a Call Home before a dynamic subscription is absolutely
> fine.  Luckily this step is out of scope for the subscription drafts, as
> the transport session is already available when the establish-subscription
> comes in.
>
>
>
It is not fine according to RFC 8071.

   The techniques described in this document are suitable for network
   management scenarios such as the ones described in Section 1.1.
   However, these techniques are only defined for NETCONF Call Home and
   RESTCONF Call Home, as described in this document.

      ...Any use of call home with SSH/TLS for purposes other than NETCONF
or RESTCONF will need a thorough contextual risk assessment. ...

If your server opens a TCP connection to the client and does anything other
than
the procedures in RFC 8071, then it isn't CallHome. It is something new
that should be specified in an RFC and approved by the IETF.



> Eric
>
>
>

Andy


>
>
> Kent // contributor
>
>
>
>
> Andy
>
>
>
>
>