Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01

Thanks Tianran, some thoughts in-line...

> From: Tianran Zhou, August 22, 2017 10:22 PM
> 
> Hi,
> 
> I support this document to be adopted by the WG.
> The other call for adoption document draft-zheng-netconf-udp-pub-channel-00
> will refer this work for the message header design.
> So I would like to review and contribute if it is adopted by the WG.
> 
> Here are some initial comments:
> 1. I do not understand why the document separate the two formats for single
> record and bundled records. In principle, the bundled message can represent
> the general cases. Maybe you are considering some optimization. But I did not
> see it.

There are a few known reasons:
(1) Optimization: one less level of encapsulation for records.
(2) Provides a minimal change from existing YANG notifications: no need to add hierarchical parsing.
(3) Notification-time is mandatory with the bundling format, but optional for single records.

I suspect we will find additional reasons as we examine specific transports

> 2. You include the "dscp" in the message header. How can this be used in upper
> transport layer? It's an IP layer parameter.

If the same application does not control both the notification generation process and the IP bundling process, then there needs to be some communication between them to allow the DSCP to be set appropriately.  

> 3. You have a "record-count? uint16" in the bundled record message. Why this
> is useful? When decoding the records, the count is discovered automatically.
> And it won't help for decoding the records. Alternatively I think a "message
> length" would help. The decoder can know how much data to feed.

This is one of the discussions we want to have about the draft.  It is true that record count can be calculated, but:
(a) it conceivable that a receiver might start processing records before receipt of the whole bundle.  Perhaps the count might matter in allocating resources?
(b) there are historical protocols which include record count as a field
(c) extra layer of error checking?

As you can see, the value might not be enough here to retain this optional header object in the draft.  But having it in for now keeps the discussion open.

 Sadly we can't use message-length in this case as that will depend on the selected encoding.  

> 4. You have "message-generator-id" and "observation-domain-id". I think both
> of them are used to indicate the source of the data. Then why we need two?

The creator of the record and the creator of the bundled notification might not been the same.    For example, a record might be created on a line card, but the notification itself might come from the main CPU.  

One objective of the discussions will be to see if we can/should reuse the definition of observation domains from IPFIX.    IPFIX itself has the concept of "Exporter" and there can be many observation domains per exporter, and many exporters per device.  In the next version of the draft, I will rename message-generator-id to exporter-id to make this discussion clearer.

> 5. In what scope is the subscription-id unique, per device, per receiver, or
> globally? It's better to indicate.

Per publisher.   I will update the text to make this clear.

Eric

> Cheers,
> Tianran
> 
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent
> > Watsen
> > Sent: Tuesday, August 22, 2017 6:06 AM
> > To: netconf@ietf.org
> > Subject: [Netconf] WG adoption poll
> > draft-voit-netconf-notification-messages-01
> >
> >
> > All,
> >
> > This is start of a two-week poll on making the following draft a
> > NETCONF working group document:
> >
> >   draft-voit-netconf-notification-messages-01 [1]
> >
> > Please send email to the list indicating "yes/support" or "no/do not support".
> > If indicating no, please state your reservations with the document.
> > If yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> >
> >
> > [1]
> > https://tools.ietf.org/id/draft-voit-netconf-notification-messages-01
> >
> >
> > Thank you,
> > Kent (and Mahesh)
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf