Subject: [netconf] netconf-https-notif-draft HTTP "pipelining"

From: Henning Rogge <[email-masked]>
Date: Thu, 14 Jan 2021 08:29:29 +0100

Hi,

I had a longer discussion with Kent Watsen yesterday and he asked me
to get the questions about the netconf-https-notif-draft to the
mailing list:

In section 1.5.1 the draft talks about "pipelining" of messages. Is
this meant equivalent to "HTTP 1.1 pipelining" or is this just a
technique unique to the draft? If this is not something reused from
HTTP, maybe there should be some advice on how this interacts with
normal HTTP server/client code.

Also the example in 1.5.1 seems to contradict each other.

The overview (page 5) shows the Publisher sending HTTPS POST message
once for each notification (which I think is important because the URL
is part of the context of the message)... but the content description
(page 6) does only show a single POST with multiple responses. Same is
true for chapter 8.3.

Henning Rogge

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 22 Jan 2021 11:08:26 -0800

Hi Henning,

The draft was trying to address the question of “pipelining” using two methods. One is the equivalent of “HTTP 1.1 pipelining” and the other is concept of “bundled-messages” introduced by draft-ietf-netconf-notification-messages. In the process it mixed both of them, and thus the contradiction in the example in section 1.5.1.

Let me update the document to fix the example(s), at which point the WG can decide if they want to support one or both the methods.

Thanks.

> On Jan 13, 2021, at 11:29 PM, Henning Rogge <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: Reshad Rahman <[email-masked]>
Date: Fri, 22 Jan 2021 14:46:52 -0500

Hi Mahesh,

Since draft-ietf-netconf-notification-messages is in parked state, and expired 8 months ago, should the netconf-https-notif document be using bundled messages? But I don’t know the reason why it’s in parked state and whether it’ll be in drive mode soon.

Regards,

Reshad.

From: netconf <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Date: Friday, January 22, 2021 at 2:08 PM
To: Henning Rogge <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [netconf] netconf-https-notif-draft HTTP "pipelining"

Hi Henning,

Thanks.

Hi,

Henning Rogge

Mahesh Jethanandani

[email-masked]

 

_______________________________________________ netconf mailing list [email-masked] https://www.ietf.org/mailman/listinfo/netconf

---

From: Henning Rogge <[email-masked]>
Date: Mon, 25 Jan 2021 08:38:51 +0100

Hi,

The problem I see with the "bundled messages" method is that it seems
to transmit the URL once... which contains an important part of the
Restconf Semantics... that feels like a strange restriction and
something easy to get wrong.

Henning

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Jan 2021 01:57:40 +0000

Hi Reshad, et. al.,

> Since draft-ietf-netconf-notification-messages is in parked state, and expired 8 months ago, should the netconf-https-notif document be using bundled messages? But I don’t know the reason why it’s…

There’s an open question as to what extent this draft supports draft-ietf-netconf-notification-messages.

Section 2 (Learning Receiver Capabilities) describes how a Publisher can discover what optional capabilities a Receiver supports.  The section includes an example that shows the URN “binary-encoding:1.0” being returned.  

What’s missing, however, is the creation of something like an IANA maintained registry for all of the URNs that can be returned by the Receiver.

This registry would need to, for instance, contain an initial entry to indicate the Receiver supports XML-encoded notifications.  It was/is an oversight that it’s not in the draft now.  Mahesh and I are working on an update for that.

Back to the "notification-messages” draft, it also is the case that there needs to be a URN for Receivers to use to advertise their support for bundled-messages.  The question is if this draft should be the one to register the “bundled-messages” capability into the new registry, or if the "notification-messages” draft should.

We believe that the "notification-messages” draft should register it because:

  1) In general, the I-D that defines a thing (e.g., a binary-encoding for notifs)
      should be the one that registers hooks as needed for the it to be used.  

  2) That this draft and "notification-messages” are both WG docs doesn’t
      change that, especially given that the "notification-messages” draft is
      expired. 

  3) We feel uncomfortable having a "notification-messages” example in this
      draft knowing that it will likely be wrong (as already a quick review shows
      potential problems)

  4) We prefer this draft not be held in the MISREF state by RFC Editor.

Thusly, we propose to remove the "notification-messages” references from the draft, leaving it to that draft to register a capability (for the Receiver to return to the Publisher) and provide usage examples.

Comments?

Kent and Mahesh