Re: [netconf] Configured receiver capability exchange

Mahesh Jethanandani <> Tue, 28 January 2020 00:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A01F3A11E3 for <>; Mon, 27 Jan 2020 16:44:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0q6eRbdMOZh9 for <>; Mon, 27 Jan 2020 16:44:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BC0A3A0D6A for <>; Mon, 27 Jan 2020 16:44:35 -0800 (PST)
Received: by with SMTP id x185so5730738pfc.5 for <>; Mon, 27 Jan 2020 16:44:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 [] ([]) by with ESMTPSA id b12sm12849283pfr.26.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jan 2020 16:44:33 -0800 (PST)
From: Mahesh Jethanandani <>
Message-Id: <>
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: <>
Cc: "" <>
To: "Eric Voit (evoit)" <>
References: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [netconf] Configured receiver capability exchange
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?


> On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <>; 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 <>;.  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 <> *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 <> 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