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

[Kent Watsen <[e-mail]>]

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 in parked state and whether it’ll be in drive mode soon.

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