Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

Mahesh Jethanandani <> Mon, 28 October 2019 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2312C120086 for <>; Mon, 28 Oct 2019 13:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 1FRELy-FeoH5 for <>; Mon, 28 Oct 2019 13:51:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A1B3120024 for <>; Mon, 28 Oct 2019 13:51:38 -0700 (PDT)
Received: by with SMTP id p5so1091867plr.7 for <>; Mon, 28 Oct 2019 13:51:38 -0700 (PDT)
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=K9fM6CEvMMfDwStR5of5vX1uyGNBdk00wFH6wbX0b24=; b=PXTNb+If/8JT0vYbynuJEc6ly8Z675LE6AmKTeow5h3/V4PvpLnPIpOzcEdJjRpwCy iZKwY9emWLKAtT/byAso7NFITN/XFzbJ0uKrPfhAMV39be8IZwhIfvafEZslBYtQuYO9 fqKZvh81004LRQM2+K/QVUz0ErnkSADJhTD2f+hmisAvbCpil6nv87qQO4IINjfxC2tZ GS0595eLeHw/jtGKj5F1PrQGsWQqDSEFWP9ukgyB4nVrzI7TkCGFnDIAoMtaCVMLzHwU WUysAubCMUJDoU9QaPe62LQugSnEv5xugXahiO2Az13crKQqJxnU/Z5AriLghz7tYbDC d6fQ==
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=K9fM6CEvMMfDwStR5of5vX1uyGNBdk00wFH6wbX0b24=; b=aQ0yAI6EIwY5EffUkCsyvRtd1h/A6ZCWdImV9tv43Cx28QlgCa6gq2kcX0M759xk5/ FhMzCaeStZbTw+D9m/ob1HLSRYMILHWrbQOU0Hv/cfc/OgGDAESeNerKfcUXsTI4qbzh UCtOoN1aDCcoGnc90m7JsEE87/AZSTv24JFGLifjJxniIAJ7qZJu7Ch7eF75yidSrq6w PyZWU9wicSJeRQYWMGnFnua3EhtT8xoCQJSceGhnQOtgUhMdr4Nc2IYkx3xDboIM4Cv5 dOaeTlSD0qOBangUhaU4RyuLcG0seqk3aQmgyoHWOAgZcO/SrV3BVg+0yV0ULJM3cINu Zc+g==
X-Gm-Message-State: APjAAAU3/h3qzsd93r4oyF/jynu5a2g/ignGynV3edU7beizll3rlEem HwEOXr54mNW6BdZgdgSdVTs=
X-Google-Smtp-Source: APXvYqyNqrV1UFiJMi5O0WBrNcG/veiD7PHinSwnrh3pidzXRtNzUgsww1NNo1vE3UB7rhhqAQZLdQ==
X-Received: by 2002:a17:902:441:: with SMTP id 59mr34911ple.300.1572295897430; Mon, 28 Oct 2019 13:51:37 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id y20sm12799322pge.48.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Oct 2019 13:51:36 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_626CAC55-6F05-4C8B-BD67-1D972128630E"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 28 Oct 2019 13:51:35 -0700
In-Reply-To: <>
Cc: Kent Watsen <>, "" <>
To: "Eric Voit (evoit)" <>
References: <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
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: Mon, 28 Oct 2019 20:51:40 -0000

Hi Eric,

Picking up on this thread ...

> On Sep 3, 2019, at 8:00 AM, Eric Voit (evoit) <> wrote:
> Building upon that, there are a few elements which would be good to consider in future iterations.
> (1)  Understanding the capabilities of the configured receiver is important.  One or more publishers of configured subscriptions could be used to overwhelm a receiver which doesn't even support subscriptions.    This document should include ways to ensure a configured stream won't be established with an endpoint unequipped to deal with the inbound notifications.  As a starting point for these discussions, there are mechanisms in draft-ietf-netconf-restconf-notif v5 to address this.   E.g., the  HTTP transport augmentation on the receiver must send an "HTTP OK" to a "subscription-started" notification before the publisher starts streaming any subscribed content.

You bring up some interesting points.

> (2)  Multiple versions of draft-ietf-netconf-restconf-notif include topics/text which might be useful, even as an appendix.   For example Section B.2 of v5 includes example config operations and interaction models.

Our motivation with the draft is to keep the “protocol” simple. The draft does not assume HTTP2, and therefore cannot assume a state of “subscription-started” as described in draft-ietf-netconf-restconf-notif-05. 

What it can do, however, is to use the HTTP Response, much as you show in your draft, to indicate that the receiver could not process the notification for whatever reason.

> Side comment:  there are advantages in subscriptions over HTTP2 transports, which I don't believe it will be covered in this draft.  GRPC has the ability to optimize based its leverage of HTTP2.    To examples from draft-ietf-netconf-restconf-notif v5 which are good to think about are:
> (a) optimizing multiple configured subscription streams to a single receiver (such as a controller). 

This has been discussed on the thread, where Martin suggested the notion of “pipelining” of notifications. As far as “subscription stream” is concerned, the idea was to use “bundled-messages” structure defined in draft-ietf-netconf-notification-messages.

> (b) it can be easier overwhelm a receiver which is unable to control or handle the volume of Event Notifications received  
> It would be good to somehow capture the implications of using different underlying HTTP capabilities as part of these discussions.

I have opened an issue titled "Supporting discovery of receiver capabilities” for this in GitHub here <>. I am not clear on how a receiver can document its capability in a way that is meaningful to each stream across all the streams of messages it is receiving.

Mahesh Jethanandani