Re: [netconf] Configured receiver capability exchange

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 28 January 2020 00:44 UTC

Return-Path: <mjethanandani@gmail.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 2A01F3A11E3 for <netconf@ietfa.amsl.com>; Mon, 27 Jan 2020 16:44:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0q6eRbdMOZh9 for <netconf@ietfa.amsl.com>; Mon, 27 Jan 2020 16:44:35 -0800 (PST)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 2BC0A3A0D6A for <netconf@ietf.org>; Mon, 27 Jan 2020 16:44:35 -0800 (PST)
Received: by mail-pf1-x436.google.com with SMTP id x185so5730738pfc.5 for <netconf@ietf.org>; Mon, 27 Jan 2020 16:44:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Mo7UCJlKgl8lC5+WuA5Doqk3NgpFQYR1fzpKB8LcwHg=; b=Lz3FGiI2SPw/SoHAbOOSQ9tCrDH8V/fQ+aUqhiSv7rB2n5l2hh8Xk1wSNsINd9P25W Ie9abBKNBuYWTWBG3S063IqSP5ezCgJpI3fCquHq7iZjblCL/1B1avuq0LImM+8/WEW6 HqIhhIhJDIepXIW7gIBXUL86Z6+i8Ziml1xa6QYNlh8Z2frp6Stu8X0/zKK0tMhrWiJp P5ccFNfh6Ige81p3ngkDRjgGB+F3hq+8rtYdv5JPUYllyDfCeIkE/+J9y8tc93qIp/RO s4gECnLmJSxLoUDd8FK09d4KY++855qDl20AucyA/ii59Fkng3SdC6DKPjbvqIDHQTpR osSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Mo7UCJlKgl8lC5+WuA5Doqk3NgpFQYR1fzpKB8LcwHg=; b=D0du3YpUdSR0jkyvZ8X4VOpfTUg5hdjwzGNdpG2FL+2IjLu8oAoF2OhEXK8NEjDd4x zsDI4rHn1p0MUc0lcMbm+dKBkG2Z4kqpywyYPmTCvl0ZFpkfjYK8s6OdVgAvo4CCJkJg 0Or4Y1shzQdNOsyW8QYfglzum1oD0ejM6V+3PgHDfuMCCwDiWTUkU1b6Tl9IOnqDxqpS lABL8Q1Os07+0zi5DrZMhk8+zDQOoxlX34kUpP4H0LRN++XpxmfMMuGBfUUz7lk9vK0Z PI00ckH3yeyoBjAySHG5U9bGJddtYB2NE69QK4kUz0b2KS2LlDaPBnFiptXhbO1Z0kNu 4z+w==
X-Gm-Message-State: APjAAAV1k6PXZ5mJgZk8qcfKNx4LzDG1vs710VqDx49rn3OyjJocf5L8 +wo2XM90P12srZ0hxS+BnlNTNUQC
X-Google-Smtp-Source: APXvYqyyy1i9X8SXFsJ6q+QscOASkNt5NOo4AUtfHL7Q0xX50dGQcta/5uqo+xZ0mZDsmOFM075oLg==
X-Received: by 2002:a63:a54c:: with SMTP id r12mr21731615pgu.438.1580172274611; Mon, 27 Jan 2020 16:44:34 -0800 (PST)
Received: from [10.33.123.108] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id b12sm12849283pfr.26.2020.01.27.16.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jan 2020 16:44:33 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <9E429FFB-23F2-4005-9153-A35B4231E965@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1D1DF1B0-C973-4FAF-94B7-72437A3205BA"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 27 Jan 2020 16:44:32 -0800
In-Reply-To: <BYAPR11MB25368EF3AFE9E2CBF396B8D0A1370@BYAPR11MB2536.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <BYAPR11MB25368EF3AFE9E2CBF396B8D0A1370@BYAPR11MB2536.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/mzVcBFwRemmjBqwPhTSW_-KnIl0>
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 00:44:40 -0000

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.

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-messages/?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