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

Martin Björklund <mbj+ietf@4668.se> Thu, 04 February 2021 19:39 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 0A5883A1777 for <netconf@ietfa.amsl.com>; Thu, 4 Feb 2021 11:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level:
X-Spam-Status: No, score=-0.123 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.997, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=Vf5/tHQq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HbkoGrMM
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 esqS78JfDEeO for <netconf@ietfa.amsl.com>; Thu, 4 Feb 2021 11:39:47 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABFC3A1776 for <netconf@ietf.org>; Thu, 4 Feb 2021 11:39:47 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A71E75C0129; Thu, 4 Feb 2021 14:39:46 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 04 Feb 2021 14:39:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= uutfq1P0OlNgPdfsaR7G0jvLMPbZDyftgsPM1D4CZM8=; b=Vf5/tHQq3H0rIDWr Q/asBWik8iDUAqjH1hYetOzJCJfSyU6Bsz8BIy5NnNGD649DibESK4BFMyqziacY 8LM+ZDGInTH8i1OBWiVo0fE0RioZ2mZ9wz7Zj3NVmb+nKycdEhqrUdEfblnFgpQO DOYY+0DNI2HWUZ1AXpBuZ6gebSVSUEruRf548ZAslkyN8Gnsh/tq+HXfwJxl+CIE 6knNOT9+dmeuVCbl1WYDgfLQhuykweVCYyqyh/9lvJ/3+csNZQmScylHhsgptPEp oFfeVRm1DlN0S4tMtGpeGxLQVHhic+dp/SicTcTv46Lda6uQifXxrkl+r1wjaoDU dL22Gg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=uutfq1P0OlNgPdfsaR7G0jvLMPbZDyftgsPM1D4CZ M8=; b=HbkoGrMM4krArDcAClnEdIToZCtDWwWcxgnNtFFKHdcNnjpbnJVH5Xf9I +M3TDKHAzskRu4iM0hT/da+h210yYVv3Ps7sFj671tnVgf0cfbSrwwWTKL1vgjgh xFZ1N5IQ0ZdskgpvI4Qjn9kpXzVn3YH7vSQdEvYGj9i0ROiboZ3KdjEqo9zF84gW zA7sFbSHLPvn24RdmkGhdEBHAxvjfDgXlKX7hM9DGeRpLF+kKMEe8xWRRzHT2j1s 4Y00KnxJDbCIgBqv46iGGYFCxgZCUWdUPNN3jw18iC0kwlE4VRk6Tl2goT1f9L/M IlpC9saI5h9rhv4NIluEv0JVpAkvw==
X-ME-Sender: <xms:gk0cYEKavL4CRX82gAOeIG-SR1Ar-4BNBRPtLdz9NrfwDhCzrW9fBQ> <xme:gk0cYE1obKiIsoWfYIVycHqgV3lODDblZxgqhwNR2XiuIR5SfQcCDKastNgfWa4U0 p6iLskVtHqrRwFgUDw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgeeggdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepfeehkefgudekfeehieehhf ekgedvffehteevgfeffeeghfdvfeeuleduvddvgfehnecuffhomhgrihhnpehivghtfhdr ohhrghenucfkphepudehkedrudejgedrgedrvdduheenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg
X-ME-Proxy: <xmx:gk0cYC5rjlDe7aR42daa_lvkNoB2KUVjVlh84VOyE2j6bFyQhXjkHw> <xmx:gk0cYF9WpEXLwRiTI7tX9xWVSK8kVRgyIn9yHM3jrYYTL_UZXp5kuw> <xmx:gk0cYBV8AMJTXhnfOcDXqwJsvFr6DdEIibjyXaND_MlFafqmhn_c0g> <xmx:gk0cYJzhLhTDrwfWpTrNtap90LaWWbKw6tIquiaQCJN2_TvYL4nDqw>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id F12FF1080064; Thu, 4 Feb 2021 14:39:45 -0500 (EST)
Date: Thu, 04 Feb 2021 20:39:44 +0100
Message-Id: <20210204.203944.1533922869570231478.id@4668.se>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com>
References: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <A979E7E5-1F85-4D6D-8560-1321589800B9@yahoo.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9Am5YQvazH-LyppCJNE0WrEFCuM>
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, 04 Feb 2021 19:39:49 -0000

Hi,

I have reviewed this document (-07), and I just have some minor
comments.  The document is well written and easy to understand.


o  Abstract

   [...] It also presents an example
   module for configuration without using the data model defined in RFC
   8639.

  Is this such an important example that it should be mentioned in the
  abstract?  Does this mean that the NETCONF WG doesn't think that the
  data model defined in RFC 8639 is useful anymore?  Why is a
  "simpler" module needed?


o  3.1.  Applicability

   For publishers using Subscription to YANG Notifications [RFC8639],
   dynamic discovery of a receiver's supported encoding is necessary
   only when the "/subscriptions/subscription/encoding" leaf is not
   configured, per the "encoding" leaf's description statement in the
   "ietf-subscribed-notification" module.  FIXME: do they need to
   discover *any* capabilities?

  Note that the "encoding" leaf has a when expression and is
  present only if the chosen transport is derived from
  sn:configurable-encoding.  The "https" transport identity is not
  derived from sn:configurable-encoding, so the "encoding" leaf will
  never be present.


3.2.  Request

   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

  I think you should mention what this "known path" is.  After reading
  the data model in detail I understand how it works, but it would be
  good with an early explanation (the path is configured per
  receiver).


o  3.3

     leaf-list receiver-capability {
       type string {
         pattern "urn:ietf:capability:https-notif-receiver:*";
       }

  What's the point of the "urn:..." prefix if it is required?  It
  would be simpler to just have the "*"-part in the registry.

  But I think a better solution would be

     leaf-list receiver-capability {
       type inet:uri;
     }

  This would be more extensible.


o  3.4.  Example

   The publisher can send the following request to learn the receiver
   capabilities.  In this example, the "Accept" states that the receiver
   wants to receive notifications in XML but, if not supported, to use
   JSON encoding.

  Copy&paste error?  The "Accept" header states that the client wants
  to get the capabilities as xml, json.


o  5.2

   <CODE BEGINS> file "ietf-subscribed-notif-receivers@2021-02-02.yang"
   [note: '\' line wrapping for formatting only]

   module ietf-subscribed-notif-receivers {

  Remove the "note" line (no "\" is used, and this line should not be
  part of the <CODE BEGINS>).

o  6.2

  As above, but also remove the  "\" in the module; they are not
  needed.


o 6.2

  feature receiver-identity {
    description
      "Indicates if the server supports filtering notifications

  s/if/that/



o  Appendix

  The examples would be easier to read if the "\"-line wrapping
  convention was used only when absolutely needed.  For example, this
  doesn't look right:

                  <cleartext-password>my-password</cleartext-password\
>

  And this:

  <subscriptions xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-n\
otifications">

  would be easier on the eye as:

  <subscriptions
    xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">





/martin




Kent Watsen <kent+ietf@watsen.net> wrote:
> NETCONF,
> 
>       The just posted -07 addresses issues raised thus far.
>       https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07>
> 
> Henning, Eric, Reshad,
> 
>       Please re-review as your comments are important to us.
> 
> Everyone else,
> 
>       The hasn’t been many reviews as yet.  Please review this
>       version, as it is significantly better (ready for publication?)
>       than the prevision version.
> 
> K.
> 
> 
> 
> > On Feb 1, 2021, at 11:33 AM, Reshad Rahman <reshad@yahoo.com> wrote:
> > 
> > Good with me.
> >  
> > Regards,
> > Reshad.
> >  
> > From: Kent Watsen <kent+ietf@watsen.net>
> > Date: Sunday, January 31, 2021 at 7:54 AM
> > To: Reshad Rahman <reshad@yahoo.com>
> > Cc: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
> > Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
> >  
> >  
> >> I've reviewed this document and I think the document will be ready once the changes planned by the authors (regarding notification-messages) are made.
> >  
> > Thanks, but a couple more problems:
> >  
> > 1) the URLs are bad.  Specifically, the example in the “Learning Receiver Capabilities” section uses a nonsensical URL (‘/‘).   The authors propose to instead use a sub-resource to the user-configured “path” (e.g., GET /some/path/capabilities) and move the POST URL to another sub-resource (e.g., /some/path/relay-notification).  [see below for more on this]
> >  
> > 2) the media-types are bad: “application/yang-data+[xml/json]” is used for notifications, which is wrong since they are not YANG-defined, and the custom media-types for capabilities (application/ietf-https-notif-cap+[xml/json]) is a way overkill.  The authors propose to use “application/[xml/json]” for both cases.
> >  
> > 
> > 
> >> I have a question on the following YANG description. Section 4.1 mentions 'path-absolute' for the URI but the description below says "Relative URI...". Should this description be clarified/corrected or am I missing something?
> >> 
> >>             augment "transport/tls/tls/http-client-parameters" {
> >>               leaf path {
> >>                 type string;
> >>                 description
> >>                   "Relative URI to the target resource.";
> >>               }
> >>               description
> >>                 "Augmentation to add a path to the target resource.";
> >>             }
> >  
> > Agreed.  How about this?
> >  
> >         leaf path {
> >           type string;
> >           mandatory true;
> >           description
> >             "URI prefix to the target resources.  Under this
> >              path the receiver must support both the 'capabilities'
> >              and 'relay-notification' resource targets, as described
> >              in RFC XXXX.";
> >         }
> > 
> > So, if path==“/som/path”, capability-discovery would be to "/some/path/capabilities” and notifications would be sent to “/some/path/relay-notification”.
> >  
> > Thoughts?
> >  
> >  
> >> Formatting nit:
> >>            Trust anchors (i.e. CA certs) that are used to authenticat\
> >>  e
> >  
> > Fixed, but the other example cannot be fixed because the “xmlns” strings alone are too long, and XML doesn’t internally support folding, and the “string” type doesn’t allows for whitespace (include ‘\n’) both at the beginning and end of strings (recall my request for rfc6991-bis to define a “token” type that would enable the parser to discard any found, so our examples could more often be manually-folded).
> >  
> > K.
>