Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

[Martin Bjorklund <[e-mail]>]

Hi,

I think that defining a "simple" protocol for notification delivery
only is an interesting problem to work on.  However, this document
doesn't define this protocol.  It just says "https".  But how is the
client supposed to deliver the notifs?  PUT?  POST?  To which uri?
Further, it doesn't discuss authorization at all (which "user" will be
used for NACM checks of the notifications?)

The document relies on the client-server suite of drafts, including
the individual draft draft-kwatsen-netconf-http-client-server (these
need to be added as references BTW).  I would really like the WG to
finish these documents before starting to work on something new.
(BUT, I also think that having a module that is the user of these
generic client-server drafts is very useful to validate the design of
them.  (*))

I have a bunch of more detailed comments as well, but these can wait.

(*) An observation: This module introduces a level of indirection for
receivers; something we should have done in the
subscribed-notifications model directly.  Perhaps we should revisit
that model and add the indirection there instead.


/martin



Kent Watsen <[e-mail]> wrote:
> This email begins a 2-week adoption poll for:
> 
>     https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00
>     <https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00>
> 
> In-room support for this draft was noted but, as always, it is
> necessary to confirm WG consensus on the list.  If interested in the
> WG defining an HTTPS-based solution for *configured subscriptions*
> (for which there are none to date), please voice your support for this
> draft's adoption.  If objecting, please state your reasons.
> 
> PS: Authors, please additionally respond to as if there is any IPR to
> disclose.
> 
> Kent and Mahesh // as chairs