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

Hi Giles,

Thank you very much for your review and comments.
This version we were going to state the problem, raise possible issues that may need to solve, and attract WG interests. So there are some TBDs in the detailed solution part. 
We hope the working group can adopt this work, and we can work on the solution together with the community contributions.
Since last meeting, we keep moving forward, and are working on the new revision internally.
In line, please see my reply.

Thanks,
Tianran

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Giles Heron
> Sent: Tuesday, August 22, 2017 6:39 PM
> To: netconf@ietf.org
> Subject: Re: [Netconf] WG adoption poll
> draft-zheng-netconf-udp-pub-channel-00
> 
> There seem to be a few issues with this draft:
> 
> 1) it suggests a 32 bit field for device ID and then suggests generating
> it from the MAC address.  48 into 32 doesn’t go.   Perhaps an EUI-64 makes
> more sense?  Or do you even need this given that UDP packets tend to have
> source IP addresses? 

[ztr] We were to use the device ID to indicate the source of the data. Just as you suggested, the UDP session identifier can be used. So in the new version, we are going to use an message generator id for the device level and plus the src-dst IP as well as port number.

> Or are you thinking in terms of NAT?  
[ztr] The NAT issue is a good catch, which we did not think about. We assumed the device management port/interface and the collector are in the same private network. Do you have any use case that the NAT will be used  when collecting data?

> Or of correlating
> notifications from different line-cards on the same system that may have
> different source IP addresses?
[ztr] We suggest all the line cards on the same system use the same source IP address. But the case you mentioned may happen. In this case, I think the collector/subscriber may have the mapping from the source IP to device.

> 2) the timestamp has 32 bits each of seconds and microseconds and says those
> are as per RFC3339.  From my reading of RFC3339 it encodes dates/times as
> strings.
[ztr] Yes, it is not a suitable reference. We meant to say the encoding will support the expression in RFC3339. But it seems the timestamp on message generation is not so important to be accurate. So we tend to modify to: 
     "The Notification-Time, is the time at which the message leaves the
      exporter, expressed in seconds since the UNIX epoch of 1 January
      1970 at 00:00 UTC, encoded as an unsigned 32-bit integer."

> 3) building your own reliability mechanism on top of UDP seems like a strange
> choice.  Why not just use TCP if you want reliable delivery?  Or re-use
> existing work on adding reliability to UDP if you see issues with TCP? (in
> which case explain how reliability based on UDP is better than TCP).
[ztr] We are not going to provide the full reliability mechanism for UDP. We just want to provide necessary support (sequence number) from the transport. Then the application can decide the reaction to the packet loss/ reordering or so. 
In addition, I think the reliability may also have different levels. The application may not care about any packet loss, or may need to record the packet loss but not need retransmission, or need retransmission but no ordering requirement from transport,... Simply using TCP seems not a good option.

> 4) big chunks of the draft are left TBD (e.g. selecting encodings, adding
> authentication/encryption options).    Again there may be work you can reuse
> there rather than defining your own.
[ztr] Yes, based on the discussion in the community, the coming update will focus on the necessary parts. For example, the subscription model may move to a separate document. And we are not going to create authentication algorithms, but to suggest algorithms and how to truncate to fit in the header field. We will reuse existing work as much as possible.

> sections 1 - 3 are generally ok - but don’t really say anything we didn’t
> know already...
> 
> Giles
> 
> > On 22 Aug 2017, at 02:46, Lizhenbin <lizhenbin@huawei.com> wrote:
> >
> > Yes/Support.
> >
> > Best Regards,
> > Zhenbin(Robin)
> >
> >
> >
> > -----邮件原件-----
> > 发件人: Netconf [mailto:netconf-bounces@ietf.org] 代表 Kent Watsen
> > 发送时间: 2017年8月22日 6:04
> > 收件人: netconf@ietf.org
> > 主题: [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
> > _______________________________________________
> > 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