Re: [netconf] Configured receiver capability exchange

Martin Bjorklund <mbj@tail-f.com> Tue, 28 January 2020 16:28 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 781581209D5 for <netconf@ietfa.amsl.com>; Tue, 28 Jan 2020 08:28:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 qwRWRuji0qMx for <netconf@ietfa.amsl.com>; Tue, 28 Jan 2020 08:28:03 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3315C120BBB for <netconf@ietf.org>; Tue, 28 Jan 2020 08:27:59 -0800 (PST)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 446D01AE01AA; Tue, 28 Jan 2020 17:27:56 +0100 (CET)
Date: Tue, 28 Jan 2020 17:27:18 +0100
Message-Id: <20200128.172718.208580931536379456.mbj@tail-f.com>
To: evoit@cisco.com
Cc: mjethanandani@gmail.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <BYAPR11MB2536E16646834EBB9BFF8E3DA10A0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com> <20200128.074935.2293026921027473843.mbj@tail-f.com> <BYAPR11MB2536E16646834EBB9BFF8E3DA10A0@BYAPR11MB2536.namprd11.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/KjqzUqXnxG4kXOfhTxkUZ1wCEBY>
Subject: Re: [netconf] Configured receiver capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Tue, 28 Jan 2020 16:28:05 -0000

"Eric Voit (evoit)" <evoit@cisco.com> wrote:
> > Hi,
> > 
> > Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> > > Hi Eric,
> > >
> > > Specifically to your suggestion towards
> > > draft-ietf-netconf-https-notif, and its ability to learn the receiver
> > > capabilities …
> > >
> > > As you might have seen, we had suggested a rather simple mechanism to
> > > learn the capabilities of the receiver that involved a GET with a
> > > specific Content-Type to invoke a response that returns the metadata
> > > we desire. All the method requires is a HTTP(S) server at the other
> > > end. If the Content-Type is not supported by the server, the server
> > > will return an error. We like it for its simplicity.
> > 
> > I prefer this over the proposal to (mis?)use <subscription-started>.
> > 
> > First of all, one thing you want to discover is the encoding for
> > notifications.
> > <subscription-started> is a notification.  So which encoding should be
> > used
> > to send it?
> 
> <subscription-started> is just for configured subscriptions.  The
> encoding is set as part of the publisher configuration.

My bad (but perhaps unfortunate that this needs to be manually
configured, rather than dynamically agreed upon).

Anyway, the <subscription-started> notification must be sent in some
message format.  Should it be 5277-style or
draft-ietf-netconf-notification-messages-style?

> > Second, there is no "reply" defined for <subscription-started> since
> > it is a
> > one-way notification, so adding that seems a bit out of place.
> 
> With configured subscriptions, there is a need the receiver to confirm
> acceptance of the subscription.  Otherwise, configured subscriptions
> becomes a denial-of-service risk.  As a result of this need, there is
> the following text in the Security Considerations of RFC-8639:
> 
>   With configured subscriptions, one or more publishers could be used
>    to overwhelm a receiver.  To counter this, notification messages
>    SHOULD NOT be sent to any receiver that does not support this
>    specification.  Receivers that do not want notification messages need
>    only terminate or refuse any transport sessions from the publisher.
> 
> This is one reason we already need to do an "ok" is in reply to the
> HTTP, even without capability exchange.  I am just thinking we can use
> the already needed "OK" message for additional information on receiver
> capabilities.

Not sure I follow how this is a need to do an "ok" and what that would
be.  In my understanding, when the publisher needs to send a
notification to a configured receiver that is doing https-notif, it
will open an HTTPS session (unless there already is one active) and
POST the notification in some format, with some encoding.  The HTTPS
server will reply 200 OK or an error, or perhaps close the session.


/martin



> 
> Eric
> 
> > /martin
> > 
> > 
> > 
> > >
> > > Your suggestion is of using <subscription-started>. Does that not
> > > involve having a RESTCONF/NETCONF server support on the receiver? If
> > > <subscription-started> is supported, does it mean
> > > <subscription-modified> or <subscription-terminated> also needs to be
> > > supported? If we do not/cannot support modification of subscription,
> > > and instead require establishment of a new subscription to learn of
> > > modifications, what would we be missing out with the GET method? Could
> > > subscription be terminated simply by terminating the session?
> > >
> > > Thanks.
> > >
> > > > On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <evoit@cisco.com>
> > > > wrote:
> > > >
> > > > Hi Mahesh,
> > > >
> > > > During the IETF 106 session, there was discussion on how both a
> > > > publisher might know if there is receiver support for
> > > > draft-ietf-netconf-notification-messages
> > > > <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-
> > messages/?include_text=1>.
> > > > Section 6 highlights several of the considerations.  Relevant are
> > > > the
> > > > following:
> > > >
> > > > (a) Remote device capability discovery from the point of view of the
> > > > Publisher needs to be enhanced to know if the far end can interpret
> > > > notification messages type beyond RFC-5277, Section 4.
> > > >
> > > > (b) This capability discovery question is relevant for both
> > > > configured subscription receivers and dynamic subscribers.
> > > >
> > > > (c) The capability discovery question can be generalized beyond
> > > > subscriptions, as there are many reasons to know the available
> > > > capabilities of the far end.
> > > >
> > > > (d) Capability discovery advertisement has traditionally been
> > > > discussed within transport documents (e.g. RFC-6241 Section 8.1).
> > > >
> > > >
> > > > Based on (a)-(d), coming up with a transport independent
> > > > point-solution within draft-ietf-netconf-notification-messages
> > > > <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-me
> > > > ssages/?include_text=1>
> > > > *just* to discover this single element of client functionality seems
> > > > overkill/heavyweight.
> > > >
> > > > I was fine with letting this remote capabilities discovery question
> > > > sit for a while.  However draft-ietf-netconf-https-notif
> > > > <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01>
> > > > shows that we now must address this question.  Specifically should
> > > > the diagram section 1.4.1 show this capability exchange?
> > > >
> > > > It turns out that independent of
> > > > draft-ietf-netconf-notification-messages, there several questions in
> > > > draft-ietf-netconf-https-notif which need to be answered prior to
> > > > the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined
> > > > notification #1" anyway.  These questions are:
> > > >   (1) Does the targeted HTTPS receiver support configured subscriptions?
> > > >   (2) Can the targeted HTTP@ receiver accept a new subscription as
> > > >   described in a <subscription-started>?
> > > > Only if these questions are "yes", should the <subscription-started>
> > > > be responded to with an "OK".
> > > >
> > > > Add to this a third question driven from (a)-(d):
> > > >   (3) Does the receiver support the message type within
> > > >   "draft-ietf-netconf-notification-messages"?
> > > >
> > > > A strawman way to handle the all three questions within
> > > > draft-ietf-netconf-https-notif would be to respond to a
> > > > <subscription-started> notification with an HTTP Status 202
> > > > (Accepted)" acknowledgement.  This 202 would include body elements
> > > > listing supported receiver resources.  Maybe something YANG encoded
> > > > via ietf-yang-structure-ext containing:
> > > >
> > > >       <foo xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >         <capabilities>
> > > >           <capability>
> > > >             urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
> > > >           </capability>
> > > >         </capabilities>
> > > >       </foo>
> > > >
> > > > What do you think of this approach?
> > > >
> > > > Eric
> > >
> > > Mahesh Jethanandani
> > > mjethanandani@gmail.com
> > >
> > >
> > >