From nobody Tue Jun 14 05:13:12 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1003112D542; Tue, 14 Jun 2016 05:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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 ygcFbJTwMzcI; Tue, 14 Jun 2016 05:13:07 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C1C5D12D59A; Tue, 14 Jun 2016 05:13:06 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 7DA2F1A0CE2; Tue, 14 Jun 2016 14:13:05 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_FB82BCB3-B54B-4DCD-B189-3EEED0231947"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 14 Jun 2016 14:13:04 +0200 Message-Id: To: ietf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsv-art@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@tools.ietf.org Subject: [Tsv-art] TSV-ART review of draft-ietf-dnsop-dnssec-roadblock-avoidance X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 12:13:09 -0000 --Apple-Mail=_FB82BCB3-B54B-4DCD-B189-3EEED0231947 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, I've reviewed this draft as part of the TSV Area Review Team, paying = special attention to transport-related concerns. Please take these as = any other IETF last call comments. Summary: This draft clearly describes online testing of possible DNSSEC = failures, and how to interpret the results. It does not appear to pose = any transport-related danger, and is broadly ready for publication as a = BCP. I do have the following questions, though: (1) Section 3.1: "The tests are designed to check for one feature at a = time". This is generally A Good Thing, but it does seem that there = should be some attempt to economize on packets sent. This is not as much = a problem when testing recursive resolvers, since they should only need = to be run when a host introduces itself to a neighboring recursive = resolver and the test traffic shouldn't leave the site. However, section = 3.2 are designed to run on the open Internet, and seems to suggests that = tests 3.2.1-3.2.3 should be run *first*, then followed by the fourteen = tests in section 3.1. In the "best case" future for this document, that = every stub resolver implements this online testing automatically, every = packet saved is significant. Some optimizations are obvious: 3.2.1 replaces 3.1.1, 3.2.3 replaces = 3.1.2. The document should note these (even though they're trivial). = Some optimizations have already been made: 3.1.5, 3.1.10, 3.3. test = multiple conditions. Are there any other tests that could be combined = (e.g. the TCP connectivity and EDNS0 tests) without losing fidelity? (2) Could the retries advised in section 5 be abused to cause a resolver = running roadblock avoidance to send unnecessary test traffic? It seems = that injecting an error, illegal, or bogus response could induce = multiple retries, though it's not clear that the amplification factor = makes this worth it. (2) In section 6, the draft raises the possibility of unstable = networking after connection (e.g. in a captive portal situation); = guidance to refrain from flooding the network with test traffic during = this instability might be useful. Perhaps explicitly link the DNSSEC = checks to a "network proves to be usable" signal (either from the = application or the operating system)? Thanks, cheers, Brian (as TSV-ART reviewer) --Apple-Mail=_FB82BCB3-B54B-4DCD-B189-3EEED0231947 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXX/TRAAoJEIoSt78L6kajJfUP/049oyN6ItI5WWb3J56u7iiw /0q3Z0IyleZKqeheCz90rMqa6eLwWwDtYZusev6hYeaVkDyUACKxx1uOyUVI8W96 x5pUpmnS2Opj0e9BqjQlqe/Wpsxb9CGK2DqBT/FLcKgL900DWwCHSI3zcN4mM87x puTSABMfc24eU5oU2N+U90AeVCc2td9D/Fc3vBDulkSG252jx4c520PXgTDskkSn vEWvAs6Qn2NDORPsflE8XZmAfNFFzfMdMYj1M/LXNJLCCyjwoic0vFZtT8CSkwHT 5XhQw7GsH5QDgpVsXYEeAe2/VQo32ihhkO1F7lAlDOHzZTPolGMYTmoLd8RJlfL0 miCWoHCQ8f0WC1XazHw8Eb9ltL7SqrdDrUB2aF/77iVo0G7gZr7CM/CLxu0pIjFS y6oYK4BBqizCsLZSLscRfzi5SF2MzR8yyXpyV3CfX7ptaR2u6rQg9rCYX6z0AYt4 cK7Eaz6uui96b0CuhKpScJZABVvv0w4P0Qw+VF8y19NGCz0sav0MW8YbQCiKxKX/ wCHW1G6NM4W/rs8H1G5zxJfG+uf3W0s1uVibyT25wa+TgXeoBfF1Wy39ec4RuYwy DMlQfdTftqYEsfPORFpeVndULr+XpW4zZ7gSlSgam5GulOhNcrENd2CVqC278t3+ rHs3WUB1srL2/fGEFQi2 =00oF -----END PGP SIGNATURE----- --Apple-Mail=_FB82BCB3-B54B-4DCD-B189-3EEED0231947-- From nobody Wed Jun 15 02:25:09 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1482A12D541 for ; Wed, 15 Jun 2016 02:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 RuyKVYoJ4T7N for ; Wed, 15 Jun 2016 02:25:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2313D12D522 for ; Wed, 15 Jun 2016 02:25:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 99F20D9309; Wed, 15 Jun 2016 11:25:04 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UEyEDdc9s517; Wed, 15 Jun 2016 11:25:04 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 68ECAD9305; Wed, 15 Jun 2016 11:25:04 +0200 (MEST) To: Joe Touch , Martin Stiemerling , tsv-art@ietf.org References: <031bfb41-8ebc-cc8f-103d-1f701ad32b30@gmail.com> <5760ECFF.70306@isi.edu> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <57611EEF.2090508@tik.ee.ethz.ch> Date: Wed, 15 Jun 2016 11:25:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5760ECFF.70306@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tsv-art] Fwd: Help needed: TSV Triage team: Review of IETF LC documents (as of 06/14) X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 09:25:08 -0000 Hi Joe, we already got an review from Brian for draft-ietf-dnsop-dnssec-roadblock-avoidance (thanks!). Joylan Furtado agreed to provide a review for draft-ietf-forces-interfelfb. However, this mail went to the wrong list and he is not a member of the ART, so I would be glad if you could provide a review for that one. Thanks! Mirja On 15.06.2016 07:51, Joe Touch wrote: > I can help with either of the items below if needed. I don't have > context on any of these, though, so if others do, I'll defer to them first. > > Joe > > On 6/14/2016 12:17 AM, Martin Stiemerling wrote: >> - draft-ietf-dnsop-dnssec-roadblock-avoidance >> - draft-ietf-forces-interfelfb From nobody Wed Jun 15 15:41:28 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBFD12D1A9; Wed, 15 Jun 2016 15:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 e8-sT0NH3w0V; Wed, 15 Jun 2016 15:41:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 4DC9812D740; Wed, 15 Jun 2016 15:41:22 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5FMegvO018682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jun 2016 15:40:43 -0700 (PDT) To: IETF discussion list From: Joe Touch Message-ID: Date: Wed, 15 Jun 2016 15:40:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tsv-art@ietf.org, draft-ietf-forces-interfelfb@tools.ietf.org Subject: [Tsv-art] TSV-ART review of draft-ietf-forces-interfelfb X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:41:24 -0000 Hi, all, I've reviewed this draft as part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as any other IETF last call comments. Joe --- The document contains two different types of transport issues: its relation to supporting transport traffic and the way it exchanges information between the FEs. The document's discussion of the impact on supporting transport traffic is sufficient. I'm not sure I concur with citing RFC5405bis as informational, because the correctness of the proposed approach to congestion control relies directly on definitions of controlled environments available only in the -bis update. I would prefer that claims using normative language necessitate using cited references as Normative. The document uses Ethernet as a "transport", as stated in Sec 3.1.1. The claim that this is "simpler" than using UDP would benefit from a few sentences of substantiation, especially because Ethernet does not support fragmentation, which has an impact on the solutions proposed in Sec 5.1.1 (see below). Sec 5.1.3 indicates that packet sizes increase due to the ForCES metadata (using encapsulation indicated in Sec 5.2), which could exceed the Ethernet MTU as noted in Sec 5.1.1. Sec 5.1.1 suggests an approach of falsifying MTU information, but this could also result in a reported Ethernet MTU below the required minimum of 1500. This case should be addressed in Sec 5.1.1. Other comments: Sec 5.2: The Ethertype listed should be replaced with "Ethertype-TBD" with a corresponding note to update that text in Sec 9 / IEEE Assignment Considerations. The draft should not use a specific unassigned value, even if currently available, until assigned. (it currently cites 0xFEFE). This section should also refer to the Metadata IDs directly, either by name or by registry, as if assuming that IANA has created that registry. --- From nobody Fri Jun 17 05:13:03 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BA312D516 for ; Fri, 17 Jun 2016 05:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.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 PfMx6afcQqlW for ; Fri, 17 Jun 2016 05:12:53 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 E513912D0F3 for ; Fri, 17 Jun 2016 05:12:52 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id l44so37985334qgd.0 for ; Fri, 17 Jun 2016 05:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aHtKYuuUCO73PqPeak90MHUOQYuckN3SqBstEiUYxPU=; b=J5oCw/JMg5rmoM4aeFMOmyJ6vMhrVK6/nOClYzCqi1/SuSf/6Pw9OSV8IOWFbrw0UN CcicriZT8GIsdU7P0Og+FpToLvSofYT7Y61NVW4FiiOqaIeCPwnFouBBgj+YobgtjoTo pXfFAmPmn+9iSONXvvqEYpAnVyzb3+Uw26yjCK0ke1EHxv+j+CnGckAyfUowhZEZsvkC Bz7rl9PtNeW3WtP5JghWbJwORmJQsdIjcRWJEkZmvovGKwSbwBzQIu7yUOILu7kI+HK1 7maoJ73azId6UdeBe9DTkaPL8mMHS4IbzWLZ3Yc+N2yJjv/6C83g2c0nkLALfz/K/CXD DkfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aHtKYuuUCO73PqPeak90MHUOQYuckN3SqBstEiUYxPU=; b=V9e4zr9dNB2sdV0ZjZGlIgOqWtaMqBC6mMDLOWx7tcyopydw6EeZYgzhjD/iFfAEYt vvPuQveNzGqVLdEtOCiJBhZQGXMn4iVqgTBX3bpO1vDFgD0CYd8+H3bWlEtRFGwv2Zm/ WApQP6RJlAO9pOtkyp4IzUoz2zC6WvE4ibcF99WdAittjk4LYADyMEYCoCXZZ5yoTXmI doTMXfTnn4Qg4cEEQbx6ciLjvLudjYswctxTWtQXDW74FrO/gv2kvDPG5vbsAoO1NDno Cvkd2uAsr+wDlF8CwjUGABRFYn3REshwh1YR9E42hzbDfNHy09Z30wueQ32O540y3lzb gTYw== X-Gm-Message-State: ALyK8tKaSJFCP2ky30NVaH9SNVlsNHpA8sC3rNeNMR8f3hLP4920Vqh2RvXU7QYyL9MDdMhn5udq2Rw83S2fcQ== X-Received: by 10.140.109.198 with SMTP id l64mr1646682qgf.65.1466165572019; Fri, 17 Jun 2016 05:12:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.87.3 with HTTP; Fri, 17 Jun 2016 05:12:32 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Fri, 17 Jun 2016 08:12:32 -0400 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a113a49361a6f6205357846de Archived-At: Cc: tsv-art@ietf.org, draft-ietf-forces-interfelfb@tools.ietf.org, IETF discussion list Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-forces-interfelfb X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 12:12:55 -0000 --001a113a49361a6f6205357846de Content-Type: text/plain; charset=UTF-8 Hi Joe, Thanks for your review - responses below: On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch wrote: > Hi, all, > > I've reviewed this draft as part of the TSV Area Review Team, paying > special attention to transport-related concerns. Please take these as > any other IETF last call comments. > > Joe > > --- > > The document contains two different types of transport issues: its > relation to supporting transport traffic and the way it exchanges > information between the FEs. > > The document's discussion of the impact on supporting transport traffic > is sufficient. I'm not sure I concur with citing RFC5405bis as > informational, because the correctness of the proposed approach to > congestion control relies directly on definitions of controlled > environments available only in the -bis update. I would prefer that > claims using normative language necessitate using cited references as > Normative. > > This has come up before. So i think we'll just make it a normative reference in the next update (which i plan to publish after this discussion) > The document uses Ethernet as a "transport", as stated in Sec 3.1.1. The > claim that this is "simpler" than using UDP would benefit from a few > sentences of substantiation, especially because Ethernet does not > support fragmentation, which has an impact on the solutions proposed in > Sec 5.1.1 (see below). > The reference point is the common deployment use cases; within a single rack or network owned by one admin who does all the setup. Any suggestion on wording you'd like to see? > Sec 5.1.3 indicates that packet sizes increase due to the ForCES > metadata (using encapsulation indicated in Sec 5.2), which could exceed > the Ethernet MTU as noted in Sec 5.1.1. Sec 5.1.1 suggests an approach > of falsifying MTU information, but this could also result in a reported > Ethernet MTU below the required minimum of 1500. This case should be > addressed in Sec 5.1.1. > > Thanks. Will fix. > Other comments: > > Sec 5.2: The Ethertype listed should be replaced with "Ethertype-TBD" > with a corresponding note to update that text in Sec 9 / IEEE Assignment > Considerations. The draft should not use a specific unassigned value, > even if currently available, until assigned. (it currently cites > 0xFEFE). This section should also refer to the Metadata IDs directly, > either by name or by registry, as if assuming that IANA has created that > registry. > > Yes, this also came up in earlier review. I will upload with this fixed as well. Thanks again Joe for taking the time. cheers, jamal --- > > > > --001a113a49361a6f6205357846de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,
Thanks for your review - responses below:

On Wed, Jun 15, = 2016 at 6:40 PM, Joe Touch <touch@isi.edu> wrote:
Hi, all,

I've reviewed this draft as part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as
any other IETF last call comments.

Joe

---

The document contains two different types of transport issues: its
relation to supporting transport traffic and the way it exchanges
information between the FEs.

The document's discussion of the impact on supporting transport traffic=
is sufficient. I'm not sure I concur with citing RFC5405bis as
informational, because the correctness of the proposed approach to
congestion control relies directly on definitions of controlled
environments available only in the -bis update. I would prefer that
claims using normative language necessitate using cited references as
Normative.


This has come up before. So i think we= 'll just make it a normative reference
in the next update (wh= ich i plan to publish after this discussion)
=C2=A0
The document uses Ethernet as a "transport", as stated in Sec 3.1= .1. The
claim that this is "simpler" than using UDP would benefit from a = few
sentences of substantiation, especially because Ethernet does not
support fragmentation, which has an impact on the solutions proposed in
Sec 5.1.1 (see below).

The reference po= int is the common deployment use cases; within a single
rack or n= etwork owned by one admin who does all the setup.
Any suggestion = on wording you'd like to see?
=C2=A0
Sec 5.1.3 indicates that packet sizes increase due to the ForCES
metadata (using encapsulation indicated in Sec 5.2), which could exceed
the Ethernet MTU as noted in Sec 5.1.1. Sec 5.1.1 suggests an approach
of falsifying MTU information, but this could also result in a reported
Ethernet MTU below the required minimum of 1500. This case should be
addressed in Sec 5.1.1.


Thanks. Will fix.
=C2=A0
Other comments:

Sec 5.2: The Ethertype listed should be replaced with "Ethertype-TBD&q= uot;
with a corresponding note to update that text in Sec 9 / IEEE Assignment Considerations. The draft should not use a specific unassigned value,
even if currently available, until assigned. (it currently cites
0xFEFE).=C2=A0 This section should also refer to the Metadata IDs directly,=
either by name or by registry, as if assuming that IANA has created that registry.


Yes, this also came up in earlier revi= ew.=C2=A0 I will upload with this fixed
as well.
=C2=A0=
Thanks again Joe for taking the time.

c= heers,
jamal

---




--001a113a49361a6f6205357846de-- From nobody Fri Jun 17 08:57:05 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC212D7EB; Fri, 17 Jun 2016 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 BmddrTf6sQEF; Fri, 17 Jun 2016 08:56:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 5F5BD12D7BD; Fri, 17 Jun 2016 08:56:58 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u5HFuDZw008683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jun 2016 08:56:24 -0700 (PDT) To: Jamal Hadi Salim References: From: Joe Touch Message-ID: <57641D9D.7010007@isi.edu> Date: Fri, 17 Jun 2016 08:56:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070301010502000002060402" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tsv-art@ietf.org, draft-ietf-forces-interfelfb@tools.ietf.org, IETF discussion list Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-forces-interfelfb X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:56:59 -0000 This is a multi-part message in MIME format. --------------070301010502000002060402 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Jamal, Focusing only on the portion needing continued feedback below. Joe On 6/17/2016 5:12 AM, Jamal Hadi Salim wrote: > Hi Joe, > Thanks for your review - responses below: > > On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch > wrote: > > Hi, all, > > I've reviewed this draft as part of the TSV Area Review Team, paying > special attention to transport-related concerns. Please take these as > any other IETF last call comments. > > Joe > > --- > > The document contains two different types of transport issues: its > relation to supporting transport traffic and the way it exchanges > information between the FEs. > > ... > > > > The document uses Ethernet as a "transport", as stated in Sec > 3.1.1. The > claim that this is "simpler" than using UDP would benefit from a few > sentences of substantiation, especially because Ethernet does not > support fragmentation, which has an impact on the solutions > proposed in > Sec 5.1.1 (see below). > > > The reference point is the common deployment use cases; within a single > rack or network owned by one admin who does all the setup. > Any suggestion on wording you'd like to see? from: o The FEs are already interconnected using Ethernet. We focus on Ethernet because it is a very common setup as an FE interconnect. While other higher transports (such as UDP over IP) or lower transports could be defined to carry the data and metadata it is simpler to use Ethernet (for the functional scope of a single distributed device already interconnected with ethernet). To: o The FEs are already interconnected using Ethernet. We focus on Ethernet because it is a very common setup as an FE interconnect. Other higher transports (such as UDP over IP) or lower transports could be defined to carry the data and metadata, but these cases are not addressed in this document. --- --------------070301010502000002060402 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, Jamal,

Focusing only on the portion needing continued feedback below.

Joe

On 6/17/2016 5:12 AM, Jamal Hadi Salim wrote:
Hi Joe,
Thanks for your review - responses below:

On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch <touch@isi.edu> wrote:
Hi, all,

I've reviewed this draft as part of the TSV Area Review Team, paying
special attention to transport-related concerns. Please take these as
any other IETF last call comments.

Joe

---

The document contains two different types of transport issues: its
relation to supporting transport traffic and the way it exchanges
information between the FEs.

...
 
The document uses Ethernet as a "transport", as stated in Sec 3.1.1. The
claim that this is "simpler" than using UDP would benefit from a few
sentences of substantiation, especially because Ethernet does not
support fragmentation, which has an impact on the solutions proposed in
Sec 5.1.1 (see below).

The reference point is the common deployment use cases; within a single
rack or network owned by one admin who does all the setup.
Any suggestion on wording you'd like to see?
from:
   o  The FEs are already interconnected using Ethernet.  We focus on
      Ethernet because it is a very common setup as an FE interconnect.
      While other higher transports (such as UDP over IP) or lower
      transports could be defined to carry the data and metadata it is
      simpler to use Ethernet (for the functional scope of a single
      distributed device already interconnected with ethernet).
To:
   o  The FEs are already interconnected using Ethernet.  We focus on
      Ethernet because it is a very common setup as an FE interconnect.
      Other higher transports (such as UDP over IP) or lower
      transports could be defined to carry the data and metadata, but
      these cases are not addressed in this document.
---
--------------070301010502000002060402-- From nobody Sat Jun 18 07:04:00 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68C12D507 for ; Sat, 18 Jun 2016 07:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.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 AlPES5kh6MiX for ; Sat, 18 Jun 2016 07:03:56 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851BA12D1EB for ; Sat, 18 Jun 2016 07:03:55 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p10so114092229qke.3 for ; Sat, 18 Jun 2016 07:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HtyhD9G5UL3Rt9zwxCObSofNJlIvNMfKDGkze7N4ttI=; b=fRdypH7y4cSMYnbw8/8CeknhvZynf5hWKTPZX+vlVBVkcSEyBKuM5R5twP1qyYYKAj JszQGHMzsGpvEDL6qkym3Af5PNg6A9faOv1vahh52sK829d5JBf8XG2C6yaO2jTZLRib H6MwzgINlNjIhNmUF/CZ0r/1hKac06raaS5jY4VOz+vQTeslOB1UOzX9U2griHOb0J6l anPRbd4yzBp9jQmM05NJdZLFQXRyowda1Ao6Np0GTQZpn36KjZY0t1uItuEowaX0qV5T 3gyoWpSQcd8ygiK9nln/PME0+Tk7C8upZCLjhdToBqMg5f7qXIyJlG+rm88EL48dhY6S TUZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HtyhD9G5UL3Rt9zwxCObSofNJlIvNMfKDGkze7N4ttI=; b=SrE9DVZn4MXsT/5sf+gyxjsgBvJSHSpMoVoLtk3OFuHCtlv1Eo9xNcbeuHh639Q44L 3m3jbA69/w7iqsVWnIIpPA7URA66yxzwOW09VKpAkPvo6Zy6mvLk8L/cill9TwWJ6UiI m2L/ivMTL2RydrKjXSBqEwMTfU4ARrQ4xOuZ/tp11rmUTPAuedPQmQAcv6IQCTs2V1N2 /7SeFyLRaoAGYW3ioBwNZVGJuT/dGpttFK3u4FmFqNfRTpxQpD7poJA/87rSlfcf6fyu VMa19+eqBFYgLknexFQtv2xxLO2PZh0XXWhNTHdfhc17hOf8R3GVYl4GlyGAYoMh+3mq JJ6A== X-Gm-Message-State: ALyK8tKj5LovQEGYDjfNB6IMPEatSMeRevbLfiCyd2U3jV0rQIteKNFsuxWpHoFGnENvaACp6tAajUyukaXbRg== X-Received: by 10.200.37.98 with SMTP id 31mr9367018qtn.82.1466258634228; Sat, 18 Jun 2016 07:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.87.3 with HTTP; Sat, 18 Jun 2016 07:03:34 -0700 (PDT) In-Reply-To: <57641D9D.7010007@isi.edu> References: <57641D9D.7010007@isi.edu> From: Jamal Hadi Salim Date: Sat, 18 Jun 2016 10:03:34 -0400 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a11403cdc0b186505358df19f Archived-At: Cc: tsv-art@ietf.org, draft-ietf-forces-interfelfb@tools.ietf.org, IETF discussion list Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-forces-interfelfb X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 14:03:58 -0000 --001a11403cdc0b186505358df19f Content-Type: text/plain; charset=UTF-8 Thanks Joe. I will make an update and post. cheers, jamal On Fri, Jun 17, 2016 at 11:56 AM, Joe Touch wrote: > Hi, Jamal, > > Focusing only on the portion needing continued feedback below. > > Joe > > On 6/17/2016 5:12 AM, Jamal Hadi Salim wrote: > > Hi Joe, > Thanks for your review - responses below: > > On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch wrote: > >> Hi, all, >> >> I've reviewed this draft as part of the TSV Area Review Team, paying >> special attention to transport-related concerns. Please take these as >> any other IETF last call comments. >> >> Joe >> >> --- >> >> The document contains two different types of transport issues: its >> relation to supporting transport traffic and the way it exchanges >> information between the FEs. >> >> ... > > > >> The document uses Ethernet as a "transport", as stated in Sec 3.1.1. The >> claim that this is "simpler" than using UDP would benefit from a few >> sentences of substantiation, especially because Ethernet does not >> support fragmentation, which has an impact on the solutions proposed in >> Sec 5.1.1 (see below). >> > > The reference point is the common deployment use cases; within a single > rack or network owned by one admin who does all the setup. > Any suggestion on wording you'd like to see? > > from: > > o The FEs are already interconnected using Ethernet. We focus on > Ethernet because it is a very common setup as an FE interconnect. > While other higher transports (such as UDP over IP) or lower > transports could be defined to carry the data and metadata it is > simpler to use Ethernet (for the functional scope of a single > distributed device already interconnected with ethernet). > > To: > > o The FEs are already interconnected using Ethernet. We focus on > Ethernet because it is a very common setup as an FE interconnect. > Other higher transports (such as UDP over IP) or lower > transports could be defined to carry the data and metadata, but > these cases are not addressed in this document. > > --- > --001a11403cdc0b186505358df19f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Joe. I will make an update and post.

=
cheers,
jamal

On Fri, Jun 17, 2016 at 11:56 AM, Joe Touch <touch@isi.= edu> wrote:
=20 =20 =20
Hi, Jamal,

Focusing only on the portion needing continued feedback below.

Joe

On 6/17/2016 5:12 AM, Jamal Hadi Salim wrote:
Hi Joe,
Thanks for your review - responses below:

On Wed, Jun 15, 2016 at 6:40 PM, Joe Touch <touch@isi.edu> wrote:
Hi, all,

I've reviewed this draft as part of the TSV Area Review Team, paying
special attention to transport-related concerns. Please take these as
any other IETF last call comments.

Joe

---

The document contains two different types of transport issues: its
relation to supporting transport traffic and the way it exchanges
information between the FEs.

...
=C2=A0
The document uses Ethernet as a "transport", as sta= ted in Sec 3.1.1. The
claim that this is "simpler" than using UDP would b= enefit from a few
sentences of substantiation, especially because Ethernet does not
support fragmentation, which has an impact on the solutions proposed in
Sec 5.1.1 (see below).

The reference point is the common deployment use cases; within a single
rack or network owned by one admin who does all the setup.
Any suggestion on wording you'd like to see?
from:
   o  The FEs are already interconnected using Ethernet.  We focus=
 on
      Ethernet because it is a very common setup as an FE interconnect.
      While other higher transports (such as UDP over IP) or lower
      transports could be defined to carry the data and metadata it is
      simpler to use Ethernet (for the functional scope of a single
      distributed device already interconnected with ethernet).
To:
   o  The FEs are already interconnected using Ethernet.  We focus=
 on
      Ethernet because it is a very common setup as an FE interconnect.
      Other higher transports (such as UDP over IP) or lower
      transports could be defined to carry the data and metadata, but
      these cases are not addressed in this document.
---

--001a11403cdc0b186505358df19f-- From nobody Fri Jun 24 22:54:26 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3086912D616; Fri, 24 Jun 2016 22:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 2BZgtwm6WhdH; Fri, 24 Jun 2016 22:54:23 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 528FA12D5AD; Fri, 24 Jun 2016 22:54:23 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id m2so3087247qtd.1; Fri, 24 Jun 2016 22:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qc/4tI/5yt+5ECVC/P95j8yIKwok4Cln49M0oh734JE=; b=LakCUNsS9riiHJG8wkWVqZDLo5xdmXpsbCyt+58E2CuMIH/QP8XMCC7QhjfimNomzz pJ7fmFP6Rt0eBkNMosyrBEQ4T7j9MaOvweuosGaXh+GKxptkySASmkOotf+6Ht18ICXA kw9loSQx0Ntzb9WQHsxaaDwu7sTDjjPsxMvpNXEzo4M9IRXpHsmjrBa4YENlpaxNaPrq cnUx4wU1HkLax7yaUfKECHd54Beb8HlSvUKmk/BJu/4/jSxupRbKBWK3wR6q4EkXXpuq ookM3CSOHyLG0GaPy7zh0X/d/JRCOT9IYu0s1APet5HQI6pXFYTfzEJmxjZjeFdnt9ge XSQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qc/4tI/5yt+5ECVC/P95j8yIKwok4Cln49M0oh734JE=; b=hoMUHgu4Xu+gBEZH9Q2GRWj6rjL2ZaCM4yaOC9vO6VWHVYPpdZM3etXA2ar/FouxQX 8n+Y+goyTRBymhmU1hXPXrcyYSoJWTO5N/DX769arhNlE6F/qM7GJ+4VQTpI2S3ITxzf r+lmc5HoyYUjwEXWgzdoY8ChSnib4bZncIrWuOnqH9AchGlNJiNw48IK4D4rycj9J4y6 Zb70S9lGNoDuIhLVQqZDiiXLanPQ1nu3XpluMJ08ETTfy4jvAXfltt8y+2i3fGbGuAIT eupRI+V+pO4/lVT9zcVhJ6VCRosecD6PruHu4eG2p8dB7tJ60FWYU6B3/9D20G/h1maX 3lwA== X-Gm-Message-State: ALyK8tLnWLDCjnL7sZqaFPgG2c+0C/oAK6hN27EB4Y2M/wj296ep4ACIUWKelIwiefnfwg== X-Received: by 10.237.33.69 with SMTP id 63mr9397423qtc.45.1466834062411; Fri, 24 Jun 2016 22:54:22 -0700 (PDT) Received: from twicinski-ltm.internal.salesforce.com ([64.88.227.134]) by smtp.googlemail.com with ESMTPSA id c84sm3778525qkg.48.2016.06.24.22.54.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jun 2016 22:54:21 -0700 (PDT) To: Brian Trammell , ietf References: From: Tim Wicinski Message-ID: <270baf74-ffa3-478d-8183-d0ae63aa6913@gmail.com> Date: Sat, 25 Jun 2016 01:54:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tsv-art@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@tools.ietf.org Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-dnsop-dnssec-roadblock-avoidance X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 05:54:25 -0000 Brian While I attempt to corral the authors, let me attempt to answer these questions as the Document Shepherd. Answers inline. On 6/14/16 8:13 AM, Brian Trammell wrote: > Greetings, > > I've reviewed this draft as part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as any other IETF last call comments. > > Summary: This draft clearly describes online testing of possible DNSSEC failures, and how to interpret the results. It does not appear to pose any transport-related danger, and is broadly ready for publication as a BCP. > > I do have the following questions, though: > > (1) Section 3.1: "The tests are designed to check for one feature at a time". This is generally A Good Thing, but it does seem that there should be some attempt to economize on packets sent. This is not as much a problem when testing recursive resolvers, since they should only need to be run when a host introduces itself to a neighboring recursive resolver and the test traffic shouldn't leave the site. However, section 3.2 are designed to run on the open Internet, and seems to suggests that tests 3.2.1-3.2.3 should be run *first*, then followed by the fourteen tests in section 3.1. In the "best case" future for this document, that every stub resolver implements this online testing automatically, every packet saved is significant. > Interesting point, but the tests in 3.1 would never be run against the servers in section 3.2. I agree, if they did, your optimization would be useful. I am looking for the text which may imply running section 3.1 tests first before running section 3.2 texts > Some optimizations are obvious: 3.2.1 replaces 3.1.1, 3.2.3 replaces 3.1.2. The document should note these (even though they're trivial). Some optimizations have already been made: 3.1.5, 3.1.10, 3.3. test multiple conditions. Are there any other tests that could be combined (e.g. the TCP connectivity and EDNS0 tests) without losing fidelity? > > (2) Could the retries advised in section 5 be abused to cause a resolver running roadblock avoidance to send unnecessary test traffic? It seems that injecting an error, illegal, or bogus response could induce multiple retries, though it's not clear that the amplification factor makes this worth it. > I think the answer on unnecessary traffic is yes, but the text in the document suggests retries the Validator MAY run. The text could be improved to suggest avoid creating amplification issues, however insignificant. > (2) In section 6, the draft raises the possibility of unstable networking after connection (e.g. in a captive portal situation); guidance to refrain from flooding the network with test traffic during this instability might be useful. Perhaps explicitly link the DNSSEC checks to a "network proves to be usable" signal (either from the application or the operating system)? > I believe in Section 6 the two options is a trade off between security (keep testing, and falling test) and usability (waiting for network). Does;'t the text in 6.1 express this - "the device MAY have a policy of action, like continue or fail. " thanks tim > Thanks, cheers, > > Brian (as TSV-ART reviewer) > From nobody Tue Jun 28 07:47:26 2016 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1012D881; Tue, 28 Jun 2016 07:47:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jnRhRgOL7rNq; Tue, 28 Jun 2016 07:47:14 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 885B512D52B; Tue, 28 Jun 2016 07:46:16 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id t127so33131039qkf.1; Tue, 28 Jun 2016 07:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=2euncMjQ0G7M7s3n/nAODqgR05xZHuKhbC6VDkDF2lw=; b=NCrDAWSHIWYD4qHA9fnIsz38O3KJhDv03wjnJ8sGbfOkVl5HstlbMXkTo/2WDhrQ1D B9hmjXOb6Rz5fKWSR+tZ9820XJfIUzVh5pEN8He+PYvLUnSvJfJR78/SZKe34Iop6SUN NrFZc77gtu8hi7jMjSguVfVkAQGxjH4uJyfC36i3Qavpo5TH0I377uO3zRIvPu0+WXnp NCLsMPearySVcg99KkfTm8jqY5Q24Sd0XsLxEuLq3gut9MJ2Bu0YpaRCv/yvB01Haes7 VBqcMB6CV7nrjjewcOHKvHjTZsaMWNXKhFoz8qrvmgW07jaqFx8wsFLmYYZx4OqLlX1t FZTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2euncMjQ0G7M7s3n/nAODqgR05xZHuKhbC6VDkDF2lw=; b=Ic93fLy744WFpGBzEVZTU/JlUeLLEBAjasgEQl1SjbOfr2jvGO8Y/N2KsiuIOfwRsk Gxej8ptWb69a28cPFNyc9W0pk7dDsbaev4ri8QKi77WpDZJinKqp5yZfoMvIK1kIGT8F 7DFrVhOU3Kwotbh9LQlPzDRsOFz2iMX+XY8ycmp582dH39coLolUDkwgqCwiB1/Os/52 +S1i695DQyt6rKR0949ysCrfmUj/1V8PpJYAaRX6h9A1OTyolnF6qYdSDxJar+GFNsA5 xuYj9p//oPmvtKzI5dVPCLVbZR5E71DnCPJ7Pl3ceExsEQDgnjdta3/iMX6rWsgzHL+J 8LPA== X-Gm-Message-State: ALyK8tIYytsaMZYCHPE4Tf9kFTI8fk6GrxskrPOmA9lizqhzQe4dhw62i1KYfYtNB70eL2uZ1bkyNxX2D4OIrw== X-Received: by 10.129.153.16 with SMTP id q16mr978117ywg.211.1467125175693; Tue, 28 Jun 2016 07:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.125.134 with HTTP; Tue, 28 Jun 2016 07:46:15 -0700 (PDT) From: Spencer Dawkins at IETF Date: Tue, 28 Jun 2016 08:46:15 -0600 Message-ID: To: "tsv-chairs@ietf.org" , tsv-art@ietf.org, Lars Eggert , Natasha Rooney Content-Type: multipart/alternative; boundary=94eb2c0bd86af037b1053657b230 Archived-At: Subject: [Tsv-art] TSV Chairs/ART dinner at IETF 96 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 14:47:16 -0000 --94eb2c0bd86af037b1053657b230 Content-Type: text/plain; charset=UTF-8 Dear TSV Chairs and Area Review Team members, Please reserve Monday evening, July 18, at 20:30 for our usual dinner and conversation. Please let us know if you are coming, using the Doodle poll at http://doodle.com/poll/aqt844tz9zwsctcf, by July 16. You can also let us know about any dietary restrictions in a comment there. Actual coordinates will be announced when we have a headcount. Thanks, and we're looking forward to seeing you in Berlin! Spencer and Mirja --94eb2c0bd86af037b1053657b230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TSV Chairs and Area Review Team members,

Please reserve Monday evening, July 18, at 20:30 for our usual dinne= r and conversation.

Please let us know if you are = coming, using the Doodle poll at=C2=A0http://doodle.com/poll/aqt844tz9zwsctcf, by July 16. You= can also let us know about any dietary restrictions in a comment there.

Actual coordinates will be announced when we have a = headcount.

Thanks, and we're looking forward t= o seeing you in Berlin!

Spencer and Mirja
--94eb2c0bd86af037b1053657b230--