Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06

Kent Watsen <kent@watsen.net> Thu, 18 February 2021 22:48 UTC

Return-Path: <01000177b754b3b3-87cb5eda-8f8b-4a27-be56-5dcc52a1e5c3-000000@amazonses.watsen.net>
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 544493A197D; Thu, 18 Feb 2021 14:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 fbs8na5LCi4j; Thu, 18 Feb 2021 14:48:39 -0800 (PST)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4DC3A197B; Thu, 18 Feb 2021 14:48:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613688517; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=TOckr77/fdvn+StNOKSyrch9iwPdvdsVTlkBubcBd3I=; b=fcc/Ti8hNo0reWVmVpiKXX+9fBBzEsWguPBXmQCShk3mU+xK6LtiP82KKoJFPz/v BaT4vZYBaO2biFCVk8cTvAvgcmE4L7dp/tQP4cLYeaKiN1+XX+U88eOCFLzbnVa7+/t KRzU+QPihacFJA7cLCQhmhW2NsSeiemXUrNUMMos=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Kent Watsen <kent@watsen.net>
In-Reply-To: <CABCOCHTqgk1D4=LvLJoA4BMpPYBrs5WvqLs60whBXK6EqAB3rA@mail.gmail.com>
Date: Thu, 18 Feb 2021 22:48:37 +0000
Cc: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000177b754b3b3-87cb5eda-8f8b-4a27-be56-5dcc52a1e5c3-000000@email.amazonses.com>
References: <MN2PR11MB43669EEF05655F07E39FE4BEB5A80@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHTqgk1D4=LvLJoA4BMpPYBrs5WvqLs60whBXK6EqAB3rA@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2021.02.18-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/hq1hBtvTbd3l4SppEmZTUwf0Azc>
Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
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: Thu, 18 Feb 2021 22:48:40 -0000

Hi Andy,

> It seems too much of the language is limited to XML or JSON encoding.
> The media type extensibility should be well-defined so this draft
> does not have unintended limitations later on.

We believe the defines an extensibility mechanism via the “capabilities” resource target, which we recently modified in our local copy in response to Martin’s comment enabling the capabilities to use any URI.   Please advise.


> There is a significant architectural change made without any real mention (sec. 4)
> In NETCONF and RESTCONF, a notification is a one-way message, meaning there
> is no application layer response whatsoever.
> 
> That is not the case here. Instead, the publisher sends an HTTPS POST for every notification
> and expects a "204 No Content" response for each one.
> The draft should explain the reasons for this change.
> HTTP client implementations tend to wait for a response to a POST.
> That is probably not what is intended here, but no text explains the details.
> 
> Sec. 4 does not mention what the publisher is supposed to do if the receiver does not
> send a response or sends something other than 204.  It seems like this redundant ACK
> adds complexity and network traffic for no benefit.


It is agreed that notifications have historically not entailed having any response from the receiver.  However, the HTTP protocol defines that there be a response, and since there is no content for a receiver to return, we suppose it to be 204 (No Content).

That said, please note that HTTP is a sessionless/stateless protocol and authentication MAY be conveyed via HTTP headers, which might necessitate a 401 (No Authentication) response.  There may be other possible reasons to return other values too (though we don’t have any examples to share).

To be clear, by no means are we suggesting that YANG “notification” statements introduce application-level responses.

It is unclear how HTTP responses cannot be returned; the only options seem to be for the draft to explicitly enumerate all possible responses, or leave it open.  Thoughts on what text should added?


Kent and Mahesh