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

Hi Qin,

> On Feb 6, 2021, at 4:51 AM, Qin Wu <bill.wu@huawei.com> 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

Fixed.

Thanks.

> 
> -Qin
> -----邮件原件-----
> 发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Rob Wilton (rwilton)
> 发送时间: 2021年1月14日 21:12
> 收件人: netconf@ietf.org; draft-ietf-netconf-https-notif@ietf.org
> 主题: [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
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com