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

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

> > 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.)
(2) Completion of draft-ietf-netmod-yang-data-ext 

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