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

Mahesh Jethanandani <> Fri, 19 February 2021 02:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D9C43A0AD1; Thu, 18 Feb 2021 18:01:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jf_9DMZoM8Y9; Thu, 18 Feb 2021 18:01:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D9A63A0ACB; Thu, 18 Feb 2021 18:01:54 -0800 (PST)
Received: by with SMTP id a24so2469130plm.11; Thu, 18 Feb 2021 18:01:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mWGY9SqGETmxBmhxUuBP6V2toduP9TrjdUYgugB2KOM=; b=HVvlyB17fBZop9acHZKkYo1SVUmP7SDMb9dZXC6fzzXpIkz/+AfMWrETsJZ2j3EAhE 2Bpv3bQ1xd9dY5RgoQHitCOSdA79O6lzIO7jOiAlVmIV3J6Im4SPnBZcpoS3qtiQeu0X j7s67IUmO2oAwQJGB6VxwAhyZDER3xjt8Ztf8bOeRIrWZ6z+rVXVvf/Sazo+Io7y/Zyi 9+Vfcwj9l6k49Fx2Spye4WH43t5OaA61pKhjdhxiOZdEMjes53TgmbxXFC2SrMSXKPqT v47Gy3IsXaxMZZ6REGCzmi4uNLYhO/f1e/9NIPWU9bQoB1aQaz0hvatvQZ3FFMXZQlPI nYaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mWGY9SqGETmxBmhxUuBP6V2toduP9TrjdUYgugB2KOM=; b=qruIqr6om93MIGWbnQpOosRz5J/3BeE6MgAbn1m1anoYY82CPaYmTWTvyNbbkfljZH 4PlhqnQsRELVCTkKBGt0DoI22SK6UiwtCfx2Ir3I5lx1wrVjRVPLe2oiddWMuvAnIOU9 vDeOd42PzQAGUu4ZeLiaghV0VgA0II64XeNnk6bXUJlo+Lg46HX7gQnN8qm8JWyCS8Vi Bbd5iirvbJFmpAP3iF6b93yiFVujlI3w0fjG9WwmTGljpNVlSStEIJ6mkh+rk62F4+kc QzUaKnDqnulb435PxruSqHDWkM5CLCe+TLMfwFHHuz6TsuMeqZLae7j4XMVpCtlDdi6Q ruQw==
X-Gm-Message-State: AOAM533yFcWQJy+6qHGDRbx6YtkxkEHyAsK9CdmF2TiXyPF08xyyRcQz CluX/9XY9BWBJnr65B0fM68=
X-Google-Smtp-Source: ABdhPJw6ppU4OfPJ/CzQQtW3YOMWKa9Fhd64O4IWyNrI412oshifXblFAc+09BpAPM/atB9qPF0pOQ==
X-Received: by 2002:a17:902:728a:b029:e3:530:cc73 with SMTP id d10-20020a170902728ab02900e30530cc73mr6603407pll.60.1613700114392; Thu, 18 Feb 2021 18:01:54 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:d5f6:3661:26de:c885? ([2601:647:5600:5020:d5f6:3661:26de:c885]) by with ESMTPSA id ms24sm6491391pjb.18.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 18:01:53 -0800 (PST)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_43F21887-C7EF-4614-8375-7306972D755D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 18 Feb 2021 18:01:51 -0800
In-Reply-To: <>
Cc: "" <>, "" <>
To: Qin Wu <>
References: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Feb 2021 02:01:57 -0000

Hi Qin,

> On Feb 6, 2021, at 4:51 AM, Qin Wu <> wrote:
> Hi, authors of draft-ietf-netconf-https-notif
> I have read the v-07 that has just been posted and have the following comments:
> 1. Section 1 said:
> "future efforts may define support for other encodings (e.g., binary)."
> Why Cbor can not be supported as one of example binary encoding? Isn't COBR IETF published standard work?

We are not suggesting that CBOR cannot be supported. Note, “e.g. binary” is exactly that, an example. The draft in its latest version (-08, unpublished as yet) allows for leaf-list definitions of receiver-capabilities that can be specified using a URI. Another draft can extend that list to advertise CBOR capability.

> 2. Section 1 ,last paragraph said:
> "
>   Configured subscriptions enable a server, acting as a publisher of
>   notifications, to proactively push notifications to external
>   receivers without the receivers needing to first connect to the
>   server, as is the case with dynamic subscriptions.
> "
> I want to make sure two things this paragraph want to convey:
> 1.	So call home is not needed in this case to establish service initiated RESTCONF connection

Yes. This draft does not leverage RESTCONF call home (RFC 8071) capability.

> 2.   The connection between the server and the reciver is short live connection rather than long live connection? Correct?

Per standard practice, the underlying TCP connection may be kept around longer if it is desired.

> 3. Section 2 said:
> "
>   The protocol consists of two HTTP-based target resources presented by
>   the receiver:
> "
> Is target resource target URI? Can you provide a reference for target resource?

The updated draft (-08) clarifies that the two resources are sub-paths of a common resource that the publisher must know (specified by the “path” variable which acts a prefix to where the two target resources are defined).

> 4. Section 2 second bullet said:
> "
> a future effort MAY extend the protocol to send multiple notifications per message.
> "
> What do you indicate for sending multiple notification per message? Should you add reference to message header and bundle draft,i.e., draft-ietf-netconf-notification-messages?

draft-ietf-netconf-notification-messages would be the right place to extend this draft to enable multiple notifications per message for e.g. by adding “bundling” capability.

> 5. Section 4.1 said:
> "
>   The publisher sends an HTTPS POST request to the "relay-
>   notifications"  resource under a known path on the receiver
> "
> Where relay- notifications" resource is defined? In which RFC? Can you provide a reference to it. It is a surprise to see “relay-notification” appeared without any context information 
> to be laid out for this? E.g., why relay-notification is picked? Is there any other choice?

“relay-notification” (corrected for plurality) resource is one of the two resources that are sub-paths of a common resource defined by the receiver. It was probably not very clear, and therefore in response to Martin’s comment, we have provided context to the two resources in the draft in the latest version (-08). Please review when it is published to make sure it addresses your comment.

> 6. Section 4.1 said:
> "
> Instead of saying that, for JSON-encoding purposes, the module
> name for the "notification" element is "ietf-restconf, the module
> name will instead by "ietf-https-notif".
> "
> s/the module name will instead by/the module name will be instead by



> -Qin
> -----邮件原件-----
> 发件人: netconf [] 代表 Rob Wilton (rwilton)
> 发送时间: 2021年1月14日 21:12
> 收件人:;
> 主题: [netconf] WGLC: draft-ietf-netconf-https-notif-06
> This message begins a two-week WGLC for draft-ietf-netconf-https-notif-06 ending on Jan 28.  Here is a direct link to the HTML version of the draft:
> Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.
> Please note, the reason that I am making this request rather than the WG chairs is because both chairs are listed as authors on this document.
> Thank you,
> Rob Wilton, OPS AD
> _______________________________________________
> netconf mailing list

Mahesh Jethanandani