Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

Kent Watsen <> Tue, 10 September 2019 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBA25120033 for <>; Mon, 9 Sep 2019 18:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ESPEbj-24exQ for <>; Mon, 9 Sep 2019 18:05:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C7A0120024 for <>; Mon, 9 Sep 2019 18:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1568077538; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=efDrcRE5mgjXUk6Qu9Onu3m07XCJgWN+DBq5vuxlJFU=; b=AKvPK6w4f7FB+PGjLRUYbqvvOL4CmMPT71Hq7vxXqqvOc6ZDF7QwRU8wC4awYdSw noH3BRQU8kZ70fy4bE/+LbPkLD7XwW8mDoNexgMaBjA2E0fanlr3Iv4tmBPwJ9SvxQs cipSgsKTtp89INQDrO9+LQczqYOEm4Q2PUD1mmbg=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F707A7ED-FD87-4DC2-897F-BE6114381922"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 10 Sep 2019 01:05:38 +0000
In-Reply-To: <>
Cc: "" <>
To: Martin Bjorklund <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.10-
Archived-At: <>
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
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: Tue, 10 Sep 2019 01:05:42 -0000

Hi Martin,

Mahesh reminded me that this message still needs a response...

> I think that defining a "simple" protocol for notification delivery
> only is an interesting problem to work on.  However, this document
> doesn't define this protocol.  It just says "https".  But how is the
> client supposed to deliver the notifs?  PUT?  POST?  To which uri?
> Further, it doesn't discuss authorization at all (which "user" will be
> used for NACM checks of the notifications?)

Many good points here.

Firstly, while ietf-http-client defines HTTP "basic" authentication parameters, the example in the I-D didn't show them, even though the YANG module uses the ietf-http-client module.  That said, ietf-http-client fails to define a "path" field, so that appears to be something that should be added to it (to your point about it being good to have a user of the client-server drafts to validate the design).  Thusly that part of the example in the I-D should be:


For high-availability, note that ietf-tcp-client defines the "remote-address" field as follows:

    leaf remote-address {
      type inet:host;
      mandatory true;
        "The IP address or hostname of the remote peer to
         establish a connection with.  If a domain name is
         configured, then the DNS resolution should happen on
         each connection attempt.  If the DNS resolution
         results in multiple IP addresses, the IP addresses
         are tried according to local preference order until
         a connection has been established or until all IP
         addresses have failed.";

As for the HTTP operation and request body, POST-ing a stream of notifications seems right.

Assuming `notification` statements ("foo", "bar", and "baz") are defined in a module called "my-foobar-module" (with xmlns ""), an example HTTP/1.1 notification-delivery message might be (blank lines added for readability):

    POST /some/path HTTP/1.1
    Content-Type: application/yang-data+xml

      <foo xmlns="">

      <bar xmlns="">

      <baz xmlns="">

With response:

      HTTP/1.1 204 No Content
      Date: Thu, 26 Jan 2017 20:56:30 GMT