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

Mahesh Jethanandani <> Wed, 17 March 2021 23:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 260CB3A1820 for <>; Wed, 17 Mar 2021 16:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] 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 dXMRC3p5ITGt for <>; Wed, 17 Mar 2021 16:44:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7989D3A181F for <>; Wed, 17 Mar 2021 16:44:58 -0700 (PDT)
Received: by with SMTP id m7so242140pgj.8 for <>; Wed, 17 Mar 2021 16:44:58 -0700 (PDT)
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=3YBMK9S9W31jXCWy8rOuoAuoxfcBb0dDf7cqgCu2fxw=; b=aijGQxO9l3jPA60NcwI+UyABtme9S+rmdZfRGxGwyfiaQEAZGAnpZBLJL6bBSUY3wo sAn+d7r/fzlvszkLnc+PsJkHZmhyDBTIn1pjzbyvt2QGmSN+YOdJs+bcnMP4aS1SYOJv 0+6uDT+nd36fbHL13it0bznMHpg1nGxQGhvqaWO6zC0r16D/qnqUAQQbtJpX2FLzsJKV OtjT1Z74C48FC7Ty9Wk2BLqVKVcfBr+AfeMMJyG1iF3MaV4UoQ68F1B2a3809oQIvwYo T+QRAFVTA2AMW55Zw+pk3zfP5m0GcyJ0NiXl3Pub/bBWmIjBs2X4M+UD6NQTQE5Z4wIC N+ZA==
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=3YBMK9S9W31jXCWy8rOuoAuoxfcBb0dDf7cqgCu2fxw=; b=QMiWBJzXduW4DSmNfPS5OwzXIhMC+qbcnQUk/O0qgAwqD1nCQKjfLwZxNgGKlrqKNU tjiETkqhTs0hGu5WOwqQm34bdy/KS49RVSbEJqo3678NmycsGATEA/OdPAq8kJBdgUh+ amhhyy4SLqc+kMl9nSAeH+08DK6T8t2HMWjtBOwJPFyfLOmoPGV3RNUFuN6AfvelVEOh D4zuobryhP3AJJlvzKuTNd5K6roMWZQJ/+WoAaarEOU5+hN+PdqZFiOmvjzSDC0VG9rd luYnYV5EKDZXjl8JsNBm0mu3EJoFKYXF7NbdHWMkbEGKfbMNKI+PXyCfzwWj32FRNCi3 XnzQ==
X-Gm-Message-State: AOAM532PgPLVWZfA25no2nTZJ24806ilIL6+0zLC5Z+1HQurmjewawWP pmhIVVgpO++/HckoFvNzv3AgrpxPnCuS/w==
X-Google-Smtp-Source: ABdhPJzzgVUZ+tGkI58dGNdE/HEnfPiXYtUaaZQ6mIhi9oZZDqL30a/lgStud4I/T8ytX1ItfBvE6A==
X-Received: by 2002:a63:c901:: with SMTP id o1mr4697998pgg.232.1616024696663; Wed, 17 Mar 2021 16:44:56 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:e834:82e3:cfdc:e68d? ([2601:647:5600:5020:e834:82e3:cfdc:e68d]) by with ESMTPSA id g26sm152783pge.67.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Mar 2021 16:44:56 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_886DD661-833E-41A1-817B-8CE38377F36A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 17 Mar 2021 16:44:54 -0700
In-Reply-To: <>
To: Martin Björklund <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt
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: Wed, 17 Mar 2021 23:45:00 -0000

[Trimming it down to open issues]

Hi Martin,

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

How about this?

     "A capability supported by the receiver.  A list of standard
      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.
> 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?

That is correct. This capability advertised by the receiver says that it support RFC 8639 based state machine. Only if the receiver advertises this capability  a “subscription-started” has to be sent before sending a notification. See Section 2, Overview of Publisher to Receiver Interaction. You will notice that in the figure, there is no requirement (by default) that a “subscription-started” has to be sent. 


Mahesh & Kent (as co-authors)