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

Mahesh Jethanandani <mjethanandani@gmail.com> Mon, 15 March 2021 21:23 UTC

Return-Path: <mjethanandani@gmail.com>
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 AB44E3A0EF9 for <netconf@ietfa.amsl.com>; Mon, 15 Mar 2021 14:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5WEVGPBkYaAD for <netconf@ietfa.amsl.com>; Mon, 15 Mar 2021 14:23:12 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7A93A0EF6 for <netconf@ietf.org>; Mon, 15 Mar 2021 14:23:12 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id a13so843931pln.8 for <netconf@ietf.org>; Mon, 15 Mar 2021 14:23:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=75eETvG35jrDta42s2LpMa9oiE1UFPfR4PJHzFuQp6A=; b=jFU4q9KjLeLJT1CS2zL4OmZhPHLCuiuvQtY0cfVV/Npv2Ob2js7X7PMXqBe6GR/RdW /MerpQysMfUJBZSwhbL6uF/pdCcwNxGXhYggHsSlWLnyO0W92gYLcfOh2tCNVEeV4lPD GQkE+18jGADng7TWwhSw0u4ct4hMuSh/Ll7cGhl2hZAbke3DwbNGsmcjs82cNhBF2TiJ fWtShMgvf/Isr7t938U4aJZBflnfYfdpyr7bnk5/aQ5PSOzewV2XS5M0xC12e58AhPgh xshjF4TtRTRjnyHZzuVftVcJU+I8ygiZRmAYI9ijarIb6O51hgVFsB/v6YiJEX/c7PIz FfwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=75eETvG35jrDta42s2LpMa9oiE1UFPfR4PJHzFuQp6A=; b=VFYft4vHQpWDX9A/d/mJBUHMi1A0Grt9gMNp+ERGNO/KGs7Mbms4CHoWqPMBySaw6W D+KkZirkkbGy5XOaCIXmisrpLZ/Jz6yfuqYFxnnvtZ/8ZVW74fuWSKNBEOj2gO6eQmSh kMuZrprf0AwoyfqIOSlKr9yfB+IVqBGcVjORBeIjZyeu8hZh5rO/0bSIMJPWCJBDB7H+ e/4DPO6xHtncFl4VE9WotLlQTFVcBwuzGHIqiCSmB97UWWrbdcCfyKGvW9cjtFwaiVCp IzOFuKv75kzT2MKg2+WRx1ChxhHZglFtBslumK4qYHmXXhyAi+IBKnTmkFaqDSR1gdC6 jNIw==
X-Gm-Message-State: AOAM531Bn+5kVf3tw7G15EWiRC3auinWwt8KGNtcXJA96BeBV8Yilu93 aD30OvszEMcj0I6xk5EGUKaK6p7tRTg=
X-Google-Smtp-Source: ABdhPJyWWiP2SMR0S0kTX4wXV9oKcqT12lQSOI5p1kFqj43YGt40rIsz1hL1/bHjQSquMuGNKxlREA==
X-Received: by 2002:a17:903:188:b029:e6:52f4:1b2d with SMTP id z8-20020a1709030188b02900e652f41b2dmr13590201plg.58.1615843391187; Mon, 15 Mar 2021 14:23:11 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:642b:ba90:b393:7e40? ([2601:647:5600:5020:642b:ba90:b393:7e40]) by smtp.gmail.com with ESMTPSA id v14sm551698pju.19.2021.03.15.14.23.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Mar 2021 14:23:10 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <6B4CE162-09AD-4564-A7DA-7961C69064A0@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBBAAB71-3C3A-42C2-826D-0836CC54F053"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 15 Mar 2021 14:23:08 -0700
In-Reply-To: <20210223.095903.174502091636867084.id@4668.se>
Cc: netconf@ietf.org
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>
References: <161403681984.28848.17868609938843218324@ietfa.amsl.com> <20210223.095903.174502091636867084.id@4668.se>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/TTQZqP4NPh3i4EqYDnxO8h_HuBQ>
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: Mon, 15 Mar 2021 21:23:15 -0000

Hi Martin,

> On Feb 23, 2021, at 12:59 AM, Martin Björklund <mbj+ietf@4668.se> wrote:
> 
> 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.

Thanks for the suggested changes. We have incorporated them.

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

Ack.

> 
> 
> 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".
> 

Good point. We removed "sub-path”, and any suggestions that it is a resource, from the document.

> 
> 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.
> 
> 

Applied the changes to the draft.

> 
> 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?
> 
> 

Here is the updated text for the description statement:

    description
      "A capability supported by the receiver.  A partial list of
       capabilities is defined in the 'Capabilities for HTTPS
       Notification Receivers' registry (see RFC XXXX). Additional
       custom capabilities MAY be defined.”;

> 
> 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?)

How about this for an updated name and description?

Record:
   Name:        urn:ietf:capability:https-notif-receiver:encoding:sub-notif
   Reference:   RFC XXXX
   Description: Identifies support for state machine described in RFC 8639,
                enabling the publisher to send, e.g., the
                "subscription-started" notification.

> 
> 
> 
> 
> 
> /martin
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh & Kent (as co-authors)