Re: [Netconf] request for comments on draft-ietf-netconf-udp-pub-channel

Hi Martin,

Thank you very much for your review and comments.
Please see in line.

Best Regards,
Tianran

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Monday, June 11, 2018 3:48 PM
> To: Tianran Zhou <zhoutianran@huawei.com>
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] request for comments on
> draft-ietf-netconf-udp-pub-channel
> 
> Hi,
> 
> I have read draft-ietf-netconf-udp-pub-channel-02, but struggle with some
> basics.
> 
> I don't understand how this new transport is supposed to fit into the design
> of draft-ietf-netconf-subscribed-notifications.  For example, the
> udp-pub-channel draft seems to expect a request to "establish-subscription"
> over NETCONF to send the notifications over UDP.  But AFAICT this is not
> possible with the current design of establish-subscription.

[ztr]:
Yes, within the design team, we discussed this also. We tried to fit the existing design of draft-ietf-netconf-subscribed-notifications(SN).
In the case of "establish-subscription", existing SN design require the notification to use the same channel as the subscription. But the distributed data collection mechanism(draft-zhou-netconf-multi-stream-originators-02) cannot meet this. Because the notification channel and the subscription channel are always separated. So we require:
   "the Receiver and the Subscriber
   SHOULD be collocated.  So UPC can use the source IP address of the
   Subscription Channel as it's destination IP address.  The Receiver
   MUST support listening messages at the IANA-assigned PORT-X, but MAY
   be configured to listen at a different port."

It's not the only one issue. For configured subscription, SN requires the "subscription-started" message before sending notifications. However, for UDP, we cannot guarantee the notifications arrive the receiver after the "subscription-started". We cannot guarantee "subscription-started" will not lost neither. So I am wandering if the "subscription-started" message is still necessary. 

> Is the transport in this draft supposed to work for notifications in general,
> or only YANG push notifications?
> 
> Also, it seems many of the references to yang-push really should be to
> subscribed-notifications.

[ztr]:
We want to work for notifications in general. I noticed that subscribed-notifications draft describes event stream. And YANG-Push augments the SN and add datastore.
What's your suggestion for the reference if we want to work for both event stream and datastore?

> It would also be useful to align terminology with the other documents.  It
> seems a "Master" is really the management protocol server?  And "Agent" is
> what subscribed-notifications calls a "publisher"?  Or maybe the "Master"
> is the "publisher"?
> 
> You also use the term "data originator", but I am not quite sure if that is
> the same as "Agent"?

[ztr]:
Yes, that's a good suggestion. Figure 1 is too simple and not clear. We will try to do this in the next version. We have a more detailed framework description with figures in draft-zhou-netconf-multi-stream-originators-02. It would be really appreciated if you can review that document. And you may help use normalize the terms. 
The master will decompose the subscription and distributed the requests to each agent. Both master and the agent contains a publisher as shown in Figure 3 in draft-zhou-netconf-multi-stream-originators-02. "data originator" in this draft is more like master + agent.

> 
> 
> /martin
> 
> 
> Tianran Zhou <zhoutianran@huawei.com> wrote:
> > Hi WG,
> >
> > We've got some comments on the UDP based Publication Channel for
> > Streaming Telemetry. And we are going to update it, specifically on
> > the security aspect.
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/
> >
> > Could you please help to review?
> > Any comment is appreciated.
> >
> > Thanks,
> > Tianran
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >