Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif)

["Eric Voit (evoit)" <[e-mail]>]

> From: Martin Bjorklund, September 24, 2019 9:56 AM
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> >
> >
> > > > From the email I sent Martin on Sep 9th, each POST MAY contain
> > > > more than one notification:
> > >
> > > .... to which I replied:
> > >
> > >   I'm not so sure about the streaming though.
> > >   Perhaps pipelining is the right mechanism.  For "bulk" sending, the
> > >   "bundled-message" defined in
draft-ietf-netconf-notification-messages
> > >   seems right.
> > >
> > > To clarify: if the client just sends a stream of notifs it becomes a
> > variant of
> > > SSE.  The server doesn't know when the stream will end, and thus
> > > cannot simply close the session.  You probably want to indicate
> > > end-of-message somehow (like in SSE).  And the content type in the
> > > example below cannot be "application/yang-data+xml", since it is not
> > > a valid XML instance document; you'd have to invent a new media type
> to indicate the streaming.
> > >
> > > I think we should stick to simple HTTP where each notif is POSTed,
> > > as in
> > your
> > > diagaram above.  With HTTP pipelining you can do:
> > >
> > > ------> establish TCP
> > > ------> establish TLS
> > > ------> Send HTTPS POST message with YANG defined notification 1
> > > ------> Send HTTPS POST message with YANG defined notification 2
> > > <-----Send 204 (No Content) for 1
> > > <-----Send 204 (No Content) for 2
> > >
> > > ------> Send HTTPS POST message with YANG defined notification 3
> > > <-----Send 204 (No Content) for 3
> > >
> > >
> > > If the server wants to send multiple notifs at once, it can use
> > > "bundled- message".
> >
> > This seems a reasonable approach.
> > draft-ietf-netconf-notification-messages
> > has several advantages:
> > (1) can push multiple YANG notifications at once
> > (2) can include the subscription-id in notifications when subscribing
> > to a stream.  (Right now including an explicit subscription-id is only
> > available when subscribing to a datastore.)
> > (3) includes methods to discover lost/dropped notifications
> >
> > Two things which would need to be worked:
> > (1) discovering receiver support for bundled notifications.  (As some
> > form of understanding/verifying configured receiver support over HTTP
> > is already needed, this is a topic which perhaps can be merged into
> > that.)
> 
> This can be configured or auto-detected.  For auto-detection, perhaps we
> can use HTTP OPTIONS with the server returning a special body or header to
> indicate capabilities such as this one?

The method previously proposed for HTTP configured subscriptions was an "OK"
to the POST of a <subscription-started>.  The "OK" had to be received prior
to sending YANG notifications.  If the authors want to build upon this, I
could see HTTP OPTIONS as a way to provide receiver capabilities.  Some
discussion about what capabilities would be advertisable as options would be
worthwhile.  Also worth discussion would be any intersections with
NETCONF/RESTCONF capabilities discovery/exchange.

Eric
 
> > (2) Completion of draft-ietf-netmod-yang-data-ext
> 
> Yes!  IMO it is ready for WGLC; I'll ping the chairs again.
> 
> 
> /martin
> 
> 
> 
> >
> > Eric
> >
> > > /martin
> > >
> > >
> > > >
> > > >     POST /some/path HTTP/1.1
> > > >     Host: my-receiver.my-domain.com <http://my-receiver.my-
> > > domain.com/>
> > > >     Content-Type: application/yang-data+xml
> > > >
> > > >     <notification
> > > >       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
> > > >       <eventTime>2019-03-22T12:35:00Z</eventTime>
> > > >       <foo xmlns="https://example.com
> > > >       <https://example.com/>/my-foobar-module">
> > > >         ...
> > > >       </foo>
> > > >     </notification>
> > > >
> > > >     <notification
> > > >       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
> > > >       <eventTime>2019-03-22T12:35:00Z</eventTime>
> > > >       <bar xmlns="https://example.com
> > > >       <https://example.com/>/my-foobar-module">
> > > >         ...
> > > >       </bar>
> > > >     </notification>
> > > >
> > > >     <notification
> > > >       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
> > > >       <eventTime>2019-03-22T12:35:00Z</eventTime>
> > > >       <baz xmlns="https://example.com
> > > >       <https://example.com/>/my-foobar-module">
> > > >         ...
> > > >       </baz>
> > > >     </notification>
> > > >
> > > >
> > > > With response:
> > > >
> > > >       HTTP/1.1 204 No Content
> > > >       Date: Thu, 26 Jan 2017 20:56:30 GMT
> > > >       Server: my-receiver.my-domain.com
> > > > <http://my-receiver.my-domain.com/>
> > > >
> > > >
> > > > Kent // co-author
> > > >
> > > >
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf