Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt

Martin Björklund <mbj+ietf@4668.se> Tue, 23 February 2021 08:59 UTC

Return-Path: <mbj+ietf@4668.se>
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 0329B3A28A1 for <netconf@ietfa.amsl.com>; Tue, 23 Feb 2021 00:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 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, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=ic94divT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QBQaBWXO
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 SHMXZU-SC7bb for <netconf@ietfa.amsl.com>; Tue, 23 Feb 2021 00:59:09 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDB33A271B for <netconf@ietf.org>; Tue, 23 Feb 2021 00:59:09 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 164CF10AB for <netconf@ietf.org>; Tue, 23 Feb 2021 03:59:08 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 23 Feb 2021 03:59:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:subject:from:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=fm1; bh=ASxtqAdl0OFCk sXCSWGQz7wCDmWg3e0u6MEqji/xe/0=; b=ic94divTawttjdF6OfpWaizTzaxWd Yrtp7KNRoTZ1WJN5d7VIUcoUpZtiIC48jUH7dWy0i3OUtb3LhDDwFGm1Z9WERmO2 ZpUWkpjBJBkwV+CI2x8DpjLMfylvG+ph2kmIFFcOCMW9VfKGA7fYPHLXM1T/8Af1 2d+hdKXo7+LZy2akLiKtxSz3qbOGr+o4rkt3VyVcksz0iJBU68y99dSzjiJ7OM96 qXFO52u4Yp1Ytvb/SlRcRmjADhhjG7YEXuc1mIhE0SUZ7FC+EmAcXuCbIrDyN/Ab AEJAidopM6r2d6Btr90y++YN6B9u/xFr0OxoA22vhBdxeVo2YAR6FPYBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ASxtqAdl0OFCksXCSWGQz7wCDmWg3e0u6MEqji/xe /0=; b=QBQaBWXOO9/WM0vj7xyy0GuubhhLm7ClGYgA5fW9rBsKYGH2anB6afa9B X96V+JvYc5u/DLKzu1ileTNiJM3/ZOFwALnLzpt7KrMK72+I4Hcg8MbubdpxzsrZ 5JN7OQaKoPaGdrD/u3V8cWsBugpFdBK1zBUFcnTfLJSVmTL5VymHGbHeXb8eu9/p SwPc/5CmXP5w5jzGZmcrv+SYa6BX/fjhX1F7GnH/cb6KD+Kt/gPssoJG9fRrkdFQ VFS2r3hslmZdCaEYGiIT39vf/LcrgRVWYDbrxAa/KP8exkGlWvo9YAkW8zpnRuis nwzSPB2FOVoDOeFSkzHnyMWrAkAgw==
X-ME-Sender: <xms:2cM0YIz1QoiphqMFpxDJ2iKLVs_dWrvR_3d85Kq4Te_Zy248CI5U-Q> <xme:2cM0YMRwJDovilL95RIt95bn_MMSHZUxCWaxGauJRoolq1wwG_CpWQotKeO5CPwlU m3tta3fQUE7vlih2Mw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeeggdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepteefheegkeehfeeujeehie egfeejvedtteegveejieegieejfeeljeevgfejuddtnecuffhomhgrihhnpehhthhtphdq tghlihgvnhhtqdhprghrrghmvghtvghrshdrihhnpdhhthhtphhsnhhothhifhhitggrth hiohhnrhgvtggvihhvvghrshhrvghgihhsthhrhihsvggvrhhftgiggiiggidrrghsnecu kfhppeduheekrddujeegrdegrddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:2cM0YKVz5GKkkojP3V-xsZWcK1mRF-e7yAzO6gRv8qnsm53oTMua1A> <xmx:2cM0YGjnKlJLbMgIRPbOIuztoND6Zdndgj3u7ZMi2u4Pd8R-k1RnMw> <xmx:2cM0YKC7T0h1qUE0_hs9rpuZKYQhaqy275eNJHmugH6Z3rz5l3H1Cg> <xmx:28M0YNMFsCRDefjqcJElW0DOmHX-URyaQodam1tyAYYtP4N-lzTroA>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C75D24005B for <netconf@ietf.org>; Tue, 23 Feb 2021 03:59:05 -0500 (EST)
Date: Tue, 23 Feb 2021 09:59:03 +0100 (CET)
Message-Id: <20210223.095903.174502091636867084.id@4668.se>
To: netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <161403681984.28848.17868609938843218324@ietfa.amsl.com>
References: <161403681984.28848.17868609938843218324@ietfa.amsl.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sWhTh4kFxmGuQ28RpMOAnyS3KAc>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt
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, 23 Feb 2021 08:59:11 -0000

Hi,

I have read this version, and most of my comments for -07 are
addressed.  However, I still have some comments:




o  2.  Overview of Publisher to Receiver Interaction

   The protocol consists of two HTTP-based target resources presented by
   the receiver.  These two resources are sub-paths of a common resource
   that the publisher must know (e.g. specified in its configuration
   data model).

 When reading this text (and 3.2 and 4.1) it is still not clear how
 this path is made known to the publisher.

 I suggest these changes:

 NEW:

   The protocol consists of two HTTP-based target resources presented by
   the receiver.  These two resources are sub-paths of a common resource
   that the publisher must know.  If the data model in section 6.2 is
   used, this common resource is defined in the "path" leaf in
   "http-client-parameters".

   o "capabilities":  A target resource enabling the publisher
      to discover what optional capabilities a receiver supports.
      Publishers SHOULD query this target before sending any
      notifications or if ever an error occurs.

   o "relay-notifications":  A target resource enabling the publisher
      to send one or more notification to a receiver.  This document
      defines support for sending only one notification per message; a
      future effort MAY extend the protocol to send multiple
      notifications per message.

 (note that sections 3.2 and 4.1 already refer to these resources by
 the names "capabilities" and "relay-notifications").


 Additional note: are these really "sub-paths of a common resource"?
 The "path" is just a prefix, it is not a resource.  Perhaps rephrase
 to:

   The protocol consists of two HTTP-based target resources presented
   by the receiver.  If the data model in section 6.2 is used, these
   resources are defined by the "path" leaf in "http-client-parameters".


 In 3.2 and 4.1 I would also do:

  OLD:

   To learn the capabilities of a receiver, a publisher can issue an
   HTTPS GET request to the "capabilities" resource under a known path
   on the receiver

  NEW:

   To learn the capabilities of a receiver, a publisher can issue an
   HTTPS GET request to the "capabilities" resource (see Section 2)
   on the receiver

  and similar in 4.1.



o  3.3.

     leaf-list receiver-capability {
       type "inet:uri";
       description
         "A capability supported by the receiver.  A full list of
          capabilities is defined in the 'Capabilities for HTTPS
          Notification Receivers' registry (see RFC XXXX).";
     }
   }

   As it is possible that the receiver may return custom capability
   URIs, the publisher MUST ignore any capabilities that it does not
   recognize.


  This seems contradictory - how can the server return custom
  capabilities if there is a full list of capabilities available in an
  IANA registry?



o  3 and 8.3

  There's a new capability defined:

   Name:        urn:ietf:capability:https-notif-receiver:encoding:rfc8639-enabled
   Reference:   RFC XXXX
   Description: Identifies support for RFC 8639 state machine.

 This is the only description of this capability in this document.
 How is it supposed to work?  What should a publisher do with this
 information?  Which state machine is referred to?

 (And, the name of the capability should be more descriptive, and not
 contain the RFC number.  What if there's a bis version published with
 some errors fixed?)





/martin