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

From: Qin Wu <[email-masked]>
Date: Sat, 6 Feb 2021 12:51:04 +0000

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?

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
2.   The connection between the server and the reciver is short live connection rather than long live connection? Correct?

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?

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?

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?

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 [mailto:[email-masked]] 代表 Rob Wilton (rwilton)
发送时间: 2021年1月14日 21:12
收件人: [email-masked]; [email-masked]
主题: [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:

	https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 18 Feb 2021 18:01:51 -0800

Hi Qin,

> On Feb 6, 2021, at 4:51 AM, Qin Wu <[email-masked]> wrote:
> 

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.

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

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

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

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

> s/the module name will instead by/the module name will be instead by

Fixed.

Thanks.

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

Mahesh Jethanandani
[email-masked]