From nobody Sat Dec 5 08:02:27 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C111A8747 for ; Sat, 5 Dec 2015 08:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jw6t6FrQ6QF for ; Sat, 5 Dec 2015 08:02:24 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681091A8742 for ; Sat, 5 Dec 2015 08:02:24 -0800 (PST) Received: from [192.168.1.101] (p508F06EE.dip0.t-ipconnect.de [80.143.6.238]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 85DFD1C0375AF; Sat, 5 Dec 2015 17:02:21 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: <6f6d07994fde18062e39ced796f199a9.squirrel@erg.abdn.ac.uk> Date: Sat, 5 Dec 2015 17:02:20 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <945E755A-3EB4-4325-8257-9ECC2EE3FC4B@ifi.uio.no> <6f6d07994fde18062e39ced796f199a9.squirrel@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 16:02:27 -0000 > On 03 Nov 2015, at 14:33, gorry@erg.abdn.ac.uk wrote: > > A note just on the INFO status of SCTP APIs (below): >> >> Dear all, >> >> Sorry for not being able to attend the TAPS meeting on site or even >> remotely. I just finished watching the recording, and I noticed that the >> question of RFC 6458 - "why is the SCTP part of draft-welzl- .. based on >> only RFC 4960 and not on RFC 6458?" - was brought up several times. I'd >> like to provide an answer and start a discussion about this. >> >> There are two reasons why RFC 6458 wasn't used in >> draft-welzl-taps-transports-00: a very mundane one, and a more serious >> one. I'll list them both and hope we can discuss the second reason. >> >> 1) Reason one: RFC 6458 is quite long, and I wanted to limit the amount of >> work I'm putting into the -00 version, given that the point was to show >> people the procedure and the idea and see what they think, and not to >> fully cover everything 100% correctly yet. Basically, I didn't want to >> risk writing out all the stuff from RFC 6458 and then have people tell me >> to go away :-) >> >> 2) Reason two, more serious: RFC 6458 is Informational, and my >> understanding was that this is just one description of one API >> implementation, not a recommendation or even prescription of what all SCTP >> implementations must provide. However, my decision for >> draft-welzl-taps-transports was to *exclude* things that are only optional >> to implement - I don't think we want to end up with a TAPS system that >> provides services that, alas, on Operating System XY are not available >> because here only a subset of the API is implemented. Therefore I went >> with a minimal set of functions that I thought we can assume are >> implemented everywhere (well, at least in every system that claims to >> "follow the spec"). Can we assume that every system that claims to >> implement SCTP in accordance with the spec fully implements RFC 6458? >> > GF: From a TSVWG Chair perspective, beware here... *ALL* more recent IETF > SCTP API work from TSVWG is INFO. Each SCTP RFC is expected to have an > informative section that describes the API together with the normative > protocol spec. That is not because there are expected to be alternatives > to choose from: It's because, as I understand, the IETF is not the formal > standards body for specification of such normative APIs. I would like to point out that the API sections focus on the socket based API described in RFC 6458. The abstract API described in RFC 4960 an the one described in RFC 6458 are both informational. Therefore RFC 6458 should be also considered. You don't have to take the C structures and the exact function signatures into account, but you should consider what parameters can be changed, what information can be provided when sending a user message and so on. The same applies to extensions. They don't have an abstract API at all, it was considered better to extend RFC 6458... Best regards Michael >> >> >> A side note about TCP, because Karen made a comment about the TCP API too: >> a similar logic applies here, irrespective of whether the API is old or >> not: I think we should cover whatever a system claiming to "implement the >> protocol in accordance with the spec" has to cover. Going down the path of >> looking at actual socket API implementations is dangerous in that we end >> up in "only implemented here, not there" - land. We want a minimal set of >> mechanisms that are (or at least really should be! for that, what else can >> we use as a basis than our own recommendations?!) available everywhere. >> Karen, you specifically mentioned URG and PSH and how they are >> implemented; what is it in draft-welzl-.. about these two mechanisms that >> you don't agree with? >> >> Cheers, >> Michael >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > Gorry > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Tue Dec 8 05:03:23 2015 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A437C1B2D70; Tue, 8 Dec 2015 05:03:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151208130321.31798.62649.idtracker@ietfa.amsl.com> Date: Tue, 08 Dec 2015 05:03:21 -0800 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-08.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 13:03:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services Working Group of the IETF. Title : Services provided by IETF transport protocols and congestion control mechanisms Authors : Godred Fairhurst Brian Trammell Mirja Kuehlewind Filename : draft-ietf-taps-transports-08.txt Pages : 52 Date : 2015-12-08 Abstract: This document describes transport services provided by existing IETF protocols. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-08 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 8 05:05:56 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6681B2D76 for ; Tue, 8 Dec 2015 05:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCyvTX6m-Vtt for ; Tue, 8 Dec 2015 05:05:53 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 24A631B2D82 for ; Tue, 8 Dec 2015 05:05:53 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 5566F1A0562 for ; Tue, 8 Dec 2015 14:05:22 +0100 (CET) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_83E5E2FA-B066-4B1D-9B38-D5D61A884ECF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 8 Dec 2015 14:05:21 +0100 References: <20151208130321.31798.62649.idtracker@ietfa.amsl.com> To: taps WG Message-Id: <475E15A4-67BD-4CD9-A3E5-6E46C3E7D1BA@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Taps] Fwd: I-D Action: draft-ietf-taps-transports-08.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 13:05:55 -0000 --Apple-Mail=_83E5E2FA-B066-4B1D-9B38-D5D61A884ECF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, As discussed in Yokohama, here is revision 08 of = draft-ietf-taps-transports. The editors believe this document closes all = open issues, and we'd like to ask for WGLC on this revision. Many thanks, cheers, Brian (for the editors) > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [Taps] I-D Action: draft-ietf-taps-transports-08.txt > Date: 8 Dec 2015 14:03:21 CET > To: > Cc: taps@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services Working Group of = the IETF. >=20 > Title : Services provided by IETF transport protocols = and congestion control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-08.txt > Pages : 52 > Date : 2015-12-08 >=20 > Abstract: > This document describes transport services provided by existing IETF > protocols. It is designed to help application and network stack > programmers and to inform the work of the IETF TAPS Working Group. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-08 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_83E5E2FA-B066-4B1D-9B38-D5D61A884ECF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWZtWSAAoJEIoSt78L6kajLbwQAMDb6Z2Xzf9qajPHnlhlesex OkRLv3VatA+1yhRj+mvaeSk4w1S4OHlt1YYoAXnnuMzTLShrd/kyolXcVqa1A100 zhjhJBTHG0o6n2O0TEUGS2fFZPWZkTZ5WG4elqGa+XwBG4I14/G/EArbxVKCGXxU 02YgBIvsnDmpAKpyPtz0+Y/lyMEbdnwYDIA+r2kHkzgf7kt8B98V25i6qVlxHKgW mGQrqaETYPkvAUSGCdsTHVCVKsxU1yl329z1piOhhqS+Ut/0mMNEbL/AuMOys3bu u8WKSi+iCJon+k/Sb0Jd64v4PIeuEuKEqBR/WxNbdtp7Mp+ouQY40RU3xCvz/Pgw K966kIXAtR4gNYAC5QfqQxtoUAPOgLTS5h5YWw/IKravqYpl7RxS/phbjPa/FGPg /Kl8UkaqVXTVFEgEQJhUoKhOJf5T78NLA4aTL/ni5l0faq+QIn/DOXY0bqxisYFb 608b8WLY9W3RMkV1fGfZSb7r1RudVtQzK0HdYRJq6PM0CH9xA/ebCokIYVJ9gV3A 6DJYSiGCfQPXmUPq7EbLr76zBChCD+cGwPVlx+Z1jUsXn+cmAfJtbQK4s1sXeXPs /Y6/Mb8lsiLuYHSzAjj4vieqtH0OoPyqkO3jZh0B7GPkFF5tCwAU0S+BbZofTAVz oRjZOmtVPEhGYx43mU9M =/i69 -----END PGP SIGNATURE----- --Apple-Mail=_83E5E2FA-B066-4B1D-9B38-D5D61A884ECF-- From nobody Tue Dec 8 06:03:11 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2361B2E46 for ; Tue, 8 Dec 2015 06:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO6QIu2PhrgZ for ; Tue, 8 Dec 2015 06:03:08 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F4F1B2E45 for ; Tue, 8 Dec 2015 06:03:07 -0800 (PST) Received: by qgeb1 with SMTP id b1so16796271qge.1 for ; Tue, 08 Dec 2015 06:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=V9wg9hcxxlnrgrZMUiX0/34n3AaPwTI2NWTG9+RKooI=; b=ZYM4PVIfPr3687Sqqp4ISx3zfvyUFqzV01yjeec48C3gmopldntFJey/TQKNz1HEGk 3LOU8zk/MvpMCWqAMUjstcWE3ohmHugjQnlvS5rM8pXBNwIV8XTHtIOui45MFCAFDd2q phBGPpvJ7RN3Ucgbc6wPspR6mlDK9aHr886jXcROWIHVvurHtIFG3l0WHfVR22IkTCUU kI92X4PQuiA/OH9rnkxiJFn6kGOWp06Vr43gDXLWvXweR3Llpc5rUi6gGg8xXGXIxIlx Q6JftvlZrRzyAXcTkXZy+t0a/QXgZZ4CsFO3EJ/lHp/jabX3NPyN5/XOuxZtcfh0R0UU ZuKg== MIME-Version: 1.0 X-Received: by 10.129.71.5 with SMTP id u5mr438868ywa.91.1449583375860; Tue, 08 Dec 2015 06:02:55 -0800 (PST) Received: by 10.37.111.6 with HTTP; Tue, 8 Dec 2015 06:02:55 -0800 (PST) Date: Tue, 8 Dec 2015 09:02:55 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a114d719630c9bb0526636e5a Archived-At: Subject: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 14:03:09 -0000 --001a114d719630c9bb0526636e5a Content-Type: text/plain; charset=UTF-8 This email announces a TAPS Working Group Last Call (WGLC) on: Services provided by IETF transport protocols and congestion control mechanisms draft-ietf-taps-transports-08.txt Due to the timing (many people take time off during the December holidays), this WGLC will run for slightly longer than usual - it will be for just over 3 weeks, ending at midnight US Eastern (daylight) Time on Thursday, December 31st. Comments should be sent to the taps@ietf.org list, although purely editorial comments may be sent directly to the authors ( draft-ietf-taps-transports@ietf.org). We're looking for at least a couple more reviews during WGLC - please email the chair (aaron.falk@gmail.com) if you're interested and willing to review this draft (otherwise, we'll have to go "beat the bushes" for reviewers). Thanks, --aaron --001a114d719630c9bb0526636e5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This email announces a=C2= =A0TAPS=C2=A0Working Group Last Call (WGLC)= on:

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Services provided by IETF transport protocols = and congestion control mechanisms
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0draft-ietf-taps-transports-08.txt

Due to the timing (= many people take time off during the December holidays), this=C2=A0<= span class=3D"" style=3D"font-size:12.8px">WGLC=C2=A0will=C2=A0run for= slightly longer than usual - it will be for just over 3 weeks, ending at= =C2=A0midnight US Eastern (daylight= ) Time on Thursday, December 31st.= =C2=A0 Comments should be sent to the=C2=A0taps@ietf.org=C2=A0list,=C2=A0although purely editorial comments may= be sent directly to the authors (draft-ietf-taps-transports@ietf.org).

We're looking for at least a couple more=C2=A0reviews during=C2=A0WGLC=C2=A0- pleas= e email the chair (aaron.falk@gmail= .com) if=C2=A0you're interested and willing to review this dra= ft (otherwise, we'll have=C2=A0= to go "beat the bushes" for reviewers).

Thanks,=C2=A0

--aaron
--001a114d719630c9bb0526636e5a-- From nobody Wed Dec 9 00:28:30 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B251B29F5 for ; Wed, 9 Dec 2015 00:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIpWTwHxzNoD for ; Wed, 9 Dec 2015 00:28:25 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2703F1B29EA for ; Wed, 9 Dec 2015 00:28:24 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1a6a6o-0001jD-OI for taps@ietf.org; Wed, 09 Dec 2015 09:28:22 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1a6a6o-00073b-4r for taps@ietf.org; Wed, 09 Dec 2015 09:28:22 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 9 Dec 2015 09:28:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <945E755A-3EB4-4325-8257-9ECC2EE3FC4B@ifi.uio.no> <6f6d07994fde18062e39ced796f199a9.squirrel@erg.abdn.ac.uk> To: "taps@ietf.org" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 5 sum rcpts/h 10 sum msgs/h 5 total rcpts 36236 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1737DCA7FBCA9D8786110D01ADBC6243540E3059 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 8700 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 08:28:28 -0000 > On 05 Dec 2015, at 17:02, Michael Tuexen = wrote: >=20 >> On 03 Nov 2015, at 14:33, gorry@erg.abdn.ac.uk wrote: >>=20 >> A note just on the INFO status of SCTP APIs (below): >>>=20 >>> Dear all, >>>=20 >>> Sorry for not being able to attend the TAPS meeting on site or even >>> remotely. I just finished watching the recording, and I noticed that = the >>> question of RFC 6458 - "why is the SCTP part of draft-welzl- .. = based on >>> only RFC 4960 and not on RFC 6458?" - was brought up several times. = I'd >>> like to provide an answer and start a discussion about this. >>>=20 >>> There are two reasons why RFC 6458 wasn't used in >>> draft-welzl-taps-transports-00: a very mundane one, and a more = serious >>> one. I'll list them both and hope we can discuss the second reason. >>>=20 >>> 1) Reason one: RFC 6458 is quite long, and I wanted to limit the = amount of >>> work I'm putting into the -00 version, given that the point was to = show >>> people the procedure and the idea and see what they think, and not = to >>> fully cover everything 100% correctly yet. Basically, I didn't want = to >>> risk writing out all the stuff from RFC 6458 and then have people = tell me >>> to go away :-) >>>=20 >>> 2) Reason two, more serious: RFC 6458 is Informational, and my >>> understanding was that this is just one description of one API >>> implementation, not a recommendation or even prescription of what = all SCTP >>> implementations must provide. However, my decision for >>> draft-welzl-taps-transports was to *exclude* things that are only = optional >>> to implement - I don't think we want to end up with a TAPS system = that >>> provides services that, alas, on Operating System XY are not = available >>> because here only a subset of the API is implemented. Therefore I = went >>> with a minimal set of functions that I thought we can assume are >>> implemented everywhere (well, at least in every system that claims = to >>> "follow the spec"). Can we assume that every system that claims to >>> implement SCTP in accordance with the spec fully implements RFC = 6458? >>>=20 >> GF: =46rom a TSVWG Chair perspective, beware here... *ALL* more = recent IETF >> SCTP API work from TSVWG is INFO. Each SCTP RFC is expected to have = an >> informative section that describes the API together with the = normative >> protocol spec. That is not because there are expected to be = alternatives >> to choose from: It's because, as I understand, the IETF is not the = formal >> standards body for specification of such normative APIs. > I would like to point out that the API sections focus on the socket = based > API described in RFC 6458. > The abstract API described in RFC 4960 an the one described in RFC = 6458 > are both informational. Therefore RFC 6458 should be also considered. = You > don't have to take the C structures and the exact function signatures = into > account, but you should consider what parameters can be changed, what > information can be provided when sending a user message and so on. That's in line with what Karen said. I wanted to hear a second opinion = on this not because I didn't trust Karen's expertise (I do!) but because = I wanted to make sure that I'm not doing this potentially rather large = amount of work in vain. =3D> that's all fine, I'll cover RFC 6458 in a future version of = draft-welzl-taps-transports. Cheers, Michael > The same applies to extensions. They don't have an abstract API at = all, > it was considered better to extend RFC 6458... >=20 > Best regards > Michael >>>=20 >>>=20 >>> A side note about TCP, because Karen made a comment about the TCP = API too: >>> a similar logic applies here, irrespective of whether the API is old = or >>> not: I think we should cover whatever a system claiming to = "implement the >>> protocol in accordance with the spec" has to cover. Going down the = path of >>> looking at actual socket API implementations is dangerous in that we = end >>> up in "only implemented here, not there" - land. We want a minimal = set of >>> mechanisms that are (or at least really should be! for that, what = else can >>> we use as a basis than our own recommendations?!) available = everywhere. >>> Karen, you specifically mentioned URG and PSH and how they are >>> implemented; what is it in draft-welzl-.. about these two mechanisms = that >>> you don't agree with? >>>=20 >>> Cheers, >>> Michael >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >> Gorry >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 From nobody Wed Dec 9 05:24:42 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3241A9135 for ; Wed, 9 Dec 2015 05:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04-_Wh-38KGM for ; Wed, 9 Dec 2015 05:24:38 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223021A913A for ; Wed, 9 Dec 2015 05:24:38 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C52244570115D; Wed, 9 Dec 2015 13:24:33 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tB9DOPx8029390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Dec 2015 14:24:35 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 9 Dec 2015 14:24:24 +0100 From: "Scharf, Michael (Michael)" To: Aaron Falk , "taps@ietf.org" Thread-Topic: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 Thread-Index: AQHRMcEu6AnrMhvbDU+Y5iHR2D9uSJ7CoWsg Date: Wed, 9 Dec 2015 13:24:23 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4858085A@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D4858085AFR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 13:24:40 -0000 --_000_655C07320163294895BBADA28372AF5D4858085AFR712WXCHMBA15z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgYWJzdHJhY3QgY291bGQgYmV0dGVyIGRlc2NyaWJlIHRoZSBhY3R1YWwgY29u dGVudCBvZiB0aGUgZG9jdW1lbnQsIGUuZy4sIHdpdGggYSBzZW50ZW5jZSBsaWtlIOKAnOKApiBz dXJ2ZXlzLCBjbGFzc2lmaWVzIGFuZCBjb21wYXJlcyB0aGUgcHJvdG9jb2wgbWVjaGFuaXNtcyDi gKbigJ0uIEl0IGNvdWxkIGFsc28gbGlzdCB0aGUgcHJvdG9jb2xzIHRoYXQgYXJlIGluIHNjb3Bl IG9mIHRoZSBkb2N1bWVudCwgb3IgaXQgY291bGQgYm9ycm93IG90aGVyIHRleHQgZnJvbSBTZWN0 aW9uIDEuIEl0IGlzIG5vdCBjbGVhciB0byBtZSB3aGF0IGEgcmVhZGVyIGNvdWxkIGxlYXJuIGZy b20gdGhlIHN0YXRlbWVudCDigJzigKYgdG8gaW5mb3JtIHRoZSB3b3JrIG9mIHRoZSBJRVRGIFRB UFMgV29ya2luZyBHcm91cOKAnSwgaW4gcGFydGljdWxhciBpbiBhIGNvdXBsZSBvZiB5ZWFycyBm cm9tIG5vdyB3aGVuIHRoZSBXRyBtYXkgbm90IGV4aXN0IGFueSBtb3JlLg0KDQpJbiBTZWN0aW9u IDQuMSwgaXQgbWF5IGJlIGJldHRlciB0byByZWZlciB0byBSRkMgNzQxNCBpbnN0ZWFkIG9mIFJG QyA0NjE0LiBBbHNvLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGJldHRlciBl bXBoYXNpemUgdGhhdCB0aGUgc2VjdGlvbiBqdXN0IGdpdmVzIGFuIG92ZXJ2aWV3IG9mIFRDUCBh bmQgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgY29tcHJlaGVuc2l2ZSBkZXNjcmlwdGlvbi4NCg0K TWljaGFlbA0KDQoNCkZyb206IFRhcHMgW21haWx0bzp0YXBzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBBYXJvbiBGYWxrDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwOCwgMjAxNSAz OjAzIFBNDQpUbzogdGFwc0BpZXRmLm9yZw0KU3ViamVjdDogW1RhcHNdIFRBUFMgV0dMQzogZHJh ZnQtaWV0Zi10YXBzLXRyYW5zcG9ydHMtMDggLSBlbmRzIERlYyAzMQ0KDQpUaGlzIGVtYWlsIGFu bm91bmNlcyBhIFRBUFMgV29ya2luZyBHcm91cCBMYXN0IENhbGwgKFdHTEMpIG9uOg0KDQogICAg ICAgIFNlcnZpY2VzIHByb3ZpZGVkIGJ5IElFVEYgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgY29u Z2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXMNCiAgICAgICAgZHJhZnQtaWV0Zi10YXBzLXRyYW5z cG9ydHMtMDgudHh0PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt dGFwcy10cmFuc3BvcnRzLz4NCg0KRHVlIHRvIHRoZSB0aW1pbmcgKG1hbnkgcGVvcGxlIHRha2Ug dGltZSBvZmYgZHVyaW5nIHRoZSBEZWNlbWJlciBob2xpZGF5cyksIHRoaXMgV0dMQyB3aWxsIHJ1 biBmb3Igc2xpZ2h0bHkgbG9uZ2VyIHRoYW4gdXN1YWwgLSBpdCB3aWxsIGJlIGZvciBqdXN0IG92 ZXIgMyB3ZWVrcywgZW5kaW5nIGF0IG1pZG5pZ2h0IFVTIEVhc3Rlcm4gKGRheWxpZ2h0KSBUaW1l IG9uIFRodXJzZGF5LCBEZWNlbWJlciAzMXN0LiAgQ29tbWVudHMgc2hvdWxkIGJlIHNlbnQgdG8g dGhlIHRhcHNAaWV0Zi5vcmc8bWFpbHRvOnRhcHNAaWV0Zi5vcmc+IGxpc3QsIGFsdGhvdWdoIHB1 cmVseSBlZGl0b3JpYWwgY29tbWVudHMgbWF5IGJlIHNlbnQgZGlyZWN0bHkgdG8gdGhlIGF1dGhv cnMgKGRyYWZ0LWlldGYtdGFwcy10cmFuc3BvcnRzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LXRhcHMtdHJhbnNwb3J0c0BpZXRmLm9yZz4pLg0KDQpXZSdyZSBsb29raW5nIGZvciBhdCBsZWFz dCBhIGNvdXBsZSBtb3JlIHJldmlld3MgZHVyaW5nIFdHTEMgLSBwbGVhc2UgZW1haWwgdGhlIGNo YWlyIChhYXJvbi5mYWxrQGdtYWlsLmNvbTxtYWlsdG86YWFyb24uZmFsa0BnbWFpbC5jb20+KSBp ZiB5b3UncmUgaW50ZXJlc3RlZCBhbmQgd2lsbGluZyB0byByZXZpZXcgdGhpcyBkcmFmdCAob3Ro ZXJ3aXNlLCB3ZSdsbCBoYXZlIHRvIGdvICJiZWF0IHRoZSBidXNoZXMiIGZvciByZXZpZXdlcnMp Lg0KDQpUaGFua3MsDQoNCi0tYWFyb24NCg== --_000_655C07320163294895BBADA28372AF5D4858085AFR712WXCHMBA15z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGUgYWJzdHJhY3QgY291bGQg YmV0dGVyIGRlc2NyaWJlIHRoZSBhY3R1YWwgY29udGVudCBvZiB0aGUgZG9jdW1lbnQsIGUuZy4s IHdpdGggYSBzZW50ZW5jZSBsaWtlIOKAnOKApiBzdXJ2ZXlzLCBjbGFzc2lmaWVzIGFuZCBjb21w YXJlcyB0aGUgcHJvdG9jb2wgbWVjaGFuaXNtcw0KIOKApuKAnS4gSXQgY291bGQgYWxzbyBsaXN0 IHRoZSBwcm90b2NvbHMgdGhhdCBhcmUgaW4gc2NvcGUgb2YgdGhlIGRvY3VtZW50LCBvciBpdCBj b3VsZCBib3Jyb3cgb3RoZXIgdGV4dCBmcm9tIFNlY3Rpb24gMS4gSXQgaXMgbm90IGNsZWFyIHRv IG1lIHdoYXQgYSByZWFkZXIgY291bGQgbGVhcm4gZnJvbSB0aGUgc3RhdGVtZW50IOKAnOKApiB0 byBpbmZvcm0gdGhlIHdvcmsgb2YgdGhlIElFVEYgVEFQUyBXb3JraW5nIEdyb3Vw4oCdLCBpbiBw YXJ0aWN1bGFyIGluDQogYSBjb3VwbGUgb2YgeWVhcnMgZnJvbSBub3cgd2hlbiB0aGUgV0cgbWF5 IG5vdCBleGlzdCBhbnkgbW9yZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIFNlY3Rpb24gNC4xLCBpdCBtYXkgYmUg YmV0dGVyIHRvIHJlZmVyIHRvIFJGQyA3NDE0IGluc3RlYWQgb2YgUkZDIDQ2MTQuIEFsc28sIEkg dGhpbmsgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gYmV0dGVyIGVtcGhhc2l6ZSB0aGF0IHRo ZSBzZWN0aW9uIGp1c3QgZ2l2ZXMNCiBhbiBvdmVydmlldyBvZiBUQ1AgYW5kIGlzIG5vdCBpbnRl bmRlZCB0byBiZSBhIGNvbXByZWhlbnNpdmUgZGVzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGFwcyBb bWFpbHRvOnRhcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWFyb24g RmFsazxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAwOCwgMjAxNSAzOjAzIFBN PGJyPg0KPGI+VG86PC9iPiB0YXBzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUYXBz XSBUQVBTIFdHTEM6IGRyYWZ0LWlldGYtdGFwcy10cmFuc3BvcnRzLTA4IC0gZW5kcyBEZWMgMzE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPlRoaXMgZW1haWwgYW5ub3VuY2VzIGEmbmJzcDtUQVBTJm5ic3A7 V29ya2luZyBHcm91cCBMYXN0IENhbGwgKFdHTEMpIG9uOjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwO1NlcnZpY2VzIHByb3ZpZGVkIGJ5IElFVEYgdHJhbnNwb3J0 IHByb3RvY29scyBhbmQgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXM8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10YXBzLXRyYW5zcG9ydHMvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij5kcmFmdC1pZXRmLXRhcHMtdHJhbnNwb3J0cy0wOC50eHQ8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxicj4NCjxicj4NCkR1ZSB0byB0 aGUgdGltaW5nIChtYW55IHBlb3BsZSB0YWtlIHRpbWUgb2ZmIGR1cmluZyB0aGUgRGVjZW1iZXIg aG9saWRheXMpLCB0aGlzJm5ic3A7V0dMQyZuYnNwO3dpbGwmbmJzcDtydW4gZm9yIHNsaWdodGx5 IGxvbmdlciB0aGFuIHVzdWFsIC0gaXQgd2lsbCBiZSBmb3IganVzdCBvdmVyIDMgd2Vla3MsIGVu ZGluZyBhdCZuYnNwO21pZG5pZ2h0IFVTIEVhc3Rlcm4gKGRheWxpZ2h0KSBUaW1lIG9uIFRodXJz ZGF5LCBEZWNlbWJlciAzMXN0LiZuYnNwOyBDb21tZW50cyBzaG91bGQgYmUgc2VudA0KIHRvIHRo ZSZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGFwc0BpZXRmLm9yZyI+dGFwc0BpZXRmLm9y ZzwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDtsaXN0LCZuYnNwO2FsdGhv dWdoIHB1cmVseSBlZGl0b3JpYWwgY29tbWVudHMgbWF5IGJlIHNlbnQgZGlyZWN0bHkgdG8gdGhl IGF1dGhvcnMgKDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXRhcHMtdHJhbnNwb3J0c0BpZXRm Lm9yZyI+ZHJhZnQtaWV0Zi10YXBzLXRyYW5zcG9ydHNAaWV0Zi5vcmc8L2E+KS48YnI+DQo8YnI+ DQpXZSdyZSBsb29raW5nIGZvciBhdCBsZWFzdCBhIGNvdXBsZSBtb3JlJm5ic3A7cmV2aWV3cyBk dXJpbmcmbmJzcDtXR0xDJm5ic3A7LSBwbGVhc2UgZW1haWwgdGhlIGNoYWlyICg8YSBocmVmPSJt YWlsdG86YWFyb24uZmFsa0BnbWFpbC5jb20iPmFhcm9uLmZhbGtAZ21haWwuY29tPC9hPikgaWYm bmJzcDt5b3UncmUgaW50ZXJlc3RlZCBhbmQgd2lsbGluZyB0byByZXZpZXcgdGhpcyBkcmFmdCAo b3RoZXJ3aXNlLCB3ZSdsbCBoYXZlJm5ic3A7dG8gZ28gJnF1b3Q7YmVhdCB0aGUgYnVzaGVzJnF1 b3Q7IGZvciByZXZpZXdlcnMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlRoYW5rcywmbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPi0tYWFyb248L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_655C07320163294895BBADA28372AF5D4858085AFR712WXCHMBA15z_-- From nobody Thu Dec 10 01:27:35 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC1D1A882B for ; Thu, 10 Dec 2015 01:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifj_laERFdZD for ; Thu, 10 Dec 2015 01:27:32 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 594351A87F1 for ; Thu, 10 Dec 2015 01:27:32 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id AEB401A00AF; Thu, 10 Dec 2015 10:27:00 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_722F2D27-BF75-42C0-A33B-7674A1DA24E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: <655C07320163294895BBADA28372AF5D4858085A@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Thu, 10 Dec 2015 10:26:59 +0100 Message-Id: <2DB057F0-6FEC-465A-B699-4F61D51FFAEF@trammell.ch> References: <655C07320163294895BBADA28372AF5D4858085A@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Aaron Falk , "taps@ietf.org" Subject: Re: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 09:27:35 -0000 --Apple-Mail=_722F2D27-BF75-42C0-A33B-7674A1DA24E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Michael, thanks for your review and comments! Commentcomments inline > On 09 Dec 2015, at 14:24, Scharf, Michael (Michael) = wrote: >=20 > I think the abstract could better describe the actual content of the = document, e.g., with a sentence like =E2=80=9C=E2=80=A6 surveys, = classifies and compares the protocol mechanisms =E2=80=A6=E2=80=9D. Presuming we'll roll an -09 with WGLC comments, yes, agree fully and = have made the change in the working copy = (https://github.com/britram/taps-transports/draft-ietf-taps-transports.md)= . > It could also list the protocols that are in scope of the document, or = it could borrow other text from Section 1. I think I'd prefer to list the protocols. Done. > It is not clear to me what a reader could learn from the statement = =E2=80=9C=E2=80=A6 to inform the work of the IETF TAPS Working Group=E2=80= =9D, in particular in a couple of years from now when the WG may not = exist any more. This was also, I think, originally intended to be pulled out before = publication. Cut. > In Section 4.1, it may be better to refer to RFC 7414 instead of RFC = 4614. Yep, oops. > Also, I think it would be appropriate to better emphasize that the = section just gives an overview of TCP and is not intended to be a = comprehensive description. Done in first para. Thanks again, cheers, Brian >=20 > Michael >=20 >=20 > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Aaron Falk > Sent: Tuesday, December 08, 2015 3:03 PM > To: taps@ietf.org > Subject: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 >=20 > This email announces a TAPS Working Group Last Call (WGLC) on: >=20 > Services provided by IETF transport protocols and congestion = control mechanisms > draft-ietf-taps-transports-08.txt >=20 > Due to the timing (many people take time off during the December = holidays), this WGLC will run for slightly longer than usual - it will = be for just over 3 weeks, ending at midnight US Eastern (daylight) Time = on Thursday, December 31st. Comments should be sent to the = taps@ietf.org list, although purely editorial comments may be sent = directly to the authors (draft-ietf-taps-transports@ietf.org). >=20 > We're looking for at least a couple more reviews during WGLC - please = email the chair (aaron.falk@gmail.com) if you're interested and willing = to review this draft (otherwise, we'll have to go "beat the bushes" for = reviewers). >=20 > Thanks, >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_722F2D27-BF75-42C0-A33B-7674A1DA24E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWaUVkAAoJEIoSt78L6kajSK0QALH9ivQvo+Xv+0MoATojWDr3 GXBYJKmkFEaXEdzw0NHAik4bkVFLc7aNLtd84C176838p7vxmM+7yt+DiCagIhim 8HUO4iNunG07D2LBe9c9ZTVfbtaYZgyzEoTClyEBXKCKVxVBBSkv+sIGT2sn834l yHGTd0B5WpX9MvhgG5rO5mey0L4as5QdsYq+5akwpdz9M5g3NJneIVOZeHJwVQLx gCTSdPfFYYZ91lQLL8Yy+86h9JkKOLl/IaMssUFNNJzO7cbGAmRXad79EBbb4cGO vVU27/1N37U4cm2gIGi1KHF/MKt19kG/Hm2aWjH0qaqo5aRS1Wk3Z3c6D7IyAVav Q/C0GtsUvGp6U3ffqZbB6YvSXaKWS2Us0sk8Z0dHoNWmEXB6o9iDSr+FXtytTOEK dr+1YBIwK/NTrs+tr6whlcWXXtvz9nK1M4zyWGfjW6m//lha9NVJBmHMUg26TC4N IeZs9t8sMT2hBvV2w6cThtBEZCtEBffSekv/uM91Evm5txnznj1DdrfAMmBpiraG Yqz/CS9EUpvH+vIPN/cbtblVVD5TVmB2nlpKZN2matsfkdEwKjXRGd09oFcxcj4d UFs79xKFFEYaU61q+wS1v1IPl5zS/kG9hTQONfPrdaIXGJ+UYDD7G046LqIoX7yC JGtpJ/4XP3JMS1dR2OvW =xzvS -----END PGP SIGNATURE----- --Apple-Mail=_722F2D27-BF75-42C0-A33B-7674A1DA24E9-- From nobody Fri Dec 18 04:45:16 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AFE1B2B71 for ; Fri, 18 Dec 2015 04:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PW7eauS6RdD for ; Fri, 18 Dec 2015 04:45:11 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3851B2B55 for ; Fri, 18 Dec 2015 04:45:09 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1a9uPD-0001RI-Jr for taps@ietf.org; Fri, 18 Dec 2015 13:45:07 +0100 Received: from [88.128.82.60] (helo=[10.53.201.43]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1a9uPC-0007oT-Fd for taps@ietf.org; Fri, 18 Dec 2015 13:45:07 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1A961563-4484-4549-BAC0-AFE82ECFA947@ifi.uio.no> Date: Fri, 18 Dec 2015 13:45:04 +0100 To: taps WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 36589 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 40339C065C4ED483B4401B28F2DA2AD3927B6BA3 X-UiO-SPAM-Test: remote_host: 88.128.82.60 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Comments on draft-ietf-taps-transports-08 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 12:45:14 -0000 Dear all, I finally managed to read draft-ietf-taps-transports-08 in detail, here = are my comments. Now, for the first time, I believe I deserve the ACK = that is in there :-) Most of them are nits, and I apologize for = presenting them mixed together with some larger issues (with the biggest = issue being towards the end, where I comment on section 5) - but anyway = there's nothing huge or show-stopping. There may also be duplicates = between these comments and comments that were already given. Cheers, Michael Comments on draft-ietf-taps-transports-08 sec 1: s/MP-TCP/MPTCP (for consistency) sec 2: This defines "Transport Service Feature" but all the text describing = protocols talks about "Transport Features" (with non-capitalized = "features" in some section headings). Define both? Or only "Transport = Features" maybe? "Transport Service Feature" seems unnecessarily = lengthy... sec 3: unordered and unordered message delivery =3D> should probably be = "ordered and unordered" sec 3.1: *** and other protocols that choose to use a datagram protocol (e.g., UDP or UDP-Lite) need to employ mechanisms to prevent congestion collapse *** =3D> the fact that these protocols provide a datagram service isn't the = issue - it's the lack of congestion control. (indeed just a bit further = down there's talk of "datagram congestion control" in DCCP CCID-2). *** Each technique requires that the protocol provide a method *** =3D> provide_s_ ? =46rom the 3rd paragraph onward, the text of this section seems a bit = out of place: in the context of this document, it would probably be = better to explain what the various congestion controls mean for = applications (smooth TFRC, bursty Reno, LBE-style LEDBAT...), but this = text talks about loss vs. delay vs. ECN signals etc. which seems largely = irrelevant here. Well at least that part does - rate- vs. window-based = has a meaning for an application, so that part is probably fine. Also, = it's probably ok to have these explanations there, but the meaning of = different congestion control flavors for applications is missing (can be = short but should be there). *** are are deployed in the Internet *** sec 4 extra space in "connection- oriented" *** TCP Selective Acknowledgment [RFC2018] extends this mechanism by making it possible to identify missing segments more precisely, reducing spurious retransmission. *** I would have thought that DupACKs without SACK are just as precise as = SACK is - they just contain less information, and thus it takes longer = to notify the sender of multiple holes in one window. So I would say = "faster" instead of "more precisely" - and I'm also not sure SACK = (without DSACK) reduces spurious retransmission. Why would it? 4.1.2 *** This interface does not describe configuration of TCP options or parameters beside use of the PUSH and URGENT flags. *** =3D> this is the first mention of PUSH, making it hard to understand = what PUSH is about. Note however that PUSH is optional to implement, and = see my discussion with Karen about it on the list - maybe it could be a = better alternative to just not even mention PUSH here. *** There are current no documents in the RFC Series that describe this interface. *** s/current/currently *** congestion control: a window-based method that uses Additive Increase Multiplicative Decrease (AIMD) to control the sending rate and to conservatively choose a rate after congestion is detected. *** I think only mentioning AIMD here is a bit weird - after all this only = applies to long-running flows. I would at least also describe slow = start. AIMD needs a citation. 4.2.3 *** When aggregating capacity over multiple paths, and depending on the way packets are scheduled on each TCP subflow, an additional delay and higher jitter might be observed observed before in-order delivery of data to the applications. *** =3D> remove "an" before "additional delay" 4.3.1 extra space in "un- ordered" and "user- messages" 4.4 missing space after comma in "error correction,congestion control" Broken reference: {{I-D.ietf-tsvwg- rfc5405bis}} This paragraph is confusing in the context of this section because it's = strictly about IP, not UDP: *** On transmission, UDP encapsulates each datagram into an IP packet, which may in turn be fragmented by IP. Fragments are reassembled before delivery to the UDP receiver. *** =3D> I'd recommend removing it. just before 4.4.2 begins: "etc" should be "etc." 4.5 space in UDP- Lite 4.5.1: another "etc" 4.5.3: strange to have "(as for UDP)" listed only for some but not all features = - maybe better to just say that this is completely the same as UDP = except for the additional "real" UDP-Lite features. Or add (as for UDP) = for *all* features that UDP-Lite shares with UDP. NEXT: 4.6 DCCP *** Specifically it includes core functions (feature negotiation, path state management, RTT calculation, PMTUD, etc): This allows applications to use a compatible method defining how they send packets and where suitable to choose common algorithms to manage their functions. *** First, I think that "core functions" should be more specific - e.g. = "core transport functions". Second, it's strange to say that this (DCCP = including core functions) *allows* apps to use a compatible method - = compatible with what? If I need to be compatible with what DCCP does, = then this is a prescription, not something DCCP "allows" me to do. = Finally, "This" after the colon should not be capitalized. 4.6.1 *** The protocol segments data into messages, typically sized to fit in IP packets, but which may be fragmented providing they are less than the maximum packet size. *** I think s/less/smaller would be better here. *** The protocol may support ordered or unordered delivery of data *** This sounds as if ordered delivery of data is optional to implement in = DCCP. Is that so? Else, s/may support ordered or/supports ordered and *** There is also a Data Checksum option that when enabled, contains a strong CRC, to enable endpoints to detect application data corruption - similar to SCTP. *** That sounds wrong, I don't think SCTP provides a checksum covering only = the data. The data checksum option allows to acknowledge packets even = though they had errors in the payload. *** DCCP uses a Connect packet to initiate a session, and permits half- connections that allow each client to choose the features it wishes to support. *** "permits half-connections" sounds strange to a reader who understands = TCP; also, I'm not sure DCCP "permits" half-connections, aren't they = always there? I would have thought that the concept of half-connections = in DCCP makes it possible for each client to choose the features it = wishes to support. Recommendation: s/permits/uses The word "client" also seems strange here - as if we were talking about = a server and multiple clients. Recommend: e.g. endpoint or peer. 4.6.2 strange formatting here, better to make a bullet list? 4.7 *** The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and [RFC4433] for IPv6 are IETF standards track protocols. *** s/are/is or s/Protocol/Protocols (not sure which is better) 4.7.1 *** ICMP is a connection-less unidirectional protocol that delivers individual messages. *** strange for the reader that this sentence is almost the same as the one = 2 sentences earlier. Maybe just change the phrasing a bit. Or maybe drop = the sentence and begin with the next as: "ICMP uses independent...". *** For example to implement, ICMP-based Path MTU discovery... *** Comma should be after "For example", not after implement - but anyway = this isn't a complete sentence. Better to connect to the preceding one, = e.g. with a dash. *** Such reactions to received messages need to protects from off-path data injection [I-D.ietf-tsvwg-rfc5405bis], avoiding an application receiving packets that were created by an unauthorized third party. *** s/protects/protect suggest: "avoiding _that an application receives packets_ ..." (current = phrasing is wrong I think) *** ICMP processing is integrated into many connection-oriented transports, *** s/into/in ? 4.7.3 I'm not so sure about the list here... it's obvious to use these lists = to compare protocols, and this list would make ICMP seem to be almost = similar to e.g. UDP - I mean, "message-oriented delivery" makes me ask = "of what? of any data that I want to send from A to B?" - technically = this may be correct... but isn't it odd to present ICMP like a = general-purpose message-based protocol? 4.8.1 *** RTP may run over a congestion-controlled or non- congestion-controlled transport protocol. *** Suggest to remove because: how is that a property of the protocol? = Everything can run over everything, pretty much... maybe say "is = commonly run over a congestion controlled but also used over = non-congestion controlled transport protocols" ? if that's true at = all... *** RTCP is a control protocol that works alongside a RTP flow. *** s/a RTP/an RTP ? 4.9 (and 4.11 and 4.12) are not hyperlinks in the HTML ToC, what = happened? 4.9.3 *** error detection (through UDP). *** I'd remove this from the list, same reason as above: UDP is UDP, that's = not an inherent function of the protocol then... 4.10 *** NORM is designed to incorporate packet erasure coding as an inherent part of its selective ARQ in response to receiver negative acknowledgments. *** suggest s/receiver/received or "from the receiver" or something like = that? 4.10.1 extra space in "round- trip" and "rate- control" 4.10.3 *** o error detection (UDP checksum). *** suggest to remove, same argument as above 4.12 *** cases where a application server *** s/a/an *** provides some guidelines and concerns *** odd to "provide a concern" - maybe s/provides/presents ? *** HTTP 1.1's and HTTP 2.0's persistent connections can be use to *** s/use/used *** This reduces connection establishment overhead and the effect of the transport layer slow-start on each transaction, important in reducing latency for HTTP's primary use case. *** suggest "which is" before "important" (currently it's not a complete = sentence) *** which eliminates the latency of addition round-trips. *** s/addition/additional 4.12.2 *** If TLS is used, API expose a *** missing "the" before API Missing "the" before "World Wide Web Consortium (W3C)" same sentence: s/use/used in "an API that can be use for sending" *** Besides XML data format, request and response data format can also be JSON, HTML and plain text. *** suggest: Besides the XML data format, the request ...." *** Specifically JavaScript and XMLHttpRequest are a ubiquitous programming model *** s/a/an *** Representational State Transfer (REST) [REST] is another example how applications can use HTTP as transport protocol. *** I think there should be "of" before "how". *** REST is an architecture style for building application on the Internet. *** misses "an" before "application" 4.12.13 This is the first occurrence of " o object range request." and at = least I don't intuitively get what that means... does it really fit in = here? If so, please add it to the explanations of how the protocol = works. Also, which version is assumed for this list? Wouldn't it look slightly = different for v1 and v2? Also, the list probably misses some things for v2 - e.g. multiplexing = (multi-streaming) *** HTTPS (HTTP over TLS) additionally provides the following components: *** suggest s/components/features because everywhere else they are transport = features, not components 5 The tables (fig 1 and fig 2) include entries "Poss" and "Pos" which are = not self-explanatory. I guess "Poss" means "Possible" but what, then, = does "Pos" mean? *** The transport protocol components analyzed in this document that can be used as a basis for defining common transport service features, normalized and separated into categories, are as follows: *** This is odd; having read the whole document, it doesn't strike me as an = "analysis of transport protocol components" but as a survey of protocols = and their transport features. This also makes me wonder if "Transport = Protocol Component" shouldn't be removed from the terminology, the word = "component" hardly ever appears in the document, so this term seems = unnecessary. Anyway the sentence above has another issue: it says: "The transport = protocol components ..... are as follows" and then it is followed by the = list of features from the protocols that were presented in the preceding = sections. Why were they features before but all of a sudden they are = components? This bit also stands out: *** * Application to port mapping (TCP, MPTCP, SCTP, UDP, UDP-Lite, DCCP, FLUTE/ALC, NORM, TLS, HTTP) + with commonly deployed support in NAPT (TCP, MPTCP, UDP, TLS, HTTP) *** The NAPT support seems pulled out of a hat? It doesn't seem to match the = rest of the document or the section, where the impression is that this = list is a summary of the list of features found earlier. Introducing = such a seemingly made up item makes me wonder if the rest of the list = truly maps to the lists of Transport Service Features presented earlier = per protocol - it should, else this is strange and inconsistent. =3D> Indeed it seems that there is some cleaning up to do. E.g. = searching for "object-oriented delivery of discrete data or file items" = takes me only to NORM, not to FLUTE/ALC or HTTP. So are the functions = there really the same if they're not called the same? I think it's = really important for the names of these features to be consistent = throughout the document. Just as a reminder, this: *** + stream-oriented delivery (TCP, MPTCP, SCTP, TLS) - with multiple streams per association (SCTP) *** should probably also include HTTP if the version number covered is v2 - = but I already commented on this above. From nobody Tue Dec 29 09:22:37 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D351A0120 for ; Tue, 29 Dec 2015 09:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7HgQT_Zk7kI for ; Tue, 29 Dec 2015 09:22:35 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFEF1A011B for ; Tue, 29 Dec 2015 09:22:35 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id v14so41542915ykd.3 for ; Tue, 29 Dec 2015 09:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=X+s3R9P/qnSF7Awvnio0lLzO/4aXGXpvedZ63OcGASk=; b=XItA1vJ4UnDb46hmeqJwYhTvHezAPgKluj30epoQjEVQoeYL5NNzDesgk24buK9/s7 Qp1G7jOEWPD/FYPDUTzb/ULqkYcVwHCe65pG31iZ15zVWXlhIB9D33+sDOOzgpn++hlf MQ2acijw+iuEvPZlZ6Z58ZNhkN5aCeByIp3Cgcv3lFLeFydFO8JaJ6SusoXKSUrRck2c RvgOgVr+f0w2BTAZdXfsnVQUsDIvMsjj/bxOg/IItVvQ1X3wRngJpg4e40G/McPoFxhh i0uvGQu0C2NAM1Gkxx1Bke/Gdjdn2UPG+Tv36Aa2Lo8vIItK//BauPpw0dDVyNfihO0a j1sQ== MIME-Version: 1.0 X-Received: by 10.129.95.138 with SMTP id t132mr43831836ywb.61.1451409754589; Tue, 29 Dec 2015 09:22:34 -0800 (PST) Received: by 10.37.83.2 with HTTP; Tue, 29 Dec 2015 09:22:34 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Dec 2015 12:22:34 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a11470a5ad8928d05280caaab Archived-At: Subject: Re: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 17:22:37 -0000 --001a11470a5ad8928d05280caaab Content-Type: text/plain; charset=UTF-8 Reminder: WGLC on this doc ends this week. Please read the current rev and send comments -- pro or con -- to this list. --aaron On Tue, Dec 8, 2015 at 9:02 AM, Aaron Falk wrote: > This email announces a TAPS Working Group Last Call (WGLC) on: > > Services provided by IETF transport protocols and congestion > control mechanisms > draft-ietf-taps-transports-08.txt > > > Due to the timing (many people take time off during the December > holidays), this WGLC will run for slightly longer than usual - it will be > for just over 3 weeks, ending at midnight US Eastern (daylight) Time on > Thursday, December 31st. Comments should be sent to the taps@ietf.org > list, although purely editorial comments may be sent directly to the > authors (draft-ietf-taps-transports@ietf.org). > > We're looking for at least a couple more reviews during WGLC - please > email the chair (aaron.falk@gmail.com) if you're interested and willing > to review this draft (otherwise, we'll have to go "beat the bushes" for > reviewers). > > Thanks, > > --aaron > --001a11470a5ad8928d05280caaab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reminder: WGLC on this doc ends this week.=C2=A0 Please re= ad the current rev and send comments -- pro or con -- to this list.
--aaron

On Tue, Dec 8, 2015 at 9:02 AM, Aaron Falk = <aaron.falk@gm= ail.com> wrote:
This email announces a=C2=A0<= span style=3D"font-size:12.8px">TAPS=C2=A0Working Group Last Call (WGL= C) on:

= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Se= rvices provided by IETF transport protocols and congestion control mechanis= ms
= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0draft-ietf-taps-transports-08.txt

Due to the timing (many people t= ake time off during the December holidays), this=C2=A0WGLC=C2=A0will= =C2=A0run for slightly longer than = usual - it will be for just over 3 weeks, ending at=C2=A0midnight US Eastern (daylight) Time on Thursday, Dece= mber 31st.=C2=A0 Comments should be= sent to the=C2=A0taps@ietf.org=C2=A0list,=C2=A0alt= hough purely editorial comments may be sent directly to the authors (draft-ie= tf-taps-transports@ietf.org).

We're looki= ng for at least a couple more=C2=A0= reviews during=C2=A0WGLC=C2=A0- please email the chair (aaron.falk@gmail.com= ) if=C2=A0you're interested and willing to review this draft (otherwise, = we'll have=C2=A0to go "bea= t the bushes" for reviewers).

Thanks,=C2= =A0

--aaron

--001a11470a5ad8928d05280caaab-- From nobody Thu Dec 31 07:06:56 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18D71A1AA8 for ; Thu, 31 Dec 2015 07:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExewrWIAgBUe for ; Thu, 31 Dec 2015 07:06:52 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B59F1A1AA3 for ; Thu, 31 Dec 2015 07:06:52 -0800 (PST) Received: from [81.187.2.149] (port=47272 helo=[192.168.0.64]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1aEeoO-0004Ty-Ar; Thu, 31 Dec 2015 15:06:50 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_5ABCE2B2-EC68-4E23-A88C-3F399404161F" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Thu, 31 Dec 2015 15:06:34 +0000 Message-Id: <6DEDD6D8-B677-4096-925E-618392FDF719@csperkins.org> References: To: Aaron Falk X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 15:06:55 -0000 --Apple-Mail=_5ABCE2B2-EC68-4E23-A88C-3F399404161F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This draft is in good shape. Some quick comments, that are almost = entirely editorial: 1, 2nd paragraph: RTP can also run over DCCP, TLS, and DTLS. 4.1.1: =E2=80=9Cdescribed further in Section 3.1 below=E2=80=9D =E2=80=93 = but section 3.1 is above in the document. 4.3 (SCTP): =E2=80=9CIt is therefore deployed in all Web browsers = supporting WebRTC=E2=80=9D =E2=80=93 actually, a slightly restricted = subset of SCTP tunnelled over DTLS over UDP is part of WebRTC. 4.6.2: editorial - list formatting is messed up 4.8.1: the correct expansion of RTCP is =E2=80=9CRTP control = protocol=E2=80=9D, not =E2=80=9C Real Time Control Protocol=E2=80=9D 4.8.1: =E2=80=9CThe RFC-series specifies RTP media formats=E2=80=9D = should be =E2=80=9C=E2=80=A6RTP payload formats=E2=80=9D 4.8.1: =E2=80=9CRTP sender and receiver can send RTCP report packets.=E2=80= =9D =E2=80=93 actually, =E2=80=9C=E2=80=A6will send=E2=80=A6=E2=80=9D 4.8.2: =E2=80=9Cmulticast, anycast or IPv4 broadcast=E2=80=9D =E2=80=93 = not sure broadcast makes sense, and isn=E2=80=99t anycast just a = variation on unicast? (i.e., RTP is no more anycast than is TCP) 5: RTP is not mentioned in the bullet lists of transport service = features - should it be? 8: my name is mis-spelt in the bullet on section 4.8 Colin > On 29 Dec 2015, at 17:22, Aaron Falk wrote: >=20 > Reminder: WGLC on this doc ends this week. Please read the current = rev and send comments -- pro or con -- to this list. >=20 > --aaron >=20 > On Tue, Dec 8, 2015 at 9:02 AM, Aaron Falk > wrote: > This email announces a TAPS Working Group Last Call (WGLC) on: >=20 > Services provided by IETF transport protocols and congestion = control mechanisms > draft-ietf-taps-transports-08.txt = >=20 > Due to the timing (many people take time off during the December = holidays), this WGLC will run for slightly longer than usual - it will = be for just over 3 weeks, ending at midnight US Eastern (daylight) Time = on Thursday, December 31st. Comments should be sent to the = taps@ietf.org list, although purely editorial = comments may be sent directly to the authors = (draft-ietf-taps-transports@ietf.org = ). >=20 > We're looking for at least a couple more reviews during WGLC - please = email the chair (aaron.falk@gmail.com ) if = you're interested and willing to review this draft (otherwise, we'll = have to go "beat the bushes" for reviewers). >=20 > Thanks,=20 >=20 > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_5ABCE2B2-EC68-4E23-A88C-3F399404161F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

This = draft is in good shape. Some quick comments, that are almost entirely = editorial:

1, 2nd paragraph: RTP can also run over = DCCP, TLS, and DTLS.

4.1.1: =E2=80=9Cdescribed further in Section 3.1 below=E2=80=9D= =E2=80=93 but section 3.1 is above in the document.

4.3 (SCTP): =E2=80=9CIt is therefore = deployed in all Web browsers supporting WebRTC=E2=80=9D =E2=80=93 = actually, a slightly restricted subset of SCTP tunnelled over DTLS over = UDP is part of WebRTC.

4.6.2: editorial - list formatting is messed up

4.8.1: the correct expansion of RTCP is = =E2=80=9CRTP control protocol=E2=80=9D, not =E2=80=9C Real Time Control = Protocol=E2=80=9D

4.8.1: =E2=80=9CThe RFC-series specifies RTP media formats=E2=80= =9D should be =E2=80=9C=E2=80=A6RTP payload formats=E2=80=9D

4.8.1: =E2=80=9CRTP sender and receiver = can send RTCP report packets.=E2=80=9D =E2=80=93 actually, =E2=80=9C=E2=80= =A6will send=E2=80=A6=E2=80=9D

4.8.2: =E2=80=9Cmulticast, anycast or IPv4 = broadcast=E2=80=9D =E2=80=93 not sure broadcast makes sense, and isn=E2=80= =99t anycast just a variation on unicast? (i.e., RTP is no more anycast = than is TCP)

5: = RTP is not mentioned in the bullet lists of transport service features - = should it be?

8: = my name is mis-spelt in the bullet on section 4.8

Colin




On = 29 Dec 2015, at 17:22, Aaron Falk <aaron.falk@gmail.com> wrote:

Reminder: WGLC on this doc ends this week.  Please read = the current rev and send comments -- pro or con -- to this list.

--aaron

On Tue, = Dec 8, 2015 at 9:02 AM, Aaron Falk <aaron.falk@gmail.com> wrote:
This email = announces a TAPS Working Group Last Call (WGLC) on:

    =     Services provided by IETF transport protocols and = congestion control mechanisms
    =     draft-ietf-taps-transports-08.txt

Due to the timing = (many people take time off during the December holidays), = this WGLC will run for slightly longer than usual - it will be for just over = 3 weeks, ending at midnight US Eastern (daylight) Time on Thursday, December = 31st.  Comments = should be sent to the taps@ietf.org list, although purely editorial comments = may be sent directly to the authors (draft-ietf-taps-transports@ietf.org).

We're looking for = at least a couple more reviews during WGLC - = please email the chair (aaron.falk@gmail.com) if you're interested and willing to = review this draft (otherwise, we'll have to go "beat the bushes" for = reviewers).

Thanks, 

--aaron

_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps



-- 
Colin Perkins
https://csperkins.org/



= --Apple-Mail=_5ABCE2B2-EC68-4E23-A88C-3F399404161F-- From nobody Thu Dec 31 07:26:53 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202E71A1B14 for ; Thu, 31 Dec 2015 07:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOS4DhcMsfl7 for ; Thu, 31 Dec 2015 07:26:50 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1AED31A1B12 for ; Thu, 31 Dec 2015 07:26:49 -0800 (PST) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 526961B000AA; Thu, 31 Dec 2015 15:34:12 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 31 Dec 2015 15:26:47 -0000 Message-ID: <00e2e4166beada8d0d8702bfda032044.squirrel@erg.abdn.ac.uk> In-Reply-To: <6DEDD6D8-B677-4096-925E-618392FDF719@csperkins.org> References: <6DEDD6D8-B677-4096-925E-618392FDF719@csperkins.org> Date: Thu, 31 Dec 2015 15:26:47 -0000 From: gorry@erg.abdn.ac.uk To: "Colin Perkins" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Aaron Falk , "taps@ietf.org" Subject: Re: [Taps] TAPS WGLC: draft-ietf-taps-transports-08 - ends Dec 31 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2015 15:26:52 -0000 I think these should be incorporated, thanks Colin, we'll prepare an update. Gorry P.S. Sorry your name was misspelt. > Hi, > > This draft is in good shape. Some quick comments, that are almost entirely > editorial: > > 1, 2nd paragraph: RTP can also run over DCCP, TLS, and DTLS. > > 4.1.1: “described further in Section 3.1 below” – but section 3.1 is > above in the document. > > 4.3 (SCTP): “It is therefore deployed in all Web browsers supporting > WebRTC” – actually, a slightly restricted subset of SCTP tunnelled > over DTLS over UDP is part of WebRTC. > > 4.6.2: editorial - list formatting is messed up > > 4.8.1: the correct expansion of RTCP is “RTP control protocol”, not > “ Real Time Control Protocol” > > 4.8.1: “The RFC-series specifies RTP media formats” should be > “…RTP payload formats” > > 4.8.1: “RTP sender and receiver can send RTCP report packets.” – > actually, “…will send…” > > 4.8.2: “multicast, anycast or IPv4 broadcast” – not sure broadcast > makes sense, and isn’t anycast just a variation on unicast? (i.e., RTP > is no more anycast than is TCP) > > 5: RTP is not mentioned in the bullet lists of transport service features > - should it be? > > 8: my name is mis-spelt in the bullet on section 4.8 > > Colin > > > > >> On 29 Dec 2015, at 17:22, Aaron Falk wrote: >> >> Reminder: WGLC on this doc ends this week. Please read the current rev >> and send comments -- pro or con -- to this list. >> >> --aaron >> >> On Tue, Dec 8, 2015 at 9:02 AM, Aaron Falk > > wrote: >> This email announces a TAPS Working Group Last Call (WGLC) on: >> >> Services provided by IETF transport protocols and congestion >> control mechanisms >> draft-ietf-taps-transports-08.txt >> >> >> Due to the timing (many people take time off during the December >> holidays), this WGLC will run for slightly longer than usual - it will >> be for just over 3 weeks, ending at midnight US Eastern (daylight) Time >> on Thursday, December 31st. Comments should be sent to the >> taps@ietf.org list, although purely editorial >> comments may be sent directly to the authors >> (draft-ietf-taps-transports@ietf.org >> ). >> >> We're looking for at least a couple more reviews during WGLC - please >> email the chair (aaron.falk@gmail.com ) if >> you're interested and willing to review this draft (otherwise, we'll >> have to go "beat the bushes" for reviewers). >> >> Thanks, >> >> --aaron >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >