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

Martin Björklund <mbj+ietf@4668.se> Tue, 16 March 2021 07:44 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 D697A3A1CC1 for <netconf@ietfa.amsl.com>; Tue, 16 Mar 2021 00:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.121
X-Spam-Level:
X-Spam-Status: No, score=-0.121 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.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=jPFstSTD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AguKCTKt
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 ZumYnTJD7A8U for <netconf@ietfa.amsl.com>; Tue, 16 Mar 2021 00:44:04 -0700 (PDT)
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 7293B3A1CBF for <netconf@ietf.org>; Tue, 16 Mar 2021 00:44:03 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 10B1E5C00FF; Tue, 16 Mar 2021 03:44:02 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 16 Mar 2021 03:44:02 -0400
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= ADcwH2gLZ9VG3q7rlNgQSsYiVOa1ojjGEX0zcV6mx9s=; b=jPFstSTDMkD0pHk+ hK2G8OrXwji+GJI9f5D2ugKGNxhCgOX07KkELWIl8FOY4FjCgBmSID0pJf+zKBys 93vNPvbvgTy8kZnpP4oTTpVl3cDoTLf8gJBTDR8yAOnGh/SvK9Cowb1c1GmdWnSh hWFZRUtPAaG7cFYRxHkZHZiyEyoR37SWs4WZoMgcihmXAQyQtgLdU65bo8DkKWnR tqQJSypxZklTOdQIZ1EUO3KY347jvOExXflXl73VVq4kJciu4JgsUK35QPC79Pjf a+PU3r4eZo/osMyhudIwvZKWo5W8URIMEfHKPzq6TMjEb5L+IgaqCh9ylvdo+/kl oimAzA==
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=ADcwH2gLZ9VG3q7rlNgQSsYiVOa1ojjGEX0zcV6mx 9s=; b=AguKCTKtWXes8f/t3UERnZ8+KYLa+ztbLpHCmaTqgjTpMgYIUJ8pGur2j HTF2KkTtyw4Y8CggMDzEUYitOCiEWGR5/3JH2Rm4Gg6sDQEEK7T7wR7BGhhpZmTm MyQR/Nu6X3a0kAC+7ExcxS3Twomwz/ytU0ZV1yhs0nP9LWBcnsxs5AXqJe/FLXZT WQt4bi0/7WVUaPRKlBkQXzPShUmKtPNwXOdxbbr3rjbcIiSvSydE+rj4hnCbwG9P HiMPXY18SBAVjA8bqbFnRa2nuRTvV8wTL1qXrU4s2JTH2XCON3OqgAs7DRK1JKTf Hre9CHfuZWpaO0cgMcPVqh8BpS2Xw==
X-ME-Sender: <xms:wWFQYHXhyDudMPE7YyhIGV131dBXC_ED8AQuTNy2B59vFavAjputqA> <xme:wWFQYPk46YQUIekItzVuBTcYff1Pp6AjjdtC1bNOcOnDtNtgMkAfZhl4pSrqWrev- QqIRREIbw06dKb8nHI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefuddgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth gsredtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeejfeeggfeufeekheelle evuddtgfdvjeeltdejheetffekudehtedvtefggfdtteenucffohhmrghinhephhhtthhp shhnohhtihhfihgtrghtihhonhhrvggtvghivhgvrhhsrhgvghhishhtrhihshgvvghrfh gtgiiggiigrdgrshdpihgvthhfrdhorhhgnecukfhppeduheekrddujeegrdegrddvudeh necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgsjh doihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:wWFQYDZQaYunJJAoxrzM4BD9LSR0UbfLIDwOXBFiobioz6RqyierZg> <xmx:wWFQYCUXkwTRib9edOTKVql9AVVO_72GkbLCMaXEgnbtgHpbsNT6Aw> <xmx:wWFQYBndy8F47Nb6Tr6xySNX0k0o2h2wIWBB5dZ_8tOdc4UfrvCYcg> <xmx:wmFQYPQxNE_TsIanY8-qf64fTs-Mbv6HOWnIRnot4CckNI2sUtINTA>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 2759C24005B; Tue, 16 Mar 2021 03:44:01 -0400 (EDT)
Date: Tue, 16 Mar 2021 08:43:59 +0100 (CET)
Message-Id: <20210316.084359.697724172010373047.id@4668.se>
To: mjethanandani@gmail.com
Cc: netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <6B4CE162-09AD-4564-A7DA-7961C69064A0@gmail.com>
References: <161403681984.28848.17868609938843218324@ietfa.amsl.com> <20210223.095903.174502091636867084.id@4668.se> <6B4CE162-09AD-4564-A7DA-7961C69064A0@gmail.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/oJ5UjzxD9mXO8qMxd-eewtcl5Ck>
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, 16 Mar 2021 07:44:06 -0000

Hi,

Thanks for addressing my comments.  See inline:


Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> 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  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.”;

Ok, but is it correct to say that the IANA registry is a "partial
list"?  I would say just "list" or perhaps "standard list".

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


I'm sorry but I still don't understand.  What is the purpose of this
capability?  Does it mean that if the reciever advertises this
capability then the publisher MUST send e.g. "subscription-started"?
This seems a bit odd; if this protocol is used as a configured
subscription, then the publisher will send "subscription-started"
regardless of any receiver capabilities, right?


/martin



> 
> > 
> > 
> > 
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> Mahesh & Kent (as co-authors)
> 
> 
> 
> 
>