Re: [Netconf] two-week review of drafts related to notifications and subscriptions

[Robert Wilton <[e-mail]>]

Hi Alex,

On 18/10/2017 21:35, Alexander Clemm wrote:
> Hi Rob,
>
> Thanks for your response!  Two quick comments to add on to Eric's:
>
> Regarding ordering of the work: IMHO, we shouldn't serialize this work but try to advance subscribed-notifications, yang-push, and netconf-notifications at the same time.  This work was already started three years ago with yang-push, from where the work was broken out and modularized into the current pieces (with some new pieces added, of course), and I think it is really time to bring it to a closure .
OK, serializing the work might be expressing this the wrong way.

If there any possibility that the notification format might impact the 
subscriber or YANG push configuration?  E.g. the encoding of the 
subscription identifier could affect what the associated configuration 
model looks like.

If so, then it feels like spending a couple months with the WG trying to 
nail down the notification format would be a good idea. Then the 
subscription and YANG push drafts could formally depend on the new 
notification format.

>    
>
> Regarding notifications and notification bundles, I think it is a worthwhile optimization to address individual notifications (vs notification bundles containing just one notification), given that the bundle comes with some overhead.  But of course you are correct in that the single notification can be considered a special case and be addressed just by a notification bundle, and ultimately it would be up to servers to decide what to do (if they have only a single notification to send).
I still don't entirely get this :-).

The device is generating an unbounded stream of notifications.  Most of 
the key information related to the notification (such as a timestamp, 
subscription id, msg contents) should be in the notification structure 
itself.  Ideally, you normally want the device to send the notification 
as soon as it can (but other traffic/latency may slow this down).

If the notifications are being sent to a client on something like a 
buffered TCP connection, then I would think that you would just write 
the encoded notification structures directly to the TCP steam.  I.e. 
presumably without any extra message header fields (back to wanting to 
keep the messages small).

Conversely, if the notifications are being sent over something more like 
UDP then I would assume that you may want to pack multiple notifications 
into a single packet, and add extra fields to detect lost notifications.

Thanks,
Rob


>
> Thanks
> --- Alex
>
>> -----Original Message-----
>> From: Netconf [mailto:[e-mail]] On Behalf Of Eric Voit
>> (evoit)
>> Sent: Wednesday, October 18, 2017 12:13 PM
>> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
>> <[e-mail]>; Kent Watsen <[e-mail]>;
>> [e-mail]
>> Subject: Re: [Netconf] two-week review of drafts related to notifications and
>> subscriptions
>>
>> Hi Robert,
>>
>> Thanks for the review.  Some thoughts in-line...
>>
>>> From: Robert Wilton, October 18, 2017 1:15 PM
>>>
>>> Hi,
>>>
>>> I've not had a chance to review all of these drafts yet, but I did look at both:
>>> draft-voit-netconf-subscription-and-notif-overview-00 and
>>> draft-ietf-netconf- notification-messages.
>>>
>>> My high level comments are below:
>>>
>>> It is unclear to me whether the plan is to publish
>>> subscription-and-notif- overview or not?  Having an overview document
>>> that binds the technologies together could be quite useful (in fact
>>> some of the background, and definitions could move to an overview
>>> draft, but I think that this intro draft could do with further work before
>> going to WG LC.
>>
>> I have not been thinking of progressing this overview document into a WG
>> draft.  The main reason is that several highly placed members of the IETF
>> have expressed that they don't want to see a proliferation of generalized
>> architecture context documents.  With Kent's assistance, I have been trying
>> to straddle this line.
>>
>>> The other question I had was relating to the ordering of this work. I
>>> understand the strong desire the get this work completed, but I do
>>> wonder whether the drafts would all be able to sit together more
>>> coherently if the work on draft-ietf-netconf-notification-messages was
>>> completed first, then the other drafts could presumably more cleanly
>>> depend on the new notification message format.
>> There is still a lot of longer-term work which needs to be done on
>> notification-messages.  Once the format stabilizes, we will be going through
>> each header object to determine its proper articulation.  Objects like
>> signature are about to get contributions on this doc.  Items like attestation of
>> the contents of the messages (as well as alignment with attestation of
>> information returned from a GET) could also take some time.
>>
>> And there are short term drivers which suggest we should close on some
>> form of yang-push over NETCONF at least.  For example, at the last IETF,
>> there was already some inter-vendor work at the Hackathon looking at
>> interoperability.  Also there exist several open source implementations of a
>> Subscriber client.  My hope is we just close now on that context, and let the
>> rest await the availability of notification-messages.
>>
>>> Regarding the notification message format itself: I wasn't quite sure
>>> if there needs to be a split between a bundled and unbundled message,
>>> in that it seems that having a single message format might be easier, e.g.
>>> by always using the bundled message format.
>>>
>>> But then I was also questioning that if the messages are being streamed
>> (e.g.
>>> over TCP) then possibly you don't want to include all of the header
>>> information, in that it is presumably desirable to keep the streamed
>>> messages as compact as possible.  I think that there is probably a bit
>>> of the bigger picture that I'm still missing.
>> Yes, going to one message can be done.  But as you point out It adds
>> overhead especially to smaller high frequency messages.  The other
>> complexity with bundled messages is the publisher needs to determine
>> exactly what should be placed in each bundle.  This might not seem to be an
>> issue, but what if some elements of the bundle need to be signed, and
>> others do not.   What should be the behavior?
>>
>> In the end, if the IoT guys don't have an issue with efficiency (where this
>> seems to matter most), we could collapse to one.  (it is discussions like this
>> which need to stew for a while before we can close on notification-
>> messages.)
>>
>> Eric
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 04/10/2017 22:24, Kent Watsen wrote:
>>>> We’d like to direct the WG attention to the set of drafts related to
>>> notifications and subscriptions, with the goal of getting a pulse on
>>> if the WG thinks they are ready to progress now.
>>>> To enable you get an overview and to see how the documents relate to
>>>> each
>>> other, this draft is a good place to start:
>>> https://tools.ietf.org/html/draft-voit-
>>> netconf-subscription-and-notif-overview-00.
>>>> The drafts related to this review are:
>>>>      -  draft-ietf-netconf-subscribed-notifications
>>>>      -  draft-ietf-netconf-yang-push
>>>>      -  draft-ietf-netconf-netconf-event-notifications
>>>>      -  draft-ietf-netconf-restconf-notif
>>>>      -  draft-ietf-netconf-notification-messages
>>>>
>>>> While this is not an official WGLC, we will issue one if the
>>>> response is
>>> positive. Please provide comments within two weeks.
>>>> Thanks,
>>>> Mahesh and Kent
>>>>
>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netconf
>>> _______________________________________________
>>> Netconf mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netconf
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf