From nobody Mon Jul 1 07:17:47 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F62C1200C4 for ; Mon, 1 Jul 2019 07:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=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 Kp1prlEX4nGk for ; Mon, 1 Jul 2019 07:17:43 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 A07C31200BA for ; Mon, 1 Jul 2019 07:17:41 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x61EHZfH023777 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 1 Jul 2019 16:17:35 +0200 Received: from philipp-laptop.ods.tu-berlin.de ([130.149.141.20]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hhx5l-0007DU-1Y; Mon, 01 Jul 2019 16:15:37 +0200 From: "Philipp S. Tiesel" Message-Id: <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> Content-Type: multipart/signed; boundary="Apple-Mail=_D2A6C9E9-4362-4158-A67E-FE193E703E51"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 1 Jul 2019 16:17:34 +0200 In-Reply-To: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> Cc: Aaron Falk , Zaheduzzaman Sarker , "taps@ietf.org" To: Michael Welzl References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 14:17:45 -0000 --Apple-Mail=_D2A6C9E9-4362-4158-A67E-FE193E703E51 Content-Type: multipart/alternative; boundary="Apple-Mail=_B63B8325-EB8B-48CF-948D-234AA9E3C8F8" --Apple-Mail=_B63B8325-EB8B-48CF-948D-234AA9E3C8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30. Jun 2019, at 23:44, Michael Welzl wrote: >=20 > Hi, >=20 > Sounds like a good start! >=20 > About this: >=20 >> On Jun 30, 2019, at 11:34 PM, Aaron Falk > wrote: >>=20 >> What shall we use our face-time for in Montreal? >>=20 >> Some topics from our last interim = seem like good candidates for updates. Can we refine them with = specific to discuss (and ID someone to launch/lead the discussion)? >>=20 >> Framing >> Implementations >> Parameters & Defaults >> Yang model >> Why do people resist specific protocol selection? (from Yang = discussion) > I=E2=80=99d volunteer to lead this discussion, but I wonder: is this = really worth the time - as in: do we really (still) have any resistance = to this idea? Looks like=E2=80=A6 but I guess we have two different topics here: - Property Profiles (shortcuts for common sets of properties) - Explicit Protocol Selection I originally insisted to keep them separate, as I really like to have = the first one and feared the discussion for the second one. As I opened = PRs with proposals for both of them = (https://github.com/ietf-tapswg/api-drafts/pull/328 = and = https://github.com/ietf-tapswg/api-drafts/pull/327 = ), I got no fire and = fury, but only constructive feedback. So I agree with Michael that we may really have a short discussion on = whether to add these features. >=20 > Cheers, > Michael >=20 >=20 >> ARCH & API open topics >> --aaron >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_B63B8325-EB8B-48CF-948D-234AA9E3C8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 30. Jun 2019, at 23:44, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

Sounds like a good start!

About this:

On Jun 30, 2019, at 11:34 PM, Aaron Falk = <aaron.falk@gmail.com> wrote:

What = shall we use our face-time for in Montreal?

Some topics from our last = interim seem like good candidates for updates. Can we refine them = with specific to discuss (and ID someone to launch/lead the = discussion)?

  • Framing
  • Implementations
  • Parameters & Defaults
  • Yang model
  • Why do people resist specific protocol selection? (from = Yang discussion)
I=E2=80=99d volunteer to lead this discussion, but I wonder: = is this really worth the time - as in: do we really (still) have any = resistance to this = idea?

Looks like=E2=80=A6 but I guess we have two = different topics here:
 - Property Profiles (shortcuts = for common sets of properties)
 - Explicit Protocol = Selection

I originally insisted to = keep them separate, as I really like to have the first one and feared = the discussion for the second one. As I opened PRs with proposals for = both of them (https://github.com/ietf-tapswg/api-drafts/pull/328 and= https://github.com/ietf-tapswg/api-drafts/pull/327), I = got no fire and fury, but only constructive feedback.
So I = agree with Michael that we may really have a short discussion on whether = to add these features.


Cheers,
Michael


  • ARCH & API open topics

--aaron

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

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

AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_B63B8325-EB8B-48CF-948D-234AA9E3C8F8-- --Apple-Mail=_D2A6C9E9-4362-4158-A67E-FE193E703E51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWxyORUfQrk93Q7or9/dp0G7BPC0FAl0aFf4ACgkQ9/dp0G7B PC2FSA/+JNdcgdqHUlea7vrJA57yYbGglOCE4ZXXMEgt6Dbeozf9kGMi9YBDoInf 4/xE8xHXzha4dBkS9T2B1sQYovm43e4O1ZwQ6vXjHlpax7e5YsOMXUQiDgpEwofr Opvdb44VZrSAMWlVXD/C5qGzAeQhhloTl29UhfbT2Q4yB3lcFDG1VvzH7H4Hi1PH XIIth2hQqow2rWirYw7dwsq5xNDxwcAeThRVjwzDYQXTi52nYYq+4PJIQRxLsTeE T/Fl3ys8EMgHvFHaliMW/Gim/m7UBC6BL75DgDxDgesLZlT+4YfmZXuxCT5DlkU6 oojEIi6YRS+0/LaJ4gnEnKxP+USe9LgeX62FmJy1lYomz30UQinPec9DoLVexS0c LeusL+xt2/5uKiG+VTCu2KFwW0u/Uel6jRDEEhW84FZR7uYAd/2frF5eSc81gcwz aOguDZBDeCdhpjptMlAcU3vn2/lO9QnjGDhRAiERVlm/ez+EQhddMRHjiyH7Py8b /hynrQTR1SDVLPenc8A56YTL9aARQjB79gwtzqOSgSYzy1kyJ4kMfARscOEfq6gr 25z4HKqpt/L2I3wzc/Ev9vFW1dUi701GeXc5B8kwzFrhxzDFt0rQ50w5BK0HDaLP vTIbeXqfs3FksJouD9IirgKU4WIAlk0+d0l73j2+677K1LvADes= =5hYR -----END PGP SIGNATURE----- --Apple-Mail=_D2A6C9E9-4362-4158-A67E-FE193E703E51-- From nobody Tue Jul 2 00:24:39 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C90120227 for ; Tue, 2 Jul 2019 00:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 k5MDM-vDDEpb for ; Tue, 2 Jul 2019 00:24:33 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 14FFA1201D7 for ; Tue, 2 Jul 2019 00:24:31 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hiD9P-0002pk-1x; Tue, 02 Jul 2019 09:24:27 +0200 Received: from 1x-193-157-246-178.uio.no ([193.157.246.178]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hiD9M-0008jM-Fc; Tue, 02 Jul 2019 09:24:26 +0200 From: Michael Welzl Message-Id: <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_91F535CF-FDC3-4325-8587-F3C4B869E0C4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 2 Jul 2019 09:24:23 +0200 In-Reply-To: <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> Cc: Aaron Falk , Zaheduzzaman Sarker , "taps@ietf.org" To: "Philipp S. Tiesel" References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 193.157.246.178 is neither permitted nor denied by domain of ifi.uio.no) client-ip=193.157.246.178; envelope-from=michawe@ifi.uio.no; helo=1x-193-157-246-178.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1F228CED1DE3A7FB9C7C5B9B97DD3CACE40B8623 Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 07:24:37 -0000 --Apple-Mail=_91F535CF-FDC3-4325-8587-F3C4B869E0C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi again, > On Jul 1, 2019, at 4:17 PM, Philipp S. Tiesel = wrote: >=20 >=20 >=20 >> On 30. Jun 2019, at 23:44, Michael Welzl > wrote: >>=20 >> Hi, >>=20 >> Sounds like a good start! >>=20 >> About this: >>=20 >>> On Jun 30, 2019, at 11:34 PM, Aaron Falk > wrote: >>>=20 >>> What shall we use our face-time for in Montreal? >>>=20 >>> Some topics from our last interim = seem like good candidates for updates. Can we refine them with = specific to discuss (and ID someone to launch/lead the discussion)? >>>=20 >>> Framing >>> Implementations >>> Parameters & Defaults I=E2=80=99d volunteer for this one too. >>> Yang model >>> Why do people resist specific protocol selection? (from Yang = discussion) >> I=E2=80=99d volunteer to lead this discussion, but I wonder: is this = really worth the time - as in: do we really (still) have any resistance = to this idea? >=20 > Looks like=E2=80=A6 but I guess we have two different topics here: > - Property Profiles (shortcuts for common sets of properties) > - Explicit Protocol Selection >=20 > I originally insisted to keep them separate, as I really like to have = the first one and feared the discussion for the second one. As I opened = PRs with proposals for both of them = (https://github.com/ietf-tapswg/api-drafts/pull/328 = and = https://github.com/ietf-tapswg/api-drafts/pull/327 = ), I got no fire and = fury, but only constructive feedback. > So I agree with Michael that we may really have a short discussion on = whether to add these features. Ok, it sounds to me like this slot should be called =E2=80=9CProfiles / = choosing specific protocols=E2=80=9D. Sounds like a nice short = discussion to me. Cheers, Michael >=20 >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> ARCH & API open topics >>> --aaron >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps = >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > AVE! > Philipp S. Tiesel >=20 > --=20 > Philipp S. Tiesel=20 > https://philipp.tiesel.net/ --Apple-Mail=_91F535CF-FDC3-4325-8587-F3C4B869E0C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = again,

On Jul 1, 2019, at 4:17 PM, Philipp S. Tiesel = <phils@in-panik.de> wrote:



On 30. Jun 2019, at 23:44, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

Sounds like a good start!

About this:

On Jun 30, 2019, at 11:34 PM, Aaron Falk = <aaron.falk@gmail.com> wrote:

What = shall we use our face-time for in Montreal?

Some topics from our last = interim seem like good candidates for updates. Can we refine them = with specific to discuss (and ID someone to launch/lead the = discussion)?

  • Framing
  • Implementations
  • Parameters & = Defaults
<= /div>
I=E2=80=99d = volunteer for this one too.


  • Yang model
  • Why do people resist specific protocol selection? (from = Yang discussion)
I=E2=80=99d volunteer to lead this discussion, but I wonder: = is this really worth the time - as in: do we really (still) have any = resistance to this idea?

Looks like=E2=80=A6 but = I guess we have two different topics here:
 - = Property Profiles (shortcuts for common sets of properties)
 - Explicit Protocol Selection

I originally insisted to keep them = separate, as I really like to have the first one and feared the = discussion for the second one. As I opened PRs with proposals for both = of them (https://github.com/ietf-tapswg/api-drafts/pull/328 and= https://github.com/ietf-tapswg/api-drafts/pull/327), I = got no fire and fury, but only constructive feedback.
So I agree with Michael that we may really have a short = discussion on whether to add these = features.

Ok, it sounds to me like this slot should be = called =E2=80=9CProfiles / choosing specific protocols=E2=80=9D. =  Sounds like a nice short discussion to me.


Cheers,
Michael




Cheers,
Michael


  • ARCH & API open topics

--aaron

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

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

AVE!   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/


= --Apple-Mail=_91F535CF-FDC3-4325-8587-F3C4B869E0C4-- From nobody Tue Jul 2 01:20:52 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23D1200B3 for ; Tue, 2 Jul 2019 01:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 V8Kbe1yqdDr7 for ; Tue, 2 Jul 2019 01:20:48 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 0BF85120024 for ; Tue, 2 Jul 2019 01:20:46 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x628KgIu026797 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Jul 2019 10:20:42 +0200 Received: from philipp-laptop.ods.tu-berlin.de ([130.149.141.20]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hiDzv-0003ln-S5; Tue, 02 Jul 2019 10:18:43 +0200 From: "Philipp S. Tiesel" Message-Id: <8AD1EFFD-E84C-45D9-8C14-1B261124BA71@in-panik.de> Content-Type: multipart/signed; boundary="Apple-Mail=_0F6FD777-2BD5-4AE2-8E50-B223C9353B3D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 2 Jul 2019 10:20:41 +0200 In-Reply-To: <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> Cc: Aaron Falk , Zaheduzzaman Sarker , "taps@ietf.org" To: Michael Welzl References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 08:20:50 -0000 --Apple-Mail=_0F6FD777-2BD5-4AE2-8E50-B223C9353B3D Content-Type: multipart/alternative; boundary="Apple-Mail=_C9E3E857-3567-438E-8A62-4DD530DF6432" --Apple-Mail=_C9E3E857-3567-438E-8A62-4DD530DF6432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, >>>> On Jun 30, 2019, at 11:34 PM, Aaron Falk > wrote: >>>> What shall we use our face-time for in Montreal? >>>>=20 >>>> Some topics from our last interim = seem like good candidates for updates. Can we refine them with = specific to discuss (and ID someone to launch/lead the discussion)? >>>>=20 >>>> Framing >>>> Implementations >>>> Parameters & Defaults > I=E2=80=99d volunteer for this one too. >=20 >=20 >>>> Yang model >>>> Why do people resist specific protocol selection? (from Yang = discussion) >>> I=E2=80=99d volunteer to lead this discussion, but I wonder: is this = really worth the time - as in: do we really (still) have any resistance = to this idea? >>=20 >> Looks like=E2=80=A6 but I guess we have two different topics here: >> - Property Profiles (shortcuts for common sets of properties) >> - Explicit Protocol Selection >>=20 >> I originally insisted to keep them separate, as I really like to have = the first one and feared the discussion for the second one. As I opened = PRs with proposals for both of them = (https://github.com/ietf-tapswg/api-drafts/pull/328 = and = https://github.com/ietf-tapswg/api-drafts/pull/327 = ), I got no fire and = fury, but only constructive feedback. >> So I agree with Michael that we may really have a short discussion on = whether to add these features. >=20 > Ok, it sounds to me like this slot should be called =E2=80=9CProfiles = / choosing specific protocols=E2=80=9D. Sounds like a nice short = discussion to me. >>>> ARCH & API open topics I=E2=80=99ll volunteer to lead the discussion on the last one. AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_C9E3E857-3567-438E-8A62-4DD530DF6432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,
On Jun 30, 2019, at 11:34 PM, = Aaron Falk <aaron.falk@gmail.com> wrote:

What = shall we use our face-time for in Montreal?

Some topics from = our last interim seem like good candidates = for updates. Can we refine them with specific to discuss (and ID someone = to launch/lead the discussion)?

  • Framing
  • Implementations
  • Parameters & = Defaults
<= /div>
I=E2=80=99d volunteer for this one too.


  • Yang model
  • Why = do people resist specific protocol selection? (from Yang = discussion)
I=E2=80=99d volunteer to lead this discussion, but I wonder: = is this really worth the time - as in: do we really (still) have any = resistance to this idea?

Looks like=E2=80=A6 but = I guess we have two different topics here:
 - = Property Profiles (shortcuts for common sets of properties)
 - Explicit Protocol Selection

I originally insisted to keep them = separate, as I really like to have the first one and feared the = discussion for the second one. As I opened PRs with proposals for both = of them (https://github.com/ietf-tapswg/api-drafts/pull/328 and=  https://github.com/ietf-tapswg/api-drafts/pull/327), I = got no fire and fury, but only constructive feedback.
So I agree with Michael that we may really have a short = discussion on whether to add these = features.

Ok, it sounds to me like this slot = should be called =E2=80=9CProfiles / choosing specific protocols=E2=80=9D.=  Sounds like a nice short discussion to me.
  • ARCH & API open = topics
I=E2=80=99ll volunteer to lead the discussion on the last = one.

AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_C9E3E857-3567-438E-8A62-4DD530DF6432-- --Apple-Mail=_0F6FD777-2BD5-4AE2-8E50-B223C9353B3D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWxyORUfQrk93Q7or9/dp0G7BPC0FAl0bE9kACgkQ9/dp0G7B PC3jixAAp83VxfWea4mt1Ddko2nhXK9Kdy3CR9WLjZBvXkyNFlUbpebaHFVCIfdf fRl/JB5F0u0MgYW9auJwfd1+9ZnoMfLgqOg94jCwbROhdswyl9KU8Rvcv46lmP1r AviTI4hFnq7ZKQ7dgGY20jL8ulwZnjQuZ0G6uOrBUuaECnyaMi7bYlO/MNczoXm0 zaTaOBBN/h4glkZQWABGD6p1YKdYVgGA1z/I0S1+aT4YKcuIASgDGH5WC/d6ZaO8 iNr5l+GL/iA6ffDG0njmz8Xbu6W25xcNFPfIWy6DUg18XVbgu/96ww0H5rE49RsH oi6P/DAX74eIuSbXc2S8mv/4eiS0l7mXrWgeP10qDr5zA/8VFvADsZGyB2oPsCFW ktngwuHuBA/zx6LxjhJEb+QVTeVEYRWQ7maDsfIgwP0uHrkVQbNH9Q44PN3m04O+ bA13gNxZ8ojsRGYhLUus85Z1MgEgvPfMxy5Pawno9tUvhVrnd5nZ5nczlCTVWcg7 r+gwt9a6kfNFfrVkblOSiB3gKflqzQCHp3M3Nz8cXsQ7Or5c+hiZbvhW/2oEaERR HLaLLxJjMNDIueVovjgiSnmSdAHX46KQL2QOFzRUIuPTC/jqv8S7LOuAjhzO8sw4 nJgZ2txqZaAaK/GqBN5AbkVKvxvwpK5oQiVM2EVnKOwmwuLTrtw= =vL9I -----END PGP SIGNATURE----- --Apple-Mail=_0F6FD777-2BD5-4AE2-8E50-B223C9353B3D-- From nobody Tue Jul 2 06:55:50 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD9120075 for ; Tue, 2 Jul 2019 06:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 68p-HZIOV0AY for ; Tue, 2 Jul 2019 06:55:45 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 7B41F120105 for ; Tue, 2 Jul 2019 06:55:45 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id w17so18486738qto.10 for ; Tue, 02 Jul 2019 06:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=wNPKAHo/UG2SqN6+Vr+ixMJHORW+Pl0zzQi3Z958jUA=; b=nvWRGylo0xI5CWFhx85uAHGmW5zxrT6fpk3a1hTKQDkLL7Rf1vSsKeksraHwhXG3g4 cuplWj3fsbeZN44wtftu6/g80CLXeA54BDRWugxDMZTC0111GoVw8/OjMe4MV3E7jemV 3YKhcA9nZ4/iQ+l1xsSDuzNp11xNK1KcvSi41zw35ktjoxCL8WRCC4SeGk6irD9XL0RJ YZAzfTjK4pPyJowtJ//qwzpJfBAoH5Mt70i+QCPPNsi6pzsT8HaYfOIuDdsauE/uCXP/ ES86BD5YMeyyg/GaGmy2DG9+oiF6F98auVSXK54CVGHm/Q7CO9NBO+bsZJxV75aKJk4j GdnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wNPKAHo/UG2SqN6+Vr+ixMJHORW+Pl0zzQi3Z958jUA=; b=iH2AxSKTcl9U0HrN2rbmBazgstGeteMbTxeQU7ajTSF90gNagA2AK13gT8ixcVg5Mg wFVRcdRWSQMLi3oqJaovsBL3oLa+QfTsUQ/jenENbwGO2c6oacG06vL1h2pH2pzjiXWU Xzsfxs8U2h2H2DGT4oaadpiZdzVUh5caPqOvwHZdLuiPXll7m2chO0HlI9WE2xp7co5H 8yAAGtfapxrsafQqLyPq496sNtVGleYnUW9L+0fqbgghYpUcqIssskWE8MIjLotUV2ub wTfPtvX05ImUX4bso8h8new1k/LJ0PyFzNVwrIEhwh4BjD+iYgOSHHJgiZQ6g5ic8lVj HYMQ== X-Gm-Message-State: APjAAAUjzRvyH+bOrpiXAbUgz1zy+soMq8oK4n0gqlLe04y7+IUrwCKX YPnjAlxdrRJta1UKTSlJVYk= X-Google-Smtp-Source: APXvYqyJRe1XV8EzL9gGPOYZBxrge9wUJvIRABeBKDgn4Rx/egA5ukdwlUl3nu6OJwwkw4k/2aI33w== X-Received: by 2002:ac8:ce:: with SMTP id d14mr25367850qtg.149.1562075744477; Tue, 02 Jul 2019 06:55:44 -0700 (PDT) Received: from [172.19.32.166] ([2001:4878:a000:3000:8d61:a87a:92b2:9070]) by smtp.gmail.com with ESMTPSA id i16sm5817688qkk.1.2019.07.02.06.55.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jul 2019 06:55:43 -0700 (PDT) From: "Aaron Falk" To: "Michael Welzl" Cc: "Philipp S. Tiesel" , "Zaheduzzaman Sarker" , taps@ietf.org Date: Tue, 02 Jul 2019 09:55:41 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: In-Reply-To: <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_DEC9A686-1A86-46D1-B3D5-269EAF2D3B0B_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 13:55:49 -0000 --=_MailMate_DEC9A686-1A86-46D1-B3D5-269EAF2D3B0B_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2 Jul 2019, at 3:24, Michael Welzl wrote: >>>> * Parameters & Defaults >>>> > > I’d volunteer for this one too. Michael- Can you frame a question or decision we want to target for the discussion? It would help me (& maybe others) keep the right focus. --aaron --=_MailMate_DEC9A686-1A86-46D1-B3D5-269EAF2D3B0B_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 2 Jul 2019, at 3:24, Michael Welzl wrote:

* Parameters & Defaults

I=E2=80=99d volunt= eer for this one too.

Michael-

Can you frame a question or decision we want to target fo= r the discussion? It would help me (& maybe others) keep the right f= ocus.

--aaron

--=_MailMate_DEC9A686-1A86-46D1-B3D5-269EAF2D3B0B_=-- From nobody Tue Jul 2 06:57:28 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE9A120108 for ; Tue, 2 Jul 2019 06:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fw8IUIcmg1r8 for ; Tue, 2 Jul 2019 06:57:24 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 AE34F1200B6 for ; Tue, 2 Jul 2019 06:57:24 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id p15so18528966qtl.3 for ; Tue, 02 Jul 2019 06:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=OP35UrLkHE7oW82FDeOOlylVJUcJUOG2qZNcGh8buk8=; b=te88H7ljx9ILn+XZBlS2Y4DRMfV+QjaC43DcC80HuCy5TxbYJzD37aYSQRTwkGullZ LTUCQGz7GPme6ZwsFkOJJJgOu2rla4EzZrVqLF8AeRFyKSQaWC+6nsLzQCVujogkxEPm zulMedZecO4PBK2KaFujVLz8GrDWzbHAscu3F9kUcMY5oOMM0DZXnjH2C9vb8BgJOuLL VAiD9JuvjS5SV7VJwtetG/05nfdp3qbgMAOspZvMNYALaP4hP/ZfYVoeXdVVeWKkVaRr 2Np967AKHWIaMmYn1MOyudwIt7d9rd4PgdbTmyNrVSirJN5IXT6SYU8wFsaKfzuZFDqC oUtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OP35UrLkHE7oW82FDeOOlylVJUcJUOG2qZNcGh8buk8=; b=LKxmuHqL2koA7hU/9vMwib/ihtK7dF5RjdZEOaJj1WV7UMQgoAZuWRWTjhdxw/I1cz Tlf19q79VUd2AMW1Br/AC9ZhZKOUVsJCB5N9fSl+FJWjj+XAlmNWPLUf57d/owZO7jHr TF8rCTYOsw6ajrJImGu/kVAe1BhtTqf66Z7OVnymCYCC8noUpk/m1ThH18YHcfA+9Xk7 QxmlCCNBaGr4m+OKpII05U3AWTBlSCYnzJrtFKTasmqZCrM9pMMRzu9ucchVBoZ215a3 LplP/FIdk/+55N1WT8yb34RtRCvN87kuE1LdRvUaoR236SQZugQfFGQ1Ip9DkHJ9Wdxr ov2g== X-Gm-Message-State: APjAAAVnpZEIYBvAifaRBFN51YRPZc80n7BkYDuJVQdNpwsZ2s5e5HE3 97SuF9zQlJ2YH9JnuS/85eg= X-Google-Smtp-Source: APXvYqyjlaxulUo+6usfXa9l5mqUlLQtEuvGkaz6BR9PmIhKQsDAlQ+wUTLuwI2zoZsyZ4EnnCOgQw== X-Received: by 2002:ac8:5311:: with SMTP id t17mr24740627qtn.304.1562075843736; Tue, 02 Jul 2019 06:57:23 -0700 (PDT) Received: from [172.19.32.166] ([2001:4878:a000:3000:8d61:a87a:92b2:9070]) by smtp.gmail.com with ESMTPSA id w62sm6552583qkd.30.2019.07.02.06.57.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jul 2019 06:57:22 -0700 (PDT) From: "Aaron Falk" To: "Philipp S. Tiesel" Cc: "Michael Welzl" , "Zaheduzzaman Sarker" , taps@ietf.org Date: Tue, 02 Jul 2019 09:57:21 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: <9F996A9A-3E62-4623-8A57-8326938BD2A4@gmail.com> In-Reply-To: <8AD1EFFD-E84C-45D9-8C14-1B261124BA71@in-panik.de> References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> <8AD1EFFD-E84C-45D9-8C14-1B261124BA71@in-panik.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4E022C0E-8CFE-4E2D-BB52-404B7E28FF86_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 13:57:26 -0000 --=_MailMate_4E022C0E-8CFE-4E2D-BB52-404B7E28FF86_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2 Jul 2019, at 4:20, Philipp S. Tiesel wrote: >>>>> * ARCH & API open topics >>>>> > > I’ll volunteer to lead the discussion on the last one. Similar to my comment to Michael, I think it would be helpful to focus on the open items and frame a question or decision that is needed. Since this is a bit of a grab-bag, it doesn’t seem necessary to me to put those in the agenda although I’d be happy to include them if you can frame them now. --aaron --=_MailMate_4E022C0E-8CFE-4E2D-BB52-404B7E28FF86_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 2 Jul 2019, at 4:20, Philipp S. Tiesel wrote:

* ARCH & API open topics

I=E2=80= =99ll volunteer to lead the discussion on the last one.

Similar to my comment to Michael, I think it= would be helpful to focus on the open items and frame a question or deci= sion that is needed. Since this is a bit of a grab-bag, it doesn=E2=80=99= t seem necessary to me to put those in the agenda although I=E2=80=99d be= happy to include them if you can frame them now.

--aaron

--=_MailMate_4E022C0E-8CFE-4E2D-BB52-404B7E28FF86_=-- From nobody Tue Jul 2 12:26:57 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AE9120747 for ; Tue, 2 Jul 2019 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 zijd3wLlF5UG for ; Tue, 2 Jul 2019 12:26:49 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 8E9DD120703 for ; Tue, 2 Jul 2019 12:26:49 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x62JLpKd030600; Tue, 2 Jul 2019 12:26:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=UfI80+TelSEa6vXuRXezjRCzZLANe0fypFqNmgWvJkU=; b=R6Vp9JcSxlW6s9hGXswrCyvBpmV6JsxfaZgFXWxQeani88d2g25csi701ThkWcUHQLCm +Hg+A8tFQyiwjHvP6TlYK7bThmUa+SgA0i3pLLRlCOIGyMyHOHe/KRhPp02FzTqoh+XP PmgERRrEMAyBLuckFrcSUkuOk90rvWf3yK/9SDOLkQ36obXAaipfSJEoV+tkkPgpwwCC QwjyS65tVsQ2diCkLB1H1ildP7JgXo08hJUMD4Wwg/ZbCpVKZui+DQOc+fpG49rqx7QD f9lwBfyWwfPs4SJLpFRjlaBTMnADH3pCXluJt6BJyo2k0KH3Kvzl9yg6Y+p0ZlNry/3U Cw== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2te4nvqpnr-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 02 Jul 2019 12:26:45 -0700 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PU1006OE4O9RY80@ma1-mtap-s01.corp.apple.com>; Tue, 02 Jul 2019 12:26:33 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PU100F0045FU700@nwk-mmpp-sz11.apple.com>; Tue, 02 Jul 2019 12:26:33 -0700 (PDT) X-Va-A: X-Va-T-CD: 0325f276f41c42fd3b0ac081f7f3f808 X-Va-E-CD: e9fe70da591e25c3305d530a551289c9 X-Va-R-CD: d70fff4c6a20f6c192217937ca11ec98 X-Va-CD: 0 X-Va-ID: ab3c0485-9d45-458c-80c1-e4fa36746cfd X-V-A: X-V-T-CD: 0325f276f41c42fd3b0ac081f7f3f808 X-V-E-CD: e9fe70da591e25c3305d530a551289c9 X-V-R-CD: d70fff4c6a20f6c192217937ca11ec98 X-V-CD: 0 X-V-ID: 9b9e2ca4-54f3-446d-a788-e7453ae71a4b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-02_09:,, signatures=0 Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PU100FIA4O8JO70@nwk-mmpp-sz11.apple.com>; Tue, 02 Jul 2019 12:26:32 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <339C2B42-F0B8-40E1-9FF0-11824C855FF0@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_A34A1418-74E5-4C5D-B310-071B127F5C65" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3560.7\)) Date: Tue, 02 Jul 2019 12:26:32 -0700 In-reply-to: Cc: taps WG , Zaheduzzaman Sarker To: Aaron Falk References: X-Mailer: Apple Mail (2.3560.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-02_09:, , signatures=0 Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:26:56 -0000 --Apple-Mail=_A34A1418-74E5-4C5D-B310-071B127F5C65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 30, 2019, at 2:34 PM, Aaron Falk wrote: >=20 > What shall we use our face-time for in Montreal? >=20 > Some topics from our last interim = seem like good candidates for updates. Can we refine them with = specific to discuss (and ID someone to launch/lead the discussion)? >=20 > Framing I can give a brief update here on the status of framing, as we just = merged in the PR (https://github.com/ietf-tapswg/api-drafts/pull/323 = ). I=E2=80=99ll also = pair that with some sample framers implemented in Swift and C that we = added into our Network.framework API this year. Thanks, Tommy > Implementations > Parameters & Defaults > Yang model > Why do people resist specific protocol selection? (from Yang = discussion) > ARCH & API open topics > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_A34A1418-74E5-4C5D-B310-071B127F5C65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 30, 2019, at 2:34 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

What = shall we use our face-time for in Montreal?

Some topics from our last = interim seem like good candidates for updates. Can we refine them = with specific to discuss (and ID someone to launch/lead the = discussion)?

  • Framing
I = can give a brief update here on the status of framing, as we just merged = in the PR (https://github.com/ietf-tapswg/api-drafts/pull/323). = I=E2=80=99ll also pair that with some sample framers implemented in = Swift and C that we added into our Network.framework API this = year.

Thanks,
Tommy
  • Implementations
  • Parameters & Defaults
  • Yang model
  • Why do people resist specific protocol selection? (from = Yang discussion)
  • ARCH & API open topics

--aaron

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

= --Apple-Mail=_A34A1418-74E5-4C5D-B310-071B127F5C65-- From nobody Tue Jul 2 12:29:09 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8E7120168 for ; Tue, 2 Jul 2019 12:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NAMaoAFTHbwK for ; Tue, 2 Jul 2019 12:29:05 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 A7EB9120044 for ; Tue, 2 Jul 2019 12:29:05 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id i125so15292607qkd.6 for ; Tue, 02 Jul 2019 12:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KHNVpFf9DkAilb513n+zJZMNckogq+xKZJkGw0JOwZM=; b=kwjCeXNYdJUvIVfvzRaRZvMYMybgOw5tUFwiL6f4jA5bTEMfPbu0bndkOqnJ/M7snA LD/lwygyxOGEYln3qu3Rjp/Q9/W2S6eK300SK8NuxtvayH6VakdJkg+fe8bb3qL56xku payN+II5iCzxn2TREqo36vrCavePlDw8a743EmMHHpl2dJNpIE6LAAko6gjT9jY0Dh5O ZknEuJiYpbDIOY+f5EQY4/YDq2DkLsChAMXt4p5314MVeeqQcyouRBY9DQVwU2sKOtLj Bpgo6CseEh4qV8fwhojfK4D0YelO8bA8c12Jeka4j6nIb3ZYbhPRSfSu8oz9X23RFUoz 8Uwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KHNVpFf9DkAilb513n+zJZMNckogq+xKZJkGw0JOwZM=; b=LiLKuYvhW2BAoNl/iFOC8weMxDKIBRGxv30QO6uyiRHfAOBSjr0IyzQn6Z7cRsEWf9 Nl66Ca0tkMBftSo3tP5PBZCTyo0qYNc8uZ2eSfbg+XlbTbNC49S/bqivkzqfM04TIcir 7+HLfvlwGL4LM+DFS+nGxba1hyN+GpFcEvcVoP6o759rINgIgKiQ6VKLv5lwkkoRzzM6 wsj17aYL/+8bj9nTqiqA9cnHNvYSMk8xpXTqzCL/PMQ+tjU8RpX3CovYR7fUklgryuMf hrl0bIgwfHzU3Ue2egOS6EWU0JmHX7lZN/8LNNEJdQWSPhodNgtycTUJ/DBRt99CKLQx AxVw== X-Gm-Message-State: APjAAAVkp7qeUulQrU+vj1bkS5MdpswouZGwfCAI3fwiRNidQ7DX4MQl wVQWlH8DMq91zGT5+eMCOzelP8ev X-Google-Smtp-Source: APXvYqzp3v8eiWaA0RJwNk+OLxaVLkbIcuSHFUmfrVVYEF/XtaU2AiXkYExvG5kq5M08nfkaWdDYFg== X-Received: by 2002:a37:86c4:: with SMTP id i187mr27252348qkd.464.1562095744703; Tue, 02 Jul 2019 12:29:04 -0700 (PDT) Received: from [172.19.32.166] ([2001:4878:a000:3000:5d57:24cb:8a8e:b3b0]) by smtp.gmail.com with ESMTPSA id s8sm6356565qkg.64.2019.07.02.12.29.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jul 2019 12:29:03 -0700 (PDT) From: "Aaron Falk" To: "Tommy Pauly" Cc: "taps WG" , "Zaheduzzaman Sarker" Date: Tue, 02 Jul 2019 15:29:01 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: <10057A84-32E0-4DE7-B95F-767F5864930D@gmail.com> In-Reply-To: <339C2B42-F0B8-40E1-9FF0-11824C855FF0@apple.com> References: <339C2B42-F0B8-40E1-9FF0-11824C855FF0@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_970A9987-F994-4C45-B021-9325BC00EDF2_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:29:08 -0000 --=_MailMate_970A9987-F994-4C45-B021-9325BC00EDF2_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2 Jul 2019, at 15:26, Tommy Pauly wrote: >> * Framing >> > > I can give a brief update here on the status of framing, as we just > merged in the PR > (). I’ll also > pair that with some sample framers implemented in Swift and C that we > added into our Network.framework API this year. Sounds good. During the interim there seemed to be some confusion about when and how to apply framing. What would you say the open issues are? --aaron --=_MailMate_970A9987-F994-4C45-B021-9325BC00EDF2_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 2 Jul 2019, at 15:26, Tommy Pauly wrote:

* Framing

I can give a brief update here on the status= of framing, as we just merged in the PR (<https://github.c= om/ietf-tapswg/api-drafts/pull/323>). I=E2=80=99ll also pair that = with some sample framers implemented in Swift and C that we added into ou= r Network.framework API this year.

Sounds good. During the interim there seeme= d to be some confusion about when and how to apply framing. What would y= ou say the open issues are?

--aaron

--=_MailMate_970A9987-F994-4C45-B021-9325BC00EDF2_=-- From nobody Wed Jul 3 00:28:11 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BA31201CF for ; Wed, 3 Jul 2019 00:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l-TDXeMM9-yL for ; Wed, 3 Jul 2019 00:28:07 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 573A91201CE for ; Wed, 3 Jul 2019 00:28:07 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hiZgP-00049o-Ud; Wed, 03 Jul 2019 09:28:01 +0200 Received: from 1x-193.157.225.164.uio.no ([193.157.225.164]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hiZgP-000794-Ad; Wed, 03 Jul 2019 09:28:01 +0200 From: Michael Welzl Message-Id: <17ED49DD-AA88-4165-8635-279C06E8DD9A@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F6354B0-7ED6-4BEA-9CE1-0560BE4FE564" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 3 Jul 2019 09:27:59 +0200 In-Reply-To: Cc: "Philipp S. Tiesel" , Zaheduzzaman Sarker , "taps@ietf.org" To: Aaron Falk References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 193.157.225.164 is neither permitted nor denied by domain of ifi.uio.no) client-ip=193.157.225.164; envelope-from=michawe@ifi.uio.no; helo=1x-193.157.225.164.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BE45069D0349B0C48029DBA061CE5DF3CD84D9DD Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 07:28:10 -0000 --Apple-Mail=_6F6354B0-7ED6-4BEA-9CE1-0560BE4FE564 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 2, 2019, at 3:55 PM, Aaron Falk wrote: >=20 > On 2 Jul 2019, at 3:24, Michael Welzl wrote: >=20 > * Parameters & Defaults >=20 > I=E2=80=99d volunteer for this one too. >=20 > Michael- >=20 > Can you frame a question or decision we want to target for the = discussion? It would help me (& maybe others) keep the right focus. >=20 Yes: Should we specify rather than recommend default values? (github issue = #317) Cheers, Michael --Apple-Mail=_6F6354B0-7ED6-4BEA-9CE1-0560BE4FE564 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 2, 2019, at 3:55 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

On 2 = Jul 2019, at 3:24, Michael Welzl wrote:

* = Parameters & Defaults

I=E2=80=99= d volunteer for this one too.

Michael-

Can you frame a question or decision we want to target for = the discussion? It would help me (& maybe others) keep the right = focus.

Yes:

Should we specify rather than recommend default = values? (github issue #317)

Cheers,
Michael

= --Apple-Mail=_6F6354B0-7ED6-4BEA-9CE1-0560BE4FE564-- From nobody Wed Jul 3 08:29:05 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39821200CD for ; Wed, 3 Jul 2019 08:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yiTnwJ4a6-qo for ; Wed, 3 Jul 2019 08:29:01 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 BD65D120099 for ; Wed, 3 Jul 2019 08:29:00 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id y57so1671971qtk.4 for ; Wed, 03 Jul 2019 08:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=mn9pvzJOCku09FVsmk2JN5Q9J1be64ckXnJcKELDHIk=; b=kdpefKS9xZLjiOS4WYbMceReXmwfHtj0TZ1D+gZAmN85Ppr2eZzJk58NX2Fz2OqLXa itOQ8T/RhJmmihENyKPocluSd6aIJ0jjBpGd0HzyseIsEqNeCLEBGAEJtgqpHZE0TU1C jdhyyrJaZOZ7LRh+tnjQ1fZ7sA7BToF81bZfwmc9mJj8LxDo5qkwjuqV9f9kz0IOB2m5 AXcvFUpuM35V98dNEP0Gxoet33f6sMqcmfB/m9HHG1VQWL0gagMygn44dHTgNKf/Mj3h XKmE4MJjS4YlTGSqOGo2/mSoveofFN8xg4ny/xBF5MFrSboFfj9/F36guZ12Gl6XqoCd qBeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=mn9pvzJOCku09FVsmk2JN5Q9J1be64ckXnJcKELDHIk=; b=Wv9H38hAIhkaS7gyJUevt/d457QJX7UhsGcKzLQYdTLt32xDo1ERCaMsAvQyB0Qxk0 6Tr6cBrBYO1+ZofLAjoL+oeO9ylYhVrVfus8ycanaQ/aEqinWDNr66UTaf62/AnQVxht QDwgTsmwhIaKkYltDnotUYCnWyz8CMOtdqM/DnGUsH9vHktkfwnUPhug1olGy+IejhcD Wpayi524MUK9F1Pwl93b/gKzjvFtjTnUecpmkJDSpvFR6SBXI5SSB3/Pb0Kt0w4b8CbN OIyGQovTt31d0RM2P1zsFRCoIWrexr0OXMSlmHPpzLUhyV8iEALWAz/gEW3OtnZHxLDj Gcuw== X-Gm-Message-State: APjAAAX2WFPyGGT12tv0AqM3be5yPhboBmdXk7cd7CxsAGPHtdMC55Vc uiSER5UzeO4rnzAgw2mjkXEO4P/x X-Google-Smtp-Source: APXvYqyrZ8F+qdTXDKdqflh7F2PSaonvPKvFHddGapcPkN15+TpuYVJZP5r1ej9KqrbGXSiFyuU2vw== X-Received: by 2002:ac8:33f4:: with SMTP id d49mr31677605qtb.23.1562167739479; Wed, 03 Jul 2019 08:28:59 -0700 (PDT) Received: from [172.19.34.75] ([2001:4878:a000:3000:cdf8:aded:2499:9ca5]) by smtp.gmail.com with ESMTPSA id o33sm1176517qtk.67.2019.07.03.08.28.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 08:28:58 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 03 Jul 2019 11:28:57 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: <0F5AD5FF-E3DD-40B3-BD9B-7FDAAA2B23D2@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_DD9C54BA-769D-401E-B1FB-EF3AE2F55EA3_=" Archived-At: Subject: [Taps] Draft TAPS agenda X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 15:29:04 -0000 --=_MailMate_DD9C54BA-769D-401E-B1FB-EF3AE2F55EA3_= Content-Type: text/plain; markup=markdown Draft agenda below. Comments? Additions? Revisions? * Administrivia - Aaron & Zahed * Need a shepherd for draft-ietf-taps-transport-security * September interim? * Framing - Tommy Pauly - Status & examples * Parameters & Defaults - Michael Welzl - Should we specify rather than recommend default values? - https://github.com/ietf-tapswg/api-drafts/pull/317 * Property Profiles & Explicit Protocol Selection - Michael Welzl - https://github.com/ietf-tapswg/api-drafts/pull/328 - https://github.com/ietf-tapswg/api-drafts/pull/327 - Do we really (still) have any resistance to this idea? * ARCH & API open topics - Phillip * YANG Model - Jake? --=_MailMate_DD9C54BA-769D-401E-B1FB-EF3AE2F55EA3_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Draft agenda below. Comments? Additions? Revisions?

--=_MailMate_DD9C54BA-769D-401E-B1FB-EF3AE2F55EA3_=-- From nobody Wed Jul 3 08:39:24 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEE112021B for ; Wed, 3 Jul 2019 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eMlrZDSpmFBC for ; Wed, 3 Jul 2019 08:39:18 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.152.141]) by ietfa.amsl.com (Postfix) with ESMTP id ED37812065D for ; Wed, 3 Jul 2019 08:39:06 -0700 (PDT) Received: from [130.149.220.45] (esmeralda.net.t-labs.tu-berlin.de [130.149.220.45]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id B54FA2025A; Wed, 3 Jul 2019 17:39:02 +0200 (CEST) To: Aaron Falk References: Cc: taps@ietf.org, Zaheduzzaman Sarker From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= mQENBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAG0N1RoZXJlc2EgRW5naGFyZHQgKFJlc2VhcmNoKSA8dGhlcmVzYUBpbmV0LnR1LWJlcmxp bi5kZT6JAVUEEwEKAD8CGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEE7xG3phZ0Plgk 2BDpgz007xx2oPcFAlqgJ40FCRC919sACgkQgz007xx2oPfiHggAsCfbxjo+hlUYdEHmg/a8 RGDZfOqgmNrEWfWbB+H06A3izNpvfRbqdxhi64F8MXtKPxhPGBrB9H3/E3WfsOHc9tJe+19Y GkHBOMhbXmp/o92BVHw6q/l5bcvLO8sgcemqrh8GYZgZrho7F3UTIpb8dkCjt+jCAbsAAFzR 4ziEAqw+2KVmZw5t2/1KygnPsgMz70JGAfq2jTt+NR9DxMizXNa7pZjdSmqhBjCbTlzPnn0C rAkK1/IXSM3Y704asyQrHD2pNxXQyXEe/K5uN6w80gHdyK4bBWVIVZULaRngcKrcX9gillK+ 8zs3nr8eDgsq1cURk8nmkIkFm++6PgO8lLkBDQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149J BtI8Oh4Ywktc1ExLuZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjN d6uFEdFNLtf+2/QqjVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1W mMcXMQX+Npwv9plEJOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5 w8p8OYN41q0vqefBaMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsg Xurujk0OvEFhhkQonVRXUYmLTM0EXQARAQABiQE8BBgBCgAmAhsMFiEE7xG3phZ0Plgk2BDp gz007xx2oPcFAlqgJ40FCRC91+cACgkQgz007xx2oPfRiwf9H9BNITXs2wLFjrej7wV8XoCO 5z3iN4TTeKz/2XA0CQr7OjkqbEkllnlGvywJOsCsrficHGL+eXk7tWXf8LMm0QOA1pEgA7oN ynGp7O65WG4kN93j9PFA/0k+nkqWtztuw3KBApSqytEBaaqwdeOG5mCWYawAjpSII2Bo+r9I ghH9miMgAsT044OPj3QMKSZAzTEzHekEuYa/AZqfFxLFE27WdDZpEqzvQ3uaIDbYx5HbT+xt LJJczpENdiTwyvHN4PwNSfWacyv1TA7WM2Qusgs5OVRwaJIQypvoGRl0YawaHHgxpLgs/x3r 2IqmnTXThea+Wx/iYSrPFFv4rEbS/w== Message-ID: Date: Wed, 3 Jul 2019 17:39:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3E4A7C61BFB2E961E2E786A4" Content-Language: en-US Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 15:39:23 -0000 This is a multi-part message in MIME format. --------------3E4A7C61BFB2E961E2E786A4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, On 30.06.19 23:34, Aaron Falk wrote: > > What shall we use our face-time for in Montreal? > > Some topics from our last interim > > seem like good candidates for updates. Can we refine them with > specific to discuss (and ID someone to launch/lead the discussion)? > > * Framing > * Implementations > * Parameters & Defaults > * Yang model > I can lead a discussion on the Yang model, as unfortunately Jake has a conflict with the MOPS BoF. Specifics: Benefits and pain points of using Yang within our PyTAPS implementation Suggested changes to the model we come up with during the hackathon Best, Theresa --------------3E4A7C61BFB2E961E2E786A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi,

On 30.06.19 23:34, Aaron Falk wrote:

What shall we use our face-time for in Montreal?

Some topics from our last interim seem like good candidates for updates. Can we refine them with specific to discuss (and ID someone to launch/lead the discussion)?

  • Framing
  • Implementations
  • Parameters & Defaults
  • Yang model

I can lead a discussion on the Yang model, as unfortunately Jake has a conflict with the MOPS BoF.

Specifics:

Benefits and pain points of using Yang within our PyTAPS implementation

Suggested changes to the model we come up with during the hackathon


Best,
Theresa

--------------3E4A7C61BFB2E961E2E786A4-- From nobody Wed Jul 3 08:40:16 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD3912065E for ; Wed, 3 Jul 2019 08:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zbCxilMntys6 for ; Wed, 3 Jul 2019 08:40:08 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 6E17612064F for ; Wed, 3 Jul 2019 08:40:08 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id m14so3082606qka.10 for ; Wed, 03 Jul 2019 08:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:embedded-html; bh=A1A3yq1bIWmKy3KUfLR4pPKr7VJB6HDfpRE1lwJJXvk=; b=qIUJEhWeknJqP5RccIXekrJ/4PVDFbq3fjk5sBH2RO+HKLUlyi6Zh6t8ydTmy6DTpy eDydyFNSrbWKIEezmi7Xd4A0e+9H/mLTF/FBReaD1f0ky7jsfVB9x8EfMIHQso9SswYW +kg17C08jFU+rhfnNwQ2poJLuMymdr2hNm2AwwRsDsUijF8jj1ZYbJGezbbbiIfPm1J9 60K/aTo5wIxG645p0vPavk7IXeP1Aj04j1wYKigLTXYa//bx2S/LB7/c326oopBLlmgn l02ieTyU51OuoXhjNmWsSv4fe4EQWrSB+/4i/L2B/WvBC6S13E+QYQXJCPryBa7qK7DM 4dTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:embedded-html; bh=A1A3yq1bIWmKy3KUfLR4pPKr7VJB6HDfpRE1lwJJXvk=; b=VSRABux4HUHYe34L8niIeMaNotNnAJx6/bqC/tSuLgG8nqIFc3Ul2owrufGk35syfq N2/YpKgp5/OhQstpGwOxnHpd2QjQKspKWr3dnQfKRu5CIRNj9Tk0vmFJ5ps+9SHHNdTt aJAxJGyd9otIZY4vwepAfPYxPlk8650DLTyts1coFNkcTswqn5h5NHkgS/Yg7pjGACeB NTbzTxTDLKeU1P4l9yhZpoLckqPxfY7gDq/2gt6Upwy7Z9F8cXciICMh1ISpvhvXfuHv /0Asrri8EJl9JdtpRqwAk2fM+gAtCjCDETWjnJxzsV/6Xlmx5rF02ZpTPOwX6wzCaoeo S1EQ== X-Gm-Message-State: APjAAAW1zSgs2I9/erCH1+PY9GjqWT924/wN8PBmabtMwQbDMkiSqQm1 zvEf7yhuwIq+fuYEP2Btxqg= X-Google-Smtp-Source: APXvYqxfmQkTrWLMYJxIGQRSk7npwK6SO5a2iPjLb842iPra6psOb9MHKctBqeJLoB3M2GA5Dtp/Cg== X-Received: by 2002:a37:2750:: with SMTP id n77mr32436195qkn.370.1562168407500; Wed, 03 Jul 2019 08:40:07 -0700 (PDT) Received: from [172.19.34.75] ([2001:4878:a000:3000:cdf8:aded:2499:9ca5]) by smtp.gmail.com with ESMTPSA id g124sm1055547qke.115.2019.07.03.08.40.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 08:40:06 -0700 (PDT) From: "Aaron Falk" To: "Theresa Enghardt" Cc: taps@ietf.org, "Zaheduzzaman Sarker" Date: Wed, 03 Jul 2019 11:40:05 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: <4520ECF1-BB91-4429-9564-1AD996BD6449@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_12A2BBDC-A0E5-4D12-A5BD-CB7AED3178B7_=" Embedded-HTML: [{"HTML":[384, 1606], "plain":[70, 737], "uuid":"B81ED7FD-35CD-4783-A245-D875524439DC"}] Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 15:40:15 -0000 --=_MailMate_12A2BBDC-A0E5-4D12-A5BD-CB7AED3178B7_= Content-Type: text/plain; format=flowed Thanks, Theresa! On 3 Jul 2019, at 11:39, Theresa Enghardt wrote: > Hi, > > On 30.06.19 23:34, Aaron Falk wrote: >> >> What shall we use our face-time for in Montreal? >> >> Some topics from our last interim >> >> seem like good candidates for updates. Can we refine them with >> specific to discuss (and ID someone to launch/lead the discussion)? >> >> * Framing >> * Implementations >> * Parameters & Defaults >> * Yang model >> > I can lead a discussion on the Yang model, as unfortunately Jake has a > conflict with the MOPS BoF. > > Specifics: > > Benefits and pain points of using Yang within our PyTAPS > implementation > > Suggested changes to the model we come up with during the hackathon > > > Best, > Theresa --=_MailMate_12A2BBDC-A0E5-4D12-A5BD-CB7AED3178B7_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Thanks, Theresa!

On 3 Jul 2019, at 11:39, Theresa Enghardt wrote:

Hi,

On 30.06.19 23:34, Aaron Falk wrote:

What shall we use our face-time for in Montreal= ?

Some topics fro= m our last interim seem like good candidates for updates. Can we refine them with specific to discuss (and ID someone to launch/lead the discussion)?

  • Framing
  • Implementations
  • Parameters & Defaults
  • Yang model

I can lead a discussion on the Yang model, as unfortunately Jake has a conflict with the MOPS BoF.

Specifics:

Benefits and pain points of using Yang within our PyTAPS implementation

Suggested changes to the model we come up with during the hackathon


Best,
Theresa

--=_MailMate_12A2BBDC-A0E5-4D12-A5BD-CB7AED3178B7_=-- From nobody Wed Jul 3 08:49:49 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3747120382 for ; Wed, 3 Jul 2019 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bGoAebEgtnwY for ; Wed, 3 Jul 2019 08:49:46 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 CFC93120380 for ; Wed, 3 Jul 2019 08:49:45 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id d23so4037571qto.2 for ; Wed, 03 Jul 2019 08:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=LqCHCNrj+gwGshNb3VNNpRAF9ajNMszFM38GdHe45RE=; b=LGsuELBb6+mWGXmtKEWTNGN4+mFd57FVeth5GEBoaRhlvFyCAp5D0fzz7rtvV84EIX KTE1/b8wr9OF0qe17pjCFIiiVTnTIHjvqLjUC/O6a7PGMEG/cN8IpMRwo/9GAAQVbe5w mNijf1JbqaGLWmLEq3yWbpbHT83KXVokWkUEkmY7VhZJ+6njPelWq12bb2OKGhP2JBAg dGa/UsOTIssQ9ERwHvIJkmGes7LDxIWBUW6yCofbf1WOcfmvqtqXk7E9K6HK+Xak+nVP 6rfTMQFx8CEFRX+MIFwmycCYrGb170GqF4rLnSWM5H18EuTNb9Tr7apZt91X9TAWkiwV P7tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=LqCHCNrj+gwGshNb3VNNpRAF9ajNMszFM38GdHe45RE=; b=mIl8/3PCydEneEkkDQVk4JNHd/zEJ8+FDe3VMv7N31eDZLfwCxt2tYqPzWsbTK7FF2 JZBhw/4emufGjkH9cegzDqnyUa4oN5YGloPgZ3lDlim7O5uYD84BtXFVyRyrsk37baSH 7zgLmgo6r1tmQdoL6OUZmXo8tr//zx7+9u26k3EDuoS1x98UvyM+c1qMRGqsqSH0HdCd /F1gmc/E2kdmgEHk2pXpNoNIa9HDRyh39aocflUh17IJ/9wbjhJQM1h4dl6ltuFK9DY8 jj+3FI367Bx2g4/q5R4RhrAVCX/uok1leHlk9b0va6Df291O5seakqzyRb+650Dwp+Rv sLEg== X-Gm-Message-State: APjAAAUbcYJ6G3Ji28wuHcTTTrS6+WNiGOfpuUxfv97uMPRCQNrnzddE ZIFWETE3GHAWackgjMLfBRngHIoz X-Google-Smtp-Source: APXvYqzEylg7lM2rlOC6n9NG/ZVvygU1LBwZZD2yuPgBiogfDemybQDXPfJnRz5XwRLVBWlAeSYVhg== X-Received: by 2002:a0c:9332:: with SMTP id d47mr32213337qvd.222.1562168984448; Wed, 03 Jul 2019 08:49:44 -0700 (PDT) Received: from [172.19.34.75] ([2001:4878:a000:3000:cdf8:aded:2499:9ca5]) by smtp.gmail.com with ESMTPSA id j2sm1160359qtb.89.2019.07.03.08.49.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 08:49:43 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 03 Jul 2019 11:49:41 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: <8C77CDF7-2646-4EBC-8974-AAFA0AEBCE6F@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_F65F3D68-AEDE-4F03-A45C-207ED3AFE11D_=" Archived-At: Subject: [Taps] TAPS agenda for IETF-105 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 15:49:48 -0000 --=_MailMate_F65F3D68-AEDE-4F03-A45C-207ED3AFE11D_= Content-Type: text/plain; markup=markdown Transport Services (TAPS) Working Group 13:30-15:30 Monday Afternoon session I Room: Van Horne * Administrivia - Aaron & Zahed (5m) * Need a shepherd for draft-ietf-taps-transport-security * September interim? * Framing - Tommy Pauly (15m) * Status & examples * Parameters & Defaults - Michael Welzl (15m) * Should we specify rather than recommend default values? * https://github.com/ietf-tapswg/api-drafts/pull/317 * Property Profiles & Explicit Protocol Selection - Michael Welzl (15m) * https://github.com/ietf-tapswg/api-drafts/pull/328 * https://github.com/ietf-tapswg/api-drafts/pull/327 * Do we really (still) have any resistance to this idea? * ARCH & API open topics - Philipp Tiesel (15m) * YANG Model - Theresa Enghardt (15m) * Benefits and pain points of using Yang within our PyTAPS implementation * Suggested changes to the model we come up with during the hackathon --=_MailMate_F65F3D68-AEDE-4F03-A45C-207ED3AFE11D_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Transport Services (TAPS) Working Group
13:30-15:30 Monday Afternoon session I
Room: Van Horne

  • Administrivia - Aaron & Zahed (5m)
    • Need a shepherd for draft-ietf-taps-transport-security
    • September interim?
  • Framing - Tommy Pauly (15m)
    • Status & examples
  • Parameters & Defaults - Michael Welzl (15m)
  • Property Profiles & Explicit Protocol Selection - Michael Welzl (= 15m)
  • ARCH & API open topics - Philipp Tiesel (15m)
  • YANG Model - Theresa Enghardt (15m)
    • Benefits and pain points of using Yang within our PyTAPS implementati= on
    • Suggested changes to the model we come up with during the hackathon
--=_MailMate_F65F3D68-AEDE-4F03-A45C-207ED3AFE11D_=-- From nobody Wed Jul 3 10:57:14 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0D12038E for ; Wed, 3 Jul 2019 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 5YckzIpbiP8K for ; Wed, 3 Jul 2019 10:57:06 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9625B1202F9 for ; Wed, 3 Jul 2019 10:57:06 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x63Hv1KE011960; Wed, 3 Jul 2019 18:57:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=j+yT2MpmzLLkTC4T2dE55eCfuxrtrlCLA7E8fq9o3eM=; b=BzmXW2oxY1rNKOiprFR8e/NX57cB5ZP3eykfCK0mBSdmcWrzQ58M8iqKl42VPWcxrfVq NabsFdMwczUSiOsfn3KsLCXwnS9/mseXctgwx4AxeoW1q8sqTUAWvK0roWEW4GsaKfA0 NvGQjLOnsIVcK20KwdMXKfzMjBKTSb5iX+mDc5uy9uwpk4omdW0JCNVY2xWWA/dxGLib Gq2IxciHC4djSDGIs59jjZ8QoQfbgJbLkbxh7iv1xSprwYk8pIm9OqXGHjbXv5BiVPv4 GmXeJmVoOVo0MJu0qDQQbPnGc2xYmnP7VStrvEi8J9L+1DIrM51fzq6EEjzAkJarghp9 nw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2tg66vdpax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Jul 2019 18:57:01 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x63Hkr2e012271; Wed, 3 Jul 2019 13:56:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2te3awu5rd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Jul 2019 13:56:59 -0400 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 3 Jul 2019 12:56:58 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.004; Wed, 3 Jul 2019 12:56:58 -0500 From: "Holland, Jake" To: Aaron Falk , Theresa Enghardt CC: Zaheduzzaman Sarker , "taps@ietf.org" Thread-Topic: [Taps] call for TAPS agenda items Thread-Index: AQHVL4uYz3mPnd5jh0iQFrkLw8IRvaa5X5sAgAAAS4D//7DkgA== Date: Wed, 3 Jul 2019 17:56:58 +0000 Message-ID: <8072BA1D-C0C9-43EC-AAB7-1613FA8EB20B@akamai.com> References: <4520ECF1-BB91-4429-9564-1AD996BD6449@gmail.com> In-Reply-To: <4520ECF1-BB91-4429-9564-1AD996BD6449@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.213] Content-Type: multipart/alternative; boundary="_000_8072BA1DC0C943ECAAB71613FA8EB20Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907030216 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-03_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907030218 Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 17:57:11 -0000 --_000_8072BA1DC0C943ECAAB71613FA8EB20Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFRoZXJlc2EhDQoNCk9yZGluYXJpbHkgSeKAmWQgaGF2ZSBoYXBwaWx5IHZvbHVudGVl cmVkIHRvIGxlYWQgdGhlIHlhbmcgZGlzY3Vzc2lvbiwgYW5kIEkgYXBwcmVjaWF0ZSB5b3UgY292 ZXJpbmcgbWUuICBJ4oCZbGwgYmUgYXQgdGhlIHRhcHMgdGFibGUgZm9yIHRoZSBoYWNrYXRob24s IGFuZCBob3BlZnVsbHkgaWYgSeKAmXZlIGdvdCBhbnl0aGluZyB1c2VmdWwgdG8gYWRkIEkgY2Fu IHBhc3MgaXQgYWxvbmcgdGhlcmUgb3Igb24gdGhlIGxpc3QuDQoNCknigJltIGFubm95ZWQgdG8g aGF2ZSB0byBtaXNzIHRhcHMsIGJ1dCBtZWRpYSBvcHMgaXMgbGlmZSBmb3IgdGhlIHBhcnQgb2Yg bXkgY29tcGFueSB0aGF0IGVtcGxveXMgbWUsIHNvIEkgbmVlZCB0byBzdXBwb3J0IGEgdmVudWUg dG8gZGlzY3VzcyBpdCBhcyBhIGhpZ2hlciBwcmlvcml0eSwgZXZlbiB0aG91Z2ggSSB3b3VsZCBk ZWFybHkgbG92ZSB0byBzZWUgYSBiZXR0ZXIgc29ja2V0IEFQSSBzdGFuZGFyZGl6ZWQgYW5kIEkg bG92ZSB3aGF0IHRhcHMgaXMgZG9pbmcgdG8gbWFrZSB0aGF0IGhhcHBlbi4NCg0KU28gcGxlYXNl IGFjY2VwdCBteSByZWdyZXRzLCBldmVyeW9uZSwgYW5kIEnigJlsbCB0cnkgdG8gYmUgdGhlcmUg bmV4dCB0aW1lLg0KDQpCZXN0LA0KSmFrZQ0KDQpGcm9tOiBBYXJvbiBGYWxrIDxhYXJvbi5mYWxr QGdtYWlsLmNvbT4NCkRhdGU6IDIwMTktMDctMDMgYXQgMDg6NDANClRvOiBUaGVyZXNhIEVuZ2hh cmR0IDx0aGVyZXNhQGluZXQudHUtYmVybGluLmRlPg0KQ2M6IFphaGVkdXp6YW1hbiBTYXJrZXIg PHphaGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tPiwgInRhcHNAaWV0Zi5vcmciIDx0YXBz QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUYXBzXSBjYWxsIGZvciBUQVBTIGFnZW5kYSBpdGVt cw0KDQoNClRoYW5rcywgVGhlcmVzYSENCg0KT24gMyBKdWwgMjAxOSwgYXQgMTE6MzksIFRoZXJl c2EgRW5naGFyZHQgd3JvdGU6DQpIaSwNCg0KT24gMzAuMDYuMTkgMjM6MzQsIEFhcm9uIEZhbGsg d3JvdGU6DQoNCldoYXQgc2hhbGwgd2UgdXNlIG91ciBmYWNlLXRpbWUgZm9yIGluIE1vbnRyZWFs Pw0KDQpTb21lIHRvcGljcyBmcm9tIG91ciBsYXN0IGludGVyaW08aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19ldGhlcnBhZC5pZXRmLm9yZ19wX25v dHMtMkRpbnRlcmltLTJEMjAxOS0yRHRhcHMtMkQwMi0zRnVzZU1vbm9zcGFjZUZvbnQtM0R0cnVl JmQ9RHdNRkFnJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPWJxbkZST2l2RG9fNGlGOFozUjRE eU5XS2JiTWVYcjBMT2dMbkVsVDFPb2smbT1lVFJob1J2a2NZcnRWZ3pOVC1qMGE5V1NPdW42NHYx MUNEOGc3UzR3dEFZJnM9dGtIYWhvQzJ4Q3hEa1BTQTctMU1CYUlSaE55Vk42N0lmWmpudmJPQ3hq MCZlPT4gc2VlbSBsaWtlIGdvb2QgY2FuZGlkYXRlcyBmb3IgdXBkYXRlcy4gQ2FuIHdlIHJlZmlu ZSB0aGVtIHdpdGggc3BlY2lmaWMgdG8gZGlzY3VzcyAoYW5kIElEIHNvbWVvbmUgdG8gbGF1bmNo L2xlYWQgdGhlIGRpc2N1c3Npb24pPw0KwrcgICAgICAgICBGcmFtaW5nDQrCtyAgICAgICAgIElt cGxlbWVudGF0aW9ucw0KwrcgICAgICAgICBQYXJhbWV0ZXJzICYgRGVmYXVsdHMNCsK3ICAgICAg ICAgWWFuZyBtb2RlbA0KDQpJIGNhbiBsZWFkIGEgZGlzY3Vzc2lvbiBvbiB0aGUgWWFuZyBtb2Rl bCwgYXMgdW5mb3J0dW5hdGVseSBKYWtlIGhhcyBhIGNvbmZsaWN0IHdpdGggdGhlIE1PUFMgQm9G Lg0KDQpTcGVjaWZpY3M6DQoNCkJlbmVmaXRzIGFuZCBwYWluIHBvaW50cyBvZiB1c2luZyBZYW5n IHdpdGhpbiBvdXIgUHlUQVBTIGltcGxlbWVudGF0aW9uDQoNClN1Z2dlc3RlZCBjaGFuZ2VzIHRv IHRoZSBtb2RlbCB3ZSBjb21lIHVwIHdpdGggZHVyaW5nIHRoZSBoYWNrYXRob24NCg0KDQoNCkJl c3QsDQpUaGVyZXNhDQo= --_000_8072BA1DC0C943ECAAB71613FA8EB20Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <44B362DDA4C86F4F9A7F93D32D934F2A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBp bjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0K CWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRp b246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU1NTg5NDk4 NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0ODUyOTA3MDA7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MgVGhlcmVzYSE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3JkaW5hcmlseSBJ4oCZZCBoYXZl IGhhcHBpbHkgdm9sdW50ZWVyZWQgdG8gbGVhZCB0aGUgeWFuZyBkaXNjdXNzaW9uLCBhbmQgSSBh cHByZWNpYXRlIHlvdSBjb3ZlcmluZyBtZS4mbmJzcDsgSeKAmWxsIGJlIGF0IHRoZSB0YXBzIHRh YmxlIGZvciB0aGUgaGFja2F0aG9uLCBhbmQgaG9wZWZ1bGx5IGlmIEnigJl2ZSBnb3QgYW55dGhp bmcgdXNlZnVsIHRvIGFkZCBJIGNhbiBwYXNzIGl0IGFsb25nIHRoZXJlIG9yIG9uIHRoZSBsaXN0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBhbm5veWVkIHRvIGhhdmUgdG8gbWlzcyB0 YXBzLCBidXQgbWVkaWEgb3BzIGlzIGxpZmUgZm9yIHRoZSBwYXJ0IG9mIG15IGNvbXBhbnkgdGhh dCBlbXBsb3lzIG1lLCBzbyBJIG5lZWQgdG8gc3VwcG9ydCBhIHZlbnVlIHRvIGRpc2N1c3MgaXQg YXMgYSBoaWdoZXIgcHJpb3JpdHksIGV2ZW4gdGhvdWdoIEkgd291bGQgZGVhcmx5IGxvdmUgdG8g c2VlIGEgYmV0dGVyIHNvY2tldCBBUEkgc3RhbmRhcmRpemVkDQogYW5kIEkgbG92ZSB3aGF0IHRh cHMgaXMgZG9pbmcgdG8gbWFrZSB0aGF0IGhhcHBlbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U28gcGxlYXNlIGFjY2VwdCBteSByZWdyZXRzLCBldmVyeW9uZSwgYW5kIEnigJlsbCB0cnkgdG8g YmUgdGhlcmUgbmV4dCB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5BYXJvbiBGYWxr ICZsdDthYXJvbi5mYWxrQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+MjAxOS0wNy0w MyBhdCAwODo0MDxicj4NCjxiPlRvOiA8L2I+VGhlcmVzYSBFbmdoYXJkdCAmbHQ7dGhlcmVzYUBp bmV0LnR1LWJlcmxpbi5kZSZndDs8YnI+DQo8Yj5DYzogPC9iPlphaGVkdXp6YW1hbiBTYXJrZXIg Jmx0O3phaGVkdXp6YW1hbi5zYXJrZXJAZXJpY3Nzb24uY29tJmd0OywgJnF1b3Q7dGFwc0BpZXRm Lm9yZyZxdW90OyAmbHQ7dGFwc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtUYXBzXSBjYWxsIGZvciBUQVBTIGFnZW5kYSBpdGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcywgVGhlcmVzYSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDMgSnVsIDIwMTksIGF0IDExOjM5LCBUaGVy ZXNhIEVuZ2hhcmR0IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3Nzc3NzcgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDowaW47bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8ZGl2IGlkPSJCODFFRDdGRC0zNUNELTQ3ODMtQTI0 NS1EODc1NTI0NDM5REMiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3Nzc3NzciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3Ij5PbiAzMC4wNi4xOSAyMzozNCwgQWFyb24gRmFsayB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Izc3Nzc3NyI+V2hhdCBzaGFsbCB3ZSB1c2Ugb3VyIGZhY2UtdGltZSBmb3IgaW4g TW9udHJlYWw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPlNvbWUNCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZXRoZXJwYWQuaWV0Zi5vcmdfcF9ub3RzLTJEaW50 ZXJpbS0yRDIwMTktMkR0YXBzLTJEMDItM0Z1c2VNb25vc3BhY2VGb250LTNEdHJ1ZSZhbXA7ZD1E d01GQWcmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1icW5GUk9pdkRvXzRpRjha M1I0RHlOV0tiYk1lWHIwTE9nTG5FbFQxT29rJmFtcDttPWVUUmhvUnZrY1lydFZnek5ULWowYTlX U091bjY0djExQ0Q4ZzdTNHd0QVkmYW1wO3M9dGtIYWhvQzJ4Q3hEa1BTQTctMU1CYUlSaE55Vk42 N0lmWmpudmJPQ3hqMCZhbXA7ZT0iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMzOTgzQzQiPnRvcGlj cyBmcm9tIG91ciBsYXN0IGludGVyaW08L3NwYW4+PC9hPiBzZWVtIGxpa2UgZ29vZCBjYW5kaWRh dGVzIGZvciB1cGRhdGVzLiBDYW4gd2UgcmVmaW5lIHRoZW0gd2l0aCBzcGVjaWZpYyB0byBkaXNj dXNzIChhbmQgSUQgc29tZW9uZSB0byBsYXVuY2gvbGVhZCB0aGUgZGlzY3Vzc2lvbik/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1i b2w7Y29sb3I6Izc3Nzc3NyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkZyYW1pbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiM3Nzc3Nzci PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3Ij5JbXBsZW1lbnRhdGlvbnMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiM3Nzc3NzciPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5Q YXJhbWV0ZXJzICZhbXA7IERlZmF1bHRzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojNzc3Nzc3Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+ WWFuZyBtb2RlbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5JIGNhbiBs ZWFkIGEgZGlzY3Vzc2lvbiBvbiB0aGUgWWFuZyBtb2RlbCwgYXMgdW5mb3J0dW5hdGVseSBKYWtl IGhhcyBhIGNvbmZsaWN0IHdpdGggdGhlIE1PUFMgQm9GLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5TcGVjaWZpY3M6DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3 NyI+QmVuZWZpdHMgYW5kIHBhaW4gcG9pbnRzIG9mIHVzaW5nIFlhbmcgd2l0aGluIG91ciBQeVRB UFMgaW1wbGVtZW50YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+U3VnZ2VzdGVkIGNoYW5nZXMgdG8gdGhlIG1vZGVsIHdl IGNvbWUgdXAgd2l0aCBkdXJpbmcgdGhlIGhhY2thdGhvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+QmVz dCw8YnI+DQpUaGVyZXNhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8072BA1DC0C943ECAAB71613FA8EB20Bakamaicom_-- From nobody Fri Jul 5 01:02:23 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C10012008D for ; Fri, 5 Jul 2019 01:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 J3oABBh81HvM for ; Fri, 5 Jul 2019 01:02:18 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 3068A120044 for ; Fri, 5 Jul 2019 01:02:17 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1hjJ8Y-0000va-PX for taps@ietf.org; Fri, 05 Jul 2019 08:00:06 +0000 Content-Type: multipart/alternative; boundary="===============1511430570921264507==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 05 Jul 2019 08:00:06 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 08:02:21 -0000 --===============1511430570921264507== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+2/-7/=F0=9F=92=AC11) 2 issues created: - Should "send" return a MessageContex? (by philsbln) https://github.com/ietf-tapswg/api-drafts/issues/336 [API] [discuss] = - Consider message send API that takes padding policy as input (by chris-= wood) https://github.com/ietf-tapswg/api-drafts/issues/334 = 8 issues received 11 new comments: - #334 Consider message send API that takes padding policy as input (3 by= philsbln, gorryfair, chris-wood) https://github.com/ietf-tapswg/api-drafts/issues/334 = - #315 Default for Control checksum coverage (2 by britram, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/315 [API] [ready for t= ext] = - #257 Not all Events are shown in the diagram (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/257 [Architecture] = - #266 Do we want to add Connection Pools to the Architecture / API (1 by= philsbln) https://github.com/ietf-tapswg/api-drafts/issues/266 [API] [Architectur= e] [discuss] = - #331 9.1 defaults (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/331 [API] = - #304 Clarify mapping of Connection to multiple flows (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/issues/304 [Architecture] = - #305 Protocol stacks that are not equivalent (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/issues/305 [Architecture] = - #316 Section 4.2.1 - Transport Properties (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/316 [API] = 7 issues closed: - 9.1 defaults https://github.com/ietf-tapswg/api-drafts/issues/331 [API] = - Section 4.2.1 - Transport Properties https://github.com/ietf-tapswg/ap= i-drafts/issues/316 [API] = - Default for Control checksum coverage https://github.com/ietf-tapswg/ap= i-drafts/issues/315 [API] [ready for text] = - Default for Use 0-RTT session establishment https://github.com/ietf-tap= swg/api-drafts/issues/314 [API] [discuss] = - msgref is never specified https://github.com/ietf-tapswg/api-drafts/is= sues/310 [API] = - Clarify mapping of Connection to multiple flows https://github.com/ietf= -tapswg/api-drafts/issues/304 [Architecture] = - More editorial author comments on API https://github.com/ietf-tapswg/ap= i-drafts/issues/318 [API] = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-3/=F0=9F=92=AC6) 1 pull requests submitted: - Various minor issues - closes #314, #315 #316 and #331 (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/335 = 4 pull requests received 6 new comments: - #327 Adding a way of forcing the use of specific protocols (2 by philsb= ln, britram) https://github.com/ietf-tapswg/api-drafts/pull/327 [API] [discuss] = - #321 Merge Message References and Message Contexts and enable their use= for Requests/Response protocols (2 by mwelzl, tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/321 [API] = - #323 Add details to the Framer Interface (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/323 = - #328 Add Transport Property Profiles (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/pull/328 [API] [discuss] = 3 pull requests merged: - Various minor issues - closes #314, #315 #316 and #331 https://github.com/ietf-tapswg/api-drafts/pull/335 = - Merge Message References and Message Contexts and enable their use for = Requests/Response protocols https://github.com/ietf-tapswg/api-drafts/pull/321 [API] = - Add details to the Framer Interface https://github.com/ietf-tapswg/api-drafts/pull/323 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============1511430570921264507== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday July 05, 2019

Issues

ietf-tapswg/api-drafts (+2/-7/=F0=9F=92=AC11)

2 issues created:

8 issues received 11 new comments:

7 issues closed:

Pull requests

ietf-tapswg/api-drafts (+1/-3/=F0=9F=92=AC6)

1 pull requests submitted:

4 pull requests received 6 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============1511430570921264507==-- From nobody Mon Jul 8 01:48:38 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE4C120183 for ; Mon, 8 Jul 2019 01:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Eyjcbt4T6JyY for ; Mon, 8 Jul 2019 01:48:23 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 2099412017F for ; Mon, 8 Jul 2019 01:48:19 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x688mEb6024359 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jul 2019 10:48:14 +0200 Received: from client-141-23-203-17.wlan.tu-berlin.de ([141.23.203.17]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hkPHq-00085x-K1; Mon, 08 Jul 2019 10:46:14 +0200 From: "Philipp S. Tiesel" Message-Id: <55452E22-097F-497A-A381-E1C1F71412AB@in-panik.de> Content-Type: multipart/signed; boundary="Apple-Mail=_4B9F0321-05F4-4161-919A-D10C3D5B1B3B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 8 Jul 2019 10:48:13 +0200 In-Reply-To: <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> Cc: Aaron Falk , Zaheduzzaman Sarker , "taps@ietf.org" To: Michael Welzl References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 08:48:37 -0000 --Apple-Mail=_4B9F0321-05F4-4161-919A-D10C3D5B1B3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2. Jul 2019, at 09:24, Michael Welzl wrote: >=20 > Hi again, >=20 >> On Jul 1, 2019, at 4:17 PM, Philipp S. Tiesel = wrote: >>=20 >>=20 >>=20 >>> On 30. Jun 2019, at 23:44, Michael Welzl wrote: >>>=20 >>> Hi, >>>=20 >>> Sounds like a good start! >>>=20 >>> About this: >>>=20 >>>> On Jun 30, 2019, at 11:34 PM, Aaron Falk = wrote: >>>>=20 >>>> What shall we use our face-time for in Montreal? >>>>=20 >>>> Some topics from our last interim seem like good candidates for = updates. Can we refine them with specific to discuss (and ID someone to = launch/lead the discussion)? >>>>=20 >>>> =E2=80=A2 Framing >>>> =E2=80=A2 Implementations >>>> =E2=80=A2 Parameters & Defaults > I=E2=80=99d volunteer for this one too. >=20 >=20 >>>> =E2=80=A2 Yang model >>>> =E2=80=A2 Why do people resist specific protocol selection? = (from Yang discussion) >>> I=E2=80=99d volunteer to lead this discussion, but I wonder: is this = really worth the time - as in: do we really (still) have any resistance = to this idea? >>=20 >> Looks like=E2=80=A6 but I guess we have two different topics here: >> - Property Profiles (shortcuts for common sets of properties) >> - Explicit Protocol Selection >>=20 >> I originally insisted to keep them separate, as I really like to have = the first one and feared the discussion for the second one. As I opened = PRs with proposals for both of them = (https://github.com/ietf-tapswg/api-drafts/pull/328 and = https://github.com/ietf-tapswg/api-drafts/pull/327), I got no fire and = fury, but only constructive feedback. >> So I agree with Michael that we may really have a short discussion on = whether to add these features. >=20 > Ok, it sounds to me like this slot should be called =E2=80=9CProfiles = / choosing specific protocols=E2=80=9D. Sounds like a nice short = discussion to me. I would like to move this point before =E2=80=9CParameters and = Defaults=E2=80=9D, as the introduction of Profiles adds an additional = resolution for disputed defaults: moving these defaults into the = individual profiles and have no/implementation specific defaults for the = case without profile. >=20 >=20 > Cheers, > Michael >=20 >=20 >>=20 >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>> =E2=80=A2 ARCH & API open topics >>>> --aaron >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> AVE! >> Philipp S. Tiesel >>=20 >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_4B9F0321-05F4-4161-919A-D10C3D5B1B3B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWxyORUfQrk93Q7or9/dp0G7BPC0FAl0jA00ACgkQ9/dp0G7B PC0xaQ/9GFO9P8CXKA4DI0i9eOjxO1chZYspV2OtgnH0WCq4aqKg129vu5dPev1M pY8LnlYg/n7xuHulPZBul8gJU7f+RdYqa7CwqcfPsXKjClQBDKpS/SLhT/wvQFnw Q1vs/giqn9DZr/25toiyRdHp9YcwlN5AUtw4r04AeWkV46zAG6cn63x+AuxeqIQr TG9Bl89LqIFy+uNxJGDAJlyx3ZxdMc3ksEsIyv+DHMKpRBEevFEvsSQR10g7YsCr RLsLemx5MDR8yImXNIVHGwWrQW0/GQgiGS6O7cUlTP8kMQ7aiOdTaF0tSOBBgy/y ux1BGi6Fa3c/eNAsZUhNODa7mzsdFl6A6un9L+LfV6SmhsHX6lDbvkZVYga95KJw Nb7TxoLlPb9twFTzalYnhLedTesYPkO8nph9LPJMVAlDZ0PKJzF7bvwsWCa3qLZg XurcjTWDTvF+JU54u2Lek5Ro8IPjSc7K+7J9NzR7Etngo+09RBELc2mBGDU0fqCY n+Rnwtso1aouPdGGUzn3bpwk+aA/Y6zDqDbLbPhMiPg8nyfh/jjinmxTCZFJjDUQ SvdQfS7avDGKE2T0VM9HZ3FcJBvC6Jt888sX6oO+z1UUyTtUrTTWXabupssLap3P Y62GBBvo1G159kVOmmjdFGOAtjq4l+uyksn1JYJCjwM8bEOJtN8= =IUQO -----END PGP SIGNATURE----- --Apple-Mail=_4B9F0321-05F4-4161-919A-D10C3D5B1B3B-- From nobody Mon Jul 8 06:46:39 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49E7120196 for ; Mon, 8 Jul 2019 06:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XQQ7g05V-mFX for ; Mon, 8 Jul 2019 06:46:36 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 EB31312003F for ; Mon, 8 Jul 2019 06:46:35 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id 201so11156916qkm.9 for ; Mon, 08 Jul 2019 06:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7R0RaobLuXK5lAeovIS8kQx/xsbGHilzlRbQNoq3MP0=; b=CmlVHytb22g8bk8r8MWl1sZV5ulMWFMRjjhXR3id6xZNne4k13+crMq+op63EN289h s7BZ/UHDlLaDcrtnVyiYPeZEXEdUOcCz70oUf3t0IrBfGwPggluzacS0EO4/0ziRFY6M hRsWzv+NQKNxEhfPUAhFixTHh7KwZ9PJuW0SFbcSHaQEia5J4+JO5LWmfQnkthsOsH5K sXoxA2dmaxHSoIjSAiT893eUpOi3orVOP/O/58l5qBwJ6wPfWRps3F15iNap3RSuFdjf h8Ewjq2tsM+BiasDSJ1cwhrkycOLgPhQdh6WqAhK6KscDlRpDuDEmHnEX9UIiko/e+m/ kJUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7R0RaobLuXK5lAeovIS8kQx/xsbGHilzlRbQNoq3MP0=; b=nJUgEEbxWsKLe9azjhqtc0RluX2rg348fLklYDYnYMStsTXWg2nI88YuUPS8ihnf2m Df0TUR78+7M1z0vKWL6NiwWslnXj7qrSITCMrRtC2m4wB0OIy65kPggwuI0VUjAHn5XE 9l7qnJlD3rEqEGimFS+HxfEaaJnln55hdBh1CxwZCD4R1k9OBGIcd1+MdzGXbYE9sL6T oDjZc+TQzRlh3HWhFmxPfCnIB+ZODnZU4KgNydaG2Ds8caIbtFiYwfDiTfYYyX4bQN6j ckO68+N8KL9O7DGZSEP9LJ1xMu50VFborxYRqyv5RnyDXsEgcbhcb1EBZqpW0m+k7FSk g1xQ== X-Gm-Message-State: APjAAAVnpHLELT9nHh3u+3W97Knuru4huP+X4rw5Gkl04ZAPwzES0c/M C2yDP5a8ePJh3rwYIewqdcY= X-Google-Smtp-Source: APXvYqwqoj7i2VnjQ1fLg18sCcDAWyTXR3zB2Yvywr1799OqVSnrOPu2nsxkBn0HvlLXf8ib/Chk4Q== X-Received: by 2002:a37:a692:: with SMTP id p140mr13860571qke.432.1562593594827; Mon, 08 Jul 2019 06:46:34 -0700 (PDT) Received: from [172.19.34.158] ([2001:4878:a000:3000:8183:35ec:29bb:5984]) by smtp.gmail.com with ESMTPSA id s7sm6257278qtq.8.2019.07.08.06.46.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 06:46:33 -0700 (PDT) From: "Aaron Falk" To: "Philipp S. Tiesel" Cc: "Michael Welzl" , "Zaheduzzaman Sarker" , taps@ietf.org Date: Mon, 08 Jul 2019 09:46:29 -0400 X-Mailer: MailMate (1.12.5r5635) Message-ID: <6E4E66D9-0887-407C-A804-7256B0F3D0CE@gmail.com> In-Reply-To: <55452E22-097F-497A-A381-E1C1F71412AB@in-panik.de> References: <929381CF-E86F-41D5-B1BA-29C1B58171A9@ifi.uio.no> <55D72312-E8A8-4BD4-86E5-E9D57A9ECA45@in-panik.de> <2574F272-3141-4D84-A43F-ED464435F1C9@ifi.uio.no> <55452E22-097F-497A-A381-E1C1F71412AB@in-panik.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_02E5AFE2-E136-4D0A-A5D9-418F71D66D90_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:46:38 -0000 --=_MailMate_02E5AFE2-E136-4D0A-A5D9-418F71D66D90_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8 Jul 2019, at 4:48, Philipp S. Tiesel wrote: >>>>> • Parameters & Defaults >> I’d volunteer for this one too. OK >> Ok, it sounds to me like this slot should be called “Profiles / >> choosing specific protocols”. Sounds like a nice short discussion >> to me. > > I would like to move this point before “Parameters and Defaults”, > as the introduction of Profiles adds an additional resolution for > disputed defaults: moving these defaults into the individual profiles > and have no/implementation specific defaults for the case without > profile. Moved. Updated agenda here: https://datatracker.ietf.org/meeting/105/materials/agenda-105-taps-02 --aaron --=_MailMate_02E5AFE2-E136-4D0A-A5D9-418F71D66D90_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= br>

On 8 Jul 2019, at 4:48, Philipp S. Tiesel wrote:

=E2=80=A2 Parameters & Defaults

I=E2=80=99d volunt= eer for this one too.

OK

Ok, it sounds to me like this slot should be called =E2=80=9CP= rofiles / choosing specific protocols=E2=80=9D. Sounds like a nice short= discussion to me.

I would like to move this point before =E2=80= =9CParameters and Defaults=E2=80=9D, as the introduction of Profiles adds= an additional resolution for disputed defaults: moving these defaults in= to the individual profiles and have no/implementation specific defaults f= or the case without profile.

Moved.

Updated agenda here: htt= ps://datatracker.ietf.org/meeting/105/materials/agenda-105-taps-02

--aaron

--=_MailMate_02E5AFE2-E136-4D0A-A5D9-418F71D66D90_=-- From nobody Mon Jul 8 10:39:10 2019 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 9F5B0120334; Mon, 8 Jul 2019 10:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <156260753955.1039.9564367417239468727@ietfa.amsl.com> Date: Mon, 08 Jul 2019 10:38:59 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-arch-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:39:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Architecture for Transport Services Authors : Tommy Pauly Brian Trammell Anna Brunstrom Godred Fairhurst Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-arch-04.txt Pages : 25 Date : 2019-07-08 Abstract: This document provides an overview of the architecture of Transport Services, a model for exposing transport protocol features to applications for network communication. In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document further defines the common set of terminology and concepts to be used in definitions of Transport Services APIs and implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-arch-04 https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-arch-04 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 Mon Jul 8 10:39:54 2019 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 18418120418; Mon, 8 Jul 2019 10:39:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <156260758202.1035.1402642513145100298@ietfa.amsl.com> Date: Mon, 08 Jul 2019 10:39:42 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-impl-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:39:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : Implementing Interfaces to Transport Services Authors : Anna Brunstrom Tommy Pauly Theresa Enghardt Karl-Johan Grinnemo Tom Jones Philipp S. Tiesel Colin Perkins Michael Welzl Filename : draft-ietf-taps-impl-04.txt Pages : 42 Date : 2019-07-08 Abstract: The Transport Services architecture [I-D.ietf-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-impl-04 https://datatracker.ietf.org/doc/html/draft-ietf-taps-impl-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-impl-04 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 Mon Jul 8 11:16:55 2019 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 23CBD12063F; Mon, 8 Jul 2019 11:16:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <156260979505.1055.10155570804074109030@ietfa.amsl.com> Date: Mon, 08 Jul 2019 11:16:35 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-interface-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 18:16:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Abstract Application Layer Interface to Transport Services Authors : Brian Trammell Michael Welzl Theresa Enghardt Godred Fairhurst Mirja Kuehlewind Colin Perkins Philipp S. Tiesel Chris Wood Tommy Pauly Filename : draft-ietf-taps-interface-04.txt Pages : 64 Date : 2019-07-08 Abstract: This document describes an abstract programming interface to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime. It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-interface-04 https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-interface-04 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 Fri Jul 12 01:02:20 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8131201D8 for ; Fri, 12 Jul 2019 01:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 1fi6AsNGIUHV for ; Fri, 12 Jul 2019 01:02:17 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 F327A120096 for ; Fri, 12 Jul 2019 01:02:16 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1hlqTM-0004D4-12 for taps@ietf.org; Fri, 12 Jul 2019 08:00:04 +0000 Content-Type: multipart/alternative; boundary="===============5061566015519304426==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 12 Jul 2019 08:00:04 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 08:02:19 -0000 --===============5061566015519304426== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+3/-1/=F0=9F=92=AC7) 3 issues created: - Add text about connection coalescing and connection pooling (by philsbl= n) https://github.com/ietf-tapswg/api-drafts/issues/339 [Implementation] [= ready for text] = - Listen filtering behavior for TLS connections? (by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/338 = - Update implementation mapping text for SCTP (by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/337 = 3 issues received 7 new comments: - #336 Should "send" return a MessageContex? (5 by philsbln, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/336 [API] [discuss] = - #266 Do we want to add Connection Pools to the Architecture / API (1 by= philsbln) https://github.com/ietf-tapswg/api-drafts/issues/266 [API] [Architectur= e] [discuss] = - #337 Update implementation mapping text for SCTP (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/337 = 1 issues closed: - Do we want to add Connection Pools to the Architecture / API https://gi= thub.com/ietf-tapswg/api-drafts/issues/266 [API] [Architecture] [discuss] = Pull requests ------------- * ietf-tapswg/api-drafts (+0/-1/=F0=9F=92=AC5) 2 pull requests received 5 new comments: - #328 Add Transport Property Profiles (3 by mirjak, philsbln) https://github.com/ietf-tapswg/api-drafts/pull/328 [API] [discuss] = - #327 Adding a way of forcing the use of specific protocols (2 by philsb= ln, GrumpyOldTroll) https://github.com/ietf-tapswg/api-drafts/pull/327 [API] [discuss] = 1 pull requests merged: - Make protocol-specific mappings in TAPS Implementation more rigorous https://github.com/ietf-tapswg/api-drafts/pull/333 [Implementation] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============5061566015519304426== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday July 12, 2019

Issues

ietf-tapswg/api-drafts (+3/-1/=F0=9F=92=AC7)

3 issues created:

3 issues received 7 new comments:

1 issues closed:

Pull requests

ietf-tapswg/api-drafts (+0/-1/=F0=9F=92=AC5)

2 pull requests received 5 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============5061566015519304426==-- From nobody Fri Jul 19 01:02:19 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73CE120145 for ; Fri, 19 Jul 2019 01:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 Yw2waY0qvOOi for ; Fri, 19 Jul 2019 01:02:16 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 E3D0C1200F3 for ; Fri, 19 Jul 2019 01:02:15 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1hoNoC-0004U0-Dr for taps@ietf.org; Fri, 19 Jul 2019 08:00:04 +0000 Content-Type: multipart/alternative; boundary="===============8067614928023090903==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 19 Jul 2019 08:00:04 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2019 08:02:18 -0000 --===============8067614928023090903== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC2) 1 issues created: - Comments on new framers (by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/340 = 2 issues received 2 new comments: - #322 Issues concerning framers (1 by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/322 [API] = - #340 Comments on new framers (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/340 = 1 issues closed: - Issues concerning framers https://github.com/ietf-tapswg/api-drafts/iss= ues/322 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============8067614928023090903== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday July 19, 2019

Issues

ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC2)

1 issues created:

2 issues received 2 new comments:

1 issues closed:

Repositories tracked by this digest:

--===============8067614928023090903==-- From nobody Mon Jul 22 12:09:37 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE3120125 for ; Mon, 22 Jul 2019 12:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 Kyk7eAnS5_tu for ; Mon, 22 Jul 2019 12:09:34 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 25ECE12011B for ; Mon, 22 Jul 2019 12:09:34 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6MJ74Rf010780 for ; Mon, 22 Jul 2019 12:09:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=sDOKiBdAi3/7uCl00xecL6BV3Cz29XOF/QiM9xxcS+4=; b=YyEdN8k0rjE6WcaeT1GXWuIczDT8aupKTTYM2tHDtU4G1MXwfZ6SlGmEIkTZZI0M3yCd BeIfMkY+TuwbmtMYpsveO6iT9hLKUy9WM0wawketoFO2NpqHIGVr0f84siA4ZF4Eqgd3 Kx5Tx46fAnmJ6GlUubRepLG7/optFFj2+iQNGLdwPZIAslF7b5SzhIzC7sZ+iaTQyhE0 n+miUJ/Fvn2OJPrEvA2bMRprL65+V+tZG/s8PElA1zauSAQ8jgwCHfiXluaPy6/80bJd BzWXog7BqEmybbmk99oz3OnZxI+7uzyACNWHQiOlFErF3S7SE0AD7JbrtsdMkKSnB8sZ mA== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2tv1m5v9dj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 22 Jul 2019 12:09:32 -0700 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV20043G57OPT80@ma1-mtap-s02.corp.apple.com> for taps@ietf.org; Mon, 22 Jul 2019 12:09:25 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV200A005703J00@nwk-mmpp-sz13.apple.com> for taps@ietf.org; Mon, 22 Jul 2019 12:09:24 -0700 (PDT) X-Va-A: X-Va-T-CD: 5808c5f95406ec7719a15f5c3784581a X-Va-E-CD: 7767081b3a220600287c21a9b1a4ebdf X-Va-R-CD: c1589dcd68ee813140d015a7610f5889 X-Va-CD: 0 X-Va-ID: 707d5062-af02-4e49-a548-d3f3acbf4c99 X-V-A: X-V-T-CD: 5808c5f95406ec7719a15f5c3784581a X-V-E-CD: 7767081b3a220600287c21a9b1a4ebdf X-V-R-CD: c1589dcd68ee813140d015a7610f5889 X-V-CD: 0 X-V-ID: 752b9fe8-7869-47e2-b06d-b6d022b2d262 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-22_14:,, signatures=0 Received: from [17.235.20.105] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV200C9957LZF50@nwk-mmpp-sz13.apple.com> for taps@ietf.org; Mon, 22 Jul 2019 12:09:24 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Message-id: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> Date: Mon, 22 Jul 2019 15:09:17 -0400 To: taps WG X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-22_14:, , signatures=0 Archived-At: Subject: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 19:09:36 -0000 An issue we discussed today in the TAPS meeting was whether or not we = should add a concept of "profiles" to the Transport Services APIs. An = example of a profile is a "reliable, secure, in-order stream"; or = "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 To help discern the working group's position, I'll try to distill the = high-level options here: 1. Add Profiles as a top-level API document concept that modifies how = transport properties and/or preconnections are created. (This is PR = #328.) 2. Mention in the API document that specific API implementations may = expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. 3. Do not mention profiles at all in the API document, but mention = something in the implementation document. Let's use this thread to discuss how to converge! Thanks, Tommy= From nobody Mon Jul 22 14:16:16 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EEB1200A3 for ; Mon, 22 Jul 2019 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 tnr1RfIi_Znm for ; Mon, 22 Jul 2019 14:16:13 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 1E3011200B8 for ; Mon, 22 Jul 2019 14:16:12 -0700 (PDT) X-Envelope-From: philipp@tiesel.net X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6MLGBgk015435 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 22 Jul 2019 23:16:11 +0200 Received: from [2001:67c:1232:144:61e4:ece:6fb0:5d36] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hpfdH-0008RE-Lf for taps@ietf.org; Mon, 22 Jul 2019 23:14:08 +0200 From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <2768ADD7-DC1A-4CAA-A627-C328257C52D7@tiesel.net> Date: Mon, 22 Jul 2019 17:16:03 -0400 To: taps WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Taps] Draft should point at existing implementations X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:16:15 -0000 Hi, as time did not permit to discuss all open issues in the session today, = I=E2=80=99ll take them to the list as proposed. This issue is based on Github issue #145: = https://github.com/ietf-tapswg/api-drafts/issues/145 The issue ask for the drafts to point at existing TAPS implementations. It might be useful to reference existing implementations (e.g., Apple = NWConnections and PyTAPS) and similar systems (e.g., NEAT, PostSockets, = SocketIntents) that where used as input to the TAPS design. Resolution Proposals: a) Add section to appendix b) Add notes to acknowledgements=20 c) Do nothing and close the issue AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/= From nobody Mon Jul 22 14:16:25 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427ED12008C for ; Mon, 22 Jul 2019 14:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gln2-76mLOWx for ; Mon, 22 Jul 2019 14:16:12 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 95BF312001B for ; Mon, 22 Jul 2019 14:16:12 -0700 (PDT) X-Envelope-From: philipp@tiesel.net X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6MLGAGf015424 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 22 Jul 2019 23:16:10 +0200 Received: from [2001:67c:1232:144:61e4:ece:6fb0:5d36] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hpfdF-0008RE-FR for taps@ietf.org; Mon, 22 Jul 2019 23:14:07 +0200 From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Mon, 22 Jul 2019 17:16:02 -0400 To: taps WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Taps] Implementation should separate out protocol-specific bits X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:16:16 -0000 Hi, as time did not permit to discuss all open issues in the session today, = I=E2=80=99ll take them to the list as proposed. This issue is based on Github issue #248: = https://github.com/ietf-tapswg/api-drafts/issues/248 The issue suggests to restructure the API to separate out = protocol-specific bits. Right now, there are protocol specific examples mixed into the generic = flow description; then, later, there is a section that has some = description for protocol specific considerations. Possible re-organizations: a) Per-protocol mappings for each API call + per-protocol specific = options. This is a guide to each protocol, such as a section for UDP and = how each call is imple-mented for UDP, and what options UDP offers = specifically.=E2=80=A8General discussion about Pre-Establishment, = Establishment, Data Transfer, etc, that has less information about = specific protocols. b) Structure everything with the general topics (Pre-Establishment, = Establishment, Data Transfer, etc), and have a rigorous list of each = protocol's mappings at the end of each section. So, for Establishment, = we describe racing, etc; and then go through and explain what Initiate() = does for TCP, UDP, UDP Lite, QUIC, SCTP. AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ From nobody Mon Jul 22 14:26:37 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346AC1200B6 for ; Mon, 22 Jul 2019 14:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 s3g_VkWSIoXN for ; Mon, 22 Jul 2019 14:26:33 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 345A312001B for ; Mon, 22 Jul 2019 14:26:33 -0700 (PDT) X-Envelope-From: philipp@tiesel.net X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6MLGC1V015441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 22 Jul 2019 23:16:12 +0200 Received: from [2001:67c:1232:144:61e4:ece:6fb0:5d36] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hpfdI-0008RE-Lr for taps@ietf.org; Mon, 22 Jul 2019 23:14:08 +0200 From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> Date: Mon, 22 Jul 2019 17:16:05 -0400 To: taps WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:26:35 -0000 Hi, as time did not permit to discuss all open issues in the session today, = I=E2=80=99ll take them to the list as proposed. This issue is based on Github issue #305: = https://github.com/ietf-tapswg/api-drafts/issues/305 Following the architecture draft, only protocol stacks that are = equivalent can be safely raced. What should happen if selection = properties result in a candidate set that includes protocol stacks that = are not intuitively equivalent? Resolution Proposals: a) Define Protocol Stack Equivalence more rigorously. A possible way to = do this would be to say two stacks are equivalent with respect to the = applications=E2=80=99 requirements if both fulfil all require properties = specified by the applications and do not violate any of the prohibit = properties. b) Generate some kind of Error Event for configurations with unlike = protocol stack candidates. (May need a definition of "unlike=E2=80=9D). c) Do nothing and close the issue. AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ From nobody Mon Jul 22 14:36:43 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0466B120077 for ; Mon, 22 Jul 2019 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7aQkml7XghZ5 for ; Mon, 22 Jul 2019 14:36:40 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 D8ED712001B for ; Mon, 22 Jul 2019 14:36:39 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpfz3-0004BO-D3; Mon, 22 Jul 2019 23:36:37 +0200 Received: from dhcp-9902.meeting.ietf.org ([31.133.153.2]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hpfz2-000ABo-Jb; Mon, 22 Jul 2019 23:36:37 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: <2768ADD7-DC1A-4CAA-A627-C328257C52D7@tiesel.net> Date: Mon, 22 Jul 2019 17:36:33 -0400 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2D1A7024-50B5-40EF-A094-425E5F45EE17@ifi.uio.no> References: <2768ADD7-DC1A-4CAA-A627-C328257C52D7@tiesel.net> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 31.133.153.2 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.153.2; envelope-from=michawe@ifi.uio.no; helo=dhcp-9902.meeting.ietf.org; 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: 15B5F08880B70AF9EF89577BF36BE782ED303493 Archived-At: Subject: Re: [Taps] Draft should point at existing implementations X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:36:42 -0000 Hi, I added a comment to this issue because I saw it on your slides, to = explain: this isn=E2=80=99t really worth discussing. I meant it only as a =E2=80=9Ctodo item=E2=80=9D for myself and assigned = it to me. I=E2=80=99ll do it when I do my planned next update on the = implementation draft (which this is about). Sorry, I guess this was bad github style. Cheers, Michael > On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel = wrote: >=20 > Hi, >=20 > as time did not permit to discuss all open issues in the session = today, I=E2=80=99ll take them to the list as proposed. > This issue is based on Github issue #145: = https://github.com/ietf-tapswg/api-drafts/issues/145 >=20 > The issue ask for the drafts to point at existing TAPS = implementations. >=20 > It might be useful to reference existing implementations (e.g., Apple = NWConnections and PyTAPS) and similar systems (e.g., NEAT, PostSockets, = SocketIntents) that where used as input to the TAPS design. >=20 >=20 > Resolution Proposals: >=20 > a) Add section to appendix >=20 > b) Add notes to acknowledgements=20 >=20 > c) Do nothing and close the issue >=20 > AVE! > Philipp S. Tiesel >=20 > --=20 > Philipp S. Tiesel=20 > https://philipp.tiesel.net/ > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Jul 22 15:56:44 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186AA1200BA for ; Mon, 22 Jul 2019 15:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 CUYDN-jVDMlp for ; Mon, 22 Jul 2019 15:56:40 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 394CC1200DE for ; Mon, 22 Jul 2019 15:56:40 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6MMuXNl016871 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 00:56:33 +0200 Received: from [2001:67c:370:128:6d26:adba:4d25:1628] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hphCP-0000K8-Bb; Tue, 23 Jul 2019 00:54:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Philipp S. Tiesel" In-Reply-To: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> Date: Mon, 22 Jul 2019 18:56:30 -0400 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net> References: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:56:42 -0000 Hi, > On 22. Jul 2019, at 15:09, Tommy Pauly = wrote: >=20 > An issue we discussed today in the TAPS meeting was whether or not we = should add a concept of "profiles" to the Transport Services APIs. An = example of a profile is a "reliable, secure, in-order stream"; or = "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. >=20 > One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 >=20 > To help discern the working group's position, I'll try to distill the = high-level options here: >=20 > 1. Add Profiles as a top-level API document concept that modifies how = transport properties and/or preconnections are created. (This is PR = #328.) > 2. Mention in the API document that specific API implementations may = expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. > 3. Do not mention profiles at all in the API document, but mention = something in the implementation document. I am definitely in favour of option 1. Our implementation experience = with PyTAPS showed that setting all transport properties necessary to = get =E2=80=9CUDP like service=E2=80=9D becomes tedious otherwise. I fear not including them in the examples and the core API will result = in many developers rejecting TAPS as too complex to use. The profiles provide a useful convenience to applications (just like the = the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)). In addition, profiles allow us to be less conservative in how we choose = the defaults for transport properties, i.e., we don=E2=80=99t need the = TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is. AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ From nobody Mon Jul 22 16:15:16 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE59120094 for ; Mon, 22 Jul 2019 16:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 G47H2Gp0LWZy for ; Mon, 22 Jul 2019 16:15:11 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 00738120048 for ; Mon, 22 Jul 2019 16:15:10 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6MN2ELk062408; Mon, 22 Jul 2019 16:15:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=llpq8zIjicizuM1GE82ZOFh7rQgJM/cSp/Myg12XL0Q=; b=XUyTlrKBuL7LP1XneOkjL/L40OTtf/phJNXSa7Y29JfE/AEy/FtqnIGeUHGFwFL7530O bItE7h+C2kzx95X4cnjr/06aw6TRLWpeQ2CK9UIImliVluS3+aCc6E0vah9RoouyzUqg 08m7859xlx1+glaETjlU0lqunBHsU33PEDKif1Fzelb5si4sj225DiXj+kPtp7Lmtzvl 10OY/qEPiJZ0eUpwfDwppTC+n/Hvkiv3ww8rivI1vumHikr+8AKOInQnYTeeBud/iUU+ uMckwN8h5YtyK5lhH/wH0H7xVUxKdr3VLtDRZ1lk0lXxlMrA6fuJPPQ1bAQxx9flYLes VA== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2tuymwwd6m-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jul 2019 16:15:10 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV2004VKGL9V140@mr2-mtap-s02.rno.apple.com>; Mon, 22 Jul 2019 16:15:09 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV200200GGI1D00@nwk-mmpp-sz09.apple.com>; Mon, 22 Jul 2019 16:15:09 -0700 (PDT) X-Va-A: X-Va-T-CD: 2b784dc161e0635db4a0c2407b1814f4 X-Va-E-CD: 6b84095c203fe2a1a8945a03453fd93c X-Va-R-CD: 6aae7abbe171cacdfada0471f498e066 X-Va-CD: 0 X-Va-ID: 29d6903f-fa0e-44f5-a46b-a17e67bab7fa X-V-A: X-V-T-CD: 2b784dc161e0635db4a0c2407b1814f4 X-V-E-CD: 6b84095c203fe2a1a8945a03453fd93c X-V-R-CD: 6aae7abbe171cacdfada0471f498e066 X-V-CD: 0 X-V-ID: 69b2eb42-9b97-4102-876a-606d9683e5a1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-22_16:,, signatures=0 Received: from [17.235.47.251] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV200IWIGL5H900@nwk-mmpp-sz09.apple.com>; Mon, 22 Jul 2019 16:15:08 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: Tommy Pauly In-reply-to: <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net> Date: Mon, 22 Jul 2019 19:15:02 -0400 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: References: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-22_16:, , signatures=0 Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 23:15:14 -0000 > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel = wrote: >=20 > Hi, >=20 >> On 22. Jul 2019, at 15:09, Tommy Pauly = wrote: >>=20 >> An issue we discussed today in the TAPS meeting was whether or not we = should add a concept of "profiles" to the Transport Services APIs. An = example of a profile is a "reliable, secure, in-order stream"; or = "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. >>=20 >> One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 >>=20 >> To help discern the working group's position, I'll try to distill the = high-level options here: >>=20 >> 1. Add Profiles as a top-level API document concept that modifies how = transport properties and/or preconnections are created. (This is PR = #328.) >> 2. Mention in the API document that specific API implementations may = expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. >> 3. Do not mention profiles at all in the API document, but mention = something in the implementation document. >=20 > I am definitely in favour of option 1. Our implementation experience = with PyTAPS showed that setting all transport properties necessary to = get =E2=80=9CUDP like service=E2=80=9D becomes tedious otherwise. > I fear not including them in the examples and the core API will result = in many developers rejecting TAPS as too complex to use. > The profiles provide a useful convenience to applications (just like = the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)). >=20 > In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is. Speaking not as the person asking the question, but as an individual in = the group: I'm pretty strongly against option (1), and prefer (2). I think we = should specify that convenience functions can exist, but I think = changing the one initialization function of the transport properties to = take a profile is not the right move for the API. Everything can be = achieved by making the API for a convenience profile be a layer on top = of the existing API. Specifically, these are the differences: (1) Exposes an API in which you always pass a profile (or an explicit = nil) to a TransportProperties object; but the TransportProperties *also* = lets you set each of the individual properties after that. (2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally. Thanks, Tommy >=20 > AVE! > Philipp S. Tiesel >=20 > --=20 > Philipp S. Tiesel=20 > https://philipp.tiesel.net/ >=20 From nobody Tue Jul 23 06:35:10 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE65D1202BD for ; Tue, 23 Jul 2019 06:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 v7UuhdF7o3g3 for ; Tue, 23 Jul 2019 06:35:04 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail1.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff11:130:149:220:242]) by ietfa.amsl.com (Postfix) with ESMTP id 07990120302 for ; Tue, 23 Jul 2019 06:34:52 -0700 (PDT) Received: from [172.16.150.129] (unknown [207.115.96.130]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 5F334171B; Tue, 23 Jul 2019 15:34:50 +0200 (CEST) Date: Tue, 23 Jul 2019 09:34:51 -0400 Message-ID: X-Android-Message-ID: In-Reply-To: From: Max Franke To: Tommy Pauly Cc: "Philipp S. Tiesel" , taps WG Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:35:08 -0000 PGRpdiBkaXI9J2F1dG8nPjxkaXY+SSB3b25kZXIgaWYgdGhpcyBhcmd1bWVudCBpcyBtb3JlIGJl Y2F1c2UgYXQgdGhlIG1vbWVudCBwcm9maWxlcyBhcmUgaGFuZGVkIG92ZXIgYXMgYSBwYXJhbWV0 ZXIgb24gY3JlYXRpb24gb2YgdGhlIHByb3BlcnRpZXMgYW5kIG5vdCBhYm91dCB0aGUgZXhpc3Rh bmNlIG9mIHByb3BlcnRpZXMgaW4gZ2VuZXJhbC4mbmJzcDs8ZGl2IGRpcj0iYXV0byI+TWF5YmUg YW5vdGhlciBzb2x1dGlvbiB3b3VsZCBiZSBhIGNhbGwgYWxvbmcgdGhlIGxpbmVzIG9mJm5ic3A7 PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyMzAsIDI1NSwgMjM3KTsgY29sb3I6 IHJnYigzLCA0NywgOTgpOyBmb250LWZhbWlseTogc2Ztb25vLXJlZ3VsYXIsIGNvbnNvbGFzLCAm cXVvdDtsaWJlcmF0aW9uIG1vbm8mcXVvdDssIG1lbmxvLCBjb3VyaWVyLCBtb25vc3BhY2U7IGZv bnQtc2l6ZTogMTJweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+VHJhbnNwb3J0UHJvcGVydGll cy5XaXRoUHJvZmlsZShwcm9maWxlKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IHNh bnMtc2VyaWY7Ij4mbmJzcDssIHNpbWlsYXIgdG8gd2hhdCB3ZSBhbHJlYWR5IGhhdmUgd2l0aCBX aXRoU2VydmljZSBvbiB0aGUgZW5kcG9pbnRzPzwvc3Bhbj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyI+QXMgUGhpbGlwcCBzYWlkLCB0 aGVyZSBhcmUgYWxyZWFkeSBjb252ZW5pZW5jZSBmZWF0dXJlcyBpbiBvdGhlciBwbGFjZXMgb2Yg dGhlIEFQSSB3aGljaCBzaG91bGQgYmUgcmVtb3ZlZCBpZiB3ZSBhZ3JlZSBvbiBrZWVwaW5nIHRo ZSBjb21wbGV4aXR5IHRvIHRoZSBiYXJlIG1pbmltdW0gZm9yIHRoZSBjb3JlIGludGVyZmFjZS4m bmJzcDs8L3NwYW4+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+QmVzdCByZWdh cmRzLDwvZGl2PjxkaXYgZGlyPSJhdXRvIj5NYXg8YnI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi IGRpcj0iYXV0byI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5BbSAyMi4wNy4yMDE5IDE5 OjE1IHNjaHJpZWIgVG9tbXkgUGF1bHkgJmx0O3RwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRm Lm9yZyZndDs6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj48YmxvY2txdW90ZSBjbGFzcz0icXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij48cCBkaXI9Imx0ciI+PC9wPgo8cCBkaXI9Imx0ciI+Jmd0OyBPbiBKdWwg MjIsIDIwMTksIGF0IDY6NTYgUE0sIFBoaWxpcHAgUy4gVGllc2VsICZsdDtwaGlsaXBwQHRpZXNl bC5uZXQmZ3Q7IHdyb3RlOjxicj4KJmd0OyA8YnI+CiZndDsgSGksPGJyPgomZ3Q7IDxicj4KJmd0 OyZndDsgT24gMjIuIEp1bCAyMDE5LCBhdCAxNTowOSwgVG9tbXkgUGF1bHkgJmx0O3RwYXVseT00 MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZyZndDsgd3JvdGU6PGJyPgomZ3Q7Jmd0OyA8YnI+CiZn dDsmZ3Q7IEFuIGlzc3VlIHdlIGRpc2N1c3NlZCB0b2RheSBpbiB0aGUgVEFQUyBtZWV0aW5nIHdh cyB3aGV0aGVyIG9yIG5vdCB3ZSBzaG91bGQgYWRkIGEgY29uY2VwdCBvZiAicHJvZmlsZXMiIHRv IHRoZSBUcmFuc3BvcnQgU2VydmljZXMgQVBJcy4gQW4gZXhhbXBsZSBvZiBhIHByb2ZpbGUgaXMg YSAicmVsaWFibGUsIHNlY3VyZSwgaW4tb3JkZXIgc3RyZWFtIjsgb3IgInVucmVsaWFibGUgZGF0 YWdyYW1zIi4gQW5vdGhlciB3YXkgdG8gdGhpbmsgb2YgdGhlc2UgcHJvZmlsZXMgYXJlIGFzIGNv bnZlbmllbnQgd2F5cyB0byBpbml0aWFsaXplIGNvbW1vbiBwYXJhbWV0ZXJzLjxicj4KJmd0OyZn dDsgPGJyPgomZ3Q7Jmd0OyBPbmUgb3B0aW9uIGlzIGRlc2NyaWJlZCBpbiB0aGlzIFBSOiBodHRw czovL2dpdGh1Yi5jb20vaWV0Zi10YXBzd2cvYXBpLWRyYWZ0cy9wdWxsLzMyODxicj4KJmd0OyZn dDsgPGJyPgomZ3Q7Jmd0OyBUbyBoZWxwIGRpc2Nlcm4gdGhlIHdvcmtpbmcgZ3JvdXAncyBwb3Np dGlvbiwgSSdsbCB0cnkgdG8gZGlzdGlsbCB0aGUgaGlnaC1sZXZlbCBvcHRpb25zIGhlcmU6PGJy PgomZ3Q7Jmd0OyA8YnI+CiZndDsmZ3Q7IDEuIEFkZCBQcm9maWxlcyBhcyBhIHRvcC1sZXZlbCBB UEkgZG9jdW1lbnQgY29uY2VwdCB0aGF0IG1vZGlmaWVzIGhvdyB0cmFuc3BvcnQgcHJvcGVydGll cyBhbmQvb3IgcHJlY29ubmVjdGlvbnMgYXJlIGNyZWF0ZWQuIChUaGlzIGlzIFBSICMzMjguKTxi cj4KJmd0OyZndDsgMi4gTWVudGlvbiBpbiB0aGUgQVBJIGRvY3VtZW50IHRoYXQgc3BlY2lmaWMg QVBJIGltcGxlbWVudGF0aW9ucyBtYXkgZXhwb3NlIGNvbnZlbmllbmNlcyBhbmQgcHJvZmlsZXMg KHByZXN1bWFibHkgYXMgYSB3YXkgdG8gaW5pdGlhbGl6ZSBwcmVjb25uZWN0aW9ucyksIGJ1dCBk byBub3QgbW9kaWZ5IHRoZSBBUEkgb3Igc3BlY2lmeSBhbiBhYnN0cmFjdCBzeW1ib2wgZm9yIHBy b2ZpbGVzLjxicj4KJmd0OyZndDsgMy4gRG8gbm90IG1lbnRpb24gcHJvZmlsZXMgYXQgYWxsIGlu IHRoZSBBUEkgZG9jdW1lbnQsIGJ1dCBtZW50aW9uIHNvbWV0aGluZyBpbiB0aGUgaW1wbGVtZW50 YXRpb24gZG9jdW1lbnQuPGJyPgomZ3Q7IDxicj4KJmd0OyBJIGFtIGRlZmluaXRlbHkgaW4gZmF2 b3VyIG9mIG9wdGlvbiAxLiBPdXIgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB3aXRoIFB5VEFQ UyBzaG93ZWQgdGhhdCBzZXR0aW5nIGFsbCB0cmFuc3BvcnQgcHJvcGVydGllcyBuZWNlc3Nhcnkg dG8gZ2V0IOKAnFVEUCBsaWtlIHNlcnZpY2XigJ0gYmVjb21lcyB0ZWRpb3VzIG90aGVyd2lzZS48 YnI+CiZndDsgSSBmZWFyIG5vdCBpbmNsdWRpbmcgdGhlbSBpbiB0aGUgZXhhbXBsZXMgYW5kIHRo ZSBjb3JlIEFQSSB3aWxsIHJlc3VsdCBpbiBtYW55IGRldmVsb3BlcnMgcmVqZWN0aW5nIFRBUFMg YXMgdG9vIGNvbXBsZXggdG8gdXNlLjxicj4KJmd0OyBUaGUgcHJvZmlsZXMgcHJvdmlkZSBhIHVz ZWZ1bCBjb252ZW5pZW5jZSB0byBhcHBsaWNhdGlvbnMgKGp1c3QgbGlrZSB0aGUgdGhlIHNob3J0 Y3V0cyBwcm9wZXJ0aWVzLnByZWZlcihwcm9wZXJ0eSkgaW5zdGVhZCBvZiBwcm9wZXJ0aWVzLmFk ZChwcm9wZXJ0eSwgcHJlZmVyKSkuPGJyPgomZ3Q7IDxicj4KJmd0OyBJbiBhZGRpdGlvbiwgcHJv ZmlsZXMgYWxsb3cgdXMgdG8gYmUgbGVzcyBjb25zZXJ2YXRpdmUgaW4gaG93IHdlIGNob29zZSB0 aGUgZGVmYXVsdHMgZm9yIHRyYW5zcG9ydCBwcm9wZXJ0aWVzLCBpLmUuLCB3ZSBkb27igJl0IG5l ZWQgdGhlIFRBUFMgZGVmYXVsdHMgdG8gYmUgVENQIGNvbXBhdGlibGUgYXMgbG9uZyBhcyB0aGUg cmVsaWFibGUtaW4tb3JkZXItc3RyZWFtIHByb2ZpbGUgaXMuPC9wPgo8cCBkaXI9Imx0ciI+U3Bl YWtpbmcgbm90IGFzIHRoZSBwZXJzb24gYXNraW5nIHRoZSBxdWVzdGlvbiwgYnV0IGFzIGFuIGlu ZGl2aWR1YWwgaW4gdGhlIGdyb3VwOjwvcD4KPHAgZGlyPSJsdHIiPkknbSBwcmV0dHkgc3Ryb25n bHkgYWdhaW5zdCBvcHRpb24gKDEpLCBhbmQgcHJlZmVyICgyKS4gSSB0aGluayB3ZSBzaG91bGQg c3BlY2lmeSB0aGF0IGNvbnZlbmllbmNlIGZ1bmN0aW9ucyBjYW4gZXhpc3QsIGJ1dCBJIHRoaW5r IGNoYW5naW5nIHRoZSBvbmUgaW5pdGlhbGl6YXRpb24gZnVuY3Rpb24gb2YgdGhlIHRyYW5zcG9y dCBwcm9wZXJ0aWVzIHRvIHRha2UgYSBwcm9maWxlIGlzIG5vdCB0aGUgcmlnaHQgbW92ZSBmb3Ig dGhlIEFQSS4gRXZlcnl0aGluZyBjYW4gYmUgYWNoaWV2ZWQgYnkgbWFraW5nIHRoZSBBUEkgZm9y IGEgY29udmVuaWVuY2UgcHJvZmlsZSBiZSBhIGxheWVyIG9uIHRvcCBvZiB0aGUgZXhpc3Rpbmcg QVBJLjwvcD4KPHAgZGlyPSJsdHIiPlNwZWNpZmljYWxseSwgdGhlc2UgYXJlIHRoZSBkaWZmZXJl bmNlczo8L3A+CjxwIGRpcj0ibHRyIj4oMSkgRXhwb3NlcyBhbiBBUEkgaW4gd2hpY2ggeW91IGFs d2F5cyBwYXNzIGEgcHJvZmlsZSAob3IgYW4gZXhwbGljaXQgbmlsKSB0byBhIFRyYW5zcG9ydFBy b3BlcnRpZXMgb2JqZWN0OyBidXQgdGhlIFRyYW5zcG9ydFByb3BlcnRpZXMgKmFsc28qIGxldHMg eW91IHNldCBlYWNoIG9mIHRoZSBpbmRpdmlkdWFsIHByb3BlcnRpZXMgYWZ0ZXIgdGhhdC48YnI+ CigyKSBBbGxvd3MgaW1wbGVtZW50YXRpb25zIHRvIGV4cG9zZSBhbiBBUEkgY2FsbCB0byBkZWxp dmVyIGEgVHJhbnNwb3J0UHJvcGVydGllcyB0aGF0J3Mgc2V0IHVwIGJhc2VkIG9uIGEgcHJvZmls ZSwgYnV0IHRoYXQgaXNuJ3QgdGhlIGZ1bmRhbWVudGFsIGNvbnN0cnVjdG9yLiBJdCBpcyBpbXBs ZW1lbnRlZCBieSBjcmVhdGluZyBhIFRyYW5zcG9ydFByb3BlcnRpZXMgKFRyYW5zcG9ydFByb3Bl cnRpZXMoKSkgYW5kIHRoZW4gc2V0dGluZyB0aGUgcHJvcGVydGllcyBpbnRlcm5hbGx5LjwvcD4K PHAgZGlyPSJsdHIiPlRoYW5rcyw8YnI+ClRvbW15PC9wPgo8cCBkaXI9Imx0ciI+Jmd0OyA8YnI+ CiZndDsgQVZFITxicj4KJmd0OyZuYnNwOyZuYnNwOyBQaGlsaXBwIFMuIFRpZXNlbDxicj4KJmd0 OyA8YnI+CiZndDsgLS0gPGJyPgomZ3Q7IFBoaWxpcHAgUy4gVGllc2VsIDxicj4KJmd0OyBodHRw czovL3BoaWxpcHAudGllc2VsLm5ldC88YnI+CiZndDsgPC9wPgo8cCBkaXI9Imx0ciI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ClRhcHMgbWFpbGlu ZyBsaXN0PGJyPgpUYXBzQGlldGYub3JnPGJyPgpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RhcHM8YnI+CjwvcD4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Rp dj48L2Rpdj4= From nobody Tue Jul 23 06:42:37 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7346012030C for ; Tue, 23 Jul 2019 06:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 ag2Fw73EDcpz for ; Tue, 23 Jul 2019 06:42:25 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 06F3F120313 for ; Tue, 23 Jul 2019 06:42:25 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NDgH2J053220; Tue, 23 Jul 2019 06:42:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=jjRvVdKV63xUXolvaNwgNuE01+5mH+idZ+xTDulE10w=; b=vfpsApFiciG60cHd5Sw8PP8NWYEqu6C3kC7ZUBbDJHMtesTEQ9aRd+s2nIB+UQYB6yJp +WACLKPv+AvPSqdOkR2bqHdfoXMlKqxZ448DYkyWOvbxkS53AaRfmFrWdAMmFcQuE+Jc 2MZITKdi88y6uqaHb1N9ErxqkIu/l+yXUCaBpjkHS9TXMH3ZVyAEbiqUSbxhbmY1zlw7 Uf/rZ/jqDl6hc+qebZC5OP558Qk+E3i3fXrAigmhODepeF1QT6OC1SpD9juFjzqwP1bG PpXruLAveupyLcCYr+K+FJs+a2GcSUZjeOaQrV8h64Nnt8CbF5SVFVI10Nw4q16y6G1c Ew== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2tvk6mts5p-24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 06:42:22 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV300GW6KQ8FE60@ma1-mtap-s03.corp.apple.com>; Tue, 23 Jul 2019 06:42:09 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV300800KJ6FI00@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 06:42:09 -0700 (PDT) X-Va-A: X-Va-T-CD: 8dd9a97d16a6334c7005ce5b0715e098 X-Va-E-CD: 6b84095c203fe2a1a8945a03453fd93c X-Va-R-CD: 6aae7abbe171cacdfada0471f498e066 X-Va-CD: 0 X-Va-ID: b6b42bef-8885-4b46-80ce-e50c64da277b X-V-A: X-V-T-CD: 8dd9a97d16a6334c7005ce5b0715e098 X-V-E-CD: 6b84095c203fe2a1a8945a03453fd93c X-V-R-CD: 6aae7abbe171cacdfada0471f498e066 X-V-CD: 0 X-V-ID: 7a2477b5-1037-441a-bb33-cc85d4bb1655 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-23_06:,, signatures=0 Received: from [17.235.51.16] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV300B93KNTPG10@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 06:40:44 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_7C884793-E2D9-48FF-9E48-82CF78E3A059" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: Tommy Pauly X-Priority: 3 In-reply-to: Date: Tue, 23 Jul 2019 09:40:37 -0400 Cc: Tommy Pauly , taps WG , "Philipp S. Tiesel" Message-id: <857A1326-9DA7-4BE9-A8C3-B12474ABEF76@apple.com> References: To: Max Franke X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_06:, , signatures=0 Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:42:34 -0000 --Apple-Mail=_7C884793-E2D9-48FF-9E48-82CF78E3A059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, I would be happier with suggesting something like = TransportProperties.WithProfile(profile), rather than replacing the = primary constructor. To the point of trimming down the API, I do think that it may be good to = only choose one between options like this: * properties.prefer(property) * properties.add(property, prefer) The API prescribed by this document is abstract, and needs to give = freedom to implementations to make things elegant in their particular = languages. What about having an appending, that's non-normative and not required = for RFC compliance, that describes suggested conveniences, such as = "properties.prefer()" and the concept of convenience profiles? The point is, if you wanted to have the minimal implementation of a TAPS = implementation that made it possible to let applications do what they = need over TAPS, you wouldn't necessarily need to implement these = conveniences, since they don't add any new capabilities, but instead are = semantic sugar. Thanks, Tommy > On Jul 23, 2019, at 9:34 AM, Max Franke = wrote: >=20 > I wonder if this argument is more because at the moment profiles are = handed over as a parameter on creation of the properties and not about = the existance of properties in general.=20 > Maybe another solution would be a call along the lines of = TransportProperties.WithProfile(profile) , similar to what we already = have with WithService on the endpoints? > As Philipp said, there are already convenience features in other = places of the API which should be removed if we agree on keeping the = complexity to the bare minimum for the core interface.=20 >=20 > Best regards, > Max >=20 > Am 22.07.2019 19:15 schrieb Tommy Pauly = : >=20 > > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel = wrote: > >=20 > > Hi, > >=20 > >> On 22. Jul 2019, at 15:09, Tommy Pauly = wrote: > >>=20 > >> An issue we discussed today in the TAPS meeting was whether or not = we should add a concept of "profiles" to the Transport Services APIs. An = example of a profile is a "reliable, secure, in-order stream"; or = "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. > >>=20 > >> One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 > >>=20 > >> To help discern the working group's position, I'll try to distill = the high-level options here: > >>=20 > >> 1. Add Profiles as a top-level API document concept that modifies = how transport properties and/or preconnections are created. (This is PR = #328.) > >> 2. Mention in the API document that specific API implementations = may expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. > >> 3. Do not mention profiles at all in the API document, but mention = something in the implementation document. > >=20 > > I am definitely in favour of option 1. Our implementation experience = with PyTAPS showed that setting all transport properties necessary to = get =E2=80=9CUDP like service=E2=80=9D becomes tedious otherwise. > > I fear not including them in the examples and the core API will = result in many developers rejecting TAPS as too complex to use. > > The profiles provide a useful convenience to applications (just like = the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)). > >=20 > > In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is. >=20 > Speaking not as the person asking the question, but as an individual = in the group: >=20 > I'm pretty strongly against option (1), and prefer (2). I think we = should specify that convenience functions can exist, but I think = changing the one initialization function of the transport properties to = take a profile is not the right move for the API. Everything can be = achieved by making the API for a convenience profile be a layer on top = of the existing API. >=20 > Specifically, these are the differences: >=20 > (1) Exposes an API in which you always pass a profile (or an explicit = nil) to a TransportProperties object; but the TransportProperties *also* = lets you set each of the individual properties after that. > (2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally. >=20 > Thanks, > Tommy >=20 > >=20 > > AVE! > > Philipp S. Tiesel > >=20 > > --=20 > > Philipp S. Tiesel=20 > > https://philipp.tiesel.net/ > > >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_7C884793-E2D9-48FF-9E48-82CF78E3A059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, = I would be happier with suggesting something = like TransportProperties.WithProfile(profile), rather than = replacing the primary constructor.

To the point of trimming down the API, = I do think that it may be good to only choose one between options like = this:

* = properties.prefer(property)
* = properties.add(property, prefer)

The API prescribed by this document is = abstract, and needs to give freedom to implementations to make things = elegant in their particular languages.

What about having an appending, that's = non-normative and not required for RFC compliance, that describes = suggested conveniences, such as "properties.prefer()" and the concept of = convenience profiles?

The point is, if you wanted to have the minimal = implementation of a TAPS implementation that made it possible to let = applications do what they need over TAPS, you wouldn't necessarily need = to implement these conveniences, since they don't add any new = capabilities, but instead are semantic sugar.

Thanks,
Tommy

On Jul 23, 2019, at 9:34 AM, = Max Franke <mfranke@inet.tu-berlin.de> wrote:

I wonder if this argument is more because at = the moment profiles are handed over as a parameter on creation of the = properties and not about the existance of properties in = general. 
Maybe another solution would = be a call along the lines of TransportProperties.WithProfile(profile) , similar to what we = already have with WithService on the endpoints?
As Philipp said, there are already convenience features in = other places of the API which should be removed if we agree on keeping = the complexity to the bare minimum for the core = interface. 

Best regards,
Max

Am 22.07.2019 19:15 schrieb Tommy = Pauly <tpauly=3D40apple.com@dmarc.ietf.org>:

> = On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <philipp@tiesel.net> = wrote:
>
> Hi,
>
>> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
>>
>> An issue we discussed today in the TAPS meeting was whether or = not we should add a concept of "profiles" to the Transport Services = APIs. An example of a profile is a "reliable, secure, in-order stream"; = or "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters.
>>
>> One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328
>>
>> To help discern the working group's position, I'll try to = distill the high-level options here:
>>
>> 1. Add Profiles as a top-level API document concept that = modifies how transport properties and/or preconnections are created. = (This is PR #328.)
>> 2. Mention in the API document that specific API = implementations may expose conveniences and profiles (presumably as a = way to initialize preconnections), but do not modify the API or specify = an abstract symbol for profiles.
>> 3. Do not mention profiles at all in the API document, but = mention something in the implementation document.
>
> I am definitely in favour of option 1. Our implementation = experience with PyTAPS showed that setting all transport properties = necessary to get =E2=80=9CUDP like service=E2=80=9D becomes tedious = otherwise.
> I fear not including them in the examples and the core API will = result in many developers rejecting TAPS as too complex to use.
> The profiles provide a useful convenience to applications (just = like the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)).
>
> In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is.

Speaking= not as the person asking the question, but as an individual in the = group:

I'm pretty strongly against option = (1), and prefer (2). I think we should specify that convenience = functions can exist, but I think changing the one initialization = function of the transport properties to take a profile is not the right = move for the API. Everything can be achieved by making the API for a = convenience profile be a layer on top of the existing API.

Specifically, these are the differences:

(1) Exposes an API in which you always pass a = profile (or an explicit nil) to a TransportProperties object; but the = TransportProperties *also* lets you set each of the individual = properties after that.
(2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally.

Thanks,
= Tommy

>
> AVE!
>   Philipp S. Tiesel
>
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>

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


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

= --Apple-Mail=_7C884793-E2D9-48FF-9E48-82CF78E3A059-- From nobody Tue Jul 23 06:52:07 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E46120116 for ; Tue, 23 Jul 2019 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.477 X-Spam-Level: X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 iyhP11oF4y63 for ; Tue, 23 Jul 2019 06:51:52 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8976F1202DA for ; Tue, 23 Jul 2019 06:51:52 -0700 (PDT) Received: from [172.16.150.129] (unknown [207.115.96.130]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id A1069171B; Tue, 23 Jul 2019 15:51:50 +0200 (CEST) Date: Tue, 23 Jul 2019 09:51:53 -0400 Message-ID: X-Android-Message-ID: In-Reply-To: <857A1326-9DA7-4BE9-A8C3-B12474ABEF76@apple.com> From: Max Franke To: Tommy Pauly Cc: "Philipp S. Tiesel" , taps WG Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 13:52:05 -0000 PGRpdiBkaXI9J2F1dG8nPjxkaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPjxibG9ja3F1b3RlIGNsYXNzPSJxdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48ZGl2PlRoZSBBUEkgcHJlc2Ny aWJlZCBieSB0aGlzIGRvY3VtZW50IGlzIGFic3RyYWN0LCBhbmQgbmVlZHMgdG8gZ2l2ZSBmcmVl ZG9tIHRvIGltcGxlbWVudGF0aW9ucyB0byBtYWtlIHRoaW5ncyBlbGVnYW50IGluIHRoZWlyIHBh cnRpY3VsYXIgbGFuZ3VhZ2VzLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PldoYXQgYWJv dXQgaGF2aW5nIGFuIGFwcGVuZGluZywgdGhhdCdzIG5vbi1ub3JtYXRpdmUgYW5kIG5vdCByZXF1 aXJlZCBmb3IgUkZDIGNvbXBsaWFuY2UsIHRoYXQgZGVzY3JpYmVzIHN1Z2dlc3RlZCBjb252ZW5p ZW5jZXMsIHN1Y2ggYXMgInByb3BlcnRpZXMucHJlZmVyKCkiIGFuZCB0aGUgY29uY2VwdCBvZiBj b252ZW5pZW5jZSBwcm9maWxlcz88L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlllcywgSSBsaWtlIHRoaXMgaWRlYS4gSSBhbHNvIGFncmVl IHRoYXQgdGhlIEFQSSBpcyBjb21wbGV4IGVub3VnaCBhcyBpdCBpcyBhbmQgcmVxdWlyaW5nIGNv bnZlbmllbmNlIGZlYXR1cmVzIHRvIGJlIFJGQyBjb21wbGlhbnQgaXMgcHJvYmFibHkgbm90IGEg Z29vZCBpZGVhLiBBcyBsb25nIGFzIHdlIGFyZSBjb25zaXN0ZW50IHdpdGggbW92aW5nIGFsbCBj b252ZW5pZW5jZXMgdG8gdGhlIGFwcGVuZGl4IHRoaXMgaXMgbXkgcHJlZmVycmVkIG9wdGlvbi48 L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5CZXN0PC9kaXY+ PGRpdiBkaXI9ImF1dG8iPk1heDwvZGl2PjwvZGl2Pg== From nobody Tue Jul 23 07:17:25 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7612011D for ; Tue, 23 Jul 2019 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 WNPxm7lR-urZ for ; Tue, 23 Jul 2019 07:17:22 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 B819D1200B3 for ; Tue, 23 Jul 2019 07:17:22 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpvbS-0006iF-9Q; Tue, 23 Jul 2019 16:17:18 +0200 Received: from dhcp-9902.meeting.ietf.org ([31.133.153.2]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hpvbR-000Dyb-6i; Tue, 23 Jul 2019 16:17:18 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_AF43829E-BFF2-4C3E-B852-C5973A39FA49" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl X-Priority: 3 In-Reply-To: Date: Tue, 23 Jul 2019 10:17:13 -0400 Cc: Tommy Pauly , "taps@ietf.org" , "Philipp S. Tiesel" Message-Id: <7DB06BAF-BC10-4367-BD5E-C7EFB698200B@ifi.uio.no> References: To: Max Franke X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 31.133.153.2 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.153.2; envelope-from=michawe@ifi.uio.no; helo=dhcp-9902.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4DEFF521ED58784B4CBFA5FB306A17884E3A7D0D Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:17:24 -0000 --Apple-Mail=_AF43829E-BFF2-4C3E-B852-C5973A39FA49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 23, 2019, at 9:51 AM, Max Franke = wrote: >=20 >=20 >=20 > The API prescribed by this document is abstract, and needs to give = freedom to implementations to make things elegant in their particular = languages. >=20 > What about having an appending, that's non-normative and not required = for RFC compliance, that describes suggested conveniences, such as = "properties.prefer()" and the concept of convenience profiles? > Yes, I like this idea. I also agree that the API is complex enough as = it is and requiring convenience features to be RFC compliant is probably = not a good idea. As long as we are consistent with moving all = conveniences to the appendix this is my preferred option. +1 on this if it=E2=80=99s a workable solution (sounds like it is), and = a particular +1 on the side comment about "consistently moving all = conveniences to the appendix=E2=80=9D Cheers, Michael --Apple-Mail=_AF43829E-BFF2-4C3E-B852-C5973A39FA49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 23, 2019, at 9:51 AM, Max Franke <mfranke@inet.tu-berlin.de> wrote:



The API prescribed by this document is = abstract, and needs to give freedom to implementations to make things = elegant in their particular languages.

What about having an = appending, that's non-normative and not required for RFC compliance, = that describes suggested conveniences, such as "properties.prefer()" and = the concept of convenience = profiles?
Yes, I like this idea. I also agree that the API is complex = enough as it is and requiring convenience features to be RFC compliant = is probably not a good idea. As long as we are consistent with moving = all conveniences to the appendix this is my preferred = option.

+1 on = this if it=E2=80=99s a workable solution (sounds like it is), and a = particular +1 on the side comment about "consistently moving all = conveniences to the appendix=E2=80=9D

Cheers,
Michael

= --Apple-Mail=_AF43829E-BFF2-4C3E-B852-C5973A39FA49-- From nobody Tue Jul 23 07:28:20 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB47120323 for ; Tue, 23 Jul 2019 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 tL2nEUcxamYL for ; Tue, 23 Jul 2019 07:28:06 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 B8F28120309 for ; Tue, 23 Jul 2019 07:28:05 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6NES0bb023753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 16:28:00 +0200 Received: from [2001:67c:1232:144:2195:9781:734:997d] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hpvjo-0003ys-8L; Tue, 23 Jul 2019 16:25:56 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_F548D14C-AB81-4CD8-94AB-8675C2C72A58" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Philipp S. Tiesel" X-Priority: 3 In-Reply-To: <7DB06BAF-BC10-4367-BD5E-C7EFB698200B@ifi.uio.no> Date: Tue, 23 Jul 2019 10:27:57 -0400 Cc: Maximilian Franke , Tommy Pauly , "taps@ietf.org" Message-Id: <9D63340C-3116-476F-B758-D015A3A5A6A4@tiesel.net> References: <7DB06BAF-BC10-4367-BD5E-C7EFB698200B@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:28:19 -0000 --Apple-Mail=_F548D14C-AB81-4CD8-94AB-8675C2C72A58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23. Jul 2019, at 10:17, Michael Welzl wrote: >=20 >=20 >=20 >> On Jul 23, 2019, at 9:51 AM, Max Franke > wrote: >>=20 >>=20 >>=20 >> The API prescribed by this document is abstract, and needs to give = freedom to implementations to make things elegant in their particular = languages. >>=20 >> What about having an appending, that's non-normative and not required = for RFC compliance, that describes suggested conveniences, such as = "properties.prefer()" and the concept of convenience profiles? >> Yes, I like this idea. I also agree that the API is complex enough as = it is and requiring convenience features to be RFC compliant is probably = not a good idea. As long as we are consistent with moving all = conveniences to the appendix this is my preferred option. >=20 > +1 on this if it=E2=80=99s a workable solution (sounds like it is), = and a particular +1 on the side comment about "consistently moving all = conveniences to the appendix=E2=80=9D I am fine with moving all conveniences to the appendix, but we might = still need to reference them in the main text to make sure the API does = not look overly inconvenient. I also would like to use the profiles in = one of the examples. AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ --Apple-Mail=_F548D14C-AB81-4CD8-94AB-8675C2C72A58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23. Jul 2019, at 10:17, Michael Welzl <michawe@ifi.uio.no> = wrote:



On Jul 23, 2019, at 9:51 AM, Max Franke <mfranke@inet.tu-berlin.de> wrote:



The API prescribed by this document is = abstract, and needs to give freedom to implementations to make things = elegant in their particular languages.

What about having an = appending, that's non-normative and not required for RFC compliance, = that describes suggested conveniences, such as "properties.prefer()" and = the concept of convenience = profiles?
Yes, I like this idea. I also agree that the API is complex = enough as it is and requiring convenience features to be RFC compliant = is probably not a good idea. As long as we are consistent with moving = all conveniences to the appendix this is my preferred = option.

+1 on this if it=E2=80=99s a workable solution (sounds = like it is), and a particular +1 on the side comment about "consistently = moving all conveniences to the = appendix=E2=80=9D

I am fine with moving all conveniences to the = appendix, but we might still need to reference them in the main text to = make sure the API does not look overly inconvenient. I also would like = to use the profiles in one of the examples.

AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_F548D14C-AB81-4CD8-94AB-8675C2C72A58-- From nobody Tue Jul 23 07:33:19 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBD51202A5 for ; Tue, 23 Jul 2019 07:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 UR9QRiGe8JDo for ; Tue, 23 Jul 2019 07:33:07 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 0E7EA120131 for ; Tue, 23 Jul 2019 07:33:06 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NEMqdc039546; Tue, 23 Jul 2019 07:33:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=hlelD5K0FGCajItDg9ge9XIUQ6DtragU9fDiv6REOfM=; b=AZuJ+K2ND3cpkxVo0FR2x1zpt8kvYmB4aTYPb9k3P2Zfy/wRRCFgEnitQ+HYIpEqcTP2 bmSPnUWpZfLDl2s2qXWyNeC6n1KtugCgur0UKQNBnBHs92Q/0uYTWZN7cD6e3yUPJ4zC /BXCAI93LV8S149oYUdbtTc/g+ygFNYbZvt2ZXuiDkixHVPRpTwP9UMrLICU9dqn4n3n 3bfCDgY1Bm7656JVoYXJ5HWi+KvcH6F3W3x8JtRW7HY1w5YHGvjccYnl9vprY28bLXcK MiohkQVH4Oz6oQuDgC1Jw1Tu20vwuylYe202shZQLJ4LjcWwKxxYPpIW8NSG3eXc28el ew== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2tv1m6wfn6-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 07:33:04 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV300CTRN33QB50@mr2-mtap-s02.rno.apple.com>; Tue, 23 Jul 2019 07:33:03 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV300600N2KT300@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 07:33:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 2b784dc161e0635db4a0c2407b1814f4 X-Va-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-Va-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-Va-CD: 0 X-Va-ID: df0e9a0d-c7e2-44cd-a39c-b1c9bece7a9c X-V-A: X-V-T-CD: 2b784dc161e0635db4a0c2407b1814f4 X-V-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-V-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-V-CD: 0 X-V-ID: 0951bce4-08dd-4d9d-a86b-fb30e94b0131 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-23_06:,, signatures=0 Received: from [17.235.51.16] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV300KGIN04XC20@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 07:31:19 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: Tommy Pauly In-reply-to: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> Date: Tue, 23 Jul 2019 10:31:12 -0400 Cc: taps WG Content-transfer-encoding: quoted-printable Message-id: References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_06:, , signatures=0 Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:33:17 -0000 My initial impression here is that any protocol stacks that provide the = same transport services, and thus can be raced as candidates, need to be = equivalent. It ends up being a bit tautological. The description in the = architecture explains what combinations are allowed based on = preference=E2=80=94if you don't require reliability, then a UDP protocol = stack is equivalent to a message protocol over TCP. If you do require = reliability, then those aren't equivalent. Thanks, Tommy > On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel = wrote: >=20 > Hi, >=20 > as time did not permit to discuss all open issues in the session = today, I=E2=80=99ll take them to the list as proposed. > This issue is based on Github issue #305: = https://github.com/ietf-tapswg/api-drafts/issues/305 >=20 > Following the architecture draft, only protocol stacks that are = equivalent can be safely raced. What should happen if selection = properties result in a candidate set that includes protocol stacks that = are not intuitively equivalent? >=20 >=20 > Resolution Proposals: >=20 > a) Define Protocol Stack Equivalence more rigorously. A possible way = to do this would be to say two stacks are equivalent with respect to the = applications=E2=80=99 requirements if both fulfil all require properties = specified by the applications and do not violate any of the prohibit = properties. >=20 > b) Generate some kind of Error Event for configurations with unlike = protocol stack candidates. (May need a definition of "unlike=E2=80=9D). >=20 > c) Do nothing and close the issue. >=20 >=20 > AVE! > Philipp S. Tiesel >=20 > --=20 > Philipp S. Tiesel=20 > https://philipp.tiesel.net/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 23 07:36:03 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354D8120072 for ; Tue, 23 Jul 2019 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 0A-0MYwgBVG1 for ; Tue, 23 Jul 2019 07:35:58 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 6D3BB120131 for ; Tue, 23 Jul 2019 07:35:58 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6NEZp1c026769 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 16:35:51 +0200 Received: from [2001:67c:1232:144:2195:9781:734:997d] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hpvrP-00041M-Jg; Tue, 23 Jul 2019 16:33:47 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_A2613C76-C698-4020-BB9C-023E21C084F9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Philipp S. Tiesel" X-Priority: 3 In-Reply-To: <857A1326-9DA7-4BE9-A8C3-B12474ABEF76@apple.com> Date: Tue, 23 Jul 2019 10:35:48 -0400 Cc: Maximilian Franke , Tommy Pauly , taps WG Message-Id: <06E302AD-081B-4B5B-8565-BF3DECCE3B13@tiesel.net> References: <857A1326-9DA7-4BE9-A8C3-B12474ABEF76@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:36:01 -0000 --Apple-Mail=_A2613C76-C698-4020-BB9C-023E21C084F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23. Jul 2019, at 09:40, Tommy Pauly wrote: >=20 > Yes, I would be happier with suggesting something like = TransportProperties.WithProfile(profile), rather than replacing the = primary constructor. This has several drawbacks and makes things more complicated: - We need to define what should happen when = TransportProperties.WithProfile(profile) is called multiple times - We need to define whether TransportProperties.WithProfile(profile) = should override properties that have been set using = TransportProperties.add(property, value) - Implementations could choose to do this differently. Having the profile only in the constructors avoids these, as the = behaviour is 100% clear - the profile sets the defaults, everything can = be overridden afterwards. Also it makes clear that one can only specify = a single profile. > To the point of trimming down the API, I do think that it may be good = to only choose one between options like this: >=20 > * properties.prefer(property) > * properties.add(property, prefer) >=20 > The API prescribed by this document is abstract, and needs to give = freedom to implementations to make things elegant in their particular = languages. >=20 > What about having an appending, that's non-normative and not required = for RFC compliance, that describes suggested conveniences, such as = "properties.prefer()" and the concept of convenience profiles? >=20 > The point is, if you wanted to have the minimal implementation of a = TAPS implementation that made it possible to let applications do what = they need over TAPS, you wouldn't necessarily need to implement these = conveniences, since they don't add any new capabilities, but instead are = semantic sugar. >=20 > Thanks, > Tommy >=20 >> On Jul 23, 2019, at 9:34 AM, Max Franke > wrote: >>=20 >> I wonder if this argument is more because at the moment profiles are = handed over as a parameter on creation of the properties and not about = the existance of properties in general.=20 >> Maybe another solution would be a call along the lines of = TransportProperties.WithProfile(profile) , similar to what we already = have with WithService on the endpoints? >> As Philipp said, there are already convenience features in other = places of the API which should be removed if we agree on keeping the = complexity to the bare minimum for the core interface.=20 >>=20 >> Best regards, >> Max >>=20 >> Am 22.07.2019 19:15 schrieb Tommy Pauly = >: >>=20 >> > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel > wrote: >> >=20 >> > Hi, >> >=20 >> >> On 22. Jul 2019, at 15:09, Tommy Pauly = > wrote: >> >>=20 >> >> An issue we discussed today in the TAPS meeting was whether or not = we should add a concept of "profiles" to the Transport Services APIs. An = example of a profile is a "reliable, secure, in-order stream"; or = "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. >> >>=20 >> >> One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 = >> >>=20 >> >> To help discern the working group's position, I'll try to distill = the high-level options here: >> >>=20 >> >> 1. Add Profiles as a top-level API document concept that modifies = how transport properties and/or preconnections are created. (This is PR = #328.) >> >> 2. Mention in the API document that specific API implementations = may expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. >> >> 3. Do not mention profiles at all in the API document, but mention = something in the implementation document. >> >=20 >> > I am definitely in favour of option 1. Our implementation = experience with PyTAPS showed that setting all transport properties = necessary to get =E2=80=9CUDP like service=E2=80=9D becomes tedious = otherwise. >> > I fear not including them in the examples and the core API will = result in many developers rejecting TAPS as too complex to use. >> > The profiles provide a useful convenience to applications (just = like the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)). >> >=20 >> > In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is. >>=20 >> Speaking not as the person asking the question, but as an individual = in the group: >>=20 >> I'm pretty strongly against option (1), and prefer (2). I think we = should specify that convenience functions can exist, but I think = changing the one initialization function of the transport properties to = take a profile is not the right move for the API. Everything can be = achieved by making the API for a convenience profile be a layer on top = of the existing API. >>=20 >> Specifically, these are the differences: >>=20 >> (1) Exposes an API in which you always pass a profile (or an explicit = nil) to a TransportProperties object; but the TransportProperties *also* = lets you set each of the individual properties after that. >> (2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally. >>=20 >> Thanks, >> Tommy >>=20 >> >=20 >> > AVE! >> > Philipp S. Tiesel >> >=20 >> > --=20 >> > Philipp S. Tiesel=20 >> > https://philipp.tiesel.net/ >> > >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps = >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ --Apple-Mail=_A2613C76-C698-4020-BB9C-023E21C084F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23. Jul 2019, at 09:40, Tommy Pauly <tpauly@apple.com> = wrote:

Yes, I would be = happier with suggesting something = like TransportProperties.WithProfile(profile), rather than = replacing the primary constructor.

This has several drawbacks and makes things more = complicated:
 - We need to define what should happen when = TransportProperties.WithProfile(profile) is called multiple = times
 - We need to define whether = TransportProperties.WithProfile(profile) should override properties that = have been set using TransportProperties.add(property, = value)
 - Implementations could choose to do this = differently.

Having the profile only = in the constructors avoids these, as the behaviour is 100% clear - the = profile sets the defaults, everything can be overridden afterwards. Also = it makes clear that one can only specify a single profile.

To the point of trimming = down the API, I do think that it may be good to only choose one between = options like this:

* properties.prefer(property)
* = properties.add(property, prefer)

The API prescribed by this document is = abstract, and needs to give freedom to implementations to make things = elegant in their particular languages.

What about having an appending, that's = non-normative and not required for RFC compliance, that describes = suggested conveniences, such as "properties.prefer()" and the concept of = convenience profiles?

The point is, if you wanted to have the minimal = implementation of a TAPS implementation that made it possible to let = applications do what they need over TAPS, you wouldn't necessarily need = to implement these conveniences, since they don't add any new = capabilities, but instead are semantic sugar.

Thanks,
Tommy

On Jul = 23, 2019, at 9:34 AM, Max Franke <mfranke@inet.tu-berlin.de> wrote:

I wonder if this argument is more because at = the moment profiles are handed over as a parameter on creation of the = properties and not about the existance of properties in = general. 
Maybe another solution would = be a call along the lines of TransportProperties.WithProfile(profile) , similar to what we = already have with WithService on the endpoints?
As Philipp said, there are already convenience features in = other places of the API which should be removed if we agree on keeping = the complexity to the bare minimum for the core = interface. 

Best regards,
Max

Am 22.07.2019 19:15 schrieb Tommy = Pauly <tpauly=3D40apple.com@dmarc.ietf.org>:

> = On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <philipp@tiesel.net> = wrote:
>
> Hi,
>
>> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
>>
>> An issue we discussed today in the TAPS meeting was whether or = not we should add a concept of "profiles" to the Transport Services = APIs. An example of a profile is a "reliable, secure, in-order stream"; = or "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters.
>>
>> One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328
>>
>> To help discern the working group's position, I'll try to = distill the high-level options here:
>>
>> 1. Add Profiles as a top-level API document concept that = modifies how transport properties and/or preconnections are created. = (This is PR #328.)
>> 2. Mention in the API document that specific API = implementations may expose conveniences and profiles (presumably as a = way to initialize preconnections), but do not modify the API or specify = an abstract symbol for profiles.
>> 3. Do not mention profiles at all in the API document, but = mention something in the implementation document.
>
> I am definitely in favour of option 1. Our implementation = experience with PyTAPS showed that setting all transport properties = necessary to get =E2=80=9CUDP like service=E2=80=9D becomes tedious = otherwise.
> I fear not including them in the examples and the core API will = result in many developers rejecting TAPS as too complex to use.
> The profiles provide a useful convenience to applications (just = like the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)).
>
> In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is.

Speaking= not as the person asking the question, but as an individual in the = group:

I'm pretty strongly against option = (1), and prefer (2). I think we should specify that convenience = functions can exist, but I think changing the one initialization = function of the transport properties to take a profile is not the right = move for the API. Everything can be achieved by making the API for a = convenience profile be a layer on top of the existing API.

Specifically, these are the differences:

(1) Exposes an API in which you always pass a = profile (or an explicit nil) to a TransportProperties object; but the = TransportProperties *also* lets you set each of the individual = properties after that.
(2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally.

Thanks,
= Tommy

>
> AVE!
>   Philipp S. Tiesel
>
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>

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


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


AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_A2613C76-C698-4020-BB9C-023E21C084F9-- From nobody Tue Jul 23 07:47:19 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4441202F3 for ; Tue, 23 Jul 2019 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 YnyV9dju03fl for ; Tue, 23 Jul 2019 07:47:14 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 3584C1202D4 for ; Tue, 23 Jul 2019 07:47:05 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NEgIvY009497; Tue, 23 Jul 2019 07:47:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=57TNF+/1QXwzArxZPkboCU75pNiaGIcmdsErHbQZvYY=; b=YRcsabhh8633TRV6hAuc/BfJNclrdwg2jf0q821hdFp0qzNhCzQw/yzYyT29t600qwsl k/rWxT3cZllaa4QrdeSBFtFJn0CkdW5350+SxIIg60tjoB3W4eemS6DSQkbJoAiX1RHX K6QIrrKNevNxy74sSY1pkCv/HaPEvUe5PFr5usvw5NAd9DJNV2LJNRRM4GIpdCbb+owC C/uBfa5IdUeGAValAxpFXZpz02MSzYBHLQYWghUg3mqGWmDk46gRXo0yKIzdBz2o1le4 9bUDcu+tT1VcROvSmWYP9qIAr6B0oAGiPAtnZ2DLiZIl/hiaKCo4uOBudQaQxXKXSRH6 Zg== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2tuyhn3rm1-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 07:47:03 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV3001QFNQDAH60@ma1-mtap-s03.corp.apple.com>; Tue, 23 Jul 2019 07:47:02 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV300C00N6YCI00@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 07:47:01 -0700 (PDT) X-Va-A: X-Va-T-CD: 2b784dc161e0635db4a0c2407b1814f4 X-Va-E-CD: 6b84095c203fe2a1a8945a03453fd93c X-Va-R-CD: 6aae7abbe171cacdfada0471f498e066 X-Va-CD: 0 X-Va-ID: 20ae2876-92b5-4f17-ab86-17700d8058ef X-V-A: X-V-T-CD: 2b784dc161e0635db4a0c2407b1814f4 X-V-E-CD: 6b84095c203fe2a1a8945a03453fd93c X-V-R-CD: 6aae7abbe171cacdfada0471f498e066 X-V-CD: 0 X-V-ID: 439b3bd2-1264-4af4-af4c-0b152d161804 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-23_06:,, signatures=0 Received: from [17.235.51.16] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV300IITNQA6X70@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 07:47:01 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_8CFE614B-0C07-401E-A733-BEDC18AA0138" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: Tommy Pauly X-Priority: 3 In-reply-to: <06E302AD-081B-4B5B-8565-BF3DECCE3B13@tiesel.net> Date: Tue, 23 Jul 2019 10:46:54 -0400 Cc: Maximilian Franke , Tommy Pauly , taps WG Message-id: <5BC70DCC-9E80-4526-92D9-90609DD29F37@apple.com> References: <857A1326-9DA7-4BE9-A8C3-B12474ABEF76@apple.com> <06E302AD-081B-4B5B-8565-BF3DECCE3B13@tiesel.net> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_06:, , signatures=0 Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:47:18 -0000 --Apple-Mail=_8CFE614B-0C07-401E-A733-BEDC18AA0138 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 TransportProperties.WithProfile(profile) *is* a constructor, I believe? = (Or at least that's what I interpret and suggest). Calling it multiple = times creates two different sets of properties. It's just a convenience = way, but not the only way. Thanks, Tommy > On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel = wrote: >=20 >=20 >=20 >> On 23. Jul 2019, at 09:40, Tommy Pauly > wrote: >>=20 >> Yes, I would be happier with suggesting something like = TransportProperties.WithProfile(profile), rather than replacing the = primary constructor. >=20 > This has several drawbacks and makes things more complicated: > - We need to define what should happen when = TransportProperties.WithProfile(profile) is called multiple times > - We need to define whether TransportProperties.WithProfile(profile) = should override properties that have been set using = TransportProperties.add(property, value) > - Implementations could choose to do this differently. >=20 > Having the profile only in the constructors avoids these, as the = behaviour is 100% clear - the profile sets the defaults, everything can = be overridden afterwards. Also it makes clear that one can only specify = a single profile. >=20 >> To the point of trimming down the API, I do think that it may be good = to only choose one between options like this: >>=20 >> * properties.prefer(property) >> * properties.add(property, prefer) >>=20 >> The API prescribed by this document is abstract, and needs to give = freedom to implementations to make things elegant in their particular = languages. >>=20 >> What about having an appending, that's non-normative and not required = for RFC compliance, that describes suggested conveniences, such as = "properties.prefer()" and the concept of convenience profiles? >>=20 >> The point is, if you wanted to have the minimal implementation of a = TAPS implementation that made it possible to let applications do what = they need over TAPS, you wouldn't necessarily need to implement these = conveniences, since they don't add any new capabilities, but instead are = semantic sugar. >>=20 >> Thanks, >> Tommy >>=20 >>> On Jul 23, 2019, at 9:34 AM, Max Franke > wrote: >>>=20 >>> I wonder if this argument is more because at the moment profiles are = handed over as a parameter on creation of the properties and not about = the existance of properties in general.=20 >>> Maybe another solution would be a call along the lines of = TransportProperties.WithProfile(profile) , similar to what we already = have with WithService on the endpoints? >>> As Philipp said, there are already convenience features in other = places of the API which should be removed if we agree on keeping the = complexity to the bare minimum for the core interface.=20 >>>=20 >>> Best regards, >>> Max >>>=20 >>> Am 22.07.2019 19:15 schrieb Tommy Pauly = >: >>>=20 >>> > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel > wrote: >>> >=20 >>> > Hi, >>> >=20 >>> >> On 22. Jul 2019, at 15:09, Tommy Pauly = > wrote: >>> >>=20 >>> >> An issue we discussed today in the TAPS meeting was whether or = not we should add a concept of "profiles" to the Transport Services = APIs. An example of a profile is a "reliable, secure, in-order stream"; = or "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. >>> >>=20 >>> >> One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 = >>> >>=20 >>> >> To help discern the working group's position, I'll try to distill = the high-level options here: >>> >>=20 >>> >> 1. Add Profiles as a top-level API document concept that modifies = how transport properties and/or preconnections are created. (This is PR = #328.) >>> >> 2. Mention in the API document that specific API implementations = may expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. >>> >> 3. Do not mention profiles at all in the API document, but = mention something in the implementation document. >>> >=20 >>> > I am definitely in favour of option 1. Our implementation = experience with PyTAPS showed that setting all transport properties = necessary to get =E2=80=9CUDP like service=E2=80=9D becomes tedious = otherwise. >>> > I fear not including them in the examples and the core API will = result in many developers rejecting TAPS as too complex to use. >>> > The profiles provide a useful convenience to applications (just = like the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)). >>> >=20 >>> > In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is. >>>=20 >>> Speaking not as the person asking the question, but as an individual = in the group: >>>=20 >>> I'm pretty strongly against option (1), and prefer (2). I think we = should specify that convenience functions can exist, but I think = changing the one initialization function of the transport properties to = take a profile is not the right move for the API. Everything can be = achieved by making the API for a convenience profile be a layer on top = of the existing API. >>>=20 >>> Specifically, these are the differences: >>>=20 >>> (1) Exposes an API in which you always pass a profile (or an = explicit nil) to a TransportProperties object; but the = TransportProperties *also* lets you set each of the individual = properties after that. >>> (2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally. >>>=20 >>> Thanks, >>> Tommy >>>=20 >>> >=20 >>> > AVE! >>> > Philipp S. Tiesel >>> >=20 >>> > --=20 >>> > Philipp S. Tiesel=20 >>> > https://philipp.tiesel.net/ >>> >=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps = >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps = >>=20 >=20 > AVE! > Philipp S. Tiesel >=20 > --=20 > Philipp S. Tiesel=20 > https://philipp.tiesel.net/ > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = --Apple-Mail=_8CFE614B-0C07-401E-A733-BEDC18AA0138 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 TransportProperties.WithProfile(profile) *is* a constructor, = I believe? (Or at least that's what I interpret and suggest). Calling it = multiple times creates two different sets of properties. It's just a = convenience way, but not the only way.

Thanks,
Tommy

On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel <philipp@tiesel.net> = wrote:



On 23. Jul 2019, at 09:40, = Tommy Pauly <tpauly@apple.com> wrote:

Yes, I would be happier with suggesting something = like TransportProperties.WithProfile(profile), rather than = replacing the primary constructor.

This has several = drawbacks and makes things more complicated:
 - = We need to define what should happen when = TransportProperties.WithProfile(profile) is called multiple = times
 - We need to define whether = TransportProperties.WithProfile(profile) should override properties that = have been set using TransportProperties.add(property, value)
 - Implementations could choose to do this = differently.

Having the profile only in the constructors avoids these, as = the behaviour is 100% clear - the profile sets the defaults, everything = can be overridden afterwards. Also it makes clear that one can only = specify a single profile.

To the point of trimming down the = API, I do think that it may be good to only choose one between options = like this:

* = properties.prefer(property)
* = properties.add(property, prefer)

The API prescribed by this document is = abstract, and needs to give freedom to implementations to make things = elegant in their particular languages.

What about having an appending, that's = non-normative and not required for RFC compliance, that describes = suggested conveniences, such as "properties.prefer()" and the concept of = convenience profiles?

The point is, if you wanted to have the minimal = implementation of a TAPS implementation that made it possible to let = applications do what they need over TAPS, you wouldn't necessarily need = to implement these conveniences, since they don't add any new = capabilities, but instead are semantic sugar.

Thanks,
Tommy

On Jul = 23, 2019, at 9:34 AM, Max Franke <mfranke@inet.tu-berlin.de> wrote:

I wonder if this argument is more because at = the moment profiles are handed over as a parameter on creation of the = properties and not about the existance of properties in = general. 
Maybe another solution would = be a call along the lines of TransportProperties.WithProfile(profile) , similar to what we already = have with WithService on the endpoints?
As = Philipp said, there are already convenience features in other places of = the API which should be removed if we agree on keeping the complexity to = the bare minimum for the core interface. 

Best = regards,
Max

Am 22.07.2019 19:15 schrieb Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>:

> = On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <philipp@tiesel.net> = wrote:
> 
> Hi,
> 
>> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
>> 
>> An issue we discussed today in the TAPS meeting was = whether or not we should add a concept of "profiles" to the Transport = Services APIs. An example of a profile is a "reliable, secure, in-order = stream"; or "unreliable datagrams". Another way to think of these = profiles are as convenient ways to initialize common parameters.
>> 
>> One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328
>> 
>> To help discern the working group's position, I'll = try to distill the high-level options here:
>> 
>> 1. = Add Profiles as a top-level API document concept that modifies how = transport properties and/or preconnections are created. (This is PR = #328.)
>> 2. Mention in the API document that = specific API implementations may expose conveniences and profiles = (presumably as a way to initialize preconnections), but do not modify = the API or specify an abstract symbol for profiles.
>>= 3. Do not mention profiles at all in the API document, but mention = something in the implementation document.
> 
> I am = definitely in favour of option 1. Our implementation experience with = PyTAPS showed that setting all transport properties necessary to get = =E2=80=9CUDP like service=E2=80=9D becomes tedious otherwise.
> I fear not including them in the examples and the core = API will result in many developers rejecting TAPS as too complex to = use.
> The profiles provide a useful convenience to = applications (just like the the shortcuts properties.prefer(property) = instead of properties.add(property, prefer)).
> 
> In = addition, profiles allow us to be less conservative in how we choose the = defaults for transport properties, i.e., we don=E2=80=99t need the TAPS = defaults to be TCP compatible as long as the reliable-in-order-stream = profile is.

Speaking not as the person = asking the question, but as an individual in the group:

I'm pretty strongly against option (1), and prefer (2). I = think we should specify that convenience functions can exist, but I = think changing the one initialization function of the transport = properties to take a profile is not the right move for the API. = Everything can be achieved by making the API for a convenience profile = be a layer on top of the existing API.

Specifically, these are the differences:

(1) Exposes an API in which you always pass a profile (or an = explicit nil) to a TransportProperties object; but the = TransportProperties *also* lets you set each of the individual = properties after that.
(2) Allows implementations to = expose an API call to deliver a TransportProperties that's set up based = on a profile, but that isn't the fundamental constructor. It is = implemented by creating a TransportProperties (TransportProperties()) = and then setting the properties internally.

Thanks,
Tommy

> 
> AVE!
>   Philipp S. Tiesel
> 
> -- 
> Philipp S. Tiesel 
> https://philipp.tiesel.net/
> 

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


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


AVE!   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

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

= --Apple-Mail=_8CFE614B-0C07-401E-A733-BEDC18AA0138-- From nobody Tue Jul 23 07:56:49 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A626B120043 for ; Tue, 23 Jul 2019 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 kl493MpTNwWi for ; Tue, 23 Jul 2019 07:56:46 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 C3CE612011D for ; Tue, 23 Jul 2019 07:56:45 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6NEuf0v002197 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 16:56:41 +0200 Received: from [2001:67c:1232:144:2195:9781:734:997d] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hpwBZ-000482-HL; Tue, 23 Jul 2019 16:54:37 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_5E17FC38-FE02-40A4-B088-A854AA822E6D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Philipp S. Tiesel" X-Priority: 3 In-Reply-To: <5BC70DCC-9E80-4526-92D9-90609DD29F37@apple.com> Date: Tue, 23 Jul 2019 10:56:38 -0400 Cc: Maximilian Franke , taps WG Message-Id: References: <857A1326-9DA7-4BE9-A8C3-B12474ABEF76@apple.com> <06E302AD-081B-4B5B-8565-BF3DECCE3B13@tiesel.net> <5BC70DCC-9E80-4526-92D9-90609DD29F37@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:56:48 -0000 --Apple-Mail=_5E17FC38-FE02-40A4-B088-A854AA822E6D Content-Type: multipart/alternative; boundary="Apple-Mail=_0D3520B0-1ABD-4EBA-941D-3DC0C0E8ADF5" --Apple-Mail=_0D3520B0-1ABD-4EBA-941D-3DC0C0E8ADF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23. Jul 2019, at 10:46, Tommy Pauly = wrote: >=20 > TransportProperties.WithProfile(profile) *is* a constructor, I = believe? (Or at least that's what I interpret and suggest). Calling it = multiple times creates two different sets of properties. It's just a = convenience way, but not the only way. I interpreted that differently - WithProfile being a methond of an = TransportProperties instance. Anyway =E2=80=93 I don=E2=80=99t really mind if the profile is an = optional parameter to the primary constructor or whether there is an = alternate constructor that takes it as a mandatory argument. For me, the = latter is just one way to realise the former in a language that does not = support optional parameters and thus an implementer=E2=80=99s choice. >=20 > Thanks, > Tommy >=20 >> On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel > wrote: >>=20 >>=20 >>=20 >>> On 23. Jul 2019, at 09:40, Tommy Pauly > wrote: >>>=20 >>> Yes, I would be happier with suggesting something like = TransportProperties.WithProfile(profile), rather than replacing the = primary constructor. >>=20 >> This has several drawbacks and makes things more complicated: >> - We need to define what should happen when = TransportProperties.WithProfile(profile) is called multiple times >> - We need to define whether TransportProperties.WithProfile(profile) = should override properties that have been set using = TransportProperties.add(property, value) >> - Implementations could choose to do this differently. >>=20 >> Having the profile only in the constructors avoids these, as the = behaviour is 100% clear - the profile sets the defaults, everything can = be overridden afterwards. Also it makes clear that one can only specify = a single profile. >>=20 >>> To the point of trimming down the API, I do think that it may be = good to only choose one between options like this: >>>=20 >>> * properties.prefer(property) >>> * properties.add(property, prefer) >>>=20 >>> The API prescribed by this document is abstract, and needs to give = freedom to implementations to make things elegant in their particular = languages. >>>=20 >>> What about having an appending, that's non-normative and not = required for RFC compliance, that describes suggested conveniences, such = as "properties.prefer()" and the concept of convenience profiles? >>>=20 >>> The point is, if you wanted to have the minimal implementation of a = TAPS implementation that made it possible to let applications do what = they need over TAPS, you wouldn't necessarily need to implement these = conveniences, since they don't add any new capabilities, but instead are = semantic sugar. >>>=20 >>> Thanks, >>> Tommy >>>=20 >>>> On Jul 23, 2019, at 9:34 AM, Max Franke > wrote: >>>>=20 >>>> I wonder if this argument is more because at the moment profiles = are handed over as a parameter on creation of the properties and not = about the existance of properties in general. >>>> Maybe another solution would be a call along the lines of = TransportProperties.WithProfile(profile) , similar to what we already = have with WithService on the endpoints? >>>> As Philipp said, there are already convenience features in other = places of the API which should be removed if we agree on keeping the = complexity to the bare minimum for the core interface. >>>>=20 >>>> Best regards, >>>> Max >>>>=20 >>>> Am 22.07.2019 19:15 schrieb Tommy Pauly = >: >>>>=20 >>>> > On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel = > wrote: >>>> > >>>> > Hi, >>>> > >>>> >> On 22. Jul 2019, at 15:09, Tommy Pauly = > wrote: >>>> >> >>>> >> An issue we discussed today in the TAPS meeting was whether or = not we should add a concept of "profiles" to the Transport Services = APIs. An example of a profile is a "reliable, secure, in-order stream"; = or "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. >>>> >> >>>> >> One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 = >>>> >> >>>> >> To help discern the working group's position, I'll try to = distill the high-level options here: >>>> >> >>>> >> 1. Add Profiles as a top-level API document concept that = modifies how transport properties and/or preconnections are created. = (This is PR #328.) >>>> >> 2. Mention in the API document that specific API implementations = may expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. >>>> >> 3. Do not mention profiles at all in the API document, but = mention something in the implementation document. >>>> > >>>> > I am definitely in favour of option 1. Our implementation = experience with PyTAPS showed that setting all transport properties = necessary to get =E2=80=9CUDP like service=E2=80=9D becomes tedious = otherwise. >>>> > I fear not including them in the examples and the core API will = result in many developers rejecting TAPS as too complex to use. >>>> > The profiles provide a useful convenience to applications (just = like the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)). >>>> > >>>> > In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is. >>>>=20 >>>> Speaking not as the person asking the question, but as an = individual in the group: >>>>=20 >>>> I'm pretty strongly against option (1), and prefer (2). I think we = should specify that convenience functions can exist, but I think = changing the one initialization function of the transport properties to = take a profile is not the right move for the API. Everything can be = achieved by making the API for a convenience profile be a layer on top = of the existing API. >>>>=20 >>>> Specifically, these are the differences: >>>>=20 >>>> (1) Exposes an API in which you always pass a profile (or an = explicit nil) to a TransportProperties object; but the = TransportProperties *also* lets you set each of the individual = properties after that. >>>> (2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally. >>>>=20 >>>> Thanks, >>>> Tommy >>>>=20 >>>> > >>>> > AVE! >>>> > Philipp S. Tiesel >>>> > >>>> > -- >>>> > Philipp S. Tiesel >>>> > https://philipp.tiesel.net/ >>>> > >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps = >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps = >>>=20 >>=20 >> AVE! >> Philipp S. Tiesel >>=20 >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps = > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_0D3520B0-1ABD-4EBA-941D-3DC0C0E8ADF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23. Jul 2019, at 10:46, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

TransportProperties.WithProfile(profile) *is* a constructor, = I believe? (Or at least that's what I interpret and suggest). Calling it = multiple times creates two different sets of properties. It's just a = convenience way, but not the only way.

I interpreted that differently - WithProfile being = a methond of an TransportProperties instance.

Anyway =E2=80=93 I don=E2=80=99t really mind if = the profile is an optional parameter to the primary constructor or = whether there is an alternate constructor that takes it as a mandatory = argument. For me, the latter is just one way to realise the former in a = language that does not support optional parameters and thus an = implementer=E2=80=99s choice.


Thanks,
Tommy

On Jul 23, 2019, at 10:35 AM, Philipp S. Tiesel <philipp@tiesel.net> = wrote:



On 23. Jul 2019, at 09:40, = Tommy Pauly <tpauly@apple.com> wrote:

Yes, I would be happier with suggesting something = like TransportProperties.WithProfile(profile), rather than = replacing the primary constructor.

This has several = drawbacks and makes things more complicated:
 - = We need to define what should happen when = TransportProperties.WithProfile(profile) is called multiple = times
 - We need to define whether = TransportProperties.WithProfile(profile) should override properties that = have been set using TransportProperties.add(property, value)
 - Implementations could choose to do this = differently.

Having the profile only in the constructors avoids these, as = the behaviour is 100% clear - the profile sets the defaults, everything = can be overridden afterwards. Also it makes clear that one can only = specify a single profile.

To the point of trimming down the = API, I do think that it may be good to only choose one between options = like this:

* = properties.prefer(property)
* = properties.add(property, prefer)

The API prescribed by this document is = abstract, and needs to give freedom to implementations to make things = elegant in their particular languages.

What about having an appending, that's = non-normative and not required for RFC compliance, that describes = suggested conveniences, such as "properties.prefer()" and the concept of = convenience profiles?

The point is, if you wanted to have the minimal = implementation of a TAPS implementation that made it possible to let = applications do what they need over TAPS, you wouldn't necessarily need = to implement these conveniences, since they don't add any new = capabilities, but instead are semantic sugar.

Thanks,
Tommy

On Jul = 23, 2019, at 9:34 AM, Max Franke <mfranke@inet.tu-berlin.de> wrote:

I wonder if this argument is more because at = the moment profiles are handed over as a parameter on creation of the = properties and not about the existance of properties in = general. 
Maybe another solution would = be a call along the lines of TransportProperties.WithProfile(profile) , similar to what we already = have with WithService on the endpoints?
As = Philipp said, there are already convenience features in other places of = the API which should be removed if we agree on keeping the complexity to = the bare minimum for the core interface. 

Best = regards,
Max

Am 22.07.2019 19:15 schrieb Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>:

> = On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel <philipp@tiesel.net> = wrote:
> 
> Hi,
> 
>> On 22. Jul 2019, at 15:09, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
>> 
>> An issue we discussed today in the TAPS meeting was = whether or not we should add a concept of "profiles" to the Transport = Services APIs. An example of a profile is a "reliable, secure, in-order = stream"; or "unreliable datagrams". Another way to think of these = profiles are as convenient ways to initialize common parameters.
>> 
>> One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328
>> 
>> To help discern the working group's position, I'll = try to distill the high-level options here:
>> 
>> 1. = Add Profiles as a top-level API document concept that modifies how = transport properties and/or preconnections are created. (This is PR = #328.)
>> 2. Mention in the API document that = specific API implementations may expose conveniences and profiles = (presumably as a way to initialize preconnections), but do not modify = the API or specify an abstract symbol for profiles.
>>= 3. Do not mention profiles at all in the API document, but mention = something in the implementation document.
> 
> I am = definitely in favour of option 1. Our implementation experience with = PyTAPS showed that setting all transport properties necessary to get = =E2=80=9CUDP like service=E2=80=9D becomes tedious otherwise.
> I fear not including them in the examples and the core = API will result in many developers rejecting TAPS as too complex to = use.
> The profiles provide a useful convenience to = applications (just like the the shortcuts properties.prefer(property) = instead of properties.add(property, prefer)).
> 
> In = addition, profiles allow us to be less conservative in how we choose the = defaults for transport properties, i.e., we don=E2=80=99t need the TAPS = defaults to be TCP compatible as long as the reliable-in-order-stream = profile is.

Speaking not as the person = asking the question, but as an individual in the group:

I'm pretty strongly against option (1), and prefer (2). I = think we should specify that convenience functions can exist, but I = think changing the one initialization function of the transport = properties to take a profile is not the right move for the API. = Everything can be achieved by making the API for a convenience profile = be a layer on top of the existing API.

Specifically, these are the differences:

(1) Exposes an API in which you always pass a profile (or an = explicit nil) to a TransportProperties object; but the = TransportProperties *also* lets you set each of the individual = properties after that.
(2) Allows implementations to = expose an API call to deliver a TransportProperties that's set up based = on a profile, but that isn't the fundamental constructor. It is = implemented by creating a TransportProperties (TransportProperties()) = and then setting the properties internally.

Thanks,
Tommy

> 
> AVE!
>   Philipp S. Tiesel
> 
> -- 
> Philipp S. Tiesel 
> https://philipp.tiesel.net/
> 

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


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


AVE!   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

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

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

AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_0D3520B0-1ABD-4EBA-941D-3DC0C0E8ADF5-- --Apple-Mail=_5E17FC38-FE02-40A4-B088-A854AA822E6D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWxyORUfQrk93Q7or9/dp0G7BPC0FAl03ICYACgkQ9/dp0G7B PC1Fbw/9G3np5W/98cqM1jXCr2BnGetsOQM9wGGip2JVB9Tl+JFi6dFzdJUbCBX9 luWtPAtBRk1FWJ3nPrpiZf8dfXbAR6Hf2U/P7MkeGeo8G9i1fgbbIYdp3ii1FgPc Q5n4qmWqMw6rIT2Mq7ch9ulF2eea3AKt3wOIOWLIK7MYMIuN5E9NMF0mlNxHTmsP whlUfCsMUnqs0okn0UxoB0iSr7O/waqh2+Xo79xv0NvXPIZSYD7o0+xFwlWx15oN C6/10AC2irQaMUOnB/QILqGPv6ML/HAslODZsnVuzw2LDr3xSLYFgyWkX9Q413zk RHeK8U44234K8+vBjOWe+w3syf6dF7D2fJXR8BnzY1Tz90O7X3VogritQ4Oj9gS5 dXAeF8IEHz2NgfPL8oOsHIKPBmUNHyN4bnDtvQPPaGkyW1OPYulh3GtcIPMVn7Oh a7yz2NBo45yCslpmZlnoFCdZ/66z/aFffL0dH3CSjetkUCCCx938SNanTn8xiDaH UYUaKP68s8ID4COyJt7MJ8FhCXHzpU8hVE59QpStcBq/75pAiGvoGJHPXxbrVxRD oWoEv1Pl6dDJGv6WmzjM4FAmc22AMjhkrajgg4Vfv5IWEgbbKHV58zbmfjFIAx3T rextIWrfbmwXgcBBAEYiTb4QD17G38wW6bjQYa4QhbQm85SNhPw= =Yyeg -----END PGP SIGNATURE----- --Apple-Mail=_5E17FC38-FE02-40A4-B088-A854AA822E6D-- From nobody Tue Jul 23 08:08:47 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55461203E3 for ; Tue, 23 Jul 2019 08:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8UDZ281NJrBF for ; Tue, 23 Jul 2019 08:08:34 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEAB12033C for ; Tue, 23 Jul 2019 08:08:34 -0700 (PDT) Received: from dhcp-8115.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:9940:e994:d158:b3f9]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1B7B81B00111 for ; Tue, 23 Jul 2019 16:08:32 +0100 (BST) Message-ID: <5D3722DF.8070000@erg.abdn.ac.uk> Date: Tue, 23 Jul 2019 11:08:15 -0400 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: taps@ietf.org References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:08:47 -0000 On 23/07/2019, 10:31, Tommy Pauly wrote: > My initial impression here is that any protocol stacks that provide the same transport services, and thus can be raced as candidates, need to be equivalent. It ends up being a bit tautological. The description in the architecture explains what combinations are allowed based on preference—if you don't require reliability, then a UDP protocol stack is equivalent to a message protocol over TCP. If you do require reliability, then those aren't equivalent. > > Thanks, > Tommy That makes sense to me. Gorry >> On Jul 22, 2019, at 5:16 PM, Philipp S. Tiesel wrote: >> >> Hi, >> >> as time did not permit to discuss all open issues in the session today, I’ll take them to the list as proposed. >> This issue is based on Github issue #305: https://github.com/ietf-tapswg/api-drafts/issues/305 >> >> Following the architecture draft, only protocol stacks that are equivalent can be safely raced. What should happen if selection properties result in a candidate set that includes protocol stacks that are not intuitively equivalent? >> >> >> Resolution Proposals: >> >> a) Define Protocol Stack Equivalence more rigorously. A possible way to do this would be to say two stacks are equivalent with respect to the applications’ requirements if both fulfil all require properties specified by the applications and do not violate any of the prohibit properties. >> >> b) Generate some kind of Error Event for configurations with unlike protocol stack candidates. (May need a definition of "unlike”). >> >> c) Do nothing and close the issue. >> >> >> AVE! >> Philipp S. Tiesel >> >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 23 08:19:30 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659E412036E for ; Tue, 23 Jul 2019 08:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EGOfasmLlKwC for ; Tue, 23 Jul 2019 08:19:17 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.152.141]) by ietfa.amsl.com (Postfix) with ESMTP id 156761202D5 for ; Tue, 23 Jul 2019 08:19:17 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:b886:3fad:542b:a48d] (unknown [IPv6:2001:67c:1232:144:b886:3fad:542b:a48d]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 61E69207EB for ; Tue, 23 Jul 2019 17:19:15 +0200 (CEST) To: taps@ietf.org References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> <5D3722DF.8070000@erg.abdn.ac.uk> From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= mQENBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAG0N1RoZXJlc2EgRW5naGFyZHQgKFJlc2VhcmNoKSA8dGhlcmVzYUBpbmV0LnR1LWJlcmxp bi5kZT6JAVUEEwEKAD8CGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEE7xG3phZ0Plgk 2BDpgz007xx2oPcFAlqgJ40FCRC919sACgkQgz007xx2oPfiHggAsCfbxjo+hlUYdEHmg/a8 RGDZfOqgmNrEWfWbB+H06A3izNpvfRbqdxhi64F8MXtKPxhPGBrB9H3/E3WfsOHc9tJe+19Y GkHBOMhbXmp/o92BVHw6q/l5bcvLO8sgcemqrh8GYZgZrho7F3UTIpb8dkCjt+jCAbsAAFzR 4ziEAqw+2KVmZw5t2/1KygnPsgMz70JGAfq2jTt+NR9DxMizXNa7pZjdSmqhBjCbTlzPnn0C rAkK1/IXSM3Y704asyQrHD2pNxXQyXEe/K5uN6w80gHdyK4bBWVIVZULaRngcKrcX9gillK+ 8zs3nr8eDgsq1cURk8nmkIkFm++6PgO8lLkBDQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149J BtI8Oh4Ywktc1ExLuZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjN d6uFEdFNLtf+2/QqjVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1W mMcXMQX+Npwv9plEJOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5 w8p8OYN41q0vqefBaMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsg Xurujk0OvEFhhkQonVRXUYmLTM0EXQARAQABiQE8BBgBCgAmAhsMFiEE7xG3phZ0Plgk2BDp gz007xx2oPcFAlqgJ40FCRC91+cACgkQgz007xx2oPfRiwf9H9BNITXs2wLFjrej7wV8XoCO 5z3iN4TTeKz/2XA0CQr7OjkqbEkllnlGvywJOsCsrficHGL+eXk7tWXf8LMm0QOA1pEgA7oN ynGp7O65WG4kN93j9PFA/0k+nkqWtztuw3KBApSqytEBaaqwdeOG5mCWYawAjpSII2Bo+r9I ghH9miMgAsT044OPj3QMKSZAzTEzHekEuYa/AZqfFxLFE27WdDZpEqzvQ3uaIDbYx5HbT+xt LJJczpENdiTwyvHN4PwNSfWacyv1TA7WM2Qusgs5OVRwaJIQypvoGRl0YawaHHgxpLgs/x3r 2IqmnTXThea+Wx/iYSrPFFv4rEbS/w== Message-ID: <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> Date: Tue, 23 Jul 2019 11:19:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <5D3722DF.8070000@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:19:28 -0000 Hi, > On 23/07/2019, 10:31, Tommy Pauly wrote: >> […] if you don't require reliability, then a UDP protocol stack is >> equivalent to a message protocol over TCP. If you do require >> reliability, then those aren't equivalent. Another important difference between TCP and UDP are Message Boundaries. So in some cases, TCP + Framer may be equivalent to UDP. We probably don't want to put that in the Architecture draft, but a Framer can essentially provide the "Message boundaries" property, thus, making TCP equivalent to UDP if Message boundaries are required, right? Maybe that's something for Implementation draft? But the application may also want to know about the possibility to essentially use TCP or UDP without having to change (much)? Thinking about DNS, even if there may be more stuff to consider here, such as the EDNS0 features Ted Hardie mentioned. Best, Theresa From nobody Tue Jul 23 08:25:07 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03B71203CE for ; Tue, 23 Jul 2019 08:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 GuZWh5aaveZX for ; Tue, 23 Jul 2019 08:24:52 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 E456F120369 for ; Tue, 23 Jul 2019 08:24:46 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NFLwnu006397; Tue, 23 Jul 2019 08:24:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=ZZNE3+Gxr3KOBN/K1QhFYZekCGvVnPacZEXo5evyO3o=; b=ahYQ0zabu603sGGsE/a5z35Hhiz29u9doWdRSUF1mMFwLRKA4cTc2CDmcryt/MyP7nAY j1D8FkY9ewAEbW95qXMtNQMibWWttW3HEcjQO/ZmkQbdP9lejWODiqYr19zFo15V3d3P CCf3oGmKwy0I266bed0b5KL2Je7jN+PFkgkI6LOtTS5icd7XvXPNfHDIpXWVptyDCCXN pX6bSvML6l0XJLrvFmxh9KSeiXuS6KNpZE13jdwRxbg+YlGB6ar8PTx+rEUYOjFsPQfk LFFHZNTjRmtlB1vpwA6QWWaHZhdSO6yXy123GBr+BF+AUSwyqxli8+gTAmMJgS//zPGA JA== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2tv1y0j0ec-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 08:24:45 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV30094PPH7HGD0@mr2-mtap-s02.rno.apple.com>; Tue, 23 Jul 2019 08:24:43 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV300I00P9Q2D00@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:24:43 -0700 (PDT) X-Va-A: X-Va-T-CD: 243d5618d6c40fa8f19ea30f70110151 X-Va-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-Va-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-Va-CD: 0 X-Va-ID: b711b49b-0e89-46cf-b151-98576b593df7 X-V-A: X-V-T-CD: 243d5618d6c40fa8f19ea30f70110151 X-V-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-V-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-V-CD: 0 X-V-ID: 42e1dd60-d2cc-4241-b83c-89ea9927ee9a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-23_07:,, signatures=0 Received: from [17.235.51.16] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV3003QAPH4L200@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:24:43 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: Tommy Pauly In-reply-to: <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> Date: Tue, 23 Jul 2019 11:24:36 -0400 Cc: taps@ietf.org Content-transfer-encoding: quoted-printable Message-id: <68B96C1C-B5E6-4630-8019-10C704251B87@apple.com> References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> <5D3722DF.8070000@erg.abdn.ac.uk> <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> To: Theresa Enghardt X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_07:, , signatures=0 Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:25:05 -0000 > On Jul 23, 2019, at 11:19 AM, Theresa Enghardt = wrote: >=20 > Hi, >=20 >> On 23/07/2019, 10:31, Tommy Pauly wrote: >>> [=E2=80=A6] if you don't require reliability, then a UDP protocol = stack is >>> equivalent to a message protocol over TCP. If you do require >>> reliability, then those aren't equivalent. >=20 > Another important difference between TCP and UDP are Message = Boundaries. > So in some cases, TCP + Framer may be equivalent to UDP. Exactly! That's what I meant by "a message protocol over TCP". >=20 >=20 > We probably don't want to put that in the Architecture draft, but a > Framer can essentially provide the "Message boundaries" property, = thus, > making TCP equivalent to UDP if Message boundaries are required, = right? Yes, I think that's already implicit in the text in Section 4.2.3, point = 1. TCP doesn't preserve boundaries on its own/if it's the top (but does = if there's another protocol that does). >=20 > Maybe that's something for Implementation draft? But the application = may > also want to know about the possibility to essentially use TCP or UDP > without having to change (much)? Thinking about DNS, even if there may > be more stuff to consider here, such as the EDNS0 features Ted Hardie > mentioned. I agree that the implementation document is a more appropriate place to = discuss the particulars of which protocols can be determined to be = equivalent. Thanks, Tommy >=20 > Best, > Theresa >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 23 08:55:54 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9EE1203A0 for ; Tue, 23 Jul 2019 08:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 nowRj09c5jlQ for ; Tue, 23 Jul 2019 08:55:43 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 15D6C120413 for ; Tue, 23 Jul 2019 08:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IcXICj/xNL/RwHMhU8JWV/kaWNIHHE4JwOyndCa3O5U=; b=qbZ5lafdFaVQT+NJf2OXU+qnn TL5rdKVrdIx/hv+FdW/vOsVccgZ6BmMkNNnbXPQR+OMteRD6SbQEZckEnN6pWus2MgeNFhLtOlR/y Bxq0pcZdVIRWSS0MuU53jSYLDBx/VvpURYwpaO26UurESw9aShgRtEycPiplo4vPK/5WWLymE0Mk9 FZ6e47M5nylFOr2XwCgZqR0YCLh2yeMC61e7ztQrpaEMEM7fXJAPmWa1bP07sT/Q6ajwAeUpIknIB 3IqKBGC17WmFr9ttih9bYbzFHA5NoMxw0ECVz5DnQcyLnZiaTgDltSJ7yJzJIKr4IEFgV9j6jikkB I0aCRWv0g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50588 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpx8Z-003YJs-Fz; Tue, 23 Jul 2019 11:55:40 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_7539C816-072C-4759-A72F-BCDE22DECBD7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> Date: Tue, 23 Jul 2019 08:55:34 -0700 Cc: taps@ietf.org Message-Id: References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> <5D3722DF.8070000@erg.abdn.ac.uk> <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> To: Theresa Enghardt X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:55:53 -0000 --Apple-Mail=_7539C816-072C-4759-A72F-BCDE22DECBD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 23, 2019, at 8:19 AM, Theresa Enghardt = wrote: >=20 > Another important difference between TCP and UDP are Message = Boundaries. > So in some cases, TCP + Framer may be equivalent to UDP. FWIW, they might provide *similar* capabilities, even only those that = the app is concerned about, but there are a LOT of other differences = that can=E2=80=99t be glossed over. In some cases, it is TCP that is = lacking (as above); in others, UDP). It=E2=80=99s only important whether the user does or doesn=E2=80=99t = care about those properties. When they match what they care about, they = can be considered equivalent. I.e., there=E2=80=99s not likely going to be a strict and absolute = equivalence between transports. Equivalence is TO THE USER, relative to their constraints. Joe --Apple-Mail=_7539C816-072C-4759-A72F-BCDE22DECBD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <theresa@inet.tu-berlin.de> wrote:

Another important difference = between TCP and UDP are Message Boundaries.
So in some cases, TCP + Framer = may be equivalent to UDP.

FWIW, they might provide *similar* capabilities, = even only those that the app is concerned about, but there are a LOT of = other differences that can=E2=80=99t be glossed over. In some cases, it = is TCP that is lacking (as above); in others, UDP).

It=E2=80=99s only important whether the user does = or doesn=E2=80=99t care about those properties. When they match what = they care about, they can be considered equivalent.

I.e., there=E2=80=99s not likely going to be a = strict and absolute equivalence between transports.

Equivalence is TO THE USER, relative to their = constraints.

Joe

= --Apple-Mail=_7539C816-072C-4759-A72F-BCDE22DECBD7-- From nobody Tue Jul 23 08:59:36 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02763120193 for ; Tue, 23 Jul 2019 08:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 miE5spBgF8Cw for ; Tue, 23 Jul 2019 08:59:32 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 2DD54120121 for ; Tue, 23 Jul 2019 08:59:32 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NFqB0g021938; Tue, 23 Jul 2019 08:59:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=R9/hvJ5CglPEjLGOarvDIGQst2S2/oAxjPZGFAednXc=; b=AGIduK3S+yRuAb+RsSirUouO85GLMVnvXoC2IH64vCjm18FIwerqfsjGT+rNT1AfJdqS ytjHvAI0CYiIujhNi07K6P5K6FUybc0fniLCrxohwgQQ8nCp6MuJ1D8K0x1khjqte4EU L2eSIsYQZfrevdx5t6a/dbqi0q+53Dsnc2phFONOHLpkyNxRlUBaq6iqjiQsA3n5pq8d AvI8ymtbMw7Vwhiit97awtMKF3IYSB+GJO0hlk1QcGuJfDKFO9Av05Bh6gCrVthdsUYX 3ggdXuTe/6vBbnX9KxGWJGCPegJljcLm3RGBX/DXf+F1uR8FrmyCVEuG2zlB+UoI64AI KQ== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2tvk6mxkss-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 08:59:30 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV3008YDR35R230@mr2-mtap-s02.rno.apple.com>; Tue, 23 Jul 2019 08:59:29 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV300I00QQTP400@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:59:29 -0700 (PDT) X-Va-A: X-Va-T-CD: 3411a62f3898e2de3a4b1b275171c74f X-Va-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-Va-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-Va-CD: 0 X-Va-ID: 4857e7d4-bfeb-4f1d-bd5b-76dd24ab5777 X-V-A: X-V-T-CD: 3411a62f3898e2de3a4b1b275171c74f X-V-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-V-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-V-CD: 0 X-V-ID: a12e45c6-8922-4f06-ac86-894331909eda X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-23_07:,, signatures=0 Received: from [17.235.51.16] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV300BODR335J00@nwk-mmpp-sz10.apple.com>; Tue, 23 Jul 2019 08:59:29 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_1BD41395-0E94-444E-950A-926CEE979F1F" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Tue, 23 Jul 2019 11:59:24 -0400 In-reply-to: Cc: Theresa Enghardt , taps@ietf.org To: Joe Touch References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> <5D3722DF.8070000@erg.abdn.ac.uk> <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_07:, , signatures=0 Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 15:59:35 -0000 --Apple-Mail=_1BD41395-0E94-444E-950A-926CEE979F1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joe, Yes, I completely agree. The current text in -arch expresses this as: 2. Both stacks MUST offer the same transport services, as required by the application. For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP. However, if the application does not require reliability, then a Protocol Stack that adds unnecessary reliability might be allowed as an equivalent Protocol Stack as long as it does not conflict with any other application-requested properties. If you think we can clarify this any further, let me know! Thanks, Tommy > On Jul 23, 2019, at 11:55 AM, Joe Touch wrote: >=20 >=20 >=20 >> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt = > wrote: >>=20 >> Another important difference between TCP and UDP are Message = Boundaries. >> So in some cases, TCP + Framer may be equivalent to UDP. >=20 > FWIW, they might provide *similar* capabilities, even only those that = the app is concerned about, but there are a LOT of other differences = that can=E2=80=99t be glossed over. In some cases, it is TCP that is = lacking (as above); in others, UDP). >=20 > It=E2=80=99s only important whether the user does or doesn=E2=80=99t = care about those properties. When they match what they care about, they = can be considered equivalent. >=20 > I.e., there=E2=80=99s not likely going to be a strict and absolute = equivalence between transports. >=20 > Equivalence is TO THE USER, relative to their constraints. >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_1BD41395-0E94-444E-950A-926CEE979F1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Joe,

Yes, I = completely agree. The current text in -arch expresses this as:

   2.  Both stacks MUST offer =
the same transport services, as required
       by the application.  For example, if an application specifies
       that it requires reliable transmission of data, then a Protocol
       Stack using UDP without any reliability layer on top would not be
       allowed to replace a Protocol Stack using TCP.  However, if the
       application does not require reliability, then a Protocol Stack
       that adds unnecessary reliability might be allowed as an
       equivalent Protocol Stack as long as it does not conflict with
       any other application-requested properties.

If you think we = can clarify this any further, let me know!

Thanks,
Tommy

On Jul 23, 2019, at 11:55 AM, = Joe Touch <touch@strayalpha.com> wrote:



On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <theresa@inet.tu-berlin.de> wrote:

Another important difference = between TCP and UDP are Message Boundaries.
So in some cases, TCP + Framer = may be equivalent to UDP.

FWIW, they might provide *similar* = capabilities, even only those that the app is concerned about, but there = are a LOT of other differences that can=E2=80=99t be glossed over. In = some cases, it is TCP that is lacking (as above); in others, = UDP).

It=E2=80=99= s only important whether the user does or doesn=E2=80=99t care about = those properties. When they match what they care about, they can be = considered equivalent.

I.e., there=E2=80=99s not likely going to be a strict and = absolute equivalence between transports.

Equivalence is TO THE USER, relative to = their constraints.

Joe

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

= --Apple-Mail=_1BD41395-0E94-444E-950A-926CEE979F1F-- From nobody Tue Jul 23 09:06:06 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E79112039B for ; Tue, 23 Jul 2019 09:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 Z8ZDiqjs8kqh for ; Tue, 23 Jul 2019 09:05:55 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.152.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECDD120343 for ; Tue, 23 Jul 2019 09:05:55 -0700 (PDT) Received: from [172.16.150.129] (unknown [207.115.96.130]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id ADD94207EA; Tue, 23 Jul 2019 18:05:53 +0200 (CEST) Date: Tue, 23 Jul 2019 12:05:55 -0400 Message-ID: X-Android-Message-ID: In-Reply-To: From: Max Franke To: Tommy Pauly Cc: Joe Touch , Theresa Enghardt , taps@ietf.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 16:06:04 -0000 PGRpdiBkaXI9J2F1dG8nPlNvIGlmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgdGhpcyBi b2lscyBkb3duIHRvIHRoZSBmYWN0IHRoYXQgaWYgdHdvIHByb3RvY29scyBhcmUgaW4gdGhlIGNh bmRpZGF0ZSBzZXQgZm9yIHJhY2luZyB0aGV5IGFyZSBhbHNvIGVxdWl2YWxlbnQ/IFRodXMgd2Ug ZG9udCBoYXZlIHRvIHdvcnJ5IGFib3V0IHVuZXF1aXZhbGVudCBwcm90b2NvbHMgYXMgdGhleSBh cmUgbmV2ZXIgcGFydCBvZiB0aGUgc2FtZSBjYW5kaWRhdGUgc2V0IGFueXdheT88ZGl2IGRpcj0i YXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5CZXN0PC9kaXY+PGRpdiBkaXI9ImF1dG8i Pk1heDxicj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9k aXY+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+QW0gMjMuMDcuMjAxOSAxMTo1OSBzY2hyaWViIFRvbW15IFBhdWx5ICZsdDt0 cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OjxiciB0eXBlPSJhdHRyaWJ1dGlv biIgLz48YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IHN0eWxlPSJ3 b3JkLXdyYXA6YnJlYWstd29yZCI+SGkgSm9lLDxkaXY+PGJyIC8+PC9kaXY+PGRpdj5ZZXMsIEkg Y29tcGxldGVseSBhZ3JlZS4gVGhlIGN1cnJlbnQgdGV4dCBpbiAtYXJjaCBleHByZXNzZXMgdGhp cyBhczo8L2Rpdj48ZGl2PjxiciAvPjwvZGl2PjxkaXY+PHByZSBzdHlsZT0iZm9udC1zaXplOjEz LjMzMzMzMzAxNTQ0MTg5NXB4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4Ij4gICAy LiAgQm90aCBzdGFja3MgTVVTVCBvZmZlciB0aGUgc2FtZSB0cmFuc3BvcnQgc2VydmljZXMsIGFz IHJlcXVpcmVkDQogICAgICAgYnkgdGhlIGFwcGxpY2F0aW9uLiAgRm9yIGV4YW1wbGUsIGlmIGFu IGFwcGxpY2F0aW9uIHNwZWNpZmllcw0KICAgICAgIHRoYXQgaXQgcmVxdWlyZXMgcmVsaWFibGUg dHJhbnNtaXNzaW9uIG9mIGRhdGEsIHRoZW4gYSBQcm90b2NvbA0KICAgICAgIFN0YWNrIHVzaW5n IFVEUCB3aXRob3V0IGFueSByZWxpYWJpbGl0eSBsYXllciBvbiB0b3Agd291bGQgbm90IGJlDQog ICAgICAgYWxsb3dlZCB0byByZXBsYWNlIGEgUHJvdG9jb2wgU3RhY2sgdXNpbmcgVENQLiAgSG93 ZXZlciwgaWYgdGhlDQogICAgICAgYXBwbGljYXRpb24gZG9lcyBub3QgcmVxdWlyZSByZWxpYWJp bGl0eSwgdGhlbiBhIFByb3RvY29sIFN0YWNrDQogICAgICAgdGhhdCBhZGRzIHVubmVjZXNzYXJ5 IHJlbGlhYmlsaXR5IG1pZ2h0IGJlIGFsbG93ZWQgYXMgYW4NCiAgICAgICBlcXVpdmFsZW50IFBy b3RvY29sIFN0YWNrIGFzIGxvbmcgYXMgaXQgZG9lcyBub3QgY29uZmxpY3Qgd2l0aA0KICAgICAg IGFueSBvdGhlciBhcHBsaWNhdGlvbi1yZXF1ZXN0ZWQgcHJvcGVydGllcy48L3ByZT48ZGl2Pjxi ciAvPjwvZGl2PjwvZGl2PjxkaXY+SWYgeW91IHRoaW5rIHdlIGNhbiBjbGFyaWZ5IHRoaXMgYW55 IGZ1cnRoZXIsIGxldCBtZSBrbm93ITwvZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5UaGFua3Ms PC9kaXY+PGRpdj5Ub21teTwvZGl2PjxkaXY+PGRpdj48YnIgLz48YmxvY2txdW90ZT48ZGl2Pk9u IEp1bCAyMywgMjAxOSwgYXQgMTE6NTUgQU0sIEpvZSBUb3VjaCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRvdWNoJiM2NDtzdHJheWFscGhhLmNvbSI+dG91Y2gmIzY0O3N0cmF5YWxwaGEuY29tPC9hPiZn dDsgd3JvdGU6PC9kaXY+PGJyIC8+PGRpdj48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29y ZCI+PGJyIC8+PGRpdj48YnIgLz48YmxvY2txdW90ZT48ZGl2Pk9uIEp1bCAyMywgMjAxOSwgYXQg ODoxOSBBTSwgVGhlcmVzYSBFbmdoYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRoZXJlc2EmIzY0 O2luZXQudHUtYmVybGluLmRlIj50aGVyZXNhJiM2NDtpbmV0LnR1LWJlcmxpbi5kZTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2PjxiciAvPjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7aGVs dmV0aWNhJiMzOTs7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zv cm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRp b246bm9uZTtmbG9hdDpub25lO2Rpc3BsYXk6aW5saW5lICFpbXBvcnRhbnQiPkFub3RoZXIgaW1w b3J0YW50IGRpZmZlcmVuY2UgYmV0d2VlbiBUQ1AgYW5kIFVEUCBhcmUgTWVzc2FnZSBCb3VuZGFy aWVzLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7aGVsdmV0aWNhJiMzOTs7Zm9u dC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1z cGFjaW5nOm5vcm1hbDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1z cGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSIgLz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtoZWx2ZXRpY2EmIzM5Oztmb250LXNpemU6MTJweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFs O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3 b3JkLXNwYWNpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25lO2Zsb2F0Om5vbmU7ZGlzcGxheTpp bmxpbmUgIWltcG9ydGFudCI+U28gaW4gc29tZSBjYXNlcywgVENQICYjNDM7IEZyYW1lciBtYXkg YmUgZXF1aXZhbGVudCB0byBVRFAuPC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48YnIgLz48L2Rp dj48ZGl2PkZXSVcsIHRoZXkgbWlnaHQgcHJvdmlkZSAqc2ltaWxhciogY2FwYWJpbGl0aWVzLCBl dmVuIG9ubHkgdGhvc2UgdGhhdCB0aGUgYXBwIGlzIGNvbmNlcm5lZCBhYm91dCwgYnV0IHRoZXJl IGFyZSBhIExPVCBvZiBvdGhlciBkaWZmZXJlbmNlcyB0aGF0IGNhbuKAmXQgYmUgZ2xvc3NlZCBv dmVyLiBJbiBzb21lIGNhc2VzLCBpdCBpcyBUQ1AgdGhhdCBpcyBsYWNraW5nIChhcyBhYm92ZSk7 IGluIG90aGVycywgVURQKS48L2Rpdj48ZGl2PjxiciAvPjwvZGl2PjxkaXY+SXTigJlzIG9ubHkg aW1wb3J0YW50IHdoZXRoZXIgdGhlIHVzZXIgZG9lcyBvciBkb2VzbuKAmXQgY2FyZSBhYm91dCB0 aG9zZSBwcm9wZXJ0aWVzLiBXaGVuIHRoZXkgbWF0Y2ggd2hhdCB0aGV5IGNhcmUgYWJvdXQsIHRo ZXkgY2FuIGJlIGNvbnNpZGVyZWQgZXF1aXZhbGVudC48L2Rpdj48ZGl2PjxiciAvPjwvZGl2Pjxk aXY+SS5lLiwgdGhlcmXigJlzIG5vdCBsaWtlbHkgZ29pbmcgdG8gYmUgYSBzdHJpY3QgYW5kIGFi c29sdXRlIGVxdWl2YWxlbmNlIGJldHdlZW4gdHJhbnNwb3J0cy48L2Rpdj48ZGl2PjxiciAvPjwv ZGl2PjxkaXY+RXF1aXZhbGVuY2UgaXMgVE8gVEhFIFVTRVIsIHJlbGF0aXZlIHRvIHRoZWlyIGNv bnN0cmFpbnRzLjwvZGl2PjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5Kb2U8L2Rpdj48YnIgLz48L2Rp dj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciAvPlRh cHMgbWFpbGluZyBsaXN0PGJyIC8+PGEgaHJlZj0ibWFpbHRvOlRhcHMmIzY0O2lldGYub3JnIj5U YXBzJiM2NDtpZXRmLm9yZzwvYT48YnIgLz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RhcHM8YnIgLz48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyIC8+PC9kaXY+PC9k aXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4= From nobody Tue Jul 23 09:15:06 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E34120344 for ; Tue, 23 Jul 2019 09:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 QXZEHs1KKsjw for ; Tue, 23 Jul 2019 09:14:51 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 AF7B012036E for ; Tue, 23 Jul 2019 09:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m6JGRQ7/ZhMY36U7AWY09qXr0BJv0hDXt4nNF/i1JPk=; b=kiIE8ADqX865XqnQqT9IIflYz baYidm+jSp6pkqw25VEnSww8WyIi5JDe6f83JC+MDUh2r/sV9HBUfRyJeySLaDPN+1umvG+bfkG5T 8E7BpAY31W6gN6LKKSpartxGXxgpR39irdSbrxTX2bRhRfIlAWt02NuqtURJ0Wmk4k4gDy+hzn5nA 8Dvc5fhyuPQd7vf46T9GCs8vv0RyTIwPWtLHgs1pQe7P1lpUgnfkCYpjvUM9nWOmrz+12aIxACUuD j+2NdD/QPnlvu4oi0lodF191WkO/EkC7T3CBVpgD1by117ItyiXzchVeYArRGWkZv9XRrajjcSurW lC2ylMfFA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55829 helo=[192.168.1.11]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hpxR8-004HmV-If; Tue, 23 Jul 2019 12:14:51 -0400 To: Tommy Pauly Cc: Theresa Enghardt , taps@ietf.org References: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net> <5D3722DF.8070000@erg.abdn.ac.uk> <8fdbe7df-872c-57da-a79e-e51ec0ba6553@inet.tu-berlin.de> From: Joe Touch Message-ID: <4263a14e-9f29-e009-45fa-52acca139be5@strayalpha.com> Date: Tue, 23 Jul 2019 09:14:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CE02AD1FB5D14EF6AF10432A" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 16:15:05 -0000 This is a multi-part message in MIME format. --------------CE02AD1FB5D14EF6AF10432A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit You've specified this as if it were an individual property. You need to deal with sets of properties, perhaps including choices (A and B) or (A and C) but not (A and B and D)... This is widely known as "constraint satisfaction", unsurprisingly. Joe On 7/23/2019 8:59 AM, Tommy Pauly wrote: > Hi Joe, > > Yes, I completely agree. The current text in -arch expresses this as: > > 2. Both stacks MUST offer the same transport services, as required > by the application. For example, if an application specifies > that it requires reliable transmission of data, then a Protocol > Stack using UDP without any reliability layer on top would not be > allowed to replace a Protocol Stack using TCP. However, if the > application does not require reliability, then a Protocol Stack > that adds unnecessary reliability might be allowed as an > equivalent Protocol Stack as long as it does not conflict with > any other application-requested properties. > > If you think we can clarify this any further, let me know! > > Thanks, > Tommy > >> On Jul 23, 2019, at 11:55 AM, Joe Touch > > wrote: >> >> >> >>> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt >>> > wrote: >>> >>> Another important difference between TCP and UDP are Message Boundaries. >>> So in some cases, TCP + Framer may be equivalent to UDP. >> >> FWIW, they might provide *similar* capabilities, even only those that >> the app is concerned about, but there are a LOT of other differences >> that can’t be glossed over. In some cases, it is TCP that is lacking >> (as above); in others, UDP). >> >> It’s only important whether the user does or doesn’t care about those >> properties. When they match what they care about, they can be >> considered equivalent. >> >> I.e., there’s not likely going to be a strict and absolute >> equivalence between transports. >> >> Equivalence is TO THE USER, relative to their constraints. >> >> Joe >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > --------------CE02AD1FB5D14EF6AF10432A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

You've specified this as if it were an individual property. You need to deal with sets of properties, perhaps including choices (A and B) or (A and C) but not (A and B and D)...

This is widely known as "constraint satisfaction", unsurprisingly.

Joe

On 7/23/2019 8:59 AM, Tommy Pauly wrote:
Hi Joe,

Yes, I completely agree. The current text in -arch expresses this as:

   2.  Both stacks MUST offer the same transport services, as required
       by the application.  For example, if an application specifies
       that it requires reliable transmission of data, then a Protocol
       Stack using UDP without any reliability layer on top would not be
       allowed to replace a Protocol Stack using TCP.  However, if the
       application does not require reliability, then a Protocol Stack
       that adds unnecessary reliability might be allowed as an
       equivalent Protocol Stack as long as it does not conflict with
       any other application-requested properties.

If you think we can clarify this any further, let me know!

Thanks,
Tommy

On Jul 23, 2019, at 11:55 AM, Joe Touch <touch@strayalpha.com> wrote:



On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <theresa@inet.tu-berlin.de> wrote:

Another important difference between TCP and UDP are Message Boundaries.
So in some cases, TCP + Framer may be equivalent to UDP.

FWIW, they might provide *similar* capabilities, even only those that the app is concerned about, but there are a LOT of other differences that can’t be glossed over. In some cases, it is TCP that is lacking (as above); in others, UDP).

It’s only important whether the user does or doesn’t care about those properties. When they match what they care about, they can be considered equivalent.

I.e., there’s not likely going to be a strict and absolute equivalence between transports.

Equivalence is TO THE USER, relative to their constraints.

Joe

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

--------------CE02AD1FB5D14EF6AF10432A-- From nobody Tue Jul 23 10:51:58 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE17F120700 for ; Tue, 23 Jul 2019 10:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 EVVTvYChhtKh for ; Tue, 23 Jul 2019 10:51:55 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 CFE3212070E for ; Tue, 23 Jul 2019 10:51:54 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6NHgFuw038821; Tue, 23 Jul 2019 10:51:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=bVSXUNfXAuYy1/JA1GvlFlV7TBoXN3h1egv26SoscOM=; b=UnwR6tpJ4h2TmIh5tCf2UzanWy/NSaCscr/YKdb/dpxyKjt7xVDZpXbsCPr5icoyhdpA eNjr8LBhs0xKIEJohsQvXysKjeUcCo24W2ZPysCOZNg2P+IIGmKaprDZp/ubuGAu9uRo eDyMuPI0okI23rLUMCjr8qLVLx/HTJw7gsVTanQy85kV7WdycvWpZexUL/BaZP8OeTsS 3CxXmdyjUEjoQsmLxuWWlDVTFdYgJiEL0F4+E9w5rliw0wf1b4XPB7W44phoBr0jYGZ/ +yTG9hEDaZhQ3DF2m7W8Cwmgu/ch6Dl1+kNPXu64eSmEHtlBXvgwpFpv/Bf3i8IO30iq zw== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2tx62v9v4a-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 10:51:50 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV300FC9WAEC7D0@mr2-mtap-s03.rno.apple.com>; Tue, 23 Jul 2019 10:51:50 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV300E00W58OM00@nwk-mmpp-sz12.apple.com>; Tue, 23 Jul 2019 10:51:50 -0700 (PDT) X-Va-A: X-Va-T-CD: 8dd9a97d16a6334c7005ce5b0715e098 X-Va-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-Va-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-Va-CD: 0 X-Va-ID: bab52bba-79cc-4676-bd90-ef13446f6cb3 X-V-A: X-V-T-CD: 8dd9a97d16a6334c7005ce5b0715e098 X-V-E-CD: 844c7cd8bab9de5eb47f49962d389d34 X-V-R-CD: 9ea3b1bc4aa98e49e23c581d3272df86 X-V-CD: 0 X-V-ID: 532d1207-d4c2-43a7-bf1e-fbd93b10b765 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-23_07:,, signatures=0 Received: from [17.235.47.236] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV300DP6WA9OV00@nwk-mmpp-sz12.apple.com>; Tue, 23 Jul 2019 10:51:50 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_0CFB71E4-93A1-4A3D-88CA-0572B065638B" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: Tommy Pauly X-Priority: 3 In-reply-to: Date: Tue, 23 Jul 2019 13:51:42 -0400 Cc: Tommy Pauly , Joe Touch , Theresa Enghardt , taps@ietf.org Message-id: References: To: Max Franke X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_07:, , signatures=0 Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 17:51:57 -0000 --Apple-Mail=_0CFB71E4-93A1-4A3D-88CA-0572B065638B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, that's correct. My interpretation is that being in the candidate = set already requires equivalence. We can make the text more clear here, = but it isn't a technical change. Thanks, Tommy > On Jul 23, 2019, at 12:05 PM, Max Franke = wrote: >=20 > So if I understand this correctly, this boils down to the fact that if = two protocols are in the candidate set for racing they are also = equivalent? Thus we dont have to worry about unequivalent protocols as = they are never part of the same candidate set anyway? >=20 > Best > Max >=20 >=20 >=20 > Am 23.07.2019 11:59 schrieb Tommy Pauly = : > Hi Joe, >=20 > Yes, I completely agree. The current text in -arch expresses this as: >=20 > 2. Both stacks MUST offer the same transport services, as required > by the application. For example, if an application specifies > that it requires reliable transmission of data, then a Protocol > Stack using UDP without any reliability layer on top would not = be > allowed to replace a Protocol Stack using TCP. However, if the > application does not require reliability, then a Protocol Stack > that adds unnecessary reliability might be allowed as an > equivalent Protocol Stack as long as it does not conflict with > any other application-requested properties. >=20 > If you think we can clarify this any further, let me know! >=20 > Thanks, > Tommy >=20 > On Jul 23, 2019, at 11:55 AM, Joe Touch > wrote: >=20 >=20 >=20 > On Jul 23, 2019, at 8:19 AM, Theresa Enghardt = > wrote: >=20 > Another important difference between TCP and UDP are Message = Boundaries. > So in some cases, TCP + Framer may be equivalent to UDP. >=20 > FWIW, they might provide *similar* capabilities, even only those that = the app is concerned about, but there are a LOT of other differences = that can=E2=80=99t be glossed over. In some cases, it is TCP that is = lacking (as above); in others, UDP). >=20 > It=E2=80=99s only important whether the user does or doesn=E2=80=99t = care about those properties. When they match what they care about, they = can be considered equivalent. >=20 > I.e., there=E2=80=99s not likely going to be a strict and absolute = equivalence between transports. >=20 > Equivalence is TO THE USER, relative to their constraints. >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_0CFB71E4-93A1-4A3D-88CA-0572B065638B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, = that's correct. My interpretation is that being in the candidate set = already requires equivalence. We can make the text more clear here, but = it isn't a technical change.

Thanks,
Tommy

On Jul = 23, 2019, at 12:05 PM, Max Franke <mfranke@inet.tu-berlin.de> wrote:

So if I understand this correctly, this boils down to the = fact that if two protocols are in the candidate set for racing they are = also equivalent? Thus we dont have to worry about unequivalent protocols = as they are never part of the same candidate set anyway?

Best
Max


Am 23.07.2019 11:59 schrieb Tommy = Pauly <tpauly=3D40apple.com@dmarc.ietf.org>:
Hi = Joe,

Yes, I = completely agree. The current text in -arch expresses this as:

   2.  Both stacks MUST offer the same transport services, as =
required
       by the application.  For example, if an application specifies
       that it requires reliable transmission of data, then a Protocol
       Stack using UDP without any reliability layer on top would not be
       allowed to replace a Protocol Stack using TCP.  However, if the
       application does not require reliability, then a Protocol Stack
       that adds unnecessary reliability might be allowed as an
       equivalent Protocol Stack as long as it does not conflict with
       any other application-requested properties.

If you think we = can clarify this any further, let me know!

Thanks,
Tommy

On Jul 23, 2019, at = 11:55 AM, Joe Touch <touch@strayalpha.com> wrote:



On Jul 23, 2019, at 8:19 AM, Theresa Enghardt <theresa@inet.tu-berlin.de> wrote:

Another important difference between TCP and = UDP are Message Boundaries.
So in some cases, TCP + Framer may be = equivalent to UDP.

FWIW, they might provide *similar* capabilities, even only = those that the app is concerned about, but there are a LOT of other = differences that can=E2=80=99t be glossed over. In some cases, it is TCP = that is lacking (as above); in others, UDP).

It=E2=80=99s only important whether the = user does or doesn=E2=80=99t care about those properties. When they = match what they care about, they can be considered equivalent.

I.e., there=E2=80=99s = not likely going to be a strict and absolute equivalence between = transports.

Equivalence is TO THE USER, relative to their = constraints.

Joe

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


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

= --Apple-Mail=_0CFB71E4-93A1-4A3D-88CA-0572B065638B-- From nobody Tue Jul 23 11:21:57 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7612079F for ; Tue, 23 Jul 2019 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 pY2qXNp_YwRR for ; Tue, 23 Jul 2019 11:21:53 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 25FE5120476 for ; Tue, 23 Jul 2019 11:21:52 -0700 (PDT) Received: from smtp7.infomaniak.ch (smtp7.infomaniak.ch [83.166.132.30]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x6NILmBi024678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Jul 2019 20:21:48 +0200 Received: from [IPv6:2001:67c:370:128:2092:d1eb:42de:d3d5] ([IPv6:2001:67c:370:128:2092:d1eb:42de:d3d5]) (authenticated bits=0) by smtp7.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x6NILkjC100261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jul 2019 20:21:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: Date: Tue, 23 Jul 2019 14:21:45 -0400 Cc: "Philipp S. Tiesel" , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net> To: Tommy Pauly X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 18:21:55 -0000 hi Tommy, all, > On 22 Jul 2019, at 19:15, Tommy Pauly = wrote: >=20 >=20 >=20 >> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel = wrote: >>=20 >> Hi, >>=20 >>> On 22. Jul 2019, at 15:09, Tommy Pauly = wrote: >>>=20 >>> An issue we discussed today in the TAPS meeting was whether or not = we should add a concept of "profiles" to the Transport Services APIs. An = example of a profile is a "reliable, secure, in-order stream"; or = "unreliable datagrams". Another way to think of these profiles are as = convenient ways to initialize common parameters. >>>=20 >>> One option is described in this PR: = https://github.com/ietf-tapswg/api-drafts/pull/328 >>>=20 >>> To help discern the working group's position, I'll try to distill = the high-level options here: >>>=20 >>> 1. Add Profiles as a top-level API document concept that modifies = how transport properties and/or preconnections are created. (This is PR = #328.) >>> 2. Mention in the API document that specific API implementations may = expose conveniences and profiles (presumably as a way to initialize = preconnections), but do not modify the API or specify an abstract symbol = for profiles. >>> 3. Do not mention profiles at all in the API document, but mention = something in the implementation document. >>=20 >> I am definitely in favour of option 1. Our implementation experience = with PyTAPS showed that setting all transport properties necessary to = get =E2=80=9CUDP like service=E2=80=9D becomes tedious otherwise. >> I fear not including them in the examples and the core API will = result in many developers rejecting TAPS as too complex to use. >> The profiles provide a useful convenience to applications (just like = the the shortcuts properties.prefer(property) instead of = properties.add(property, prefer)). >>=20 >> In addition, profiles allow us to be less conservative in how we = choose the defaults for transport properties, i.e., we don=E2=80=99t = need the TAPS defaults to be TCP compatible as long as the = reliable-in-order-stream profile is. >=20 > Speaking not as the person asking the question, but as an individual = in the group: >=20 > I'm pretty strongly against option (1), and prefer (2). I think we = should specify that convenience functions can exist, but I think = changing the one initialization function of the transport properties to = take a profile is not the right move for the API. Everything can be = achieved by making the API for a convenience profile be a layer on top = of the existing API. +1, for the same reasons. > Specifically, these are the differences: >=20 > (1) Exposes an API in which you always pass a profile (or an explicit = nil) to a TransportProperties object; but the TransportProperties *also* = lets you set each of the individual properties after that. I really like the idea of being able to pull a profile off the shelf and = then tweak it. It does seem to me that the right model here is "profiles as convenience = constructors or copyable constants" -- that model is pretty reasonably = implementable as an add-on, without=20 (That's separate from the question of whether profiles are a "mandatory" = feature in taps-interface, a suggested feature in an appendix, or = something that exists in a different document). Cheers, Brian > (2) Allows implementations to expose an API call to deliver a = TransportProperties that's set up based on a profile, but that isn't the = fundamental constructor. It is implemented by creating a = TransportProperties (TransportProperties()) and then setting the = properties internally. >=20 > Thanks, > Tommy >=20 >>=20 >> AVE! >> Philipp S. Tiesel >>=20 >> --=20 >> Philipp S. Tiesel=20 >> https://philipp.tiesel.net/ >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 23 11:40:13 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AF5120819 for ; Tue, 23 Jul 2019 11:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7OzuaU9Q8CCH for ; Tue, 23 Jul 2019 11:39:44 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 584B812084C for ; Tue, 23 Jul 2019 11:39:44 -0700 (PDT) Received: from dhcp-8115.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:e525:4735:6fb5:37de]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 51C1E1B00111; Tue, 23 Jul 2019 19:39:38 +0100 (BST) Message-ID: <5D375469.9050807@erg.abdn.ac.uk> Date: Tue, 23 Jul 2019 14:39:37 -0400 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Brian Trammell (IETF)" CC: Tommy Pauly , taps WG , "Philipp S. Tiesel" References: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 18:40:00 -0000 Hi all, see below - how near are we to agreement? On 23/07/2019, 14:21, Brian Trammell (IETF) wrote: > hi Tommy, all, > >> On 22 Jul 2019, at 19:15, Tommy Pauly wrote: >> >> >> >>> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel wrote: >>> >>> Hi, >>> >>>> On 22. Jul 2019, at 15:09, Tommy Pauly wrote: >>>> >>>> An issue we discussed today in the TAPS meeting was whether or not we should add a concept of "profiles" to the Transport Services APIs. An example of a profile is a "reliable, secure, in-order stream"; or "unreliable datagrams". Another way to think of these profiles are as convenient ways to initialize common parameters. >>>> >>>> One option is described in this PR: https://github.com/ietf-tapswg/api-drafts/pull/328 >>>> >>>> To help discern the working group's position, I'll try to distill the high-level options here: >>>> >>>> 1. Add Profiles as a top-level API document concept that modifies how transport properties and/or preconnections are created. (This is PR #328.) >>>> 2. Mention in the API document that specific API implementations may expose conveniences and profiles (presumably as a way to initialize preconnections), but do not modify the API or specify an abstract symbol for profiles. >>>> 3. Do not mention profiles at all in the API document, but mention something in the implementation document. >>> I am definitely in favour of option 1. Our implementation experience with PyTAPS showed that setting all transport properties necessary to get “UDP like service” becomes tedious otherwise. >>> I fear not including them in the examples and the core API will result in many developers rejecting TAPS as too complex to use. >>> The profiles provide a useful convenience to applications (just like the the shortcuts properties.prefer(property) instead of properties.add(property, prefer)). >>> >>> In addition, profiles allow us to be less conservative in how we choose the defaults for transport properties, i.e., we don’t need the TAPS defaults to be TCP compatible as long as the reliable-in-order-stream profile is. >> Speaking not as the person asking the question, but as an individual in the group: >> >> I'm pretty strongly against option (1), and prefer (2). I think we should specify that convenience functions can exist, but I think changing the one initialization function of the transport properties to take a profile is not the right move for the API. Everything can be achieved by making the API for a convenience profile be a layer on top of the existing API. > +1, for the same reasons. I'm fairly striongly against (3). Profiles are really important as a concept and I'd really encourage the group to write this. Some additional motivation is that it can very significantly impact the way the TAPS system is presented to the user. It can help allow applications to set many TAPS parameters, providing additional info to the selection (racing) without the pain of having to understand what each parameter should be set to. That's a big simplification. For example a low-rate transactional app could eplicitly need datagram to make choices for low latency using one profile - another app that wishes to optimise for throughput could start by setting a different profile. >> Specifically, these are the differences: >> >> (1) Exposes an API in which you always pass a profile (or an explicit nil) to a TransportProperties object; but the TransportProperties *also* lets you set each of the individual properties after that. The API options win: Apps can choose a profile, and they can - maybe should be encouraged to - over-ride anything that is important to them. > I really like the idea of being able to pull a profile off the shelf and then tweak it. > > It does seem to me that the right model here is "profiles as convenience constructors or copyable constants" -- that model is pretty reasonably implementable as an add-on, without > > (That's separate from the question of whether profiles are a "mandatory" feature in taps-interface, a suggested feature in an appendix, or something that exists in a different document). > > Cheers, > > Brian +1 if you'd like to have (sample) profile descriptions in an informative appendix, that would seem like a way to achieve that. >> (2) Allows implementations to expose an API call to deliver a TransportProperties that's set up based on a profile, but that isn't the fundamental constructor. It is implemented by creating a TransportProperties (TransportProperties()) and then setting the properties internally. >> >> Thanks, >> Tommy At the start of TAPS, I thought of profiles as the same as other parameters (i.e. they are inputs to the selection algorithm, that are less signficant than apps-supplied params, and more significant that the system default). I'd prefer we call this out explicitly in the documents. Gorry >>> AVE! >>> Philipp S. Tiesel >>> >>> -- >>> Philipp S. Tiesel >>> https://philipp.tiesel.net/ >>> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jul 23 13:12:15 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C308120910 for ; Tue, 23 Jul 2019 13:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kau.se 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 vSYdfbNIfskX for ; Tue, 23 Jul 2019 13:12:10 -0700 (PDT) Received: from smtp1.kau.se (smtp1.kau.se [130.243.21.250]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8412036D for ; Tue, 23 Jul 2019 13:12:09 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by smtp1.kau.se (Postfix) with ESMTP id C27C618502FE; Tue, 23 Jul 2019 22:12:07 +0200 (CEST) Received: from Exch-A2.personal.kau (exch-a2.kau.se [130.243.19.83]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x6NKC5e4081061 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 Jul 2019 22:12:06 +0200 Received: from Exch-A2.personal.kau (130.243.19.83) by Exch-A2.personal.kau (130.243.19.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Tue, 23 Jul 2019 22:11:52 +0200 Received: from Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60]) by Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60%7]) with mapi id 15.01.1591.017; Tue, 23 Jul 2019 22:11:52 +0200 From: =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= To: "gorry@erg.abdn.ac.uk" , "Brian Trammell (IETF)" CC: "Philipp S. Tiesel" , Tommy Pauly , taps WG Thread-Topic: [Taps] On Profiles for TAPS Preconnections Thread-Index: AQHVQMEKasj+RXnz0kKDEHWACfIXBKbXHl0AgAAFLQCAAUBkgIAABP6AgAA0wWA= Date: Tue, 23 Jul 2019 20:11:52 +0000 Message-ID: References: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net> <5D375469.9050807@erg.abdn.ac.uk> In-Reply-To: <5D375469.9050807@erg.abdn.ac.uk> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.243.27.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Bayes-Prob: 0.9999 (Score 5, tokens from: outbound, outbound-kau-se:default, kau-se:default, base:default, @@RPTN) X-p0f-Info: os=Windows 7 or 8, link=Ethernet or modem X-CanIt-Geo: No geolocation information available for fe80::d09:7e68:ff95:4a60 X-CanItPRO-Stream: outbound-kau-se:outbound (inherits from outbound-kau-se:default, kau-se:default, base:default) X-Canit-Stats-ID: 090Ekc5sz - 6b4a2f9ff492 - 20190723 X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?c=f&i=090Ekc5sz&m=6b4a2f9ff492&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?c=n&i=090Ekc5sz&m=6b4a2f9ff492&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Phish: https://mailfilter.sunet.se/canit/b.php?c=p&i=090Ekc5sz&m=6b4a2f9ff492&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?c=s&i=090Ekc5sz&m=6b4a2f9ff492&rlm=outbound-kau-se&t=20190723 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kau.se; h=from:to:cc :subject:date:message-id:references:in-reply-to:content-type :content-transfer-encoding:mime-version; s=canit; bh=JgUv8aaQ/kn S6/w0okh5jj0DBgq9mQK4CNd4kzmIO2A=; b=SB0DNAtvaX5z0Iq/j6nfJf9ud0n S1/XbsSoPqBFhWTIBVXYutvo81EgPkODx0g0r5kKJPlDXYlsDziZpZ6XBEzeWtOv jnl+Wh52SwE44vp6dG6GVSdtDzjnz5NkqLq01VY6w//vlGn8bxUPr9YSdQ5MqNkg EJ05ITeNPAz6eDKuKHn/7s0CfIAvhjO/a4GD0s3BY7KQ7yUtU9hTu4gOdLERRQRF FHznOhunpnHYtCsdZ1I/tE8nHD9p6ohgw/9OubhRV+iC4l1XcFdyXe1v9Sc9qKyK 3fTgDTPWjYkJp2gwxt1FHh5WhjVOSQz4YTXrYC08xfpRRTzWMuT5BhBBTuA== X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:12:14 -0000 SGkgYWxsLCBpbmxpbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBU YXBzIDx0YXBzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBHb3JyeSBGYWlyaHVyc3QN Cj4gU2VudDogZGVuIDIzIGp1bGkgMjAxOSAyMDo0MA0KPiBUbzogQnJpYW4gVHJhbW1lbGwgKElF VEYpIDxpZXRmQHRyYW1tZWxsLmNoPg0KPiBDYzogUGhpbGlwcCBTLiBUaWVzZWwgPHBoaWxpcHBA dGllc2VsLm5ldD47IFRvbW15IFBhdWx5DQo+IDx0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0 Zi5vcmc+OyB0YXBzIFdHIDx0YXBzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW1RhcHNdIE9u IFByb2ZpbGVzIGZvciBUQVBTIFByZWNvbm5lY3Rpb25zDQo+IA0KPiBIaSBhbGwsIHNlZSBiZWxv dyAtIGhvdyBuZWFyIGFyZSB3ZSB0byBhZ3JlZW1lbnQ/DQo+IA0KPiBPbiAyMy8wNy8yMDE5LCAx NDoyMSwgQnJpYW4gVHJhbW1lbGwgKElFVEYpIHdyb3RlOg0KPiA+IGhpIFRvbW15LCBhbGwsDQo+ ID4NCj4gPj4gT24gMjIgSnVsIDIwMTksIGF0IDE5OjE1LCBUb21teQ0KPiBQYXVseTx0cGF1bHk9 NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc+ICB3cm90ZToNCj4gPj4NCj4gPj4NCj4gPj4NCj4g Pj4+IE9uIEp1bCAyMiwgMjAxOSwgYXQgNjo1NiBQTSwgUGhpbGlwcCBTLiBUaWVzZWw8cGhpbGlw cEB0aWVzZWwubmV0PiAgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGksDQo+ID4+Pg0KPiA+Pj4+IE9u IDIyLiBKdWwgMjAxOSwgYXQgMTU6MDksIFRvbW15DQo+IFBhdWx5PHRwYXVseT00MGFwcGxlLmNv bUBkbWFyYy5pZXRmLm9yZz4gIHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gQW4gaXNzdWUgd2UgZGlz Y3Vzc2VkIHRvZGF5IGluIHRoZSBUQVBTIG1lZXRpbmcgd2FzIHdoZXRoZXIgb3Igbm90IHdlDQo+ IHNob3VsZCBhZGQgYSBjb25jZXB0IG9mICJwcm9maWxlcyIgdG8gdGhlIFRyYW5zcG9ydCBTZXJ2 aWNlcyBBUElzLiBBbiBleGFtcGxlDQo+IG9mIGEgcHJvZmlsZSBpcyBhICJyZWxpYWJsZSwgc2Vj dXJlLCBpbi1vcmRlciBzdHJlYW0iOyBvciAidW5yZWxpYWJsZSBkYXRhZ3JhbXMiLg0KPiBBbm90 aGVyIHdheSB0byB0aGluayBvZiB0aGVzZSBwcm9maWxlcyBhcmUgYXMgY29udmVuaWVudCB3YXlz IHRvIGluaXRpYWxpemUNCj4gY29tbW9uIHBhcmFtZXRlcnMuDQo+ID4+Pj4NCj4gPj4+PiBPbmUg b3B0aW9uIGlzIGRlc2NyaWJlZCBpbiB0aGlzIFBSOg0KPiA+Pj4+IGh0dHBzOi8vZ2l0aHViLmNv bS9pZXRmLXRhcHN3Zy9hcGktZHJhZnRzL3B1bGwvMzI4DQo+ID4+Pj4NCj4gPj4+PiBUbyBoZWxw IGRpc2Nlcm4gdGhlIHdvcmtpbmcgZ3JvdXAncyBwb3NpdGlvbiwgSSdsbCB0cnkgdG8gZGlzdGls bCB0aGUgaGlnaC0NCj4gbGV2ZWwgb3B0aW9ucyBoZXJlOg0KPiA+Pj4+DQo+ID4+Pj4gMS4gQWRk IFByb2ZpbGVzIGFzIGEgdG9wLWxldmVsIEFQSSBkb2N1bWVudCBjb25jZXB0IHRoYXQgbW9kaWZp ZXMNCj4gPj4+PiBob3cgdHJhbnNwb3J0IHByb3BlcnRpZXMgYW5kL29yIHByZWNvbm5lY3Rpb25z IGFyZSBjcmVhdGVkLiAoVGhpcyBpcyBQUg0KPiAjMzI4LikgMi4gTWVudGlvbiBpbiB0aGUgQVBJ IGRvY3VtZW50IHRoYXQgc3BlY2lmaWMgQVBJIGltcGxlbWVudGF0aW9ucyBtYXkNCj4gZXhwb3Nl IGNvbnZlbmllbmNlcyBhbmQgcHJvZmlsZXMgKHByZXN1bWFibHkgYXMgYSB3YXkgdG8gaW5pdGlh bGl6ZQ0KPiBwcmVjb25uZWN0aW9ucyksIGJ1dCBkbyBub3QgbW9kaWZ5IHRoZSBBUEkgb3Igc3Bl Y2lmeSBhbiBhYnN0cmFjdCBzeW1ib2wgZm9yDQo+IHByb2ZpbGVzLg0KPiA+Pj4+IDMuIERvIG5v dCBtZW50aW9uIHByb2ZpbGVzIGF0IGFsbCBpbiB0aGUgQVBJIGRvY3VtZW50LCBidXQgbWVudGlv bg0KPiBzb21ldGhpbmcgaW4gdGhlIGltcGxlbWVudGF0aW9uIGRvY3VtZW50Lg0KPiA+Pj4gSSBh bSBkZWZpbml0ZWx5IGluIGZhdm91ciBvZiBvcHRpb24gMS4gT3VyIGltcGxlbWVudGF0aW9uIGV4 cGVyaWVuY2Ugd2l0aA0KPiBQeVRBUFMgc2hvd2VkIHRoYXQgc2V0dGluZyBhbGwgdHJhbnNwb3J0 IHByb3BlcnRpZXMgbmVjZXNzYXJ5IHRvIGdldCDigJxVRFANCj4gbGlrZSBzZXJ2aWNl4oCdIGJl Y29tZXMgdGVkaW91cyBvdGhlcndpc2UuDQo+ID4+PiBJIGZlYXIgbm90IGluY2x1ZGluZyB0aGVt IGluIHRoZSBleGFtcGxlcyBhbmQgdGhlIGNvcmUgQVBJIHdpbGwgcmVzdWx0IGluDQo+IG1hbnkg ZGV2ZWxvcGVycyByZWplY3RpbmcgVEFQUyBhcyB0b28gY29tcGxleCB0byB1c2UuDQo+ID4+PiBU aGUgcHJvZmlsZXMgcHJvdmlkZSBhIHVzZWZ1bCBjb252ZW5pZW5jZSB0byBhcHBsaWNhdGlvbnMg KGp1c3QgbGlrZSB0aGUNCj4gdGhlIHNob3J0Y3V0cyBwcm9wZXJ0aWVzLnByZWZlcihwcm9wZXJ0 eSkgaW5zdGVhZCBvZiBwcm9wZXJ0aWVzLmFkZChwcm9wZXJ0eSwNCj4gcHJlZmVyKSkuDQo+ID4+ Pg0KPiA+Pj4gSW4gYWRkaXRpb24sIHByb2ZpbGVzIGFsbG93IHVzIHRvIGJlIGxlc3MgY29uc2Vy dmF0aXZlIGluIGhvdyB3ZSBjaG9vc2UNCj4gdGhlIGRlZmF1bHRzIGZvciB0cmFuc3BvcnQgcHJv cGVydGllcywgaS5lLiwgd2UgZG9u4oCZdCBuZWVkIHRoZSBUQVBTIGRlZmF1bHRzIHRvDQo+IGJl IFRDUCBjb21wYXRpYmxlIGFzIGxvbmcgYXMgdGhlIHJlbGlhYmxlLWluLW9yZGVyLXN0cmVhbSBw cm9maWxlIGlzLg0KDQpJIGRvIG5vdCB0aGluayB0aGVyZSBpcyBhbnkgY29ubmVjdGlvbiBoZXJl LiBXZWF0aGVyIHdlIGhhdmUgcHJvZmlsZXMgb3Igbm90IHdlIHdpbGwgbmVlZCBnb29kIGRlZmF1 bHRzLiAoVGhlIGFib3ZlIHdvdWxkIG9ubHkgaG9sZCBpZiBhbGwgcHJvZmlsZXMgY292ZXJlZCBh bGwgdHJhbnNwb3J0IHByb3BlcnRpZXMgYW5kIHlvdSB3ZXJlIHJlcXVpcmVkIHRvIGFsd2F5cyBz ZWxlY3QgYSBwcm9maWxlLiBJIGRvIG5vdCB0aGluayBhbnlvbmUgaXMgYXJndWluZyBmb3IgdGhp cy4pDQoNCj4gPj4gU3BlYWtpbmcgbm90IGFzIHRoZSBwZXJzb24gYXNraW5nIHRoZSBxdWVzdGlv biwgYnV0IGFzIGFuIGluZGl2aWR1YWwgaW4gdGhlDQo+IGdyb3VwOg0KPiA+Pg0KPiA+PiBJJ20g cHJldHR5IHN0cm9uZ2x5IGFnYWluc3Qgb3B0aW9uICgxKSwgYW5kIHByZWZlciAoMikuIEkgdGhp bmsgd2Ugc2hvdWxkDQo+IHNwZWNpZnkgdGhhdCBjb252ZW5pZW5jZSBmdW5jdGlvbnMgY2FuIGV4 aXN0LCBidXQgSSB0aGluayBjaGFuZ2luZyB0aGUgb25lDQo+IGluaXRpYWxpemF0aW9uIGZ1bmN0 aW9uIG9mIHRoZSB0cmFuc3BvcnQgcHJvcGVydGllcyB0byB0YWtlIGEgcHJvZmlsZSBpcyBub3Qg dGhlDQo+IHJpZ2h0IG1vdmUgZm9yIHRoZSBBUEkuIEV2ZXJ5dGhpbmcgY2FuIGJlIGFjaGlldmVk IGJ5IG1ha2luZyB0aGUgQVBJIGZvciBhDQo+IGNvbnZlbmllbmNlIHByb2ZpbGUgYmUgYSBsYXll ciBvbiB0b3Agb2YgdGhlIGV4aXN0aW5nIEFQSS4NCj4gPiArMSwgZm9yIHRoZSBzYW1lIHJlYXNv bnMuDQoNCisxIGZvciBvcHRpb24gMiBhcyB3ZWxsLiBJIHRoaW5rIHdlIHNob3VsZCBrZWVwIHRo ZSBjb3JlIEFQSSBhcyBzbWFsbCBhbmQgY2xlYW4gYXMgcG9zc2libGUuIFRvIG1lIHByb2ZpbGVz IGFyZSBuYXR1cmFsbHkgYnVpbHQgb24gdG9wIG9mIHRoZSBBUEkgYW5kIGRvIG5vdCBuZWVkIHRv IGJlIHBhcnQgb2YgdGhlIGNvcmUgQVBJLg0KDQo+IEknbSBmYWlybHkgc3RyaW9uZ2x5IGFnYWlu c3QgKDMpLiBQcm9maWxlcyBhcmUgcmVhbGx5IGltcG9ydGFudCBhcyBhIGNvbmNlcHQgYW5kDQo+ IEknZCByZWFsbHkgZW5jb3VyYWdlIHRoZSBncm91cCB0byB3cml0ZSB0aGlzLg0KDQpTbyBmYXIg aXQgc2VlbXMgd2UgYWxsIGFncmVlIHRoYXQgcHJvZmlsZXMgYXJlIGEgdXNlZnVsIGNvbmNlcHQg YW5kIHNob3VsZCBiZSBtZW50aW9uZWQgaW4gdGhlIGRvY3VtZW50cy4gDQoNCkFubmENCiANCj4g U29tZSBhZGRpdGlvbmFsIG1vdGl2YXRpb24gaXMgdGhhdCBpdCBjYW4gdmVyeSBzaWduaWZpY2Fu dGx5IGltcGFjdCB0aGUgd2F5DQo+IHRoZSBUQVBTIHN5c3RlbSBpcyBwcmVzZW50ZWQgdG8gdGhl IHVzZXIuIEl0IGNhbiBoZWxwIGFsbG93IGFwcGxpY2F0aW9ucyB0byBzZXQNCj4gbWFueSBUQVBT IHBhcmFtZXRlcnMsIHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm8gdG8gdGhlIHNlbGVjdGlvbiAo cmFjaW5nKQ0KPiB3aXRob3V0IHRoZSBwYWluIG9mIGhhdmluZyB0byB1bmRlcnN0YW5kIHdoYXQg ZWFjaCBwYXJhbWV0ZXIgc2hvdWxkIGJlIHNldA0KPiB0by4gVGhhdCdzIGEgYmlnIHNpbXBsaWZp Y2F0aW9uLiBGb3IgZXhhbXBsZSBhIGxvdy1yYXRlIHRyYW5zYWN0aW9uYWwgYXBwIGNvdWxkDQo+ IGVwbGljaXRseSBuZWVkIGRhdGFncmFtIHRvIG1ha2UgY2hvaWNlcyBmb3IgbG93IGxhdGVuY3kg dXNpbmcgb25lIHByb2ZpbGUgLQ0KPiBhbm90aGVyIGFwcCB0aGF0IHdpc2hlcyB0byBvcHRpbWlz ZSBmb3IgdGhyb3VnaHB1dCBjb3VsZCBzdGFydCBieSBzZXR0aW5nIGENCj4gZGlmZmVyZW50IHBy b2ZpbGUuDQo+ID4+IFNwZWNpZmljYWxseSwgdGhlc2UgYXJlIHRoZSBkaWZmZXJlbmNlczoNCj4g Pj4NCj4gPj4gKDEpIEV4cG9zZXMgYW4gQVBJIGluIHdoaWNoIHlvdSBhbHdheXMgcGFzcyBhIHBy b2ZpbGUgKG9yIGFuIGV4cGxpY2l0IG5pbCkgdG8gYQ0KPiBUcmFuc3BvcnRQcm9wZXJ0aWVzIG9i amVjdDsgYnV0IHRoZSBUcmFuc3BvcnRQcm9wZXJ0aWVzICphbHNvKiBsZXRzIHlvdSBzZXQNCj4g ZWFjaCBvZiB0aGUgaW5kaXZpZHVhbCBwcm9wZXJ0aWVzIGFmdGVyIHRoYXQuDQo+IFRoZSBBUEkg b3B0aW9ucyB3aW46IEFwcHMgY2FuIGNob29zZSBhIHByb2ZpbGUsIGFuZCB0aGV5IGNhbiAtIG1h eWJlIHNob3VsZA0KPiBiZSBlbmNvdXJhZ2VkIHRvIC0gb3Zlci1yaWRlIGFueXRoaW5nIHRoYXQg aXMgaW1wb3J0YW50IHRvIHRoZW0uDQo+ID4gSSByZWFsbHkgbGlrZSB0aGUgaWRlYSBvZiBiZWlu ZyBhYmxlIHRvIHB1bGwgYSBwcm9maWxlIG9mZiB0aGUgc2hlbGYgYW5kIHRoZW4NCj4gdHdlYWsg aXQuDQo+ID4NCj4gPiBJdCBkb2VzIHNlZW0gdG8gbWUgdGhhdCB0aGUgcmlnaHQgbW9kZWwgaGVy ZSBpcyAicHJvZmlsZXMgYXMNCj4gPiBjb252ZW5pZW5jZSBjb25zdHJ1Y3RvcnMgb3IgY29weWFi bGUgY29uc3RhbnRzIiAtLSB0aGF0IG1vZGVsIGlzDQo+ID4gcHJldHR5IHJlYXNvbmFibHkgaW1w bGVtZW50YWJsZSBhcyBhbiBhZGQtb24sIHdpdGhvdXQNCj4gPg0KPiA+IChUaGF0J3Mgc2VwYXJh dGUgZnJvbSB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBwcm9maWxlcyBhcmUgYSAibWFuZGF0b3J5 Ig0KPiBmZWF0dXJlIGluIHRhcHMtaW50ZXJmYWNlLCBhIHN1Z2dlc3RlZCBmZWF0dXJlIGluIGFu IGFwcGVuZGl4LCBvciBzb21ldGhpbmcNCj4gdGhhdCBleGlzdHMgaW4gYSBkaWZmZXJlbnQgZG9j dW1lbnQpLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+DQo+ID4gQnJpYW4NCj4gKzEgaWYgeW91J2Qg bGlrZSB0byBoYXZlIChzYW1wbGUpIHByb2ZpbGUgZGVzY3JpcHRpb25zIGluIGFuIGluZm9ybWF0 aXZlDQo+IGFwcGVuZGl4LCB0aGF0IHdvdWxkIHNlZW0gbGlrZSBhIHdheSB0byBhY2hpZXZlIHRo YXQuDQo+ID4+ICgyKSBBbGxvd3MgaW1wbGVtZW50YXRpb25zIHRvIGV4cG9zZSBhbiBBUEkgY2Fs bCB0byBkZWxpdmVyIGENCj4gVHJhbnNwb3J0UHJvcGVydGllcyB0aGF0J3Mgc2V0IHVwIGJhc2Vk IG9uIGEgcHJvZmlsZSwgYnV0IHRoYXQgaXNuJ3QgdGhlDQo+IGZ1bmRhbWVudGFsIGNvbnN0cnVj dG9yLiBJdCBpcyBpbXBsZW1lbnRlZCBieSBjcmVhdGluZyBhIFRyYW5zcG9ydFByb3BlcnRpZXMN Cj4gKFRyYW5zcG9ydFByb3BlcnRpZXMoKSkgYW5kIHRoZW4gc2V0dGluZyB0aGUgcHJvcGVydGll cyBpbnRlcm5hbGx5Lg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ID4+IFRvbW15DQo+IEF0IHRoZSBz dGFydCBvZiBUQVBTLCBJIHRob3VnaHQgb2YgcHJvZmlsZXMgYXMgdGhlIHNhbWUgYXMgb3RoZXIg cGFyYW1ldGVycyAoaS5lLg0KPiB0aGV5IGFyZSBpbnB1dHMgdG8gdGhlIHNlbGVjdGlvbiBhbGdv cml0aG0sIHRoYXQgYXJlIGxlc3Mgc2lnbmZpY2FudCB0aGFuIGFwcHMtDQo+IHN1cHBsaWVkIHBh cmFtcywgYW5kIG1vcmUgc2lnbmlmaWNhbnQgdGhhdCB0aGUgc3lzdGVtIGRlZmF1bHQpLg0KPiAN Cj4gSSdkIHByZWZlciB3ZSBjYWxsIHRoaXMgb3V0IGV4cGxpY2l0bHkgaW4gdGhlIGRvY3VtZW50 cy4NCj4gDQo+IEdvcnJ5DQo+IA0KPiA+Pj4gQVZFIQ0KPiA+Pj4gICBQaGlsaXBwIFMuIFRpZXNl bA0KPiA+Pj4NCj4gPj4+IC0tDQo+ID4+PiBQaGlsaXBwIFMuIFRpZXNlbA0KPiA+Pj4gaHR0cHM6 Ly9waGlsaXBwLnRpZXNlbC5uZXQvDQo+ID4+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBUYXBzIG1haWxpbmcgbGlzdA0KPiA+PiBU YXBzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGFwcw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gVGFwcyBtYWlsaW5nIGxpc3QNCj4gPiBUYXBzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUYXBzIG1haWxpbmcgbGlzdA0KPiBU YXBzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFw cw0K From nobody Tue Jul 23 13:47:28 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1495120999 for ; Tue, 23 Jul 2019 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kau.se 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 oyiWHfS7Flqz for ; Tue, 23 Jul 2019 13:47:13 -0700 (PDT) Received: from smtp1.kau.se (smtp1.kau.se [130.243.21.250]) by ietfa.amsl.com (Postfix) with ESMTP id 130BF1209B2 for ; Tue, 23 Jul 2019 13:47:13 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [192.36.171.202]) by smtp1.kau.se (Postfix) with ESMTP id 2C90618145AF; Tue, 23 Jul 2019 22:47:12 +0200 (CEST) Received: from Exch-A3.personal.kau (exch-a3.kau.se [130.243.19.84]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x6NKlAR7143797 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 Jul 2019 22:47:10 +0200 Received: from Exch-A2.personal.kau (130.243.19.83) by Exch-A3.personal.kau (130.243.19.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Tue, 23 Jul 2019 22:47:10 +0200 Received: from Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60]) by Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60%7]) with mapi id 15.01.1591.017; Tue, 23 Jul 2019 22:46:57 +0200 From: =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= To: Michael Welzl , Max Franke CC: "Philipp S. Tiesel" , Tommy Pauly , "taps@ietf.org" Thread-Topic: [Taps] On Profiles for TAPS Preconnections Thread-Index: AQHVQMEKasj+RXnz0kKDEHWACfIXBKbXHl0AgAAFLQCAAPA7gIAAAZ2AgAADJYCAAAcUgIAAjIvw Date: Tue, 23 Jul 2019 20:46:57 +0000 Message-ID: <8fb41c493c4542bfbaee1f0b230c361c@kau.se> References: <7DB06BAF-BC10-4367-BD5E-C7EFB698200B@ifi.uio.no> In-Reply-To: <7DB06BAF-BC10-4367-BD5E-C7EFB698200B@ifi.uio.no> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.243.27.149] Content-Type: multipart/alternative; boundary="_000_8fb41c493c4542bfbaee1f0b230c361ckause_" MIME-Version: 1.0 X-Bayes-Prob: 0.9999 (Score 5, tokens from: outbound, outbound-kau-se:default, kau-se:default, base:default, @@RPTN) X-p0f-Info: os=Windows 7 or 8, link=Ethernet or modem X-CanIt-Geo: No geolocation information available for fe80::d09:7e68:ff95:4a60 X-CanItPRO-Stream: outbound-kau-se:outbound (inherits from outbound-kau-se:default, kau-se:default, base:default) X-Canit-Stats-ID: 0a0EkLaaL - 6995646c99b0 - 20190723 X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?c=f&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?c=n&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Phish: https://mailfilter.sunet.se/canit/b.php?c=p&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?c=s&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kau.se; h=from:to:cc :subject:date:message-id:references:in-reply-to:content-type :mime-version; s=canit; bh=X8V5KqeuGNvjIMD2B3+dl7ouIDVR7wZBSMGqy VL70oA=; b=ZznIa5BFQbra7K/8os9JKpqyjFShY9FLAIBLAJopo0OvhLGE5Yia+ FvqOGdWZXJohL757n3qvdIQzdZ8sox/4XMYjxIFBUnZx9yv3u4EM9Zj5Nn6wu5/J NU/YidozQUCuousJFw6LotVPyjqkCPO0wfEUylxsW7R+90+gu+At8egSdsZjOx5A r9S6RszCUe1jycZVmptjqPwL5NMbSMZ/dzkLcwrhlmtAf05vd/4Xqnaqc7monmLr baKMkB9TvluLauoqc4woLwiTqz0vBYcGs56TGDKfa882KM5LxnPuTdYvH8eikyR+ 8+XP2fg4PKrEETqGGOJp7cqXghcnkiNOA== X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:47:27 -0000 --_000_8fb41c493c4542bfbaee1f0b230c361ckause_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFRhcHMgPHRhcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1pY2hh ZWwgV2VsemwNClNlbnQ6IGRlbiAyMyBqdWxpIDIwMTkgMTY6MTcNClRvOiBNYXggRnJhbmtlIDxt ZnJhbmtlQGluZXQudHUtYmVybGluLmRlPg0KQ2M6IFBoaWxpcHAgUy4gVGllc2VsIDxwaGlsaXBw QHRpZXNlbC5uZXQ+OyBUb21teSBQYXVseSA8dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYu b3JnPjsgdGFwc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUYXBzXSBPbiBQcm9maWxlcyBmb3Ig VEFQUyBQcmVjb25uZWN0aW9ucw0KDQoNCg0KDQpPbiBKdWwgMjMsIDIwMTksIGF0IDk6NTEgQU0s IE1heCBGcmFua2UgPG1mcmFua2VAaW5ldC50dS1iZXJsaW4uZGU8bWFpbHRvOm1mcmFua2VAaW5l dC50dS1iZXJsaW4uZGU+PiB3cm90ZToNCg0KDQoNClRoZSBBUEkgcHJlc2NyaWJlZCBieSB0aGlz IGRvY3VtZW50IGlzIGFic3RyYWN0LCBhbmQgbmVlZHMgdG8gZ2l2ZSBmcmVlZG9tIHRvIGltcGxl bWVudGF0aW9ucyB0byBtYWtlIHRoaW5ncyBlbGVnYW50IGluIHRoZWlyIHBhcnRpY3VsYXIgbGFu Z3VhZ2VzLg0KDQpXaGF0IGFib3V0IGhhdmluZyBhbiBhcHBlbmRpbmcsIHRoYXQncyBub24tbm9y bWF0aXZlIGFuZCBub3QgcmVxdWlyZWQgZm9yIFJGQyBjb21wbGlhbmNlLCB0aGF0IGRlc2NyaWJl cyBzdWdnZXN0ZWQgY29udmVuaWVuY2VzLCBzdWNoIGFzICJwcm9wZXJ0aWVzLnByZWZlcigpIiBh bmQgdGhlIGNvbmNlcHQgb2YgY29udmVuaWVuY2UgcHJvZmlsZXM/DQpZZXMsIEkgbGlrZSB0aGlz IGlkZWEuIEkgYWxzbyBhZ3JlZSB0aGF0IHRoZSBBUEkgaXMgY29tcGxleCBlbm91Z2ggYXMgaXQg aXMgYW5kIHJlcXVpcmluZyBjb252ZW5pZW5jZSBmZWF0dXJlcyB0byBiZSBSRkMgY29tcGxpYW50 IGlzIHByb2JhYmx5IG5vdCBhIGdvb2QgaWRlYS4gQXMgbG9uZyBhcyB3ZSBhcmUgY29uc2lzdGVu dCB3aXRoIG1vdmluZyBhbGwgY29udmVuaWVuY2VzIHRvIHRoZSBhcHBlbmRpeCB0aGlzIGlzIG15 IHByZWZlcnJlZCBvcHRpb24uDQoNCisxIG9uIHRoaXMgaWYgaXTigJlzIGEgd29ya2FibGUgc29s dXRpb24gKHNvdW5kcyBsaWtlIGl0IGlzKSwgYW5kIGEgcGFydGljdWxhciArMSBvbiB0aGUgc2lk ZSBjb21tZW50IGFib3V0ICJjb25zaXN0ZW50bHkgbW92aW5nIGFsbCBjb252ZW5pZW5jZXMgdG8g dGhlIGFwcGVuZGl44oCdDQoNCkkgYWdyZWUgYW4gYXBwZW5kaXggY2FuIGJlIGEgZ29vZCBpZGVh LiBJIHdvdWxkIHN0aWxsIHByZWZlciBub3QgdG8gZGVmaW5lIGEgbGlzdCBvZiBwcm9maWxlcywg cmF0aGVyIG1lbnRpb24gdGhlIGNvbmNlcHQgb2YgcHJvZmlsZXMgYXMgb25lIG9mIHRoZSBjb252 ZW5pZW5jZSBmdW5jdGlvbnMgYW5kIHBlcmhhcHMgZ2l2ZSBhbiBleGFtcGxlLg0KDQpBbm5hDQoN CkNoZWVycywNCk1pY2hhZWwNCg0K --_000_8fb41c493c4542bfbaee1f0b230c361ckause_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3 MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBUYXBzICZsdDt0YXBzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhh bGYgT2YgPC9iPk1pY2hhZWwgV2Vsemw8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDIzIGp1bGkgMjAx OSAxNjoxNzxicj4NCjxiPlRvOjwvYj4gTWF4IEZyYW5rZSAmbHQ7bWZyYW5rZUBpbmV0LnR1LWJl cmxpbi5kZSZndDs8YnI+DQo8Yj5DYzo8L2I+IFBoaWxpcHAgUy4gVGllc2VsICZsdDtwaGlsaXBw QHRpZXNlbC5uZXQmZ3Q7OyBUb21teSBQYXVseSAmbHQ7dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJj LmlldGYub3JnJmd0OzsgdGFwc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1Rh cHNdIE9uIFByb2ZpbGVzIGZvciBUQVBTIFByZWNvbm5lY3Rpb25zPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NjUuMnB0Ij5PbiBKdWwgMjMsIDIwMTksIGF0IDk6NTEgQU0sIE1heCBGcmFu a2UgJmx0OzxhIGhyZWY9Im1haWx0bzptZnJhbmtlQGluZXQudHUtYmVybGluLmRlIj5tZnJhbmtl QGluZXQudHUtYmVybGluLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+VGhlIEFQSSBwcmVzY3JpYmVk IGJ5IHRoaXMgZG9jdW1lbnQgaXMgYWJzdHJhY3QsIGFuZCBuZWVkcyB0byBnaXZlIGZyZWVkb20g dG8gaW1wbGVtZW50YXRpb25zIHRvIG1ha2UgdGhpbmdzIGVsZWdhbnQgaW4gdGhlaXIgcGFydGlj dWxhciBsYW5ndWFnZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDo2NS4ycHQiPldoYXQgYWJvdXQgaGF2aW5nIGFuIGFwcGVuZGluZywgdGhhdCdzIG5vbi1ub3Jt YXRpdmUgYW5kIG5vdCByZXF1aXJlZCBmb3IgUkZDIGNvbXBsaWFuY2UsIHRoYXQgZGVzY3JpYmVz IHN1Z2dlc3RlZCBjb252ZW5pZW5jZXMsIHN1Y2ggYXMgJnF1b3Q7cHJvcGVydGllcy5wcmVmZXIo KSZxdW90OyBhbmQgdGhlIGNvbmNlcHQgb2YgY29udmVuaWVuY2UgcHJvZmlsZXM/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4y cHQiPlllcywgSSBsaWtlIHRoaXMgaWRlYS4gSSBhbHNvIGFncmVlIHRoYXQgdGhlIEFQSSBpcyBj b21wbGV4IGVub3VnaCBhcyBpdCBpcyBhbmQgcmVxdWlyaW5nIGNvbnZlbmllbmNlIGZlYXR1cmVz IHRvIGJlIFJGQyBjb21wbGlhbnQgaXMgcHJvYmFibHkgbm90IGEgZ29vZCBpZGVhLiBBcyBsb25n IGFzIHdlIGFyZSBjb25zaXN0ZW50IHdpdGggbW92aW5nIGFsbCBjb252ZW5pZW5jZXMNCiB0byB0 aGUgYXBwZW5kaXggdGhpcyBpcyBteSBwcmVmZXJyZWQgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0 Ij4mIzQzOzEgb24gdGhpcyBpZiBpdOKAmXMgYSB3b3JrYWJsZSBzb2x1dGlvbiAoc291bmRzIGxp a2UgaXQgaXMpLCBhbmQgYSBwYXJ0aWN1bGFyICYjNDM7MSBvbiB0aGUgc2lkZSBjb21tZW50IGFi b3V0ICZxdW90O2NvbnNpc3RlbnRseSBtb3ZpbmcgYWxsIGNvbnZlbmllbmNlcyB0byB0aGUgYXBw ZW5kaXjigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkkgYWdyZWUgYW4gYXBwZW5kaXggY2FuIGJlIGEgZ29vZCBpZGVhLiBJIHdvdWxkIHN0aWxsIHBy ZWZlciBub3QgdG8gZGVmaW5lIGEgbGlzdCBvZiBwcm9maWxlcywgcmF0aGVyIG1lbnRpb24gdGhl IGNvbmNlcHQgb2YgcHJvZmlsZXMgYXMgb25lIG9mIHRoZQ0KIGNvbnZlbmllbmNlIGZ1bmN0aW9u cyBhbmQgcGVyaGFwcyBnaXZlIGFuIGV4YW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFubmE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NjUuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjY1LjJwdCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+TWljaGFlbDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8fb41c493c4542bfbaee1f0b230c361ckause_-- From nobody Tue Jul 23 13:53:27 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA74120153 for ; Tue, 23 Jul 2019 13:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kau.se 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 mjQ2d1WgWstz for ; Tue, 23 Jul 2019 13:53:22 -0700 (PDT) Received: from smtp1.kau.se (smtp1.kau.se [130.243.21.250]) by ietfa.amsl.com (Postfix) with ESMTP id 892D4120999 for ; Tue, 23 Jul 2019 13:53:22 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [192.36.171.202]) by smtp1.kau.se (Postfix) with ESMTP id 626331804B33; Tue, 23 Jul 2019 22:53:21 +0200 (CEST) Received: from Exch-A3.personal.kau (exch-a3.kau.se [130.243.19.84]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x6NKrJgh145551 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 Jul 2019 22:53:20 +0200 Received: from Exch-A2.personal.kau (130.243.19.83) by Exch-A3.personal.kau (130.243.19.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Tue, 23 Jul 2019 22:53:19 +0200 Received: from Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60]) by Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60%7]) with mapi id 15.01.1591.017; Tue, 23 Jul 2019 22:53:06 +0200 From: =?utf-8?B?QW5uYSBCcnVuc3Ryw7Zt?= To: Tommy Pauly , Max Franke CC: Joe Touch , Theresa Enghardt , "taps@ietf.org" Thread-Topic: [Taps] How to handle Protocol stacks that are not equivalent Thread-Index: AQHVQNQriOlnBtdw5kCBd2y9GfbT16bYI10AgAAKWoCAAAMSAIAACicAgAABEgCAAAHSgIAAHY4AgABTrGA= Date: Tue, 23 Jul 2019 20:53:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.243.27.149] Content-Type: multipart/alternative; boundary="_000_ce92bad3a6294c78a4078d60da05615dkause_" MIME-Version: 1.0 X-Bayes-Prob: 0.9999 (Score 5, tokens from: outbound, outbound-kau-se:default, kau-se:default, base:default, @@RPTN) X-p0f-Info: os=Windows 7 or 8, link=Ethernet or modem X-CanIt-Geo: No geolocation information available for fe80::d09:7e68:ff95:4a60 X-CanItPRO-Stream: outbound-kau-se:outbound (inherits from outbound-kau-se:default, kau-se:default, base:default) X-Canit-Stats-ID: 0a0EkRjcr - ac600e4db7d6 - 20190723 X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?c=f&i=0a0EkRjcr&m=ac600e4db7d6&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?c=n&i=0a0EkRjcr&m=ac600e4db7d6&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Phish: https://mailfilter.sunet.se/canit/b.php?c=p&i=0a0EkRjcr&m=ac600e4db7d6&rlm=outbound-kau-se&t=20190723 X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?c=s&i=0a0EkRjcr&m=ac600e4db7d6&rlm=outbound-kau-se&t=20190723 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kau.se; h=from:to:cc :subject:date:message-id:references:in-reply-to:content-type :mime-version; s=canit; bh=cR2ttHEzd15MDyQs1P2DVsov5a/LDXCQJg0A7 NGJ2O8=; b=PTmwtR69eq4+kECXE/wp0/ahI14sFuoKqWF7+WQrgmKnsyWUpu7U7 QD+gljJs5Mh5MWSxTH9RsxuweZdDQ71GLX8g6x6V+TECzcQPbDbp4ivZ3QhxKI1z tRTct3VgwsuT4goCWPPCp2JsvgFuqNCvIGNKWtPqZx79FyFPw6ejr+2mjug6HikZ 6NLzjX6IFsD73OFaYMgcQVqtnISwUWzUIsSmGacN/4F0pvnVEUSxqtzzvqLF68jw UQXqiF9J55g9LboxTMZuD0MpVPAEu8YEqtffwLyzKomAsOzM8eRtRWknkssuAng1 CXULbL2ee9r/LFn2MXJ0N251P2oJZuQog== X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 20:53:26 -0000 --_000_ce92bad3a6294c78a4078d60da05615dkause_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFRhcHMgPHRhcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFRvbW15 IFBhdWx5DQpTZW50OiBkZW4gMjMganVsaSAyMDE5IDE5OjUyDQpUbzogTWF4IEZyYW5rZSA8bWZy YW5rZUBpbmV0LnR1LWJlcmxpbi5kZT4NCkNjOiBKb2UgVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEu Y29tPjsgVG9tbXkgUGF1bHkgPHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz47IFRo ZXJlc2EgRW5naGFyZHQgPHRoZXJlc2FAaW5ldC50dS1iZXJsaW4uZGU+OyB0YXBzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW1RhcHNdIEhvdyB0byBoYW5kbGUgUHJvdG9jb2wgc3RhY2tzIHRoYXQg YXJlIG5vdCBlcXVpdmFsZW50DQoNClllcywgdGhhdCdzIGNvcnJlY3QuIE15IGludGVycHJldGF0 aW9uIGlzIHRoYXQgYmVpbmcgaW4gdGhlIGNhbmRpZGF0ZSBzZXQgYWxyZWFkeSByZXF1aXJlcyBl cXVpdmFsZW5jZS4NCg0KU2FtZSBoZXJlLCBzZWVtcyB3ZSBhbGwgYWdyZWUgb24gdGhpcy4NCg0K VGhhbmtzLA0KQW5uYQ0KDQpXZSBjYW4gbWFrZSB0aGUgdGV4dCBtb3JlIGNsZWFyIGhlcmUsIGJ1 dCBpdCBpc24ndCBhIHRlY2huaWNhbCBjaGFuZ2UuDQoNClRoYW5rcywNClRvbW15DQoNCg0KT24g SnVsIDIzLCAyMDE5LCBhdCAxMjowNSBQTSwgTWF4IEZyYW5rZSA8bWZyYW5rZUBpbmV0LnR1LWJl cmxpbi5kZTxtYWlsdG86bWZyYW5rZUBpbmV0LnR1LWJlcmxpbi5kZT4+IHdyb3RlOg0KDQpTbyBp ZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0bHksIHRoaXMgYm9pbHMgZG93biB0byB0aGUgZmFj dCB0aGF0IGlmIHR3byBwcm90b2NvbHMgYXJlIGluIHRoZSBjYW5kaWRhdGUgc2V0IGZvciByYWNp bmcgdGhleSBhcmUgYWxzbyBlcXVpdmFsZW50PyBUaHVzIHdlIGRvbnQgaGF2ZSB0byB3b3JyeSBh Ym91dCB1bmVxdWl2YWxlbnQgcHJvdG9jb2xzIGFzIHRoZXkgYXJlIG5ldmVyIHBhcnQgb2YgdGhl IHNhbWUgY2FuZGlkYXRlIHNldCBhbnl3YXk/DQoNCkJlc3QNCk1heA0KDQoNCg0KQW0gMjMuMDcu MjAxOSAxMTo1OSBzY2hyaWViIFRvbW15IFBhdWx5IDx0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOnRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz4+Og0KSGkg Sm9lLA0KDQpZZXMsIEkgY29tcGxldGVseSBhZ3JlZS4gVGhlIGN1cnJlbnQgdGV4dCBpbiAtYXJj aCBleHByZXNzZXMgdGhpcyBhczoNCg0KDQogICAyLiAgQm90aCBzdGFja3MgTVVTVCBvZmZlciB0 aGUgc2FtZSB0cmFuc3BvcnQgc2VydmljZXMsIGFzIHJlcXVpcmVkDQoNCiAgICAgICBieSB0aGUg YXBwbGljYXRpb24uICBGb3IgZXhhbXBsZSwgaWYgYW4gYXBwbGljYXRpb24gc3BlY2lmaWVzDQoN CiAgICAgICB0aGF0IGl0IHJlcXVpcmVzIHJlbGlhYmxlIHRyYW5zbWlzc2lvbiBvZiBkYXRhLCB0 aGVuIGEgUHJvdG9jb2wNCg0KICAgICAgIFN0YWNrIHVzaW5nIFVEUCB3aXRob3V0IGFueSByZWxp YWJpbGl0eSBsYXllciBvbiB0b3Agd291bGQgbm90IGJlDQoNCiAgICAgICBhbGxvd2VkIHRvIHJl cGxhY2UgYSBQcm90b2NvbCBTdGFjayB1c2luZyBUQ1AuICBIb3dldmVyLCBpZiB0aGUNCg0KICAg ICAgIGFwcGxpY2F0aW9uIGRvZXMgbm90IHJlcXVpcmUgcmVsaWFiaWxpdHksIHRoZW4gYSBQcm90 b2NvbCBTdGFjaw0KDQogICAgICAgdGhhdCBhZGRzIHVubmVjZXNzYXJ5IHJlbGlhYmlsaXR5IG1p Z2h0IGJlIGFsbG93ZWQgYXMgYW4NCg0KICAgICAgIGVxdWl2YWxlbnQgUHJvdG9jb2wgU3RhY2sg YXMgbG9uZyBhcyBpdCBkb2VzIG5vdCBjb25mbGljdCB3aXRoDQoNCiAgICAgICBhbnkgb3RoZXIg YXBwbGljYXRpb24tcmVxdWVzdGVkIHByb3BlcnRpZXMuDQoNCklmIHlvdSB0aGluayB3ZSBjYW4g Y2xhcmlmeSB0aGlzIGFueSBmdXJ0aGVyLCBsZXQgbWUga25vdyENCg0KVGhhbmtzLA0KVG9tbXkN Cg0KT24gSnVsIDIzLCAyMDE5LCBhdCAxMTo1NSBBTSwgSm9lIFRvdWNoIDx0b3VjaEBzdHJheWFs cGhhLmNvbTxtYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb20+PiB3cm90ZToNCg0KDQoNCk9uIEp1 bCAyMywgMjAxOSwgYXQgODoxOSBBTSwgVGhlcmVzYSBFbmdoYXJkdCA8dGhlcmVzYUBpbmV0LnR1 LWJlcmxpbi5kZTxtYWlsdG86dGhlcmVzYUBpbmV0LnR1LWJlcmxpbi5kZT4+IHdyb3RlOg0KDQpB bm90aGVyIGltcG9ydGFudCBkaWZmZXJlbmNlIGJldHdlZW4gVENQIGFuZCBVRFAgYXJlIE1lc3Nh Z2UgQm91bmRhcmllcy4NClNvIGluIHNvbWUgY2FzZXMsIFRDUCArIEZyYW1lciBtYXkgYmUgZXF1 aXZhbGVudCB0byBVRFAuDQoNCkZXSVcsIHRoZXkgbWlnaHQgcHJvdmlkZSAqc2ltaWxhciogY2Fw YWJpbGl0aWVzLCBldmVuIG9ubHkgdGhvc2UgdGhhdCB0aGUgYXBwIGlzIGNvbmNlcm5lZCBhYm91 dCwgYnV0IHRoZXJlIGFyZSBhIExPVCBvZiBvdGhlciBkaWZmZXJlbmNlcyB0aGF0IGNhbuKAmXQg YmUgZ2xvc3NlZCBvdmVyLiBJbiBzb21lIGNhc2VzLCBpdCBpcyBUQ1AgdGhhdCBpcyBsYWNraW5n IChhcyBhYm92ZSk7IGluIG90aGVycywgVURQKS4NCg0KSXTigJlzIG9ubHkgaW1wb3J0YW50IHdo ZXRoZXIgdGhlIHVzZXIgZG9lcyBvciBkb2VzbuKAmXQgY2FyZSBhYm91dCB0aG9zZSBwcm9wZXJ0 aWVzLiBXaGVuIHRoZXkgbWF0Y2ggd2hhdCB0aGV5IGNhcmUgYWJvdXQsIHRoZXkgY2FuIGJlIGNv bnNpZGVyZWQgZXF1aXZhbGVudC4NCg0KSS5lLiwgdGhlcmXigJlzIG5vdCBsaWtlbHkgZ29pbmcg dG8gYmUgYSBzdHJpY3QgYW5kIGFic29sdXRlIGVxdWl2YWxlbmNlIGJldHdlZW4gdHJhbnNwb3J0 cy4NCg0KRXF1aXZhbGVuY2UgaXMgVE8gVEhFIFVTRVIsIHJlbGF0aXZlIHRvIHRoZWlyIGNvbnN0 cmFpbnRzLg0KDQpKb2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClRhcHMgbWFpbGluZyBsaXN0DQpUYXBzQGlldGYub3JnPG1haWx0bzpUYXBzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRhcHMgbWFp bGluZyBsaXN0DQpUYXBzQGlldGYub3JnPG1haWx0bzpUYXBzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQoNCg== --_000_ce92bad3a6294c78a4078d60da05615dkause_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg NzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBUYXBzICZsdDt0YXBzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlRvbW15IFBhdWx5PGJyPg0KPGI+U2VudDo8L2I+IGRlbiAyMyBq dWxpIDIwMTkgMTk6NTI8YnI+DQo8Yj5Ubzo8L2I+IE1heCBGcmFua2UgJmx0O21mcmFua2VAaW5l dC50dS1iZXJsaW4uZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKb2UgVG91Y2ggJmx0O3RvdWNoQHN0 cmF5YWxwaGEuY29tJmd0OzsgVG9tbXkgUGF1bHkgJmx0O3RwYXVseT00MGFwcGxlLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDs7IFRoZXJlc2EgRW5naGFyZHQgJmx0O3RoZXJlc2FAaW5ldC50dS1iZXJs aW4uZGUmZ3Q7OyB0YXBzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVGFwc10g SG93IHRvIGhhbmRsZSBQcm90b2NvbCBzdGFja3MgdGhhdCBhcmUgbm90IGVxdWl2YWxlbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij5ZZXMsIHRoYXQncyBjb3Jy ZWN0LiBNeSBpbnRlcnByZXRhdGlvbiBpcyB0aGF0IGJlaW5nIGluIHRoZSBjYW5kaWRhdGUgc2V0 IGFscmVhZHkgcmVxdWlyZXMgZXF1aXZhbGVuY2UuDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+U2FtZSBoZXJlLCBzZWVtcyB3ZSBhbGwgYWdyZWUgb24gdGhpcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhh bmtzLDxicj4NCkFubmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDo2NS4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBjYW4gbWFrZSB0aGUgdGV4dCBtb3JlIGNs ZWFyIGhlcmUsIGJ1dCBpdCBpc24ndCBhIHRlY2huaWNhbCBjaGFuZ2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2 NS4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUu MnB0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij5Ub21teTxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+T24gSnVsIDIzLCAyMDE5LCBhdCAxMjowNSBQTSwg TWF4IEZyYW5rZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1mcmFua2VAaW5ldC50dS1iZXJsaW4uZGUi Pm1mcmFua2VAaW5ldC50dS1iZXJsaW4uZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPlNvIGlmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJl Y3RseSwgdGhpcyBib2lscyBkb3duIHRvIHRoZSBmYWN0IHRoYXQgaWYgdHdvIHByb3RvY29scyBh cmUgaW4gdGhlIGNhbmRpZGF0ZSBzZXQgZm9yIHJhY2luZyB0aGV5IGFyZSBhbHNvIGVxdWl2YWxl bnQ/IFRodXMgd2UgZG9udCBoYXZlIHRvIHdvcnJ5IGFib3V0IHVuZXF1aXZhbGVudCBwcm90b2Nv bHMgYXMgdGhleQ0KIGFyZSBuZXZlciBwYXJ0IG9mIHRoZSBzYW1lIGNhbmRpZGF0ZSBzZXQgYW55 d2F5PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+QmVzdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjY1LjJwdCI+TWF4PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 NjUuMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NjUuMnB0Ij5BbSAyMy4wNy4yMDE5IDExOjU5IHNjaHJpZWIgVG9tbXkgUGF1bHkg Jmx0OzxhIGhyZWY9Im1haWx0bzp0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmciPnRw YXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NjUuMnB0Ij5IaSBKb2UsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUu MnB0Ij5ZZXMsIEkgY29tcGxldGVseSBhZ3JlZS4gVGhlIGN1cnJlbnQgdGV4dCBpbiAtYXJjaCBl eHByZXNzZXMgdGhpcyBhczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij4mbmJz cDsmbmJzcDsgMi4mbmJzcDsgQm90aCBzdGFja3MgTVVTVCBvZmZlciB0aGUgc2FtZSB0cmFuc3Bv cnQgc2VydmljZXMsIGFzIHJlcXVpcmVkPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjY1LjJwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5 IHRoZSBhcHBsaWNhdGlvbi4mbmJzcDsgRm9yIGV4YW1wbGUsIGlmIGFuIGFwcGxpY2F0aW9uIHNw ZWNpZmllczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGl0IHJlcXVpcmVzIHJl bGlhYmxlIHRyYW5zbWlzc2lvbiBvZiBkYXRhLCB0aGVuIGEgUHJvdG9jb2w8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgU3RhY2sgdXNpbmcgVURQIHdpdGhvdXQgYW55IHJlbGlhYmlsaXR5 IGxheWVyIG9uIHRvcCB3b3VsZCBub3QgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NjUuMnB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YWxsb3dlZCB0byByZXBsYWNlIGEgUHJvdG9jb2wgU3RhY2sgdXNpbmcgVENQLiZuYnNwOyBIb3dl dmVyLCBpZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUu MnB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGljYXRpb24gZG9l cyBub3QgcmVxdWlyZSByZWxpYWJpbGl0eSwgdGhlbiBhIFByb3RvY29sIFN0YWNrPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgYWRkcyB1bm5lY2Vzc2FyeSByZWxpYWJpbGl0eSBt aWdodCBiZSBhbGxvd2VkIGFzIGFuPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjY1LjJwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVxdWl2 YWxlbnQgUHJvdG9jb2wgU3RhY2sgYXMgbG9uZyBhcyBpdCBkb2VzIG5vdCBjb25mbGljdCB3aXRo PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFueSBvdGhlciBhcHBsaWNhdGlvbi1yZXF1 ZXN0ZWQgcHJvcGVydGllcy48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NjUuMnB0Ij5JZiB5b3UgdGhpbmsgd2UgY2FuIGNsYXJpZnkgdGhpcyBhbnkgZnVydGhl ciwgbGV0IG1lIGtub3chPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDo2NS4ycHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPlRvbW15PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij5PbiBKdWwgMjMsIDIwMTks IGF0IDExOjU1IEFNLCBKb2UgVG91Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzp0b3VjaEBzdHJheWFs cGhhLmNvbSI+dG91Y2hAc3RyYXlhbHBoYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjY1LjJwdCI+T24gSnVsIDIzLCAyMDE5LCBhdCA4OjE5IEFNLCBUaGVyZXNhIEVu Z2hhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86dGhlcmVzYUBpbmV0LnR1LWJlcmxpbi5kZSI+dGhl cmVzYUBpbmV0LnR1LWJlcmxpbi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NjUuMnB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbm90aGVyIGltcG9ydGFudCBkaWZm ZXJlbmNlIGJldHdlZW4gVENQIGFuZCBVRFAgYXJlIE1lc3NhZ2UgQm91bmRhcmllcy48YnI+DQpT byBpbiBzb21lIGNhc2VzLCBUQ1AgJiM0MzsgRnJhbWVyIG1heSBiZSBlcXVpdmFsZW50IHRvIFVE UC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjY1LjJwdCI+RldJVywgdGhleSBtaWdodCBwcm92aWRlICpzaW1pbGFyKiBjYXBhYmlsaXRp ZXMsIGV2ZW4gb25seSB0aG9zZSB0aGF0IHRoZSBhcHAgaXMgY29uY2VybmVkIGFib3V0LCBidXQg dGhlcmUgYXJlIGEgTE9UIG9mIG90aGVyIGRpZmZlcmVuY2VzIHRoYXQgY2Fu4oCZdCBiZSBnbG9z c2VkIG92ZXIuIEluIHNvbWUgY2FzZXMsIGl0IGlzIFRDUCB0aGF0IGlzIGxhY2tpbmcgKGFzDQog YWJvdmUpOyBpbiBvdGhlcnMsIFVEUCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo2NS4ycHQiPkl04oCZcyBvbmx5IGltcG9ydGFudCB3aGV0aGVyIHRoZSB1c2Vy IGRvZXMgb3IgZG9lc27igJl0IGNhcmUgYWJvdXQgdGhvc2UgcHJvcGVydGllcy4gV2hlbiB0aGV5 IG1hdGNoIHdoYXQgdGhleSBjYXJlIGFib3V0LCB0aGV5IGNhbiBiZSBjb25zaWRlcmVkIGVxdWl2 YWxlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQi PkkuZS4sIHRoZXJl4oCZcyBub3QgbGlrZWx5IGdvaW5nIHRvIGJlIGEgc3RyaWN0IGFuZCBhYnNv bHV0ZSBlcXVpdmFsZW5jZSBiZXR3ZWVuIHRyYW5zcG9ydHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPkVxdWl2YWxlbmNlIGlzIFRPIFRIRSBVU0VS LCByZWxhdGl2ZSB0byB0aGVpciBjb25zdHJhaW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+Sm9lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NjUuMnB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NClRhcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRhcHNAaWV0Zi5v cmciPlRhcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90YXBzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RhcHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjY1LjJwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NjUuMnB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjY1LjJwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpUYXBzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUYXBzQGlldGYu b3JnIj5UYXBzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGFwcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90YXBzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ce92bad3a6294c78a4078d60da05615dkause_-- From nobody Tue Jul 23 14:03:25 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983BE120983 for ; Tue, 23 Jul 2019 14:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 6SddVKBnZupe for ; Tue, 23 Jul 2019 14:03:09 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 21E1E1209CA for ; Tue, 23 Jul 2019 14:03:08 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6NL30hA013135 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 23:03:00 +0200 Received: from [2001:67c:1232:144:f4b7:5e0b:bde7:fda4] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hq1u4-0005vi-FA; Tue, 23 Jul 2019 23:00:56 +0200 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AD7EAECC-73F8-445E-AECC-F30ABFCEFD0E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 23 Jul 2019 17:02:57 -0400 In-Reply-To: Cc: Gorry Fairhurst , "Brian Trammell (IETF)" , Tommy Pauly , taps WG To: =?utf-8?Q?Anna_Brunstr=C3=B6m?= References: <370C3CC6-363D-4036-ABCC-7B02F6BD04F6@apple.com> <1A621491-019B-49C0-BE4E-A3C843EA0D35@tiesel.net> <5D375469.9050807@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] On Profiles for TAPS Preconnections X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:03:23 -0000 --Apple-Mail=_AD7EAECC-73F8-445E-AECC-F30ABFCEFD0E Content-Type: multipart/alternative; boundary="Apple-Mail=_FC2E8F7C-25AC-4CF6-92D7-5A49B297F7B5" --Apple-Mail=_FC2E8F7C-25AC-4CF6-92D7-5A49B297F7B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, as we seem to have rough consensus in what we want (but may still = disagree how this should be achieved), I updated PR #328 in a way that might work for all of us. I also updated PR #327 the to include #328 and point at the profiles as = a the way to specify common requirements instead of requesting exact = protocol combinations. I think we should not include explicit protocol selection without having = a more convenient way to specify common sets of requirements. > On 23. Jul 2019, at 16:11, Anna Brunstr=C3=B6m = wrote: >=20 > Hi all, inline >=20 >> -----Original Message----- >> From: Taps > On = Behalf Of Gorry Fairhurst >> Sent: den 23 juli 2019 20:40 >> To: Brian Trammell (IETF) > >> Cc: Philipp S. Tiesel >; Tommy Pauly >> >; taps WG > >> Subject: Re: [Taps] On Profiles for TAPS Preconnections >>=20 >> Hi all, see below - how near are we to agreement? >>=20 >> On 23/07/2019, 14:21, Brian Trammell (IETF) wrote: >>> hi Tommy, all, >>>=20 >>>> On 22 Jul 2019, at 19:15, Tommy >> Pauly wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel = wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>>> On 22. Jul 2019, at 15:09, Tommy >> Pauly wrote: >>>>>>=20 >>>>>> An issue we discussed today in the TAPS meeting was whether or = not we >> should add a concept of "profiles" to the Transport Services APIs. An = example >> of a profile is a "reliable, secure, in-order stream"; or "unreliable = datagrams". >> Another way to think of these profiles are as convenient ways to = initialize >> common parameters. >>>>>>=20 >>>>>> One option is described in this PR: >>>>>> https://github.com/ietf-tapswg/api-drafts/pull/328 >>>>>>=20 >>>>>> To help discern the working group's position, I'll try to distill = the high- >> level options here: >>>>>>=20 >>>>>> 1. Add Profiles as a top-level API document concept that modifies >>>>>> how transport properties and/or preconnections are created. (This = is PR >> #328.) 2. Mention in the API document that specific API = implementations may >> expose conveniences and profiles (presumably as a way to initialize >> preconnections), but do not modify the API or specify an abstract = symbol for >> profiles. >>>>>> 3. Do not mention profiles at all in the API document, but = mention >> something in the implementation document. >>>>> I am definitely in favour of option 1. Our implementation = experience with >> PyTAPS showed that setting all transport properties necessary to get = =E2=80=9CUDP >> like service=E2=80=9D becomes tedious otherwise. >>>>> I fear not including them in the examples and the core API will = result in >> many developers rejecting TAPS as too complex to use. >>>>> The profiles provide a useful convenience to applications (just = like the >> the shortcuts properties.prefer(property) instead of = properties.add(property, >> prefer)). >>>>>=20 >>>>> In addition, profiles allow us to be less conservative in how we = choose >> the defaults for transport properties, i.e., we don=E2=80=99t need = the TAPS defaults to >> be TCP compatible as long as the reliable-in-order-stream profile is. >=20 > I do not think there is any connection here. Weather we have profiles = or not we will need good defaults. (The above would only hold if all = profiles covered all transport properties and you were required to = always select a profile. I do not think anyone is arguing for this.) >=20 >>>> Speaking not as the person asking the question, but as an = individual in the >> group: >>>>=20 >>>> I'm pretty strongly against option (1), and prefer (2). I think we = should >> specify that convenience functions can exist, but I think changing = the one >> initialization function of the transport properties to take a profile = is not the >> right move for the API. Everything can be achieved by making the API = for a >> convenience profile be a layer on top of the existing API. >>> +1, for the same reasons. >=20 > +1 for option 2 as well. I think we should keep the core API as small = and clean as possible. To me profiles are naturally built on top of the = API and do not need to be part of the core API. >=20 >> I'm fairly striongly against (3). Profiles are really important as a = concept and >> I'd really encourage the group to write this. >=20 > So far it seems we all agree that profiles are a useful concept and = should be mentioned in the documents. >=20 > Anna >=20 >> Some additional motivation is that it can very significantly impact = the way >> the TAPS system is presented to the user. It can help allow = applications to set >> many TAPS parameters, providing additional info to the selection = (racing) >> without the pain of having to understand what each parameter should = be set >> to. That's a big simplification. For example a low-rate transactional = app could >> eplicitly need datagram to make choices for low latency using one = profile - >> another app that wishes to optimise for throughput could start by = setting a >> different profile. >>>> Specifically, these are the differences: >>>>=20 >>>> (1) Exposes an API in which you always pass a profile (or an = explicit nil) to a >> TransportProperties object; but the TransportProperties *also* lets = you set >> each of the individual properties after that. >> The API options win: Apps can choose a profile, and they can - maybe = should >> be encouraged to - over-ride anything that is important to them. >>> I really like the idea of being able to pull a profile off the shelf = and then >> tweak it. >>>=20 >>> It does seem to me that the right model here is "profiles as >>> convenience constructors or copyable constants" -- that model is >>> pretty reasonably implementable as an add-on, without >>>=20 >>> (That's separate from the question of whether profiles are a = "mandatory" >> feature in taps-interface, a suggested feature in an appendix, or = something >> that exists in a different document). >>>=20 >>> Cheers, >>>=20 >>> Brian >> +1 if you'd like to have (sample) profile descriptions in an = informative >> appendix, that would seem like a way to achieve that. >>>> (2) Allows implementations to expose an API call to deliver a >> TransportProperties that's set up based on a profile, but that isn't = the >> fundamental constructor. It is implemented by creating a = TransportProperties >> (TransportProperties()) and then setting the properties internally. >>>>=20 >>>> Thanks, >>>> Tommy >> At the start of TAPS, I thought of profiles as the same as other = parameters (i.e. >> they are inputs to the selection algorithm, that are less signficant = than apps- >> supplied params, and more significant that the system default). >>=20 >> I'd prefer we call this out explicitly in the documents. >>=20 >> Gorry >>=20 >>>>> AVE! >>>>> Philipp S. Tiesel >>>>>=20 >>>>> -- >>>>> Philipp S. Tiesel >>>>> https://philipp.tiesel.net/ >>>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_FC2E8F7C-25AC-4CF6-92D7-5A49B297F7B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

as we = seem to have rough consensus in what we want (but may still disagree how = this should be achieved),
I updated PR #328 in a = way that might work for all of us.

I also updated PR #327 the to include = #328 and point at the profiles as a the way to specify common = requirements instead of requesting exact protocol = combinations.
I think we should not include = explicit protocol selection without having a more convenient way to = specify common sets of requirements. 

On 23. = Jul 2019, at 16:11, Anna Brunstr=C3=B6m <anna.brunstrom@kau.se> wrote:

Hi all, = inline

-----Original Message-----
From: Taps <taps-bounces@ietf.org> On Behalf Of Gorry Fairhurst
Sent: den 23 juli 2019 20:40
To: Brian Trammell = (IETF) <ietf@trammell.ch>
Cc: Philipp S. Tiesel = <philipp@tiesel.net>; Tommy Pauly
<tpauly=3D40apple.com@dmarc.ietf.org>; taps WG <taps@ietf.org>
Subject: Re: [Taps] On Profiles for TAPS Preconnections

Hi all, see below - how near are we to = agreement?

On 23/07/2019, 14:21, Brian = Trammell (IETF) wrote:
hi Tommy, all,

On 22 Jul 2019, at 19:15, Tommy
Pauly<tpauly=3D40apple.com@dmarc.ietf.org>  wrote:



On Jul 22, 2019, at 6:56 PM, Philipp S. = Tiesel<philipp@tiesel.net>  wrote:

Hi,

On 22. Jul 2019, at 15:09, Tommy
Pauly<tpauly=3D40apple.com@dmarc.ietf.org>  wrote:

An issue we discussed today in the TAPS = meeting was whether or not we
should = add a concept of "profiles" to the Transport Services APIs. An = example
of a profile is a "reliable, secure, in-order = stream"; or "unreliable datagrams".
Another way to think = of these profiles are as convenient ways to initialize
common parameters.

One = option is described in this PR:
https://github.com/ietf-tapswg/api-drafts/pull/328

To help discern the working group's position, = I'll try to distill the high-
level = options here:

1. Add = Profiles as a top-level API document concept that modifies
how transport properties and/or preconnections are created. = (This is PR
#328.) 2. = Mention in the API document that specific API implementations may
expose conveniences and profiles (presumably as a way to = initialize
preconnections), but do not modify the API or = specify an abstract symbol for
profiles.
3. Do not mention profiles at all in the API document, but = mention
something = in the implementation document.
I am definitely in favour of option 1. Our implementation = experience with
PyTAPS showed that = setting all transport properties necessary to get =E2=80=9CUDP
like service=E2=80=9D becomes tedious otherwise.
I fear not including = them in the examples and the core API will result in
many developers = rejecting TAPS as too complex to use.
The profiles provide a useful convenience to = applications (just like the
the shortcuts = properties.prefer(property) instead of properties.add(property,
prefer)).

In addition, profiles allow us to be less = conservative in how we choose
the defaults for = transport properties, i.e., we don=E2=80=99t need the TAPS defaults = to
be TCP compatible as long as the = reliable-in-order-stream profile is.

I do not = think there is any connection here. Weather we have profiles or not we = will need good defaults. (The above would only hold if all profiles = covered all transport properties and you were required to always select = a profile. I do not think anyone is arguing for this.)

Speaking not as the person asking the question, but as an = individual in the
group:

I'm pretty strongly against option (1), and = prefer (2). I think we should
specify that convenience functions = can exist, but I think changing the one
initialization = function of the transport properties to take a profile is not the
right move for the API. Everything can be achieved by making = the API for a
convenience profile be a layer on top of the = existing API.
+1, for = the same reasons.

+1 for option = 2 as well. I think we should keep the core API as small and clean as = possible. To me profiles are naturally built on top of the API and do = not need to be part of the core API.

I'm fairly striongly against (3). = Profiles are really important as a concept and
I'd really = encourage the group to write this.

So far it = seems we all agree that profiles are a useful concept and should be = mentioned in the documents. 

Anna

Some = additional motivation is that it can very significantly impact the = way
the TAPS system is presented to the user. It can help = allow applications to set
many TAPS parameters, providing = additional info to the selection (racing)
without the pain = of having to understand what each parameter should be set
to. That's a big simplification. For example a low-rate = transactional app could
eplicitly need datagram to make = choices for low latency using one profile -
another app = that wishes to optimise for throughput could start by setting a
different profile.
Specifically, these are = the differences:

(1) Exposes an API in = which you always pass a profile (or an explicit nil) to a
TransportProperties object; but the = TransportProperties *also* lets you set
each of the = individual properties after that.
The API options win: = Apps can choose a profile, and they can - maybe should
be = encouraged to - over-ride anything that is important to them.
I really like the idea = of being able to pull a profile off the shelf and then
tweak it.

It does seem to me that the right model here = is "profiles as
convenience constructors or copyable = constants" -- that model is
pretty reasonably = implementable as an add-on, without

(That's = separate from the question of whether profiles are a "mandatory"
feature in taps-interface, a suggested feature = in an appendix, or something
that exists in a different = document).

Cheers,

Brian
+1 if you'd like to have (sample) profile = descriptions in an informative
appendix, that would seem = like a way to achieve that.
(2) Allows = implementations to expose an API call to deliver a
TransportProperties that's set up = based on a profile, but that isn't the
fundamental = constructor. It is implemented by creating a TransportProperties
(TransportProperties()) and then setting the properties = internally.

Thanks,
Tommy
At the start of TAPS, I thought of = profiles as the same as other parameters (i.e.
they are = inputs to the selection algorithm, that are less signficant than = apps-
supplied params, and more significant that the = system default).

I'd prefer we call this = out explicitly in the documents.

Gorry

AVE!
 Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/

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

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

AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_FC2E8F7C-25AC-4CF6-92D7-5A49B297F7B5-- --Apple-Mail=_AD7EAECC-73F8-445E-AECC-F30ABFCEFD0E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEWxyORUfQrk93Q7or9/dp0G7BPC0FAl03dgEACgkQ9/dp0G7B PC1s7hAAhs3xmgd54nbvEo8d4E85WaczuQTHW7NBXWU1LkYhbyjG7fd6CZZ9A/ZK 8zzo6SchHmn65QA6XZtA64Ve9xWxlBlFe+5x6Kz/FgwkvFcXEWDkuhIle4q7p+jf oJTpq9VdR1+UC6LgzHdNxZlmWOPzccENxNH2Elt/zsCVowbAJWkeRKOEOyVL1fVW 3Xa6lZWF3hEE5J4ZodqHyA/Tr/kvmDu+4nZpmVL45ikmX9n0WVwfzm3TBxmKxuNh FWX4r3R7i2oIblfRWQW5sTxi5UvgBHcC6qy3vYU2KQtsQjdMcmkIsyGOlYpVWjf1 ++XY3Le92JArnGa82vXUHhTgAAmbziLW89VOioB4f4F370xgEGk6glggDeDqzVL1 J4QI+5JgNB7hLta6voKArMMj9b+y0prQtUVW/wAQCWD4kjU1+JfKDo81dccHyI/L d8IyfgksPyTG8fpZHz3d792vpI1W4qr8iyx8KZon8uSRuLnn/fAh5lMpL3UyNJv6 xEj/UvRErgQHtLRhCJ+aDSI50TsfxgC9mUKT5vNyxeN+FcHeQZrihZQKpNE7ivWQ vC7a4yVaU6lg0zUg3TTC++yy4lGbvsvn1YVg0EwJ66kspgbESGtSxC4iQHAGIBSu IqWRvgGy2OVk+k1k/ncBiYhqSq54I+cpiTHYttKLaI1TvGf1I3s= =Ox7h -----END PGP SIGNATURE----- --Apple-Mail=_AD7EAECC-73F8-445E-AECC-F30ABFCEFD0E-- From nobody Tue Jul 23 14:30:10 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EFF12039B for ; Tue, 23 Jul 2019 14:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vr2rgzymoFHf for ; Tue, 23 Jul 2019 14:30:06 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 41DA612098D for ; Tue, 23 Jul 2019 14:30:06 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:b886:3fad:542b:a48d] (unknown [IPv6:2001:67c:1232:144:b886:3fad:542b:a48d]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id C5B67174D for ; Tue, 23 Jul 2019 23:30:04 +0200 (CEST) References: To: "taps@ietf.org" From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= mQENBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAG0N1RoZXJlc2EgRW5naGFyZHQgKFJlc2VhcmNoKSA8dGhlcmVzYUBpbmV0LnR1LWJlcmxp bi5kZT6JAVUEEwEKAD8CGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEE7xG3phZ0Plgk 2BDpgz007xx2oPcFAlqgJ40FCRC919sACgkQgz007xx2oPfiHggAsCfbxjo+hlUYdEHmg/a8 RGDZfOqgmNrEWfWbB+H06A3izNpvfRbqdxhi64F8MXtKPxhPGBrB9H3/E3WfsOHc9tJe+19Y GkHBOMhbXmp/o92BVHw6q/l5bcvLO8sgcemqrh8GYZgZrho7F3UTIpb8dkCjt+jCAbsAAFzR 4ziEAqw+2KVmZw5t2/1KygnPsgMz70JGAfq2jTt+NR9DxMizXNa7pZjdSmqhBjCbTlzPnn0C rAkK1/IXSM3Y704asyQrHD2pNxXQyXEe/K5uN6w80gHdyK4bBWVIVZULaRngcKrcX9gillK+ 8zs3nr8eDgsq1cURk8nmkIkFm++6PgO8lLkBDQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149J BtI8Oh4Ywktc1ExLuZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjN d6uFEdFNLtf+2/QqjVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1W mMcXMQX+Npwv9plEJOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5 w8p8OYN41q0vqefBaMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsg Xurujk0OvEFhhkQonVRXUYmLTM0EXQARAQABiQE8BBgBCgAmAhsMFiEE7xG3phZ0Plgk2BDp gz007xx2oPcFAlqgJ40FCRC91+cACgkQgz007xx2oPfRiwf9H9BNITXs2wLFjrej7wV8XoCO 5z3iN4TTeKz/2XA0CQr7OjkqbEkllnlGvywJOsCsrficHGL+eXk7tWXf8LMm0QOA1pEgA7oN ynGp7O65WG4kN93j9PFA/0k+nkqWtztuw3KBApSqytEBaaqwdeOG5mCWYawAjpSII2Bo+r9I ghH9miMgAsT044OPj3QMKSZAzTEzHekEuYa/AZqfFxLFE27WdDZpEqzvQ3uaIDbYx5HbT+xt LJJczpENdiTwyvHN4PwNSfWacyv1TA7WM2Qusgs5OVRwaJIQypvoGRl0YawaHHgxpLgs/x3r 2IqmnTXThea+Wx/iYSrPFFv4rEbS/w== Message-ID: <958d4405-a636-7d60-1804-dc6951f2c873@inet.tu-berlin.de> Date: Tue, 23 Jul 2019 17:30:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------90CA993E38D681E7DCA1F8A8" Content-Language: en-US Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:30:09 -0000 This is a multi-part message in MIME format. --------------90CA993E38D681E7DCA1F8A8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, (trimmed Cc list) On 23.07.19 16:53, Anna Brunström wrote: > > *Subject:* Re: [Taps] How to handle Protocol stacks that are not > equivalent > >   > > Yes, that's correct. My interpretation is that being in the candidate > set already requires equivalence. > >   > > Same here, seems we all agree on this. > Agreed. However, the equivalence question becomes way more interesting once you're adding security. TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race them, the Architecture clearly says so and I agree. As the application probably never asked for any specific version -- What if our TCP stack only supports TLS 1.2 but our QUIC stack offers basically TLS 1.3? We always take the better version and then fall back in case this fails? But wouldn't that be racing? I think this is also an interesting question for the Implementation draft. Best, Theresa --------------90CA993E38D681E7DCA1F8A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi, (trimmed Cc list)

On 23.07.19 16:53, Anna Brunström wrote:

Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent

 

Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence.

 

Same here, seems we all agree on this.

Agreed.

However, the equivalence question becomes way more interesting once you're adding security.

TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race them, the Architecture clearly says so and I agree.

As the application probably never asked for any specific version -- What if our TCP stack only supports TLS 1.2 but our QUIC stack offers basically TLS 1.3? We always take the better version and then fall back in case this fails? But wouldn't that be racing?

I think this is also an interesting question for the Implementation draft.

Best,
Theresa

--------------90CA993E38D681E7DCA1F8A8-- From nobody Tue Jul 23 14:56:39 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C72E1209B4 for ; Tue, 23 Jul 2019 14:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 C5_cjDJpQRz8 for ; Tue, 23 Jul 2019 14:56:28 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.152.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEDC120956 for ; Tue, 23 Jul 2019 14:56:28 -0700 (PDT) Received: from [172.16.150.129] (unknown [207.115.96.130]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 7BE7C20805; Tue, 23 Jul 2019 23:56:26 +0200 (CEST) Date: Tue, 23 Jul 2019 17:56:22 -0400 Message-ID: X-Android-Message-ID: In-Reply-To: <958d4405-a636-7d60-1804-dc6951f2c873@inet.tu-berlin.de> From: Max Franke To: Theresa Enghardt Cc: taps@ietf.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:56:38 -0000 PGRpdiBkaXI9J2F1dG8nPkdvb2QgcG9pbnQsIEkgZ3Vlc3MgdGhpcyBtaWdodCBiZSB0cnVlIGZv ciBvdGhlciB0aGluZ3MgYXMgd2VsbC4mbmJzcDs8ZGl2IGRpcj0iYXV0byI+VGFrZSBTQ1RQIGZv ciBleGFtcGxlLCB5b3UgbWlnaHQgbm90IGtub3cgaWYgaXQgaXMgbXVsdGlzdHJlYW0gb3Igbm90 IHVudGlsIGFmdGVyIGl0IGhhcyBhbHJlYWR5IGJlZW4gcmFjZWQgYW5kIHRoZSBhc3NvY2lhdGlv biBoYXMgYmVlbiBlc3RhYmxpc2hlZC4mbmJzcDs8ZGl2IGRpcj0iYXV0byI+U28gZm9yIHNvbWUg dHJhbnNwb3J0IHByb3BlcnRpZXMgeW91IG1pZ2h0IGhhdmUgdG8gcmFjZSBwcm90b2NvbHMgYmVm b3JlIHlvdSBjYW4gZGV0ZXJtaW5lIGlmIHR3byBwcm90b2NvbCBzdGFja3MgYXJlIGVxdWl2YWxl bnQgb3Igbm90LiZuYnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9 ImF1dG8iPkJlc3QmbmJzcDs8L2Rpdj48ZGl2IGRpcj0iYXV0byI+TWF4PC9kaXY+PC9kaXY+PC9k aXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ QW0gMjMuMDcuMjAxOSAxNzozMCBzY2hyaWViIFRoZXJlc2EgRW5naGFyZHQgJmx0O3RoZXJlc2FA aW5ldC50dS1iZXJsaW4uZGUmZ3Q7OjxiciB0eXBlPSJhdHRyaWJ1dGlvbiIgLz48YmxvY2txdW90 ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2Pg0KICAgIDxkaXY+SGksICh0cmltbWVk IENjIGxpc3QpPGJyIC8+DQogICAgPC9kaXY+DQogICAgPGRpdj48YnIgLz4NCiAgICA8L2Rpdj4N CiAgICA8ZGl2Pk9uIDIzLjA3LjE5IDE2OjUzLCBBbm5hIEJydW5zdHLDtm0NCiAgICAgIHdyb3Rl OjxiciAvPg0KICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlPg0KICAgICAgDQogICAgICANCiAg ICAgIA0KICAgICAgPGRpdj4NCiAgICAgICAgPGRpdj4NCiAgICAgICAgICA8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNlMWUxZTEgMXB0O3BhZGRpbmc6M3B0IDBjbSAw Y20gMGNtIj4NCiAgICAgICAgICAgIDxwIHN0eWxlPSJtYXJnaW4tbGVmdDo2NS4ycHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTFwdDtmb250LWZhbWlseTomIzM5O2NhbGlicmkmIzM5OyAsIHNh bnMtc2VyaWYiPjxiPlN1YmplY3Q6PC9iPiBSZTogW1RhcHNdIEhvdyB0byBoYW5kbGUNCiAgICAg ICAgICAgICAgICBQcm90b2NvbCBzdGFja3MgdGhhdCBhcmUgbm90IGVxdWl2YWxlbnQ8L3NwYW4+ PC9wPg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0OjY1LjJwdCI+wqA8L3A+DQogICAgICAgIDxwIHN0eWxlPSJtYXJnaW4tbGVm dDo2NS4ycHQiPlllcywgdGhhdCYjMzk7cw0KICAgICAgICAgIGNvcnJlY3QuIE15IGludGVycHJl dGF0aW9uIGlzIHRoYXQgYmVpbmcgaW4gdGhlIGNhbmRpZGF0ZSBzZXQNCiAgICAgICAgICBhbHJl YWR5IHJlcXVpcmVzIGVxdWl2YWxlbmNlLg0KICAgICAgICAgIDxzcGFuIHN0eWxlPSJjb2xvcjoj MWY0OTdkIj48L3NwYW4+PC9wPg0KICAgICAgICA8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQ7Zm9udC1mYW1pbHk6JiMzOTtjYWxpYnJpJiMzOTsgLCBzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5 N2QiPsKgPC9zcGFuPjwvcD4NCiAgICAgICAgPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0 O2ZvbnQtZmFtaWx5OiYjMzk7Y2FsaWJyaSYjMzk7ICwgc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdk Ij5TYW1lIGhlcmUsIHNlZW1zIHdlIGFsbCBhZ3JlZSBvbiB0aGlzLjwvc3Bhbj48L3A+DQogICAg ICA8L2Rpdj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHA+QWdyZWVkLjwvcD4NCiAgICA8cD5I b3dldmVyLCB0aGUgZXF1aXZhbGVuY2UgcXVlc3Rpb24gYmVjb21lcyB3YXkgbW9yZSBpbnRlcmVz dGluZw0KICAgICAgb25jZSB5b3UmIzM5O3JlIGFkZGluZyBzZWN1cml0eS48L3A+DQogICAgPHA+ VExTIDEuMiBpcyBub3QgZXF1aXZhbGVudCB0byBUTFMgMS4zLCB0aGVyZWZvcmUgeW91IGNhbiYj Mzk7dCByYWNlDQogICAgICB0aGVtLCB0aGUgQXJjaGl0ZWN0dXJlIGNsZWFybHkgc2F5cyBzbyBh bmQgSSBhZ3JlZS4gPGJyIC8+DQogICAgPC9wPg0KICAgIDxwPkFzIHRoZSBhcHBsaWNhdGlvbiBw cm9iYWJseSBuZXZlciBhc2tlZCBmb3IgYW55IHNwZWNpZmljIHZlcnNpb24NCiAgICAgIC0tIFdo YXQgaWYgb3VyIFRDUCBzdGFjayBvbmx5IHN1cHBvcnRzIFRMUyAxLjIgYnV0IG91ciBRVUlDIHN0 YWNrDQogICAgICBvZmZlcnMgYmFzaWNhbGx5IFRMUyAxLjM/IFdlIGFsd2F5cyB0YWtlIHRoZSBi ZXR0ZXIgdmVyc2lvbiBhbmQNCiAgICAgIHRoZW4gZmFsbCBiYWNrIGluIGNhc2UgdGhpcyBmYWls cz8gQnV0IHdvdWxkbiYjMzk7dCB0aGF0IGJlIHJhY2luZz88L3A+DQogICAgPHA+SSB0aGluayB0 aGlzIGlzIGFsc28gYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24gZm9yIHRoZQ0KICAgICAgSW1wbGVt ZW50YXRpb24gZHJhZnQuPGJyIC8+DQogICAgPC9wPg0KICAgIDxwPkJlc3QsPGJyIC8+DQogICAg ICBUaGVyZXNhPGJyIC8+DQogICAgPC9wPg0KICA8L2Rpdj4NCjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PC9kaXY+ From nobody Wed Jul 24 07:11:12 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD859120131 for ; Wed, 24 Jul 2019 07:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 S5bOM3LindKD for ; Wed, 24 Jul 2019 07:11:07 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 ACC171200E3 for ; Wed, 24 Jul 2019 07:11:00 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6OEAw7C001899 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 16:10:58 +0200 Received: from [2001:67c:370:1998:6dfc:c233:eb2e:71b] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hqHws-0001Pr-O1; Wed, 24 Jul 2019 16:08:54 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_AE977671-E5E9-44C0-92AB-D142A1D40287" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Philipp S. Tiesel" X-Priority: 3 In-Reply-To: Date: Wed, 24 Jul 2019 10:10:56 -0400 Cc: Theresa Enghardt , taps@ietf.org Message-Id: <72D09983-6712-47D1-B9AE-AF8435C9A6CC@in-panik.de> References: To: Maximilian Franke X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 14:11:11 -0000 --Apple-Mail=_AE977671-E5E9-44C0-92AB-D142A1D40287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23. Jul 2019, at 17:56, Max Franke = wrote: >=20 > Good point, I guess this might be true for other things as well.=20 > Take SCTP for example, you might not know if it is multistream or not = until after it has already been raced and the association has been = established.=20 > So for some transport properties you might have to race protocols = before you can determine if two protocol stacks are equivalent or not.=20= No! - That is exactly the reason why we need to clarify that = =E2=80=9Cequivalent=E2=80=9D actually means =E2=80=9Csatisfies = requires/prohibits set by the application/profile=E2=80=9D =E2=80=93 = that means setting all to ignore will make all protocols equivalent! >=20 > Best=20 > Max >=20 > Am 23.07.2019 17:30 schrieb Theresa Enghardt = : > Hi, (trimmed Cc list) >=20 > On 23.07.19 16:53, Anna Brunstr=C3=B6m wrote: > Subject: Re: [Taps] How to handle Protocol stacks that are not = equivalent >=20 > =20 > Yes, that's correct. My interpretation is that being in the candidate = set already requires equivalence. >=20 > =20 > Same here, seems we all agree on this. >=20 > Agreed. >=20 > However, the equivalence question becomes way more interesting once = you're adding security. >=20 > TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race them, = the Architecture clearly says so and I agree.=20 >=20 > As the application probably never asked for any specific version -- = What if our TCP stack only supports TLS 1.2 but our QUIC stack offers = basically TLS 1.3? We always take the better version and then fall back = in case this fails? But wouldn't that be racing? >=20 > I think this is also an interesting question for the Implementation = draft. >=20 > Best, > Theresa >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ --Apple-Mail=_AE977671-E5E9-44C0-92AB-D142A1D40287 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23. Jul 2019, at 17:56, Max Franke <mfranke@inet.tu-berlin.de> wrote:

Good point, I guess this might be true for other things as = well. 
Take SCTP for example, you might = not know if it is multistream or not until after it has already been = raced and the association has been established. 
So for some transport properties you might have to race = protocols before you can determine if two protocol stacks are equivalent = or not. 

No! - That is exactly the reason why we need to = clarify that =E2=80=9Cequivalent=E2=80=9D actually means =E2=80=9Csatisfie= s requires/prohibits set by the application/profile=E2=80=9D =E2=80=93 = that means setting all to ignore will make all protocols = equivalent!




Best 
Max

Am 23.07.2019 17:30 schrieb = Theresa Enghardt <theresa@inet.tu-berlin.de>:
Hi, (trimmed Cc list)

On 23.07.19 16:53, Anna Brunstr=C3=B6m wrote:
=20 =20 =20

Subject: Re: [Taps] How to = handle Protocol stacks that are not equivalent

 

Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence.

 

Same here, seems we all agree on = this.

Agreed.

However, the = equivalence question becomes way more interesting once you're adding security.

TLS 1.2 is not = equivalent to TLS 1.3, therefore you can't race them, the Architecture clearly says so and I agree.

As the application probably never asked for any = specific version -- What if our TCP stack only supports TLS 1.2 but our QUIC stack offers basically TLS 1.3? We always take the better version and then fall back in case this fails? But wouldn't that be = racing?

I think this is also an interesting question = for the Implementation draft.

Best,
Theresa


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

AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_AE977671-E5E9-44C0-92AB-D142A1D40287-- From nobody Wed Jul 24 15:28:58 2019 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 784CB1202EC; Wed, 24 Jul 2019 15:28:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <156400733639.14601.7320258435886765160@ietfa.amsl.com> Date: Wed, 24 Jul 2019 15:28:56 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-07.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 22:28:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Christopher A. Wood Theresa Enghardt Tommy Pauly Colin Perkins Kyle Rose Filename : draft-ietf-taps-transport-security-07.txt Pages : 37 Date : 2019-07-24 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-07 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-07 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 Wed Jul 24 15:33:12 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B7D1202DB for ; Wed, 24 Jul 2019 15:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 UYzwFLMH1HGZ for ; Wed, 24 Jul 2019 15:33:09 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 7788C120110 for ; Wed, 24 Jul 2019 15:33:09 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6OMWuH2009557 for ; Wed, 24 Jul 2019 15:33:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=zn02xYb6p6gf7TGCQldwiql6b71Ur9Mbp9p0tkTuqgM=; b=U1f3GfHqgh2k0h4IVPii3mcbtUh15ORMPgTrNqzcWRh+xVnF/Trm1E/YgMIaOGfajzWn a3NQ2CyGaeoPiTywOlrf68X5Ag8HVdGvxp2qyiFnXT/9WtA/nVdbIH3UF/dRwlKOc03c fROwOxYFhst0y522ymwa+WynXLPbtdiP/gI0zjgSZCq7H7HqA0L6FQlppu42TEDumqWb HB87J3hda8KI2fGOjDfeQeYuhU6e5keXZkfASiOALtGqnjEQR/xeQJ1THtnn/PTzrV+u YVhawqJsqirG+gR73UmEKOB/Oga9IGlqWdblgy/jEtQ7JlgljzlgvKUICF+IHTp1AtBn pA== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2tx62wq1gj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 24 Jul 2019 15:33:07 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PV600EKD3YYBY30@ma1-mtap-s03.corp.apple.com> for taps@ietf.org; Wed, 24 Jul 2019 15:33:07 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PV600H003OTLS00@nwk-mmpp-sz10.apple.com> for taps@ietf.org; Wed, 24 Jul 2019 15:33:06 -0700 (PDT) X-Va-A: X-Va-T-CD: 5808c5f95406ec7719a15f5c3784581a X-Va-E-CD: 68ad857b52989ab6cc2f3f40758603d9 X-Va-R-CD: 1e2042cd82489255aaece2b899687e97 X-Va-CD: 0 X-Va-ID: 55d80e77-edfe-4a85-9a69-e4cd7cc69f07 X-V-A: X-V-T-CD: 5808c5f95406ec7719a15f5c3784581a X-V-E-CD: 68ad857b52989ab6cc2f3f40758603d9 X-V-R-CD: 1e2042cd82489255aaece2b899687e97 X-V-CD: 0 X-V-ID: a4af1e48-e116-4dfb-93f8-93368537d707 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-24_08:,, signatures=0 Received: from [17.235.0.161] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PV6000P63YKEV60@nwk-mmpp-sz10.apple.com> for taps@ietf.org; Wed, 24 Jul 2019 15:32:50 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Wed, 24 Jul 2019 18:32:40 -0400 References: <156400733639.14601.7320258435886765160@ietfa.amsl.com> To: taps WG In-reply-to: <156400733639.14601.7320258435886765160@ietfa.amsl.com> Message-id: <519B0EFF-72E1-419E-8882-6C9CA2477DC0@apple.com> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-24_08:, , signatures=0 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-07.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 22:33:12 -0000 Hi all, This revision posts the GitHub master version of the transport security = survey, which has editorial fixes, and updates all references to = Informational, and updates draft references to be RFC references. The shepherd write-up should be based on this fixed-up version. Thanks! Tommy > On Jul 24, 2019, at 6:28 PM, internet-drafts@ietf.org wrote: >=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 WG of the IETF. >=20 > Title : A Survey of Transport Security Protocols > Authors : Christopher A. Wood > Theresa Enghardt > Tommy Pauly > Colin Perkins > Kyle Rose > Filename : draft-ietf-taps-transport-security-07.txt > Pages : 37 > Date : 2019-07-24 >=20 > Abstract: > This document provides a survey of commonly used or notable network > security protocols, with a focus on how they interact and integrate > with applications and transport protocols. Its goal is to = supplement > efforts to define and catalog transport services by describing the > interfaces required to add security protocols. This survey is not > limited to protocols developed within the scope or context of the > IETF, and those included represent a superset of features a = Transport > Services system may need to support. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-taps-transport-security-07 > = https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-0= 7 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transport-security-07 >=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 From nobody Fri Jul 26 01:02:20 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000641202C3 for ; Fri, 26 Jul 2019 01:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 kjfyDM9OGjJZ for ; Fri, 26 Jul 2019 01:02:16 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 C46AA1202C5 for ; Fri, 26 Jul 2019 01:02:16 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1hqv92-0000ot-Dt for taps@ietf.org; Fri, 26 Jul 2019 08:00:04 +0000 Content-Type: multipart/alternative; boundary="===============7496220057444026086==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 26 Jul 2019 08:00:04 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 08:02:19 -0000 --===============7496220057444026086== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+4/-1/=F0=9F=92=AC22) 4 issues created: - Framers: Move parts to Implementation draft (by theri) https://github.com/ietf-tapswg/api-drafts/issues/344 = - Listeners should have backpressure (by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/343 = - Allow error events to include reason (by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/342 = - Make InitiateError more generic (by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/341 = 12 issues received 22 new comments: - #336 Send() -> Sent<> mapping underspecified (5 by britram, mwelzl, tfp= auly) https://github.com/ietf-tapswg/api-drafts/issues/336 [API] [discuss] = - #342 Allow error events to include reason (3 by mwelzl, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/342 = - #343 Listeners should have backpressure (3 by britram, abrunstrom, mwel= zl) https://github.com/ietf-tapswg/api-drafts/issues/343 [discuss] = - #324 Add explicit protocol selection. (2 by britram) https://github.com/ietf-tapswg/api-drafts/issues/324 [API] [discuss] = - #338 Listen filtering behavior for TLS connections? (2 by britram, tfpa= uly) https://github.com/ietf-tapswg/api-drafts/issues/338 [future work] = - #145 Draft should point at implementations somewhere (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/145 [Implementation] [= ready for text] = - #177 Privacy considerations section (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/177 [API] [Implementat= ion] [ready for text] = - #337 Update implementation mapping text for SCTP (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/337 [ready for text] = - #307 Differentiating between bad selection property configuration and c= onnection issues (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/issues/307 [API] = - #341 Make InitiateError more generic (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/341 = - #313 API Draft author editorial comments (1 by GrumpyOldTroll) https://github.com/ietf-tapswg/api-drafts/issues/313 [API] [ready for t= ext] = - #317 The recommended default and can we specify rather than recommend? = (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/317 [API] [discuss] = 1 issues closed: - Differentiating between bad selection property configuration and connec= tion issues https://github.com/ietf-tapswg/api-drafts/issues/307 [API] = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-2/=F0=9F=92=AC4) 1 pull requests submitted: - Remove the message context returned by send (by philsbln) https://github.com/ietf-tapswg/api-drafts/pull/345 [API] = 1 pull requests received 4 new comments: - #327 Adding a way of forcing the use of specific protocols (4 by mirjak= , britram, philsbln) https://github.com/ietf-tapswg/api-drafts/pull/327 [API] [discuss] = 2 pull requests merged: - Add Transport Property Profiles https://github.com/ietf-tapswg/api-drafts/pull/328 [API] [discuss] = - Remove the message context returned by send https://github.com/ietf-tapswg/api-drafts/pull/345 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============7496220057444026086== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday July 26, 2019

Issues

ietf-tapswg/api-drafts (+4/-1/=F0=9F=92=AC22)

4 issues created:

12 issues received 22 new comments:

1 issues closed:

Pull requests

ietf-tapswg/api-drafts (+1/-2/=F0=9F=92=AC4)

1 pull requests submitted:

1 pull requests received 4 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============7496220057444026086==--