Subject: Re: [Taps] New Version Notification for draft-fairhurst-taps-transports-usage-udp-03.txt

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 06 Oct 2016 08:22:54 +0100

We have just submitted an updated copy of the UDP usage draft we have 
been working on in TAPS.

Specifically:

(1) It omits the text for pass 2 and 3 that we now expect to be directly 
incorporated in draft-ietf-taps-transport-usage.
Michael Welzl I think indicated that this text will be copied from rev 
-usage-udp-02.

(2) It contains small changes to the document text to allow this to be 
publsihed as a separate document. The WG discussed whether such a 
document could be adopted for publication as a pair with 
draft-ietf-taps-transport-usage.  The authors are now looking to the 
group to know if the WG would like to adopt this and then what further 
work may be needed.

Best wishes,

Tom & Gorry

On 05/10/2016 21:46, [email-masked] wrote:
> A new version of I-D, draft-fairhurst-taps-transports-usage-udp-03.txt
> has been successfully submitted by Godred Fairhurst and posted to the
> IETF repository.
>
> Name:		draft-fairhurst-taps-transports-usage-udp
> Revision:	03
> Title:		Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols
> Document date:	2016-10-05
> Group:		Individual Submission
> Pages:		18
> URL:            https://www.ietf.org/internet-drafts/draft-fairhurst-taps-transports-usage-udp-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-fairhurst-taps-transports-usage-udp/
> Htmlized:       https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-fairhurst-taps-transports-usage-udp-03
>
> Abstract:
>     This document describes how the User Datagram Protocol (UDP) and the
>     Lightweight User Datagram Protocol (UDP-Lite) transport protocols
>     expose services to applications and how an application can configure
>     and use the features offered by the transport service.  The document
>     is intended as a contribution to the Transport Services (TAPS)
>     working group to assist in analysis of the UDP and UDP-Lite transport
>     interface.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat

---

From: Michael Welzl <[email-masked]>
Date: Thu, 6 Oct 2016 10:46:56 +0300

hi,

clarification: yes i said what's written below, but i think this is the first time the taps folks hear about it.  so if that's fine with everyone, that's our plan - it seemed to us to be the most reasonable approach.

about adopting this separate document, it makes sense to me

Sent from my iPhone

> On 6. okt. 2016, at 10.22, Gorry Fairhurst <[email-masked]> wrote:
> 
> We have just submitted an updated copy of the UDP usage draft we have been working on in TAPS.
> 
> Specifically:
> 
> (1) It omits the text for pass 2 and 3 that we now expect to be directly incorporated in draft-ietf-taps-transport-usage.
> Michael Welzl I think indicated that this text will be copied from rev -usage-udp-02.
> 
> (2) It contains small changes to the document text to allow this to be publsihed as a separate document. The WG discussed whether such a document could be adopted for publication as a pair with draft-ietf-taps-transport-usage.  The authors are now looking to the group to know if the WG would like to adopt this and then what further work may be needed.
> 
> Best wishes,
> 
> Tom & Gorry
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Aaron Falk <[email-masked]>
Date: Thu, 6 Oct 2016 15:57:37 -0400

IMO, this is obviously in scope for TAPS and a useful contribution.  I’d like to hear any dissenting opinions about adopting this doc as a wg item.

—aaron

> On Oct 6, 2016, at 3:46 AM, Michael Welzl <[email-masked]> wrote:
> 
> hi,
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 10 Oct 2016 11:11:41 +0200

Hi all,

quick question: what’s the advantage of having this as a separate doc instead of merging it with draft-ietf-taps-transports-usage (which was the original plan to my understanding)?

Mirja

> Am 06.10.2016 um 21:57 schrieb Aaron Falk <[email-masked]>:
>

---

From: "Gorry (erg)" <[email-masked]>
Date: Mon, 10 Oct 2016 11:15:05 +0100

Good question. In the Berlin IETF meeting - I went through arguments for and against. 

Some arguments for the two ID, ,were this may help to continue to receive the review from apps UDP users that would be less likely to happen if hurried in text about tcp SCTP etc. There is no document in the RFC series that document UDP API - this may be helpful roadmap to find this info. Two documents are easier to maintain and cite than one.

Disadvantages includes two RFC numbers. We do not expect huge changes. However : Any changes to the main doc would need to be kept consistent in the draft, etc. That to me suggests a need to publish as a pair, if we make 2 docs.

Gorry

> On 10 Oct 2016, at 10:11, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Oct 2016 07:35:28 -0700

On 10/10/2016 3:15 AM, Gorry (erg) wrote:
> ... There is no document in the RFC series that document UDP API - this may be helpful roadmap to find this info. Two documents are easier to maintain and cite than one.

RFC1122 defines one in Section 4.1.4, but it basically points off to a
definition of the IP API in Section 3.4, which ignores the issue of
controlling source and destination ports.

The true UDP API ought to be defined in the same way the TCP API is
defined in RFC793, FWIW.

I've proposed a way forward for UDP options; as a result, I'd be glad to
take a shot at a draft UDP API doc if useful.

Joe

---

From: [email-masked]
Date: Mon, 10 Oct 2016 17:56:47 +0100

See below.
>> ... There is no document in the RFC series that document UDP API - this
>> may be helpful roadmap to find this info. Two documents are easier to
>> maintain and cite than one.
>
OK, so in the context of TAPS, the WG called for a list of UDP services.
This is what is in the  ID. I thought there may something useful to
publishing this as a companion INFO RFC alongside the connection-oriented
services ID. I suggest it may help to indicate what an App may need to
know to use UDP.

This ID clearly isn't an API spec.

> take a shot at a draft UDP API doc if useful.

I don't personally know whether an API spec for UDP is useful or not, but
suspect the list of services needed by UDP Apps is the thing the WG is
presnetly looking for.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Oct 2016 10:10:19 -0700

Hi, Gorry (et al.),

On 10/10/2016 9:56 AM, [email-masked] wrote:

> ...
> This is what is in the  ID. ...
>
> ...

I have to admit I have no idea what you mean by "the list of services
needed by UDP Apps" if that doesn't basically start and end with the UDP
API.

Anything else needed by UDP apps isn't needed because they're UDP. And
having that list (of "things besides the UDP API") without a proper UDP
API wouldn't be very useful.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Thu, 13 Oct 2016 07:38:50 +0200

> On 10. okt. 2016, at 19.10, Joe Touch <[email-masked]> wrote:
> 
> Hi, Gorry (et al.),
> 
> On 10/10/2016 9:56 AM, [email-masked] <mailto:[email-masked]> wrote:
>> ...

It’s not an API spec but it does “basically start and end” with the API. It follows the same approach as
draft-ietf-taps-transports-usage, which also very much “basically starts and ends” with the API, in how
primitives are derived. Details on this relationship are maybe clearest in the appendix, where we describe
how to contribute text  (in some future version, this should probably be renamed into “how this document was
created”).

> API wouldn't be very useful.

It certainly is the right input for anyone creating an API. E.g., it IS the input from which we derive our protocol-independent
API in the NEAT project.

Cheers,
Michael

---

From: Aaron Falk <[email-masked]>
Date: Thu, 27 Oct 2016 15:53:39 -0400

Seems to me like we have a consensus to make this a working group doc.  We’ll get this re-issued with a working group filename.

—aaron

> On Oct 13, 2016, at 1:38 AM, Michael Welzl <[email-masked]> wrote:
> 
>> 
>> On 10. okt. 2016, at 19.10, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, Gorry (et al.),
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>