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

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Aug 2017 22:04:08 +0000

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)

---

From: Lizhenbin <[email-masked]>
Date: Tue, 22 Aug 2017 01:46:26 +0000

Yes/Support.

Best Regards,
Zhenbin(Robin)

-----邮件原件-----
发件人: Netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2017年8月22日 6:04
收件人: [email-masked]
主题: [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:

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.

Thank you,
Kent (and Mahesh)

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Giles Heron <[email-masked]>
Date: Tue, 22 Aug 2017 11:39:04 +0100

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? Or are you thinking in terms of NAT?  Or of correlating notifications from different line-cards on the same system that may have different source IP addresses?

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.

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).

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.

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 <[email-masked]> wrote:
> 
> Yes/Support.
> 
> Best Regards,
> Zhenbin(Robin)
> 
> 
> 
> -----邮件原件-----

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 22 Aug 2017 15:02:59 +0200

Yes, support.

As was (I believe) already pointed out at the IETF99 session, it tries to address a problem
that was also presented here:
https://www.ietf.org/proceedings/98/slides/slides-98-nmrg-self-driving-networks-00.pdf

So this work seems good to be done here. I believe that the authors of both the IETF98 and IETF99
presentations have already agreed they would work together on this issue too.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Aug 2017 08:47:16 -0700

Hi,

Is the NETCONF WG the proper venue to work on UDP?
Seems like the transport area would be a more appropriate home.

Why is this transport work specific to pub/sub?
It seems useful for unconstrained devices on constrained networks
to be able to use UDP instead of TCP for all management messages.

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 22 Aug 2017 17:46:10 +0000

This provides a transport to be used in conjunction with pub/sub.  This is certainly how it is intended to be used- the use case is definitely for ops –  and why IMHO netconf would be a good home and my preference.  Transport might be a possibility as well but seems more general.
--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, August 22, 2017 8:47 AM
To: Kent Watsen <[email-masked]>; Benoit Claise <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

Hi,

Andy

On Mon, Aug 21, 2017 at 3:04 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
All,

Thank you,
Kent (and Mahesh)

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 22 Aug 2017 18:20:37 +0000

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:[email-masked]] On Behalf Of Kent Watsen
> Sent: Monday, August 21, 2017 6:04 PM
> To: [email-masked]
> Subject: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00
> 
> All,
> 
> 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.
> 
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 23 Aug 2017 08:28:44 +0000

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

> From: Netconf [mailto:[email-masked]] On Behalf Of Giles Heron
> Sent: Tuesday, August 22, 2017 6:39 PM
> To: [email-masked]
> 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.

> 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)
> >
> >
> >
> >

---

From: Giles Heron <[email-masked]>
Date: Wed, 23 Aug 2017 14:56:50 +0100

Hi Tianran,

sure - so maybe it’d be better to split this into 2 drafts (one for the problem statement and one for the solution)?  That way you can progress those separately.

Re UDP vs TCP my point was more that it seems strange to define your own transport in a NETCONF draft.  Adding reliability to UDP is a solved problem (many times over) so you should be able to pick one of the existing solutions.

Giles

> On 23 Aug 2017, at 09:28, Tianran Zhou <[email-masked]> wrote:
> 
> Hi Giles,
>

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 24 Aug 2017 05:45:47 +0000

Hi Giles,

I just updated the draft submission, so as to answer your question. Please see:
https://datatracker.ietf.org/doc/draft-zheng-netconf-udp-pub-channel/

I tried to make it a complete work with both ps and solution. I also separate the subscription model from this document. As things progressed, now maybe a separate ps is not necessary to be published as a support documents.

We are not going to define a general purpose transport, but to adapt UDP for publication of NETCONF/RESTCONF. It's highly related to YANG Push work.
The publication channel behavior will highly depend on the configuration/subscription.
So I feel NETCONF is the right place to do this extension.
And I believe the show-hands on the NETCONF meeting showed this work is important and can be done in NETCONF.

Thanks,
Tianran
> From: Giles Heron [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2017 9:57 PM
> To: Tianran Zhou
> Cc: [email-masked]
> sure - so maybe it’d be better to split this into 2 drafts (one for the
> problem statement and one for the solution)?  That way you can progress those
> separately.
> 
> Re UDP vs TCP my point was more that it seems strange to define your own
> transport in a NETCONF draft.  Adding reliability to UDP is a solved problem
> (many times over) so you should be able to pick one of the existing solutions.
> 
> Giles
> 
> > 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.
> >> 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.
> >
> > [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:
> >> 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.
> >
> > [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.
> >
> >> document.  If yes, please also feel free to provide comments you'd
> >> like to see addressed once the document is a WG document.
> >>>
> >>>
> >>> [1]

---

From: Giles Heron <[email-masked]>
Date: Thu, 24 Aug 2017 12:35:06 +0100

Hi Tianran,

even if you’re adapting UDP for publication of YANG-modelled data (note you’re NOT adapting it for publication or NETCONF/RESTCONF) I suspect you can still build upon work others have done on reliable UDP mechanisms etc.    Even RTP does most of what you want (as it has sequence numbers, timestamps, sender IDs, support for different payload encodings etc.) - through granted it is targeted at a very different application space.

and if you do persist in trying to define your own transport then it might be worth thinking about whether you need a length field, whether reliability and authentication are per-stream (rather than per-packet as currently defined) and so on...

Giles

> On 24 Aug 2017, at 06:45, Tianran Zhou <[email-masked]> wrote:
> 
> Hi Giles,
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Aug 2017 09:57:27 -0700

On Thu, Aug 24, 2017 at 4:35 AM, Giles Heron <[email-masked]> wrote:

> Hi Tianran,
>
> even if you’re adapting UDP for publication of YANG-modelled data (note
> you’re NOT adapting it for publication or NETCONF/RESTCONF) I suspect you
> can still build upon work others have done on reliable UDP mechanisms etc.
>   Even RTP does most of what you want (as it has sequence numbers,
> timestamps, sender IDs, support for different payload encodings etc.) -
> through granted it is targeted at a very different application space.
>
> and if you do persist in trying to define your own transport then it might
> be worth thinking about whether you need a length field, whether
> reliability and authentication are per-stream (rather than per-packet as
> currently defined) and so on...
>
>
I don't understand why we bother to organize the IETF into areas of
expertise, if we are just going to
ignore that and produce ad-hoc point solutions in any WG.  IMO the NETCONF
WG does not have
the transport area expertise to to a great job on this work.  Clearly the
transport area has the experts
to understand all pre-existing solutions and all pre-existing issues (like
congestion).

How is the IESG going to ensure that there are sufficient transport area
experts involved
in the entire development cycle for this standard?

Giles

Andy

> > I tried to make it a complete work with both ps and solution. I also
> separate the subscription model from this document. As things progressed,
> now maybe a separate ps is not necessary to be published as a support
> documents.
> >
> > We are not going to define a general purpose transport, but to adapt UDP
> for publication of NETCONF/RESTCONF. It's highly related to YANG Push work.

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 24 Aug 2017 23:12:06 +0000

Couple of thoughts from my side:

- Clearly, this addresses a valid problem.  Whether we should talk to transport area or keep here, not sure.  I am wondering where else it would fit charter-wise, and how much that would slow progress down.  Netconf already has all the context that is needed.  
- There are actually two aspects in the draft.  One concerns the UDP transport option that we are discussion here.  The other aspect concerns the fact that can have multiple message originators, such as multiple line cards each with its own stream but managed via one subscription.   This is what is currently outlined in section 3.  Maybe this is something that should be broken out into a separate draft, as potentially applicable to other transports, but that aspect arguably fits much better with netconf.  

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Thursday, August 24, 2017 4:35 AM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

Hi Tianran,

Giles

>> sure - so maybe it’d be better to split this into 2 drafts (one for 
>> the problem statement and one for the solution)?  That way you can 
>> progress those separately.
>> 
>> Re UDP vs TCP my point was more that it seems strange to define your 
>> own transport in a NETCONF draft.  Adding reliability to UDP is a 
>> solved problem (many times over) so you should be able to pick one of the existing solutions.
>> 
>> Giles
>> 
>> that may need to solve, and attract WG interests. So there are some 
>> TBDs in the detailed solution part.
>>> Since last meeting, we keep moving forward, and are working on the 
>>> new
>> revision internally.
>>>> more sense?  Or do you even need this given that UDP packets tend 
>>>> to have source IP addresses?
>>> 
>> 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.
>>> 
>> 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
>> 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.
>>> 
>>> 
>>>> says those are as per RFC3339.  From my reading of RFC3339 it 
>>>> encodes dates/times as strings.
>> 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:
>>>> 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?
>> transport. Then the application can decide the reaction to the packet 
>> loss/ reordering or so.
>> 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.
>>> 
>> 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.
>>> 
>>>> 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]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Aug 2017 16:46:09 -0700

On Thu, Aug 24, 2017 at 4:12 PM, Alexander Clemm <[email-masked]
> wrote:

> - Clearly, this addresses a valid problem.  Whether we should talk to
> transport area or keep here, not sure.  I am wondering where else it would
> fit charter-wise, and how much that would slow progress down.  Netconf
> already has all the context that is needed.
>

This is clearly a general problem.
NETCONF is not the first protocol WG that wants to push lots of data around.
I think IPFIX spent a lot of time on transport issues, maybe other WGs as
well.
No need to reinvent the wheel, right?

NETCONF is OK for this work as long as early cross-area reviews are done.

> - There are actually two aspects in the draft.  One concerns the UDP
> transport option that we are discussion here.  The other aspect concerns
> the fact that can have multiple message originators, such as multiple line
> cards each with its own stream but managed via one subscription.   This is
> what is currently outlined in section 3.  Maybe this is something that
> should be broken out into a separate draft, as potentially applicable to
> other transports, but that aspect arguably fits much better with netconf.
>
>
I agree YANG Push/NETCONF WG needs to define how a subscription can be
transported.
This includes 1 subscription with multiple receivers or multiple source
addresses.
Things get complicated if there are both on 1 subscription. (That's 1
reason why I prefer
to have only 1 receiver per subscription + a shorthand way to config
duplicate subscriptions).

Andy

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 25 Aug 2017 00:08:48 +0000

Hi Andy

<ALEX>, inline

--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, August 24, 2017 4:46 PM
To: Alexander Clemm <[email-masked]>
Cc: Giles Heron <[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]
Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

On Thu, Aug 24, 2017 at 4:12 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
Couple of thoughts from my side:

This is clearly a general problem.
NETCONF is not the first protocol WG that wants to push lots of data around.
I think IPFIX spent a lot of time on transport issues, maybe other WGs as well.
No need to reinvent the wheel, right?

<ALEX> Sounds reasonable to me </ALEX>

I agree YANG Push/NETCONF WG needs to define how a subscription can be transported.
This includes 1 subscription with multiple receivers or multiple source addresses.
Things get complicated if there are both on 1 subscription. (That's 1 reason why I prefer
to have only 1 receiver per subscription + a shorthand way to config duplicate subscriptions).

<ALEX> Actually, this here is a different case – not concerning receivers – we will have multiple senders per subscription… </ALEX>

--- Alex

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Giles Heron
Sent: Thursday, August 24, 2017 4:35 AM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

Hi Tianran,

Giles

> On 24 Aug 2017, at 06:45, Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Giles,
>
>> From: Giles Heron [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>
>>> On 23 Aug 2017, at 09:28, Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Hi Giles,
>>>
>>>> From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Giles
>>>> Heron
>>>> To: [email-masked]<mailto:[email-masked]>
>>>>> On 22 Aug 2017, at 02:46, Lizhenbin <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>>>> Yes/Support.
>>>>>
>>>>> Best Regards,
>>>>> Zhenbin(Robin)
>>>>>
>>>>>
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: Netconf [mailto:[email-masked]<mailto:[email-masked]>] 代表 Kent Watsen
>>>>> 发送时间: 2017年8月22日 6:04
>>>>> 收件人: [email-masked]<mailto:[email-masked]>

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 25 Aug 2017 03:19:45 +0000

Hi Giles,

It's open whether to design the transport.
For reference, I think IPFIX and SNMP trap are also relevant.

Thanks,
Tianran

> Sent: Thursday, August 24, 2017 7:35 PM
> To: Tianran Zhou
> Cc: [email-masked]
> Even RTP does most of what you want (as it has sequence numbers, timestamps,
> sender IDs, support for different payload encodings etc.) - through granted
> it is targeted at a very different application space.
> 
> be worth thinking about whether you need a length field, whether reliability
> and authentication are per-stream (rather than per-packet as currently
> defined) and so on...
> 
> Giles
> 
> > I tried to make it a complete work with both ps and solution. I also separate
> the subscription model from this document. As things progressed, now maybe
> a separate ps is not necessary to be published as a support documents.
> >

---

From: Giles Heron <[email-masked]>
Date: Fri, 25 Aug 2017 10:35:19 +0100

Hi Alex,

> On 25 Aug 2017, at 01:08, Alexander Clemm <[email-masked]> wrote:
> 
> Hi Andy
>  
> <ALEX>, inline
>  
> --- Alex
>  
> From: Andy Bierman [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Alexander Clemm <[email-masked] <mailto:[email-masked]>>
> Cc: Giles Heron <[email-masked] <mailto:[email-masked]>>; Tianran Zhou <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Thu, Aug 24, 2017 at 4:12 PM, Alexander Clemm <[email-masked] <mailto:[email-masked]>> wrote:

likewise.   Hopefully the transport folk can point the authors in the right direction.  As Andy says - we want to avoid reinventing the wheel.
> <ALEX> Actually, this here is a different case – not concerning receivers – we will have multiple senders per subscription… </ALEX>

right - “multiple source addresses” as Andy stated?

Giles

> From: Netconf [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Giles Heron
> To: Tianran Zhou <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> > On 24 Aug 2017, at 06:45, Tianran Zhou <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi Giles,
> >
> > https://datatracker.ietf.org/doc/draft-zheng-netconf-udp-pub-channel/ <https://datatracker.ietf.org/doc/draft-zheng-netconf-udp-pub-channel/>
> >
> >> From: Giles Heron [mailto:[email-masked] <mailto:[email-masked]>]
> >> Cc: [email-masked] <mailto:[email-masked]>
> >>> On 23 Aug 2017, at 09:28, Tianran Zhou <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>> Hi Giles,
> >>>
> >>>> From: Netconf [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Giles
> >>>> Heron
> >>>> To: [email-masked] <mailto:[email-masked]>
> >>>>> On 22 Aug 2017, at 02:46, Lizhenbin <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>>
> >>>>> Yes/Support.
> >>>>>
> >>>>> Best Regards,
> >>>>> Zhenbin(Robin)
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----邮件原件-----
> >>>>> 发件人: Netconf [mailto:[email-masked] <mailto:[email-masked]>] 代表 Kent Watsen
> >>>>> 发送时间: 2017年8月22日 6:04
> >>>>> 收件人: [email-masked] <mailto:[email-masked]>
> >>>> https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00 <https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00>
> >>>>>
> >>>>>
> >>>>> Thank you,
> >>>>> Kent (and Mahesh)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >>>>> [email-masked] <mailto:[email-masked]>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >>>>
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 25 Aug 2017 17:36:20 +0000

Hi Giles,

Yes to both.  I think we are all in agreement.

--- Alex

From: Giles Heron [mailto:[email-masked]]
Sent: Friday, August 25, 2017 2:35 AM
To: Alexander Clemm <[email-masked]>
Cc: Andy Bierman <[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]
Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

Hi Alex,

On 25 Aug 2017, at 01:08, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:

Hi Andy

<ALEX>, inline

--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, August 24, 2017 4:46 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>
Cc: Giles Heron <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

Giles

--- Alex

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Giles Heron
Sent: Thursday, August 24, 2017 4:35 AM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

Hi Tianran,

Giles