Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

I do support this draft becoming a WG item.    If adopted, there are number of topics which need to be resolved in the weeks/months ahead...

Section 3
Paragraph 1 & diagram
While main board and line cards are identified as examples, there is nothing which restricts the functions to reside in these places, or even on the same box.  This document should say that a subscription server can support this logical function for many devices.

Paragraph 2
Not all datastreams will allow for the deducing of notification loss & disorder.  For UDP, this requires elements of the draft-voit-netconf-notification-messages in many deployments.  As you also bring up draft-voit several places in Section 4.  Do you believe it viable to adopt this draft without adopting the other one?  The divisions between these drafts needs to be worked through.  As Alex is an author for both drafts, we should be in a good place to make the appropriate split. 

Bullets 2 & 3
This is hard as the subscription server will have to maintain which yang-objects should be pushed by individual line cards.  Knowing that all requested elements are being sent by one-and-only-one element of the publisher can be tricky.  In fact, several problems need analysis:
- how will the subscriber know that it is receiving all updates across all cards and mainboard?
- "responsible for notifying the subscriber in case of any problems of component subscriptions"  will require augmentations to draft-ietf-netconf-subscribed-notifications (which is fine).  But such a mechanism for sub-subscription distribution and reporting should not be done in a draft specific to UDP, and it turns out it is a fairly complex problem.  What form this solution needs to take is something worthy of larger WG discussion.
- is configuration data telemetry able to be pushed in this distributed manner?  Or is this just for operational objects.

Section 4
Per comment above, there are dependencies with draft-voit-netconf-notification-messages which need to be worked through.

Section 4.2
Authentication and Encryption options

Section 4.3
- Listing support for GPB is nice to have, but I am unsure how to cover Google specific specifications within IETF documents.  This is non-trivial to resolve.
- Having CBOR for subscribed data will likely need additional supporting documentation

Section 5
The suggested tree augmentations should be made to draft-ietf-netconf-subscribed-notifications, rather than yang-push.  UDP is viable for events too.

Also the subtree for udp-transport-type might not be necessary.  We already have a transport-protocol object in the base model.  And some of the suggested objects could also be made transport-independent.

Thanks,
Eric

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
> Sent: Monday, August 21, 2017 6:04 PM
> To: netconf@ietf.org
> Subject: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00
> 
> All,
> 
> This is start of a two-week poll on making the following draft a NETCONF
> working group document:
> 
>   draft-zheng-netconf-udp-pub-channel-00 [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/html/draft-zheng-netconf-udp-pub-channel-00
> 
> 
> Thank you,
> Kent (and Mahesh)
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf