From nobody Mon Aug 1 12:28:39 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 5EDA612D98C; Mon, 1 Aug 2016 12:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, WEIRD_PORT=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 jXmB4ZemDMl8; Mon, 1 Aug 2016 12:28:35 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 B34E312D611; Mon, 1 Aug 2016 12:28:32 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id w127so106742638vkh.2; Mon, 01 Aug 2016 12:28:32 -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:cc; bh=Y04lR6qHrMbI1SHvONYGDG43dNz20xPEpZ5Q0XFES2Q=; b=0UuALAW3TO9PtQHQgbVqWnQr9EP+0iMNLEltLck0PsOgSw20lgrtunur9RkNVdfs4w 2R43osQoPwd8dBi1Q2VQGbIC67zzIffBbT+LZIlXL/oo7fxuMBY44a61jwzBWu8+G5V8 +7br5TvrGu6q9Z9XPM+Ok6ZJjxy8C7ltzcFPQv2+UYpKl8NAA1C14MMaJOVrtXXxTGEM lecshPztiEukTCgwpSNOVXO6FHcl0rKx3fy97BDZxDKPewVzpLZoXEgMqlaII5Gt4M5u tjoOvuFZOZpfG4i+tTWwnysOIjAR2Ebh8PcNgcrmU3xJmDC0l92iyx9tUUTblTggu+cK SJmQ== 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:cc; bh=Y04lR6qHrMbI1SHvONYGDG43dNz20xPEpZ5Q0XFES2Q=; b=B97vopjze/FdfST/3lCoto7Jv9BZG759AFh9JpQnNJD8TeMXZk6Xk+eUavswJtT1eI Vx6Yc8VnjbIYRU0jAY8sPx2vfZsG0S0iqQgsUDnGM6CJPuoxIeORVio0DmKFE06F8MQW 3Mymk2vo1Pshs8ketPIlsel+shSP4fHH1Uf5Ow3MgUeQhGrJak8Je3Dx4/HoSQsQx92k xN5QKMVPUWl30RVlGrgl4e0cda9ZPU8FNhvagRz/x+ylKWhGz2jU91De6r2BNheszuzF NjfxnhSk292AwamZ+A41uEUW9ha6pnROgm85zIUHfv09A8vRTDwM6FFgh1x6M5NmPQJl tYcA== X-Gm-Message-State: AEkoouvC2XVkqfcWA0VUCFH1kMV8a9NczCpImqjMFFvWFIQUDJuHDG+50MWsXszC8ON1hIyyKB2g9q2JFZya3Q== X-Received: by 10.31.207.1 with SMTP id f1mr12517915vkg.47.1470079711856; Mon, 01 Aug 2016 12:28:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.78 with HTTP; Mon, 1 Aug 2016 12:28:31 -0700 (PDT) From: Allison Mankin Date: Mon, 1 Aug 2016 15:28:31 -0400 Message-ID: To: IETF Discussion , tsv-art@ietf.org, draft-pd-dispatch-msrp-websocket@ietf.org, Mary Barnes Content-Type: multipart/alternative; boundary=001a114e1ff6044cd60539079b86 Archived-At: Cc: amankin@salesforce.com Subject: [Tsv-art] TSV-ART review of draft-pd-dispatch-msrp-websocket 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: Mon, 01 Aug 2016 19:28:37 -0000 --001a114e1ff6044cd60539079b86 Content-Type: text/plain; charset=UTF-8 Hey, folks, I've reviewed this draft (draft-pd-dispatch-msrp-websocket-13) as part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as any other (belated) IETF last call comments, addressing them in conjunction with the present IESG review. Summary: This draft specifies the WebSocket sub-protocol for MSRP, the SIP-based messaging protocol. It is very similar to RFC 7118, WebSocket as a Transport for SIP, which is already a PS. It does not appear to pose any transport-related danger, and is broadly ready for publication as a PS. Although the draft looks ready to go from a transport point of view, I have a couple of small questions: Section 5 Does the second sentence in the following mean "impossible for a WebSocket MSRP client to communicate directly with other MSRP clients"? The paragraph is confusing. WebSocket clients cannot receive WebSocket connections initiated by other WebSocket clients or WebSocket servers. This means that it is impossible for an MSRP client to communicate directly with other MSRP clients. Therefore, all MSRP over WebSocket messages MUST be routed via an MSRP WebSocket Server. Section 8 bob.example.com:8145 occurs in many of the path examples. Although I notice it also occurs in the MSRP Relay RFC (4976) along with many other unassigned port numbers from the User Space, I wonder if it could be replaced with a port from the Dynamic space (49152-65535) - in this draft, it's the only unassigned port, and this could be one RFC that doesn't confuse port users IRL. Thanks and good luck, Allison --001a114e1ff6044cd60539079b86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey, folks,

I've reviewed this draft (draft-= pd-dispatch-msrp-websocket-13) as part of the TSV Area Review Team, paying = special attention to=20 transport-related concerns. Please take these as any other (belated) IETF l= ast=20 call comments, addressing them in conjunction with the present IESG review.=

Summary: This draft specifies the WebSocket sub-protocol f= or MSRP, the SIP-based messaging protocol. =C2=A0 It is very similar to RFC= 7118, WebSocket as a Transport for SIP, which is already a PS.=C2=A0 It do= es not appear to pose any transport-related danger, and is broadly ready fo= r publication as a PS.

Although the draft looks ready to g= o from a transport point of view, I have a couple of small questions:
Section 5

Does the second sentence in the following mean= "impossible for a WebSocket MSRP client to communicate directly with = other MSRP clients"?=C2=A0 The paragraph is confusing.

   WebSocket clients cannot receive WebSocket connecti=
ons initiated by
   other WebSocket clients or WebSocket servers.  This means that it is
   impossible for an MSRP client to communicate directly with other MSRP
   clients.  Therefore, all MSRP over WebSocket messages MUST be routed
   via an MSRP WebSocket Server.

Section 8
bob.example.com:8145= occurs in many of the path examples.=C2=A0 Although I notice it also occur= s in the MSRP Relay RFC (4976) along with many other unassigned port number= s from the User Space, I wonder if it could be replaced with a port from th= e Dynamic space (49152-65535) - in this draft, it's the only unassigned= port, and this could be one RFC that doesn't confuse port users IRL.
Thanks and good luck,

Allison
--001a114e1ff6044cd60539079b86-- From nobody Tue Aug 2 22:18:06 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 E1FB712D91D; Tue, 2 Aug 2016 22:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.806 X-Spam-Level: X-Spam-Status: No, score=-15.806 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 TzMzLhkAAbBU; Tue, 2 Aug 2016 22:18:01 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3ACB128874; Tue, 2 Aug 2016 22:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11291; q=dns/txt; s=iport; t=1470201480; x=1471411080; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0XsWwpXO3JivW05ghlq3YGxbbKe+7iC/Ye7BovFfOyM=; b=mbsdyvGdR8dnSFDknJZDSd3SC5m22sTPd8xTRQqNclAertzofkdtnbEE qsGlpBXZmHHpdAyPn5oXJUA+jMtJ+cA+DO8wteRpHSdfXOTC7DZb6okPg C1usLDhw+SclrBIxXSLkgm9TIM77reAk4O5gy8ZdnE0n3UMQqQOeldOW3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAgAbfqFX/5tdJa1dgndOVnwHrQOHH?= =?us-ascii?q?4UGgX0ghElVXwKBQTgUAQEBAQEBAV0nhF4BAQUnUhACAQgRAwECKAchERQJCAI?= =?us-ascii?q?EAQ0FiBcDF7saDYNNAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIp3gkOBZzYehR0Fh?= =?us-ascii?q?gyIRIowNAGGF4VvQ4I1gWsXhEOIeoZkgUeEBYN2AQ8PNoN6bgGHNH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,464,1464652800"; d="scan'208,217";a="304630991" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 05:17:59 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u735Hwus024110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Aug 2016 05:17:59 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 Aug 2016 01:17:58 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Wed, 3 Aug 2016 01:17:58 -0400 From: "Ram Mohan R (rmohanr)" To: Allison Mankin , IETF Discussion , "tsv-art@ietf.org" , "draft-pd-dispatch-msrp-websocket@ietf.org" , Mary Barnes Thread-Topic: TSV-ART review of draft-pd-dispatch-msrp-websocket Thread-Index: AQHR7Crov82Ichz7nkCRG4NqOmDLVqA3U7IA Date: Wed, 3 Aug 2016 05:17:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.196.105.100] Content-Type: multipart/alternative; boundary="_000_D3C77BCD64AD3rmohanrciscocom_" MIME-Version: 1.0 Archived-At: Cc: "amankin@salesforce.com" Subject: Re: [Tsv-art] TSV-ART review of draft-pd-dispatch-msrp-websocket 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, 03 Aug 2016 05:18:04 -0000 --_000_D3C77BCD64AD3rmohanrciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Allison, Thanks for your review and feedback, I will replace the text below with fo= llowing. "impossible"->"challenging" EXISTING: WebSocket clients cannot receive WebSocket connections initiated by other WebSocket clients or WebSocket servers. This means that it is impossible for an MSRP client to communicate directly with other MSRP clients. Therefore, all MSRP over WebSocket messages MUST be routed via an MSRP WebSocket Server. NEW: WebSocket clients cannot receive WebSocket connections initiated by other WebSocket clients or WebSocket servers. This means that it is challenging for an MSRP client to communicate directly with other MSRP clients. Therefore, all MSRP over WebSocket messages MUST be routed via an MSRP WebSocket Server. For the second comment, I am fine using a port in the range Dynamic space = (49152-65535) for the examples. Will update the draft with these and publis= h later along with other comments received. Regards, Ram From: Allison Mankin > Date: Tuesday, 2 August 2016 at 12:58 AM To: IETF Discussion >, "tsv-art@ietf.or= g" >, "d= raft-pd-dispatch-msrp-websocket@ietf.org" >, Mary Barnes > Cc: "amankin@salesforce.com" > Subject: TSV-ART review of draft-pd-dispatch-msrp-websocket Resent-From: > Resent-To: >, >, >, Ram Mohan Ravindranath >, > Resent-Date: Tuesday, 2 August 2016 at 12:58 AM Hey, folks, I've reviewed this draft (draft-pd-dispatch-msrp-websocket-13) as part of t= he TSV Area Review Team, paying special attention to transport-related conc= erns. Please take these as any other (belated) IETF last call comments, add= ressing them in conjunction with the present IESG review. Summary: This draft specifies the WebSocket sub-protocol for MSRP, the SIP-= based messaging protocol. It is very similar to RFC 7118, WebSocket as a = Transport for SIP, which is already a PS. It does not appear to pose any t= ransport-related danger, and is broadly ready for publication as a PS. Although the draft looks ready to go from a transport point of view, I have= a couple of small questions: Section 5 Does the second sentence in the following mean "impossible for a WebSocket = MSRP client to communicate directly with other MSRP clients"? The paragrap= h is confusing. WebSocket clients cannot receive WebSocket connections initiated by other WebSocket clients or WebSocket servers. This means that it is impossible for an MSRP client to communicate directly with other MSRP clients. Therefore, all MSRP over WebSocket messages MUST be routed via an MSRP WebSocket Server. Section 8 bob.example.com:8145 occurs in many of the pat= h examples. Although I notice it also occurs in the MSRP Relay RFC (4976) = along with many other unassigned port numbers from the User Space, I wonder= if it could be replaced with a port from the Dynamic space (49152-65535) -= in this draft, it's the only unassigned port, and this could be one RFC th= at doesn't confuse port users IRL. Thanks and good luck, Allison --_000_D3C77BCD64AD3rmohanrciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Allison,

Thanks for your review and  feedback, I will replace the text bel= ow with following. "impossible"—>"challenging"=

EXISTING:
 WebSocket clients cannot receive WebSocket co=
nnections initiated by
   other WebSocket clients or WebSocket servers.  This means that it is
   impossible for an MSRP client to communicate directly with other MSRP
   clients.  Therefore, all MSRP over WebSocket messages MUST be routed
   via an MSRP WebSocket Server.
NEW:
 WebSocket clients cannot receive WebSocket co=
nnections initiated by
   other WebSocket clients or WebSocket servers.  This means that it is
   challenging for an MSRP client to communicate directly with other MSRP
   clients.  Therefore, all MSRP over WebSocket messages MUST be routed
   via an MSRP WebSocket Server.
For the second comment, I am fine using a port in the range  Dynamic space (49152-655= 35) for the examples. Will update the draft with these and publish later along with other comments received.

Regards,
Ram<= /div>

From: Allison Mankin <allison.mankin@gmail.com>
Date: Tuesday, 2 August 2016 at 12:= 58 AM
To: IETF Discussion <ietf@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-pd-dispatch-msrp-websocket@ietf.org" <draft-pd-= dispatch-msrp-websocket@ietf.org>, Mary Barnes <mary.ietf.barnes@gmail.com>
Cc: "amankin@salesforce.com" <amankin@salesforce.com>
Subject: TSV-ART review of draft-pd= -dispatch-msrp-websocket
Resent-From: <alias-bounces@ietf.org>
Resent-To: <gsalguei@cisco.com>, <peter.dunkley@xura.com>, <victor.pascual.avila@oracle.com>, Ram Mohan Ravindranath <rmohanr@ci= sco.com>, <gavin.llew= ellyn@xura.com>
Resent-Date: Tuesday, 2 August 2016= at 12:58 AM

Hey, folks,

I've reviewed this draft (draft-pd-dispatch-msrp-websocket-13) as part of t= he TSV Area Review Team, paying special attention to transport-related conc= erns. Please take these as any other (belated) IETF last call comments, add= ressing them in conjunction with the present IESG review.

Summary: This draft specifies the WebSocket sub-protocol for MSRP, the S= IP-based messaging protocol.   It is very similar to RFC 7118, WebSock= et as a Transport for SIP, which is already a PS.  It does not appear to pose any transport-related danger, and i= s broadly ready for publication as a PS.

Although the draft looks ready to go from a transport point of view, I h= ave a couple of small questions:

Section 5

Does the second sentence in the following mean "impossible for a WebSo= cket MSRP client to communicate directly with other MSRP clients"?&nbs= p; The paragraph is confusing.

   WebSocket clients cannot receive WebSocket =
connections initiated by
   other WebSocket clients or WebSocket servers.  This means that it is
   impossible for an MSRP client to communicate directly with other MSRP
   clients.  Therefore, all MSRP over WebSocket messages MUST be routed
   via an MSRP WebSocket Server.

Section 8

bob.example.com:8145 occurs = in many of the path examples.  Although I notice it also occurs in the= MSRP Relay RFC (4976) along with many other unassigned port numbers from the User Space, I wonder if it could be repla= ced with a port from the Dynamic space (49152-65535) - in this draft, it's = the only unassigned port, and this could be one RFC that doesn't confuse po= rt users IRL.

Thanks and good luck,

Allison
 --_000_D3C77BCD64AD3rmohanrciscocom_-- From nobody Wed Aug 3 02:46:42 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 87D7612D100; Wed, 3 Aug 2016 02:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 7UK58sY01r_N; Wed, 3 Aug 2016 02:46:36 -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 7C5EF12D9D2; Wed, 3 Aug 2016 02:46:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 386BAD9302; Wed, 3 Aug 2016 11:46:16 +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 oU3npbc7Rdvp; Wed, 3 Aug 2016 11:46:15 +0200 (MEST) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C924BD9303; Wed, 3 Aug 2016 11:46:15 +0200 (MEST) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_AE99CBFD-5DCE-4BA4-B541-C9A0D8B999DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 3 Aug 2016 11:46:14 +0200 Message-Id: <9AE7C890-1F2D-40D8-9F23-4D9CE68A47E4@tik.ee.ethz.ch> To: draft-ietf-xrblock-independent-burst-gap-discard@tools.ietf.org, tsv-art@ietf.org, ietf@ietf.org, The IESG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Tsv-art] TSV-ART review for draft-ietf-xrblock-independent-burst-gap-discard-02 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, 03 Aug 2016 09:46:38 -0000 --Apple-Mail=_AE99CBFD-5DCE-4BA4-B541-C9A0D8B999DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, I've reviewed draft-ietf-xrblock-independent-burst-gap-discard-02 for = the Transport Area Review Team (TSV-ART); please treat these as IETF = Last Call comments. Summary: This draft is relatively straightforward, and is ready for = publication, modulo an editorial nit, below: Nit(s): (1) Terminology, Bursts and Gaps: I can guess what Gmin is without = having to read RFC3611 section 4.7.2 (and, indeed, I was mostly right), = but it would be nice to copy at least an abbreviated definition here. Cheers, Brian --Apple-Mail=_AE99CBFD-5DCE-4BA4-B541-C9A0D8B999DA 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 iQIcBAEBCgAGBQJXob1nAAoJEIoSt78L6kajN0EP/2yuzPWb5sEwlCjFhwyvx6f9 4kHBNlV+5Fsgu/5iF/hcD+Xl3e4SPRXj/YMARDUT2WJmIWjGe4d0KAYhgKOfUtq7 KZhyInF/+LeDiabTopj7bEopoeo9K8J2zaZLDTrEjF1lGhxLgdXQkHRFvu35YdP1 V8aHmOmJ1MZud1mJPlWMUu5hgPJL94PI3eDVQnlFWSUo3o2J1JrUXEWQ/lQ9dckL dTDcd2yhXDcMs1c5H4BjaR7rdbLiM9ktpZvBcbxyDd2Quifgi3wvVkjmDmHu5loy RcvHF0iJ8MUEUbsNGjFTSTH3VOZQiRkFX/m6WED5PKBdDRyQcYH4AWxH+l+wdXyR iGtZfjg8otN8Cgis8/tcs7Kw40RQNRr0bf6Ewb7c2dGKVuV7qPNU3lF3mD02qwl8 KwxTwQcos03Yc7pXZ2i9FoM198Jr/1NEIDQ8IHHGZVIKsYOM7jEBBuLN9EhRtygB rb15zBhYo+WwfKGPqIcPy/usMnB1TGd7R9BZxn16EBV6DHbGhD3nE4uvBGmyPw2m mvTAmPiHyzoBmjMFho6uZz3QdZOH32fA97ogY449i91b5kT1vTZiXdmwgKh81Mak 1JOCHp4kxWh8qtMxb06pDAdTjua/0BZKMgMo0zqG9ibHuq04d9YLahtV8Zh8Ay+d /TpGi4ZqY7Zhari1wqBR =vl2J -----END PGP SIGNATURE----- --Apple-Mail=_AE99CBFD-5DCE-4BA4-B541-C9A0D8B999DA-- From nobody Wed Aug 3 07:00:40 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 C3D1612DD5C; Wed, 3 Aug 2016 07:00:34 -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 EVgMWgNVXPhy; Wed, 3 Aug 2016 07:00:32 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 1F38512D597; Wed, 3 Aug 2016 06:54:43 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id s189so146436158vkh.1; Wed, 03 Aug 2016 06:54:43 -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:cc; bh=9SqjeGhuAMJ7wuriZp/WbKbDUhlsgnuGgI1yveTFoKo=; b=szbQ/h9rI5UQbqIRteS3miFaurz5j4H03u3Se1eLOdYuiBzBgILAiNv3g9o5xFBf2l RIrZn2SMz5PWzEL9d3jyM2s+E36J3w7ue3Nc69GaxXsrdQ8qKoSiA0VCmW8cwmC1NQGQ fPznS1s3n5H3XtYXJgvyDeKWiCOiErtEbxFooIgK6Lm2DisWYewFwtVHi870QpDzMSjz /SNFewCtrE+qDK+sp2rDp2qpZ7qE8QwL1mZPANXHkdG0Xofo4fePl2KuhCWSgPXQkX2d 0Gn+NFfcrGllto75U7JlKc0rOWTFpsVRRq22UBeNCa/F6ODIpzg/QyKWlWkAwZBUbRPv 4ONw== 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:cc; bh=9SqjeGhuAMJ7wuriZp/WbKbDUhlsgnuGgI1yveTFoKo=; b=lBYVlfo3bBsGxI06YoSxI1P73twCi7yPeu+S3UKEk6OoMm9UBm+sAymgy8s2oPb0N/ XTZU2TivjeSL49a1XgCsBwGQyfWiCBJSeHwvLVr8nXdDD1lD1XcC3lC/ghcGBXQ0R2nd uKzGAZIfHo2UHXSbHIY141SaP3G3TNklkiNkW/huqYVXsuA4LrAjms8N4SWVItVkeYuc e5RVOwq3lrrZN7QgOPZL8SAanobvltIiN7CwASfQL+AqA4zR2Ucz7oqgmBdmCDa/Shad BOTM2sonbDbv+scIqlc2CJhV+hClxAIzR5wkVqwrUsaH9X6Q6E7Z+TNRQSFnJnOBwuag fTfQ== X-Gm-Message-State: AEkoouskK9HqoZG3f1leuU969wtPxJVDjgc+kmSbfJvfX/+NFb2tcLW6+8+wRsjFSZzyoJCbhTVMc8KS2Vcfcg== X-Received: by 10.31.72.6 with SMTP id v6mr17678337vka.106.1470232482035; Wed, 03 Aug 2016 06:54:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.78 with HTTP; Wed, 3 Aug 2016 06:54:41 -0700 (PDT) From: Allison Mankin Date: Wed, 3 Aug 2016 09:54:41 -0400 Message-ID: To: IETF Discussion , tsv-art@ietf.org, draft-ietf-rtcweb-transports@tools.ietf.org, "cullenfluffyjennings@gmail.com" , IESG Content-Type: multipart/alternative; boundary=001a114dc7e8d43d1205392b2c38 Archived-At: Cc: amankin@salesforce.com Subject: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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, 03 Aug 2016 14:00:35 -0000 --001a114dc7e8d43d1205392b2c38 Content-Type: text/plain; charset=UTF-8 Hi, I've reviewed this draft (draft-ietf-rtcpweb-transports-14.txt) 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 specifies the mandatory transport protocols (and transport features) associated with the use of WebRTC media. It does not appear to pose any transport-related danger, except perhaps that a reviewer's head aches over the number of RFCs that are needed to get media bits from point A to point B, but this is not a fault of the draft. The draft is broadly ready for publication as a PS, however there are a few issues for the Transport Area. Section 3.4: If TCP connections are used, RTP framing according to [RFC4571 ] MUST be used, both for the RTP packets and for the DTLS packets used to carry data channels. About the passage above, RFC4571 doesn't talk about DTLS. It looks like this passage also needs a reference to whatever of the specs defines framing for DTLS? Section 4.1 Local Prioritization This section describes the resource allocations that are expected for prioritized different streams when there is congestion. There are two highly relevant congestion control documents that are approved (or nearly so), and I can't see that the RTCWB WG considered them from my quick review of mailing list discussions, but it would be a good idea for this draft to call them out: draft-ietf-avtcore-rtp-circuit-breakers-17 - this has enough positions to pass and is waiting for an AD followup (looks like for the IANA re-review after a version change). It puts some additional considerations on flows that are likely to be relevant to the flows in the present draft. draft-ietf-rmcat-cc-requirements-09 - this is in the RFC Editor queue and seems to be waiting for the rtcweb-overview draft, to which it normatively refers. I think it would be better if the rmcat draft referenced rtcweb-transpoarts, and if rtcweb-transports would check on its alignment with the rmcat requirements in the congestion control remarks in section 4.1. Section 4.2 Usage of Quality of Service - DSCP and Multiplexing I will just flag here that I reviewed the mailing list and it seems that there was a lot of TSV review of the DSCP material here already, and a consensus reached. --001a114dc7e8d43d1205392b2c38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've reviewed this draft (draft= -ietf-rtcpweb-transports-14.txt) as part of the TSV Area Review Team, payin= g special attention to=20 transport-related concerns. Please take these as any other IETF last=20 call comments.

Summary: this draft specifies the mandatory = transport protocols (and transport features) associated with the use of Web= RTC media.=C2=A0 It does not appear to pose any transport-related danger, e= xcept perhaps that a reviewer's head aches over the number of RFCs that= are needed to get media bits from point A to point B, but this is not a fa= ult of the draft.=C2=A0 The draft is broadly ready for publication as a PS,= however there are a few issues for the Transport Area.

Sec= tion 3.4:
   If TCP connections are used, R=
TP framing according to [RFC4571=
] MUST
   be used, both for the RTP packets and for the DTLS packets used to
   carry data channels.
About the passage above, RFC4571 doesn'= ;t talk about DTLS.=C2=A0 It looks like this passage also needs a reference= to whatever of the specs defines framing for DTLS?

Sectio= n 4.1=C2=A0 Local Prioritization

This section describes the= resource allocations that are expected for prioritized different streams w= hen there is congestion.=C2=A0 There are two highly relevant congestion con= trol documents that are approved (or nearly so), and I can't see that t= he=C2=A0 RTCWB WG considered them from my quick review of mailing list disc= ussions, but it would be a good idea for this draft to call them out:
draft-ietf-avtcore-rtp-circuit-breakers-17 - this has enough positions to= pass and is waiting for an AD followup (looks like for the IANA re-review = after a version change).=C2=A0 It puts some additional considerations on fl= ows that are likely to be relevant to the flows in the present draft.
draft-ietf-rmcat-cc-requirements-09 - this is in the RFC Editor queue and= seems to be waiting for the rtcweb-overview draft, to which it normatively= refers.=C2=A0 I think it would be better if the rmcat draft referenced rtc= web-transpoarts, and if rtcweb-transports would check on its alignment with= the rmcat requirements in the congestion control remarks in section 4.1.
Section 4.2 Usage of Quality of Service - DSCP and Multiplex= ing

I will just flag here that I reviewed the mailing list = and it seems that there was a lot of TSV review of the DSCP material here a= lready, and a consensus reached.





<= br>
--001a114dc7e8d43d1205392b2c38-- From nobody Wed Aug 3 08:04:10 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 BBC3212D1B1; Wed, 3 Aug 2016 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=WL6SVh7y; dkim=pass (1024-bit key) header.d=emc.com header.b=Z5JXO0Ke 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 LeY_EhI1c3OC; Wed, 3 Aug 2016 08:04:01 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 5B81B12B058; Wed, 3 Aug 2016 08:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1470236631; x=1501772631; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W0+B0XG88NJHXvLRdFFNNKQNbatK5ceW2twFAAr1xrI=; b=WL6SVh7yVRl4V9isXlQJgDvZCIQQwi84CHRs5ZKoSxDPvAtxfjz12vFh FqijNGl9Nqu9Vkp711JVjkz75nj6tF+PKw44Dn3tHPkaQ8iqYxfd5O5YF +dfBedfkVAHfrf0FJMsZAlqRAsGji7Nkrt0aGwY2TEtq8BRK7qHST/yYb Q=; Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 20:03:49 +0500 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u73F3kJD007679 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Aug 2016 11:03:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u73F3kJD007679 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1470236628; bh=6mXAgIIkK/faLckG/qGSaMyNIUQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Z5JXO0KeY/SrVPPJ0Sd4wAsfF+lhftUZNYiipVa1qi0BvZxNot0Fkv7cDvjmEd1TA O6Rsch++vrwuz4mHHcvubZwTVtn3HzMZI4Bu2HFjJaJJ2rXTY55FTARXVzB+jLlJQ8 qu3LjD7DbeBlq32GSvLV/JxG/b7O8i50kqZjSjdM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u73F3kJD007679 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Wed, 3 Aug 2016 11:03:11 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u73F3Sqs005782 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 3 Aug 2016 11:03:28 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0266.001; Wed, 3 Aug 2016 11:03:27 -0400 From: "Black, David" To: Allison Mankin , IETF Discussion , "tsv-art@ietf.org" , "draft-ietf-rtcweb-transports@tools.ietf.org" , "cullenfluffyjennings@gmail.com" , IESG Thread-Topic: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports Thread-Index: AQHR7Y9r4XRzbcD7WUimeTP7mKL0wqA3UNNA Date: Wed, 3 Aug 2016 15:03:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F622F20MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "Black, David" , "amankin@salesforce.com" Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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, 03 Aug 2016 15:04:04 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F622F20MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsaXNvbiwNCg0KPiBTZWN0aW9uIDQuMiBVc2FnZSBvZiBRdWFsaXR5IG9mIFNlcnZpY2Ug LSBEU0NQIGFuZCBNdWx0aXBsZXhpbmcNCj4gSSB3aWxsIGp1c3QgZmxhZyBoZXJlIHRoYXQgSSBy ZXZpZXdlZCB0aGUgbWFpbGluZyBsaXN0IGFuZCBpdCBzZWVtcyB0aGF0IHRoZXJlIHdhcyBhIGxv dCBvZiBUU1YgcmV2aWV3IG9mIHRoZQ0KPiBEU0NQIG1hdGVyaWFsIGhlcmUgYWxyZWFkeSwgYW5k IGEgY29uc2Vuc3VzIHJlYWNoZWQuDQoNClRoYXTigJlzIGNvcnJlY3QgLSB0aGVyZSBpcyBhbHNv IG9uZSByZW1haW5pbmcgRFNDUCBpc3N1ZSwgbmFtZWx5IHdoYXQgdG8gZG8gaWYgdXNlIG9mIGEg bm9uLXplcm8gRFNDUCBjYXVzZXMgdHJhZmZpYyB0byBiZSBibGFjay1ob2xlZCAod2hpY2ggY291 bGQgaGFwcGVuIGluIHRoZSBtaWRkbGUgb2YgYSBXZWJSVEMgc2Vzc2lvbiwgZS5nLiwgZHVlIHRv IGEgcm91dGluZyBjaGFuZ2UpIC4gVGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBCZXJsaW4gUlRD V0VCIG1lZXRpbmcgYW5kIGEgcmVzb2x1dGlvbiB3YXMgYWdyZWVkIHRvIGZvciBXZWJSVEMsIHNv IHRoZXJlIHNob3VsZCBiZSBhIHJldmlzZWQgdmVyc2lvbiBvZiB0aGlzIHJ0Y3dlYi10cmFuc3Bv cnRzIGRyYWZ0IGNvbWluZyBzb29uIHRoYXQgc3BlY2lmaWVzIHdoYXQgdG8gZG8uICBTZWUgdGhl IEJlcmxpbiBSVENXRUIgIG1pbnV0ZXMgZm9yIGRldGFpbHMgYnV0IHRoZSBoaWdoLWxldmVsIHN1 bW1hcnkgaXMgdG8gbW9uaXRvciBmb3IgYmxhY2staG9saW5nIGFuZCByZXN0YXJ0IElDRSB3aXRo IGFsbC16ZXJvIERTQ1AgdXNhZ2UgaW4gdGhlIFdlYlJUQyBzZXNzaW9uIGlmIGJsYWNrLWhvbGlu ZyBvY2N1cnMuDQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBUc3YtYXJ0IFttYWlsdG86dHN2 LWFydC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxsaXNvbiBNYW5raW4NClNlbnQ6 IFdlZG5lc2RheSwgQXVndXN0IDAzLCAyMDE2IDk6NTUgQU0NClRvOiBJRVRGIERpc2N1c3Npb247 IHRzdi1hcnRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHNAdG9vbHMuaWV0 Zi5vcmc7IGN1bGxlbmZsdWZmeWplbm5pbmdzQGdtYWlsLmNvbTsgSUVTRw0KQ2M6IGFtYW5raW5A c2FsZXNmb3JjZS5jb20NClN1YmplY3Q6IFtUc3YtYXJ0XSBUU1YtQVJUIHJldmlldyBvZiBkcmFm dC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzDQoNCkhpLA0KSSd2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0 IChkcmFmdC1pZXRmLXJ0Y3B3ZWItdHJhbnNwb3J0cy0xNC50eHQpIGFzIHBhcnQgb2YgdGhlIFRT ViBBcmVhIFJldmlldyBUZWFtLCBwYXlpbmcgc3BlY2lhbCBhdHRlbnRpb24gdG8gdHJhbnNwb3J0 LXJlbGF0ZWQgY29uY2VybnMuIFBsZWFzZSB0YWtlIHRoZXNlIGFzIGFueSBvdGhlciBJRVRGIGxh c3QgY2FsbCBjb21tZW50cy4NClN1bW1hcnk6IHRoaXMgZHJhZnQgc3BlY2lmaWVzIHRoZSBtYW5k YXRvcnkgdHJhbnNwb3J0IHByb3RvY29scyAoYW5kIHRyYW5zcG9ydCBmZWF0dXJlcykgYXNzb2Np YXRlZCB3aXRoIHRoZSB1c2Ugb2YgV2ViUlRDIG1lZGlhLiAgSXQgZG9lcyBub3QgYXBwZWFyIHRv IHBvc2UgYW55IHRyYW5zcG9ydC1yZWxhdGVkIGRhbmdlciwgZXhjZXB0IHBlcmhhcHMgdGhhdCBh IHJldmlld2VyJ3MgaGVhZCBhY2hlcyBvdmVyIHRoZSBudW1iZXIgb2YgUkZDcyB0aGF0IGFyZSBu ZWVkZWQgdG8gZ2V0IG1lZGlhIGJpdHMgZnJvbSBwb2ludCBBIHRvIHBvaW50IEIsIGJ1dCB0aGlz IGlzIG5vdCBhIGZhdWx0IG9mIHRoZSBkcmFmdC4gIFRoZSBkcmFmdCBpcyBicm9hZGx5IHJlYWR5 IGZvciBwdWJsaWNhdGlvbiBhcyBhIFBTLCBob3dldmVyIHRoZXJlIGFyZSBhIGZldyBpc3N1ZXMg Zm9yIHRoZSBUcmFuc3BvcnQgQXJlYS4NClNlY3Rpb24gMy40Og0KDQogICBJZiBUQ1AgY29ubmVj dGlvbnMgYXJlIHVzZWQsIFJUUCBmcmFtaW5nIGFjY29yZGluZyB0byBbUkZDNDU3MTxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDU3MT5dIE1VU1QNCg0KICAgYmUgdXNlZCwgYm90aCBm b3IgdGhlIFJUUCBwYWNrZXRzIGFuZCBmb3IgdGhlIERUTFMgcGFja2V0cyB1c2VkIHRvDQoNCiAg IGNhcnJ5IGRhdGEgY2hhbm5lbHMuDQpBYm91dCB0aGUgcGFzc2FnZSBhYm92ZSwgUkZDNDU3MSBk b2Vzbid0IHRhbGsgYWJvdXQgRFRMUy4gIEl0IGxvb2tzIGxpa2UgdGhpcyBwYXNzYWdlIGFsc28g bmVlZHMgYSByZWZlcmVuY2UgdG8gd2hhdGV2ZXIgb2YgdGhlIHNwZWNzIGRlZmluZXMgZnJhbWlu ZyBmb3IgRFRMUz8NClNlY3Rpb24gNC4xICBMb2NhbCBQcmlvcml0aXphdGlvbg0KVGhpcyBzZWN0 aW9uIGRlc2NyaWJlcyB0aGUgcmVzb3VyY2UgYWxsb2NhdGlvbnMgdGhhdCBhcmUgZXhwZWN0ZWQg Zm9yIHByaW9yaXRpemVkIGRpZmZlcmVudCBzdHJlYW1zIHdoZW4gdGhlcmUgaXMgY29uZ2VzdGlv bi4gIFRoZXJlIGFyZSB0d28gaGlnaGx5IHJlbGV2YW50IGNvbmdlc3Rpb24gY29udHJvbCBkb2N1 bWVudHMgdGhhdCBhcmUgYXBwcm92ZWQgKG9yIG5lYXJseSBzbyksIGFuZCBJIGNhbid0IHNlZSB0 aGF0IHRoZSAgUlRDV0IgV0cgY29uc2lkZXJlZCB0aGVtIGZyb20gbXkgcXVpY2sgcmV2aWV3IG9m IG1haWxpbmcgbGlzdCBkaXNjdXNzaW9ucywgYnV0IGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIGZv ciB0aGlzIGRyYWZ0IHRvIGNhbGwgdGhlbSBvdXQ6DQoNCmRyYWZ0LWlldGYtYXZ0Y29yZS1ydHAt Y2lyY3VpdC1icmVha2Vycy0xNyAtIHRoaXMgaGFzIGVub3VnaCBwb3NpdGlvbnMgdG8gcGFzcyBh bmQgaXMgd2FpdGluZyBmb3IgYW4gQUQgZm9sbG93dXAgKGxvb2tzIGxpa2UgZm9yIHRoZSBJQU5B IHJlLXJldmlldyBhZnRlciBhIHZlcnNpb24gY2hhbmdlKS4gIEl0IHB1dHMgc29tZSBhZGRpdGlv bmFsIGNvbnNpZGVyYXRpb25zIG9uIGZsb3dzIHRoYXQgYXJlIGxpa2VseSB0byBiZSByZWxldmFu dCB0byB0aGUgZmxvd3MgaW4gdGhlIHByZXNlbnQgZHJhZnQuDQoNCmRyYWZ0LWlldGYtcm1jYXQt Y2MtcmVxdWlyZW1lbnRzLTA5IC0gdGhpcyBpcyBpbiB0aGUgUkZDIEVkaXRvciBxdWV1ZSBhbmQg c2VlbXMgdG8gYmUgd2FpdGluZyBmb3IgdGhlIHJ0Y3dlYi1vdmVydmlldyBkcmFmdCwgdG8gd2hp Y2ggaXQgbm9ybWF0aXZlbHkgcmVmZXJzLiAgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYg dGhlIHJtY2F0IGRyYWZ0IHJlZmVyZW5jZWQgcnRjd2ViLXRyYW5zcG9hcnRzLCBhbmQgaWYgcnRj d2ViLXRyYW5zcG9ydHMgd291bGQgY2hlY2sgb24gaXRzIGFsaWdubWVudCB3aXRoIHRoZSBybWNh dCByZXF1aXJlbWVudHMgaW4gdGhlIGNvbmdlc3Rpb24gY29udHJvbCByZW1hcmtzIGluIHNlY3Rp b24gNC4xLg0KU2VjdGlvbiA0LjIgVXNhZ2Ugb2YgUXVhbGl0eSBvZiBTZXJ2aWNlIC0gRFNDUCBh bmQgTXVsdGlwbGV4aW5nDQpJIHdpbGwganVzdCBmbGFnIGhlcmUgdGhhdCBJIHJldmlld2VkIHRo ZSBtYWlsaW5nIGxpc3QgYW5kIGl0IHNlZW1zIHRoYXQgdGhlcmUgd2FzIGEgbG90IG9mIFRTViBy ZXZpZXcgb2YgdGhlIERTQ1AgbWF0ZXJpYWwgaGVyZSBhbHJlYWR5LCBhbmQgYSBjb25zZW5zdXMg cmVhY2hlZC4NCg0KDQoNCg0K --_000_CE03DB3D7B45C245BCA0D243277949362F622F20MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5v cm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQWxs aXNvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5TZWN0aW9uIDQuMiBVc2FnZSBvZiBRdWFsaXR5IG9mIFNlcnZpY2UgLSBEU0NQ IGFuZCBNdWx0aXBsZXhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jmd0OyBJIHdpbGwganVzdCBmbGFnIGhlcmUgdGhhdCBJIHJldmlld2Vk IHRoZSBtYWlsaW5nIGxpc3QgYW5kIGl0IHNlZW1zIHRoYXQgdGhlcmUgd2FzIGEgbG90IG9mIFRT ViByZXZpZXcgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZndDsgRFNDUCBtYXRlcmlhbCBoZXJlIGFscmVhZHksIGFuZCBhIGNvbnNl bnN1cyByZWFjaGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgY29ycmVjdCAtIHRoZXJlIGlzIGFsc28g b25lIHJlbWFpbmluZyBEU0NQIGlzc3VlLCBuYW1lbHkgd2hhdCB0byBkbyBpZiB1c2Ugb2YgYSBu b24temVybyBEU0NQIGNhdXNlcyB0cmFmZmljIHRvIGJlIGJsYWNrLWhvbGVkICh3aGljaCBjb3Vs ZCBoYXBwZW4gaW4NCiB0aGUgbWlkZGxlIG9mIGEgV2ViUlRDIHNlc3Npb24sIGUuZy4sIGR1ZSB0 byBhIHJvdXRpbmcgY2hhbmdlKSAuIFRoaXMgd2FzIGRpc2N1c3NlZCBpbiB0aGUgQmVybGluIFJU Q1dFQiBtZWV0aW5nIGFuZCBhIHJlc29sdXRpb24gd2FzIGFncmVlZCB0byBmb3IgV2ViUlRDLCBz byB0aGVyZSBzaG91bGQgYmUgYSByZXZpc2VkIHZlcnNpb24gb2YgdGhpcyBydGN3ZWItdHJhbnNw b3J0cyBkcmFmdCBjb21pbmcgc29vbiB0aGF0IHNwZWNpZmllcyB3aGF0DQogdG8gZG8uJm5ic3A7 IFNlZSB0aGUgQmVybGluIFJUQ1dFQiAmbmJzcDttaW51dGVzIGZvciBkZXRhaWxzIGJ1dCB0aGUg aGlnaC1sZXZlbCBzdW1tYXJ5IGlzIHRvIG1vbml0b3IgZm9yIGJsYWNrLWhvbGluZyBhbmQgcmVz dGFydCBJQ0Ugd2l0aCBhbGwtemVybyBEU0NQIHVzYWdlIGluIHRoZSBXZWJSVEMgc2Vzc2lvbiBp ZiBibGFjay1ob2xpbmcgb2NjdXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCAtLURhdmlkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRzdi1hcnQgW21haWx0bzp0c3Yt YXJ0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsbGlzb24gTWFua2lu PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDAzLCAyMDE2IDk6NTUgQU08YnI+ DQo8Yj5Ubzo8L2I+IElFVEYgRGlzY3Vzc2lvbjsgdHN2LWFydEBpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1ydGN3ZWItdHJhbnNwb3J0c0B0b29scy5pZXRmLm9yZzsgY3VsbGVuZmx1ZmZ5amVubmluZ3NA Z21haWwuY29tOyBJRVNHPGJyPg0KPGI+Q2M6PC9iPiBhbWFua2luQHNhbGVzZm9yY2UuY29tPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtUc3YtYXJ0XSBUU1YtQVJUIHJldmlldyBvZiBkcmFmdC1pZXRm LXJ0Y3dlYi10cmFuc3BvcnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JJ3ZlIHJl dmlld2VkIHRoaXMgZHJhZnQgKGRyYWZ0LWlldGYtcnRjcHdlYi10cmFuc3BvcnRzLTE0LnR4dCkg YXMgcGFydCBvZiB0aGUgVFNWIEFyZWEgUmV2aWV3IFRlYW0sIHBheWluZyBzcGVjaWFsIGF0dGVu dGlvbiB0byB0cmFuc3BvcnQtcmVsYXRlZCBjb25jZXJucy4gUGxlYXNlDQogdGFrZSB0aGVzZSBh cyBhbnkgb3RoZXIgSUVURiBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3VtbWFyeTogdGhpcyBkcmFmdCBzcGVjaWZpZXMgdGhlIG1h bmRhdG9yeSB0cmFuc3BvcnQgcHJvdG9jb2xzIChhbmQgdHJhbnNwb3J0IGZlYXR1cmVzKSBhc3Nv Y2lhdGVkIHdpdGggdGhlIHVzZSBvZiBXZWJSVEMgbWVkaWEuJm5ic3A7IEl0IGRvZXMgbm90IGFw cGVhciB0byBwb3NlIGFueQ0KIHRyYW5zcG9ydC1yZWxhdGVkIGRhbmdlciwgZXhjZXB0IHBlcmhh cHMgdGhhdCBhIHJldmlld2VyJ3MgaGVhZCBhY2hlcyBvdmVyIHRoZSBudW1iZXIgb2YgUkZDcyB0 aGF0IGFyZSBuZWVkZWQgdG8gZ2V0IG1lZGlhIGJpdHMgZnJvbSBwb2ludCBBIHRvIHBvaW50IEIs IGJ1dCB0aGlzIGlzIG5vdCBhIGZhdWx0IG9mIHRoZSBkcmFmdC4mbmJzcDsgVGhlIGRyYWZ0IGlz IGJyb2FkbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGEgUFMsIGhvd2V2ZXIgdGhlcmUNCiBh cmUgYSBmZXcgaXNzdWVzIGZvciB0aGUgVHJhbnNwb3J0IEFyZWEuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3Rp b24gMy40OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IElmIFRDUCBj b25uZWN0aW9ucyBhcmUgdXNlZCwgUlRQIGZyYW1pbmcgYWNjb3JkaW5nIHRvIFs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDU3MSIgdGl0bGU9IiZxdW90O0ZyYW1pbmcg UmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBhbmQgUlRQIENvbnRyb2wgUHJvdG9j b2wgKFJUQ1ApIFBhY2tldHMgb3ZlciBDb25uZWN0aW9uLSBPcmllbnRlZCBUcmFuc3BvcnQmcXVv dDsiPlJGQzQ1NzE8L2E+XSBNVVNUPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGJlIHVzZWQsIGJvdGggZm9yIHRoZSBSVFAgcGFja2V0cyBhbmQgZm9yIHRoZSBEVExTIHBhY2tl dHMgdXNlZCB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjYXJyeSBkYXRh IGNoYW5uZWxzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BYm91dCB0aGUgcGFzc2FnZSBhYm92ZSwg UkZDNDU3MSBkb2Vzbid0IHRhbGsgYWJvdXQgRFRMUy4mbmJzcDsgSXQgbG9va3MgbGlrZSB0aGlz IHBhc3NhZ2UgYWxzbyBuZWVkcyBhIHJlZmVyZW5jZSB0byB3aGF0ZXZlciBvZiB0aGUgc3BlY3Mg ZGVmaW5lcyBmcmFtaW5nIGZvciBEVExTPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+U2VjdGlvbiA0LjEmbmJzcDsgTG9jYWwgUHJpb3JpdGl6YXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGlzIHNlY3Rpb24gZGVzY3JpYmVz IHRoZSByZXNvdXJjZSBhbGxvY2F0aW9ucyB0aGF0IGFyZSBleHBlY3RlZCBmb3IgcHJpb3JpdGl6 ZWQgZGlmZmVyZW50IHN0cmVhbXMgd2hlbiB0aGVyZSBpcyBjb25nZXN0aW9uLiZuYnNwOyBUaGVy ZSBhcmUgdHdvIGhpZ2hseSByZWxldmFudCBjb25nZXN0aW9uDQogY29udHJvbCBkb2N1bWVudHMg dGhhdCBhcmUgYXBwcm92ZWQgKG9yIG5lYXJseSBzbyksIGFuZCBJIGNhbid0IHNlZSB0aGF0IHRo ZSZuYnNwOyBSVENXQiBXRyBjb25zaWRlcmVkIHRoZW0gZnJvbSBteSBxdWljayByZXZpZXcgb2Yg bWFpbGluZyBsaXN0IGRpc2N1c3Npb25zLCBidXQgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgZm9y IHRoaXMgZHJhZnQgdG8gY2FsbCB0aGVtIG91dDo8YnI+DQo8YnI+DQpkcmFmdC1pZXRmLWF2dGNv cmUtcnRwLWNpcmN1aXQtYnJlYWtlcnMtMTcgLSB0aGlzIGhhcyBlbm91Z2ggcG9zaXRpb25zIHRv IHBhc3MgYW5kIGlzIHdhaXRpbmcgZm9yIGFuIEFEIGZvbGxvd3VwIChsb29rcyBsaWtlIGZvciB0 aGUgSUFOQSByZS1yZXZpZXcgYWZ0ZXIgYSB2ZXJzaW9uIGNoYW5nZSkuJm5ic3A7IEl0IHB1dHMg c29tZSBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIG9uIGZsb3dzIHRoYXQgYXJlIGxpa2VseSB0 byBiZSByZWxldmFudCB0byB0aGUNCiBmbG93cyBpbiB0aGUgcHJlc2VudCBkcmFmdC48YnI+DQo8 YnI+DQpkcmFmdC1pZXRmLXJtY2F0LWNjLXJlcXVpcmVtZW50cy0wOSAtIHRoaXMgaXMgaW4gdGhl IFJGQyBFZGl0b3IgcXVldWUgYW5kIHNlZW1zIHRvIGJlIHdhaXRpbmcgZm9yIHRoZSBydGN3ZWIt b3ZlcnZpZXcgZHJhZnQsIHRvIHdoaWNoIGl0IG5vcm1hdGl2ZWx5IHJlZmVycy4mbmJzcDsgSSB0 aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhlIHJtY2F0IGRyYWZ0IHJlZmVyZW5jZWQgcnRj d2ViLXRyYW5zcG9hcnRzLCBhbmQgaWYgcnRjd2ViLXRyYW5zcG9ydHMNCiB3b3VsZCBjaGVjayBv biBpdHMgYWxpZ25tZW50IHdpdGggdGhlIHJtY2F0IHJlcXVpcmVtZW50cyBpbiB0aGUgY29uZ2Vz dGlvbiBjb250cm9sIHJlbWFya3MgaW4gc2VjdGlvbiA0LjEuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VjdGlvbiA0LjIgVXNhZ2Ugb2YgUXVhbGl0eSBvZiBTZXJ2 aWNlIC0gRFNDUCBhbmQgTXVsdGlwbGV4aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgd2lsbCBqdXN0IGZsYWcg aGVyZSB0aGF0IEkgcmV2aWV3ZWQgdGhlIG1haWxpbmcgbGlzdCBhbmQgaXQgc2VlbXMgdGhhdCB0 aGVyZSB3YXMgYSBsb3Qgb2YgVFNWIHJldmlldyBvZiB0aGUgRFNDUCBtYXRlcmlhbCBoZXJlIGFs cmVhZHksIGFuZCBhIGNvbnNlbnN1cyByZWFjaGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949362F622F20MX307CL04corpem_-- From nobody Thu Aug 4 03:02:58 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 DB37112D94C; Thu, 4 Aug 2016 03:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 6quzQ2gNOMBL; Thu, 4 Aug 2016 03:02:48 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CB112D970; Thu, 4 Aug 2016 03:01:16 -0700 (PDT) Received: from [2001:630:40:f00:12dd:b1ff:feca:b79b] (port=62784) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bVFSg-0004vx-2H; Thu, 04 Aug 2016 11:01:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Thu, 4 Aug 2016 11:00:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51F4D053-22C1-4F0E-ADEE-CCAF48B931E1@csperkins.org> References: To: Allison Mankin X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Cullen Jennings , IETF Discussion , amankin@salesforce.com, IESG , draft-ietf-rtcweb-transports@tools.ietf.org, tsv-art@ietf.org Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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: Thu, 04 Aug 2016 10:02:50 -0000 > On 3 Aug 2016, at 14:54, Allison Mankin = wrote: >=20 > Hi, >=20 > I've reviewed this draft (draft-ietf-rtcpweb-transports-14.txt) 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. >=20 > Summary: this draft specifies the mandatory transport protocols (and = transport features) associated with the use of WebRTC media. It does = not appear to pose any transport-related danger, except perhaps that a = reviewer's head aches over the number of RFCs that are needed to get = media bits from point A to point B, but this is not a fault of the = draft. The draft is broadly ready for publication as a PS, however = there are a few issues for the Transport Area. >=20 > Section 3.4: > If TCP connections are used, RTP framing according to [RFC4571 > ] MUST > be used, both for the RTP packets and for the DTLS packets used to > carry data channels. >=20 > About the passage above, RFC4571 doesn't talk about DTLS. It looks = like this passage also needs a reference to whatever of the specs = defines framing for DTLS?=20 >=20 > Section 4.1 Local Prioritization >=20 > This section describes the resource allocations that are expected for = prioritized different streams when there is congestion. There are two = highly relevant congestion control documents that are approved (or = nearly so), and I can't see that the RTCWB WG considered them from my = quick review of mailing list discussions, but it would be a good idea = for this draft to call them out: >=20 > draft-ietf-avtcore-rtp-circuit-breakers-17 - this has enough positions = to pass and is waiting for an AD followup (looks like for the IANA = re-review after a version change). It puts some additional = considerations on flows that are likely to be relevant to the flows in = the present draft. This is listed as =E2=80=9CMUST implement=E2=80=9D in = draft-ietf-rtcweb-rtp-usage-26, which is referenced from Section 3.5 of = the rtcweb-transport draft.=20 Colin > draft-ietf-rmcat-cc-requirements-09 - this is in the RFC Editor queue = and seems to be waiting for the rtcweb-overview draft, to which it = normatively refers. I think it would be better if the rmcat draft = referenced rtcweb-transpoarts, and if rtcweb-transports would check on = its alignment with the rmcat requirements in the congestion control = remarks in section 4.1. >=20 > Section 4.2 Usage of Quality of Service - DSCP and Multiplexing >=20 > I will just flag here that I reviewed the mailing list and it seems = that there was a lot of TSV review of the DSCP material here already, = and a consensus reached. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art --=20 Colin Perkins https://csperkins.org/ From nobody Thu Aug 4 05:06:20 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 4200C12DE55 for ; Thu, 4 Aug 2016 05:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0D2Kyq-u1s0g for ; Thu, 4 Aug 2016 05:06:15 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918E212DE79 for ; Thu, 4 Aug 2016 05:03:55 -0700 (PDT) Received: (qmail 11304 invoked from network); 4 Aug 2016 14:03:52 +0200 Received: from p5dec2461.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.97) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 4 Aug 2016 14:03:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <51F4D053-22C1-4F0E-ADEE-CCAF48B931E1@csperkins.org> Date: Thu, 4 Aug 2016 14:03:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45871F4C-2EE2-4185-B9EE-3D4E7F6E9D57@kuehlewind.net> References: <51F4D053-22C1-4F0E-ADEE-CCAF48B931E1@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Cullen Jennings , Allison Mankin , amankin@salesforce.com, IESG , tsv-art@ietf.org, draft-ietf-rtcweb-transports@tools.ietf.org, IETF Discussion Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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: Thu, 04 Aug 2016 12:06:19 -0000 Hi Colin, see below. > Am 04.08.2016 um 12:00 schrieb Colin Perkins : >=20 >=20 >> On 3 Aug 2016, at 14:54, Allison Mankin = wrote: >>=20 >> Hi, >>=20 >> I've reviewed this draft (draft-ietf-rtcpweb-transports-14.txt) 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. >>=20 >> Summary: this draft specifies the mandatory transport protocols (and = transport features) associated with the use of WebRTC media. It does = not appear to pose any transport-related danger, except perhaps that a = reviewer's head aches over the number of RFCs that are needed to get = media bits from point A to point B, but this is not a fault of the = draft. The draft is broadly ready for publication as a PS, however = there are a few issues for the Transport Area. >>=20 >> Section 3.4: >> If TCP connections are used, RTP framing according to [RFC4571 >> ] MUST >> be used, both for the RTP packets and for the DTLS packets used to >> carry data channels. >>=20 >> About the passage above, RFC4571 doesn't talk about DTLS. It looks = like this passage also needs a reference to whatever of the specs = defines framing for DTLS?=20 >>=20 >> Section 4.1 Local Prioritization >>=20 >> This section describes the resource allocations that are expected for = prioritized different streams when there is congestion. There are two = highly relevant congestion control documents that are approved (or = nearly so), and I can't see that the RTCWB WG considered them from my = quick review of mailing list discussions, but it would be a good idea = for this draft to call them out: >>=20 >> draft-ietf-avtcore-rtp-circuit-breakers-17 - this has enough = positions to pass and is waiting for an AD followup (looks like for the = IANA re-review after a version change). It puts some additional = considerations on flows that are likely to be relevant to the flows in = the present draft. >=20 > This is listed as =E2=80=9CMUST implement=E2=80=9D in = draft-ietf-rtcweb-rtp-usage-26, which is referenced from Section 3.5 of = the rtcweb-transport draft.=20 >=20 > Colin rtcweb-transport says=20 "For transport of media, secure RTP is used. The details of the profile = of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage]." Given that this doc is called "Transports for WebRTC=E2=80=9C, I would = appreciate if it says slightly more about the recommendations given in = rtcweb-rtp-usage, especialy regarding congestion control. What=E2=80=99s about the following? "For transport of media, secure RTP is used. The details of the profile = of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C Mirja >=20 >=20 >=20 >> draft-ietf-rmcat-cc-requirements-09 - this is in the RFC Editor queue = and seems to be waiting for the rtcweb-overview draft, to which it = normatively refers. I think it would be better if the rmcat draft = referenced rtcweb-transpoarts, and if rtcweb-transports would check on = its alignment with the rmcat requirements in the congestion control = remarks in section 4.1. >>=20 >> Section 4.2 Usage of Quality of Service - DSCP and Multiplexing >>=20 >> I will just flag here that I reviewed the mailing list and it seems = that there was a lot of TSV review of the DSCP material here already, = and a consensus reached. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Thu Aug 4 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 A681A12DF2D; Thu, 4 Aug 2016 05:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 S_qKlL5gH_Ia; Thu, 4 Aug 2016 05:12:50 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C39612DEC5; Thu, 4 Aug 2016 05:07:37 -0700 (PDT) Received: from [2001:630:40:f00:12dd:b1ff:feca:b79b] (port=50043) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bVHQw-0001Gt-C2; Thu, 04 Aug 2016 13:07:33 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <45871F4C-2EE2-4185-B9EE-3D4E7F6E9D57@kuehlewind.net> Date: Thu, 4 Aug 2016 13:07:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2FB5FED1-3C27-4692-A067-1FF1CB412BC1@csperkins.org> References: <51F4D053-22C1-4F0E-ADEE-CCAF48B931E1@csperkins.org> <45871F4C-2EE2-4185-B9EE-3D4E7F6E9D57@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Cullen Jennings , Allison Mankin , amankin@salesforce.com, IESG , tsv-art@ietf.org, draft-ietf-rtcweb-transports@tools.ietf.org, IETF Discussion Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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: Thu, 04 Aug 2016 12:12:55 -0000 Hi, > On 4 Aug 2016, at 13:03, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Colin, >=20 > see below. >=20 >> Am 04.08.2016 um 12:00 schrieb Colin Perkins : >>=20 >>=20 >>> On 3 Aug 2016, at 14:54, Allison Mankin = wrote: >>>=20 >>> Hi, >>>=20 >>> I've reviewed this draft (draft-ietf-rtcpweb-transports-14.txt) 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. >>>=20 >>> Summary: this draft specifies the mandatory transport protocols (and = transport features) associated with the use of WebRTC media. It does = not appear to pose any transport-related danger, except perhaps that a = reviewer's head aches over the number of RFCs that are needed to get = media bits from point A to point B, but this is not a fault of the = draft. The draft is broadly ready for publication as a PS, however = there are a few issues for the Transport Area. >>>=20 >>> Section 3.4: >>> If TCP connections are used, RTP framing according to [RFC4571 >>> ] MUST >>> be used, both for the RTP packets and for the DTLS packets used to >>> carry data channels. >>>=20 >>> About the passage above, RFC4571 doesn't talk about DTLS. It looks = like this passage also needs a reference to whatever of the specs = defines framing for DTLS?=20 >>>=20 >>> Section 4.1 Local Prioritization >>>=20 >>> This section describes the resource allocations that are expected = for prioritized different streams when there is congestion. There are = two highly relevant congestion control documents that are approved (or = nearly so), and I can't see that the RTCWB WG considered them from my = quick review of mailing list discussions, but it would be a good idea = for this draft to call them out: >>>=20 >>> draft-ietf-avtcore-rtp-circuit-breakers-17 - this has enough = positions to pass and is waiting for an AD followup (looks like for the = IANA re-review after a version change). It puts some additional = considerations on flows that are likely to be relevant to the flows in = the present draft. >>=20 >> This is listed as =E2=80=9CMUST implement=E2=80=9D in = draft-ietf-rtcweb-rtp-usage-26, which is referenced from Section 3.5 of = the rtcweb-transport draft.=20 >>=20 >> Colin >=20 > rtcweb-transport says=20 > "For transport of media, secure RTP is used. The details of the = profile of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage]." >=20 > Given that this doc is called "Transports for WebRTC=E2=80=9C, I would = appreciate if it says slightly more about the recommendations given in = rtcweb-rtp-usage, especialy regarding congestion control. >=20 > What=E2=80=99s about the following? >=20 > "For transport of media, secure RTP is used. The details of the = profile of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C No objection, but it=E2=80=99s not my draft to make the change.=20 --=20 Colin Perkins https://csperkins.org/ From nobody Fri Aug 5 14:57:11 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 DE1AA12D672; Fri, 5 Aug 2016 14:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, 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 tQltmdpsY45E; Fri, 5 Aug 2016 14:57:03 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB4512D60B; Fri, 5 Aug 2016 14:57:03 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id EE0D821621; Fri, 5 Aug 2016 14:56:58 -0700 (PDT) From: Wes Hardaker To: Brian Trammell References: Date: Fri, 05 Aug 2016 14:56:57 -0700 In-Reply-To: (Brian Trammell's message of "Tue, 14 Jun 2016 14:13:04 +0200") Message-ID: <0lpopmzxp2.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: tsv-art@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@tools.ietf.org, ietf , Suresh Krishnaswamy 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: Fri, 05 Aug 2016 21:57:05 -0000 Brian Trammell writes: > 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. Thanks for the review and the concentration the transport side of things. Sorry for the delay in this response (it was a busy month). > (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. Most of the tests are to local recursive resolvers, so I don't think there will be a traffic issue. Even then, the number of packets sent from all the test is massively dwarfed by most devices HTTP packets, eg. We're very much in the weeds with respect to the average use by everything else the device is spinning up for in the first place. > 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? DNS doesn't allow for the combining of questions into a single packet, but we do note where some "quick tests" may be able to trump other tests. It's also, as we note, possible to do many tests in parallel as well. I do think we've done the best we can there. > (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. Well, an attacker could do that with any other DNS traffic too. So I don't think we're adding to the problem. If anything, we're taking away from it because we're preventing clients from believing untrustable data when it should be dnssec signed. Without our detection mechanisms, clients that assume they have no ability to do DNSSEC are much much worse off and subject to many more problems. > (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)? Well, the trick is how to discover that? If you follow our checks in serial, then you'll already stop. But it's very hard to prove that a network is unstable. Again, each test is functionally a packet or two so the general tests will take up 15*2 packets on average, say, and I'll double it again just to be safe and say 60 total (including both directions). Compare that with the DNS lookups done just to look up the average web page with all it's sub-domains and social buttons inside (hint > 100 for most news sites, for example. Much more than 100 in fact) and we're very much in the weeds with traffic. -- Wes Hardaker Parsons From nobody Sun Aug 7 14:31: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 4F88A12D56D; Sun, 7 Aug 2016 14:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 tSOiFRxsdHZY; Sun, 7 Aug 2016 14:30:43 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDEE12D0F9; Sun, 7 Aug 2016 14:30:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5A5BC7C8FDB; Sun, 7 Aug 2016 23:30:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFuUSzJTqwTJ; Sun, 7 Aug 2016 23:30:39 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:6d05:1baa:74c7:253] (unknown [IPv6:2001:470:de0a:1:6d05:1baa:74c7:253]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3190C7C8F1D; Sun, 7 Aug 2016 23:30:39 +0200 (CEST) To: Colin Perkins , "Mirja Kuehlewind (IETF)" References: <51F4D053-22C1-4F0E-ADEE-CCAF48B931E1@csperkins.org> <45871F4C-2EE2-4185-B9EE-3D4E7F6E9D57@kuehlewind.net> <2FB5FED1-3C27-4692-A067-1FF1CB412BC1@csperkins.org> From: Harald Alvestrand Message-ID: Date: Sun, 7 Aug 2016 23:30:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2FB5FED1-3C27-4692-A067-1FF1CB412BC1@csperkins.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Cullen Jennings , Allison Mankin , amankin@salesforce.com, IESG , tsv-art@ietf.org, draft-ietf-rtcweb-transports@tools.ietf.org, IETF Discussion Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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: Sun, 07 Aug 2016 21:30:45 -0000 Den 04. aug. 2016 14:07, skrev Colin Perkins: > Hi, >> What’s about the following? >> >> "For transport of media, secure RTP is used. The details of the profile of RTP used are described in "RTP Usage“ [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see [draft-ietf-rmcat-cc-requirements-09] for further guidance).“ > > No objection, but it’s not my draft to make the change. > This works for me. New section entitled "Congestion control". It needs to also mention that SCTP is already congestion-controlled. From nobody Sun Aug 7 15:22:58 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 3AE3212D5A8; Sun, 7 Aug 2016 15:22:48 -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 sqizGH7e9cHn; Sun, 7 Aug 2016 15:22:47 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 C1E8F12D740; Sun, 7 Aug 2016 15:22:46 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id w127so227588702vkh.2; Sun, 07 Aug 2016 15:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2+xOL8V2Uf0hodvMvUhrN3QhxdZRohtPCbsuzJrGf+M=; b=oS7Auy4ypovL0r8cojQ5iJFDvhspjzrv7ogRG9kbkaapMIouFCu5GoG+6isX4PM2rn CzwWh9eFF21rUdCzBlqMJNgXp6ItEGQYDwvxLE0sK9eu70938EAWUjeS+uPz++EYWEc/ 37uFESNYMp7KtrIduipct0dU6SUwZ8Rb5nPUTi/PfYNV6a0laD6crk32Pgl/0Cg2w3el Qb7ysdvHOlJASY8kIIU4v6AjoqkPARY8YnM043UMPIr0WMFOwy7dokOOVdZXdX5qQixC jt8IHFVuzvOw1G+EFEeLEwEwEAmn2o7joDNzx3SJPZ3jggfeGufT21cLFNgm/mHfx0Z2 izsQ== 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=2+xOL8V2Uf0hodvMvUhrN3QhxdZRohtPCbsuzJrGf+M=; b=IXUiHthogPwen8Mn/5fRJ6OORflg7kCuyCzjWVDxm29CEGzIIbwI9YVP+rf4C2gPRV 4Po7Mhksx8yZVp9iZW92Ohv6eVdrCIRJdzEtjopZ1NglDHQc4u2GhDAPf0febLzriOie GmttnZGU/b+pzFC1QJqaFXVWD/7VA5VFudrQ35EJA6S7AYP+fUOh6J1QA7PT8AeTtVfR cQCZf1B+UCnuD69v6MVqiTlCfYfNmkxr4047+ZzdiSST1yzbSP8+sBY1CyBcVnXkORg8 KZixSJPDdPxVmR1LbURLUz5dfNd+BalnXhjyvf5Q/JmKlncC5yRAcRfk92nYFDeabBwx BeAQ== X-Gm-Message-State: AEkooutQf+JHqqATqzTw6d6rLdqtbAceCxHy1Wg8jBxAlZpP+E7YJO6o4LBh0LXWivMCKvj1Tca7Jeu/Z4pe7g== X-Received: by 10.31.69.87 with SMTP id s84mr3281579vka.146.1470608565799; Sun, 07 Aug 2016 15:22:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.78 with HTTP; Sun, 7 Aug 2016 15:22:44 -0700 (PDT) Received: by 10.176.4.78 with HTTP; Sun, 7 Aug 2016 15:22:44 -0700 (PDT) In-Reply-To: References: <51F4D053-22C1-4F0E-ADEE-CCAF48B931E1@csperkins.org> <45871F4C-2EE2-4185-B9EE-3D4E7F6E9D57@kuehlewind.net> <2FB5FED1-3C27-4692-A067-1FF1CB412BC1@csperkins.org> From: Allison Mankin Date: Sun, 7 Aug 2016 18:22:44 -0400 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114dbd282b1613053982bdc0 Archived-At: Cc: Cullen Jennings , IETF Discussion , amankin@salesforce.com, "Mirja Kuehlewind \(IETF\)" , IESG , draft-ietf-rtcweb-transports@tools.ietf.org, tsv-art@ietf.org, Colin Perkins Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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: Sun, 07 Aug 2016 22:22:48 -0000 --001a114dbd282b1613053982bdc0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All sounds good to me. Thank you, Harald and Colin. On Aug 7, 2016 17:30, "Harald Alvestrand" wrote: > Den 04. aug. 2016 14:07, skrev Colin Perkins: > > Hi, > > >> What=E2=80=99s about the following? > >> > >> "For transport of media, secure RTP is used. The details of the > profile of RTP used are described in "RTP Usage=E2=80=9C > [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker > [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see > [draft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C > > > > No objection, but it=E2=80=99s not my draft to make the change. > > > > This works for me. New section entitled "Congestion control". > It needs to also mention that SCTP is already congestion-controlled. > --001a114dbd282b1613053982bdc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

All sounds good to me. Thank you, Harald and Colin.


On Aug 7, 2016 17= :30, "Harald Alvestrand" <harald@alvestrand.no> wrote:
Den 04. aug. 2016 14:07, skrev Colin Perkins:
> Hi,

>> What=E2=80=99s about the following?
>>
>> "For transport of media, secure RTP is used.=C2=A0 The detail= s of the profile of RTP used are described in "RTP Usage=E2=80=9C [I-D= .ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker [draft= -ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see [dr= aft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C
>
> No objection, but it=E2=80=99s not my draft to make the change.
>

This works for me. New section entitled "Congestion control".
It needs to also mention that SCTP is already congestion-controlled.
--001a114dbd282b1613053982bdc0-- From nobody Mon Aug 8 09:47:34 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 BDE0412D675 for ; Mon, 8 Aug 2016 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 sPJgqyVEFKNJ for ; Mon, 8 Aug 2016 09:47:32 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EC812D0FD for ; Mon, 8 Aug 2016 09:47:31 -0700 (PDT) Received: (qmail 17879 invoked from network); 8 Aug 2016 18:47:29 +0200 Received: from p5dec22a4.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.164) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Aug 2016 18:47:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 8 Aug 2016 18:47:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16EABB75-86F6-44C7-883D-60ECE60B6247@kuehlewind.net> References: <51F4D053-22C1-4F0E-ADEE-CCAF48B931E1@csperkins.org> <45871F4C-2EE2-4185-B9EE-3D4E7F6E9D57@kuehlewind.net> <2FB5FED1-3C27-4692-A067-1FF1CB412BC1@csperkins.org> To: Allison Mankin , Harald Alvestrand X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Cullen Jennings , IETF Discussion , amankin@salesforce.com, IESG , tsv-art@ietf.org, draft-ietf-rtcweb-transports@tools.ietf.org, Colin Perkins Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-rtcweb-transports 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: Mon, 08 Aug 2016 16:47:34 -0000 Hi all, thanks! Having a new section is even better! This could be used to cover = all transmissions performed by rtcweb (not only RTP-based media)! Mirja > Am 08.08.2016 um 00:22 schrieb Allison Mankin = : >=20 > All sounds good to me. Thank you, Harald and Colin. >=20 > On Aug 7, 2016 17:30, "Harald Alvestrand" = wrote: > Den 04. aug. 2016 14:07, skrev Colin Perkins: > > Hi, >=20 > >> What=E2=80=99s about the following? > >> > >> "For transport of media, secure RTP is used. The details of the = profile of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C > > > > No objection, but it=E2=80=99s not my draft to make the change. > > >=20 > This works for me. New section entitled "Congestion control". > It needs to also mention that SCTP is already congestion-controlled. > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue Aug 23 09:19:34 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 6969412D5CC for ; Tue, 23 Aug 2016 09:19:32 -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 PcGIi0tMjz-K for ; Tue, 23 Aug 2016 09:19:28 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 01C5012D5C2 for ; Tue, 23 Aug 2016 09:19:28 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id q128so28506346wma.1 for ; Tue, 23 Aug 2016 09:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=4pnV/B13k6KJYdRkQkw1M2wFN8kZk33M21CR9lUiL0o=; b=FUS9Kk+yh2EezKM0biDHYFNt9Tn2ba3ZyGngJGv8N1YIpAAN8V9/ofvAH7+2/7p8Rt BiULjhNzQXw8uSqAmQRQxC0RUZ5GfIZVmqixmqj3f1iD0nR4EENzZdvQrFr8Wknt2xP9 f6d21v/j6zyOx5RULk5x3T7a882x52l363J9peG5FF70AyalYmYtqSyIEbnan4VSuG8q F8d3nncf8Y3FmV8twX3XlB9bo13vOK4uXWJv0TuNuSkTeWsKXT9JkXOg2Pj8LUJQSuEl /p3sQLpWjbrIoBsV/x9P3w+Kkyu8nNE3f9HTlSEuQSsRzkzZIdR6878ncKrVOT0VYG48 mYkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=4pnV/B13k6KJYdRkQkw1M2wFN8kZk33M21CR9lUiL0o=; b=B08HVv9KwcPJBKPMOD22i3rKswYOnl1w1Yy5JxIr9i9WRhm6ajEWkOov2TG7k15ycW nNyl7s/W47EMTPzT3ix4zUZ8l00IMCzfzCjqkssvRz1sjObwuY6ggNxtN+1UJTWjofNw gXKnWVm+KylRiF92NfhqQ4I3hkB1rVrE9zNng12kbtD0DcKUce2qVK4dZw4waNrj8iVg r0wjE/Jgw1Aq4aaqYDNuwRZLjtHVoqs7vmgCIEfCRv9zaPPtW7wFKOeK8aux6nhgVTRC NqOoQf5Z6H6Sb4TylcRKQIspxjG6xCXwVuufkke+gaIxgW5+nvCWAI4KLvHXMaLGTB3E h/qg== X-Gm-Message-State: AEkoousK6dR8a6vUr8Pkei/7SKCtycA91cfBjkv06bm+PBBP4aUayWHw8+YNr50vtyEB4A== X-Received: by 10.28.12.133 with SMTP id 127mr19907851wmm.119.1471969166058; Tue, 23 Aug 2016 09:19:26 -0700 (PDT) Received: from mn-mn0F-2.local ([2a01:598:99c2:3bae:5578:4dd6:252e:4209]) by smtp.googlemail.com with ESMTPSA id r16sm28316575wme.16.2016.08.23.09.19.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Aug 2016 09:19:25 -0700 (PDT) From: Martin Stiemerling To: tsv-art@ietf.org Message-ID: Date: Tue, 23 Aug 2016 18:18:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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, 23 Aug 2016 16:19:32 -0000 Dear TSVers, I did work through all documents that are in IETF LC, IESG processing or being requested publication as of 08/23, 04:00 pm UTC. Please find below all documents checked and what to do with these documents. Documents that require TSV attention: - draft-ietf-6man-deprecate-atomfrag-generation - draft-ietf-mif-happy-eyeballs-extension - draft-ietf-radext-ip-port-radius-ext Documents that may require attention: - draft-ietf-hip-multihoming - draft-ietf-hip-rfc5206-bis - draft-ietf-i2rs-protocol-security-requirements - draft-ietf-mpls-entropy-lsp-ping Documents that do not require TSV attention: - draft-hardy-pdf-mime - draft-ietf-6man-deprecate-atomfrag-generation - draft-ietf-dnsop-maintain-ds - draft-ietf-dnsop-nxdomain-cut - draft-ietf-httpauth-extension - draft-ietf-nfsv4-multi-domain-fs-reqs - draft-ietf-taps-transports - draft-ietf-softwire-unified-cpe - draft-ietf-pals-rfc4447bis - draft-ietf-nvo3-arch - draft-ietf-nfsv4-scsi-layout - draft-ietf-tram-turn-mobility - draft-moriarty-pkcs1 - draft-moriarty-pkcs5-v2dot1 - draft-seantek-ldap-pkcs9 - draft-sweet-rfc2911bis Regards, Martin From nobody Tue Aug 23 10: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 D89B712D613 for ; Tue, 23 Aug 2016 10:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 xvc5O7bWNB8b for ; Tue, 23 Aug 2016 10:03:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 A205A12D60F for ; Tue, 23 Aug 2016 10:03:57 -0700 (PDT) Received: from [128.9.184.246] ([128.9.184.246]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7NH3Dha012718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Aug 2016 10:03:13 -0700 (PDT) To: Martin Stiemerling , tsv-art@ietf.org References: From: Joe Touch Message-ID: Date: Tue, 23 Aug 2016 10:03:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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, 23 Aug 2016 17:03:59 -0000 Hi, Martin, You list this doc in two places - both needing and not needing TSV attention: draft-ietf-6man-deprecate-atomfrag-generation Can you clarify which it is? Joe On 8/23/2016 9:18 AM, Martin Stiemerling wrote: > Dear TSVers, > > I did work through all documents that are in IETF LC, IESG processing > or being requested publication as of 08/23, 04:00 pm UTC. > > Please find below all documents checked and what to do with these > documents. > > > Documents that require TSV attention: > - draft-ietf-6man-deprecate-atomfrag-generation > - draft-ietf-mif-happy-eyeballs-extension > - draft-ietf-radext-ip-port-radius-ext > > > Documents that may require attention: > - draft-ietf-hip-multihoming > - draft-ietf-hip-rfc5206-bis > - draft-ietf-i2rs-protocol-security-requirements > - draft-ietf-mpls-entropy-lsp-ping > > > Documents that do not require TSV attention: > - draft-hardy-pdf-mime > - draft-ietf-6man-deprecate-atomfrag-generation > - draft-ietf-dnsop-maintain-ds > - draft-ietf-dnsop-nxdomain-cut > - draft-ietf-httpauth-extension > - draft-ietf-nfsv4-multi-domain-fs-reqs > - draft-ietf-taps-transports > - draft-ietf-softwire-unified-cpe > - draft-ietf-pals-rfc4447bis > - draft-ietf-nvo3-arch > - draft-ietf-nfsv4-scsi-layout > - draft-ietf-tram-turn-mobility > - draft-moriarty-pkcs1 > - draft-moriarty-pkcs5-v2dot1 > - draft-seantek-ldap-pkcs9 > - draft-sweet-rfc2911bis > > > Regards, > > Martin > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue Aug 23 23:55:07 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 096FE12D7B2 for ; Tue, 23 Aug 2016 23:55:06 -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 dj9OQicq0V20 for ; Tue, 23 Aug 2016 23:55:04 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 5AD3812D7BB for ; Tue, 23 Aug 2016 23:55:04 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f65so187830398wmi.0 for ; Tue, 23 Aug 2016 23:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=RgvFpa58Z6pjWlMInJY2CBgvc0b1QiBorxaWsEIrVR4=; b=LE4fi+dz1bpZvzr3MhpYwJSz3OgHWAGjwf9fD8p89I4sVtydNSpZkzMDBjrwmI3T39 TbYl7ZQ2fdUOfwAAWJdVj8/9QooSzwq2kDWFNG2SayFOK9gNorD5AF+g4iSgzwL433K3 iew77ftmHoZ/zwFEBjdv/2UYq178NiYQlf6m/0nzgW1YfdX9hA9XOoyc6aNF5OKH9weF QK715QzlVa8WtD5sAPtshIFvTOf1SBz22VyCRJZC4grLhz3t6YGJo3VUtSS8DtBozOP+ llfJpuCmZ5BLsBSEpDbRQnoLrCAOI7BX+fOCJxuuWvWjLWleV9iueBcFlc8x8WHl5y6i ouMg== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RgvFpa58Z6pjWlMInJY2CBgvc0b1QiBorxaWsEIrVR4=; b=DzeUQ9jD+I2BJKKj3yis6Urz0mr4OfSiWqiVSezbriCSthW4CjBucocGqPmbyWOVra dU3g1epEcG+K+E9MLdpjp0q6ewOLfK+6mHALGKYFu6Qfx681W23vbzWw+FVvCPUYPDXk ZvCQQE85QcJ1O5G1JnztWhAfcvgZna5mw2WpWi2mabv843BbQQjDyXDAu/rv6MGxRbFI RgOgcoumYCETHn43gIi6HrDdt82NGP04zDPgwzUbKAhYRIfso+stl/q4E2jwGaK1HsnQ FRM+OkW8ZtMw8ZKQggsK6sFcp+zN2xi4KZrBouWFtclGpom3e+/OJgQR69Tvi0Ds1wCn B4ig== X-Gm-Message-State: AEkooutXmDLsPReqE2ldO3bsSE1iLh3eKr/b8EC+PGT3gHT5lbxaBB/whFRZeDCyiEa6/Q== X-Received: by 10.28.191.14 with SMTP id p14mr24702952wmf.39.1472021702540; Tue, 23 Aug 2016 23:55:02 -0700 (PDT) Received: from [192.168.2.105] (pD9F07741.dip0.t-ipconnect.de. [217.240.119.65]) by smtp.googlemail.com with ESMTPSA id a203sm38920203wma.0.2016.08.23.23.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Aug 2016 23:55:01 -0700 (PDT) To: Joe Touch , tsv-art@ietf.org References: From: Martin Stiemerling Message-ID: Date: Wed, 24 Aug 2016 08:53:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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, 24 Aug 2016 06:55:06 -0000 Hi Joe, This is a copy and paste error. draft-ietf-6man-deprecate-atomfrag-generation is meant to be in the requires attention section. Thanks for the hint! Martin Am 23.08.16 um 19:03 schrieb Joe Touch: > Hi, Martin, > > You list this doc in two places - both needing and not needing TSV > attention: > > draft-ietf-6man-deprecate-atomfrag-generation > > Can you clarify which it is? > > Joe > > > On 8/23/2016 9:18 AM, Martin Stiemerling wrote: >> Dear TSVers, >> >> I did work through all documents that are in IETF LC, IESG processing >> or being requested publication as of 08/23, 04:00 pm UTC. >> >> Please find below all documents checked and what to do with these >> documents. >> >> >> Documents that require TSV attention: >> - draft-ietf-6man-deprecate-atomfrag-generation >> - draft-ietf-mif-happy-eyeballs-extension >> - draft-ietf-radext-ip-port-radius-ext >> >> >> Documents that may require attention: >> - draft-ietf-hip-multihoming >> - draft-ietf-hip-rfc5206-bis >> - draft-ietf-i2rs-protocol-security-requirements >> - draft-ietf-mpls-entropy-lsp-ping >> >> >> Documents that do not require TSV attention: >> - draft-hardy-pdf-mime >> - draft-ietf-6man-deprecate-atomfrag-generation >> - draft-ietf-dnsop-maintain-ds >> - draft-ietf-dnsop-nxdomain-cut >> - draft-ietf-httpauth-extension >> - draft-ietf-nfsv4-multi-domain-fs-reqs >> - draft-ietf-taps-transports >> - draft-ietf-softwire-unified-cpe >> - draft-ietf-pals-rfc4447bis >> - draft-ietf-nvo3-arch >> - draft-ietf-nfsv4-scsi-layout >> - draft-ietf-tram-turn-mobility >> - draft-moriarty-pkcs1 >> - draft-moriarty-pkcs5-v2dot1 >> - draft-seantek-ldap-pkcs9 >> - draft-sweet-rfc2911bis >> >> >> Regards, >> >> Martin >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art > From nobody Wed Aug 24 07:31:44 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 6795A12DDE0 for ; Wed, 24 Aug 2016 07:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 rEKUdKbnSGAJ for ; Wed, 24 Aug 2016 07:31:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 DBAC012DDB6 for ; Wed, 24 Aug 2016 07:30:14 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7OETGHO002966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Aug 2016 07:29:18 -0700 (PDT) To: Martin Stiemerling , tsv-art@ietf.org References: From: Joe Touch Message-ID: Date: Wed, 24 Aug 2016 07:29:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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, 24 Aug 2016 14:31:43 -0000 Can you also let us know the timeline for a review? I can do this one as I'm deeply familiar with the issues involved. Joe On 8/23/2016 11:53 PM, Martin Stiemerling wrote: > Hi Joe, > > This is a copy and paste error. > draft-ietf-6man-deprecate-atomfrag-generation is meant to be in the > requires attention section. > > Thanks for the hint! > > Martin > > Am 23.08.16 um 19:03 schrieb Joe Touch: >> Hi, Martin, >> >> You list this doc in two places - both needing and not needing TSV >> attention: >> >> draft-ietf-6man-deprecate-atomfrag-generation >> >> Can you clarify which it is? >> >> Joe >> >> >> On 8/23/2016 9:18 AM, Martin Stiemerling wrote: >>> Dear TSVers, >>> >>> I did work through all documents that are in IETF LC, IESG processing >>> or being requested publication as of 08/23, 04:00 pm UTC. >>> >>> Please find below all documents checked and what to do with these >>> documents. >>> >>> >>> Documents that require TSV attention: >>> - draft-ietf-6man-deprecate-atomfrag-generation >>> - draft-ietf-mif-happy-eyeballs-extension >>> - draft-ietf-radext-ip-port-radius-ext >>> >>> >>> Documents that may require attention: >>> - draft-ietf-hip-multihoming >>> - draft-ietf-hip-rfc5206-bis >>> - draft-ietf-i2rs-protocol-security-requirements >>> - draft-ietf-mpls-entropy-lsp-ping >>> >>> >>> Documents that do not require TSV attention: >>> - draft-hardy-pdf-mime >>> - draft-ietf-6man-deprecate-atomfrag-generation >>> - draft-ietf-dnsop-maintain-ds >>> - draft-ietf-dnsop-nxdomain-cut >>> - draft-ietf-httpauth-extension >>> - draft-ietf-nfsv4-multi-domain-fs-reqs >>> - draft-ietf-taps-transports >>> - draft-ietf-softwire-unified-cpe >>> - draft-ietf-pals-rfc4447bis >>> - draft-ietf-nvo3-arch >>> - draft-ietf-nfsv4-scsi-layout >>> - draft-ietf-tram-turn-mobility >>> - draft-moriarty-pkcs1 >>> - draft-moriarty-pkcs5-v2dot1 >>> - draft-seantek-ldap-pkcs9 >>> - draft-sweet-rfc2911bis >>> >>> >>> Regards, >>> >>> Martin >>> >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/tsv-art >> From nobody Wed Aug 24 14:29:18 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 9B50912D188 for ; Wed, 24 Aug 2016 14:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 P3y29Lh2qOBS for ; Wed, 24 Aug 2016 14:29:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 9F4FC12B00E for ; Wed, 24 Aug 2016 14:29:15 -0700 (PDT) Received: from [10.123.232.59] (usc-secure-wireless-088-059.usc.edu [68.181.88.59]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7OLSngP026792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Aug 2016 14:28:50 -0700 (PDT) To: Martin Stiemerling , tsv-art@ietf.org References: From: Joe Touch Message-ID: <25986b7d-61d3-8e99-8b7b-bc792a23abaf@isi.edu> Date: Wed, 24 Aug 2016 14:28:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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, 24 Aug 2016 21:29:16 -0000 On 8/23/2016 9:18 AM, Martin Stiemerling wrote: > Documents that require TSV attention: > - draft-ietf-6man-deprecate-atomfrag-generation > I can take that one. Joe From nobody Wed Aug 24 22:23:40 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 5B06912D1A2 for ; Wed, 24 Aug 2016 22:23:39 -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 U3l-oUnkzSm3 for ; Wed, 24 Aug 2016 22:23:38 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 0416212D17E for ; Wed, 24 Aug 2016 22:23:38 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f65so222836540wmi.0 for ; Wed, 24 Aug 2016 22:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=MR1OtSco6SSmLaRGLL/1Vflw3CAtT+bf1A7vCaZrpeI=; b=cwGfYOJ/EvWt27PTKquPtjGNPMK/1lh9W956YP5uIQZoeij4QIe675SUD1S+sNpdda DEGsyxHkky05Br/AlL0ZyMFaa57odZZRiyJwWP+Cb7GGbN0am69RVtBLYY0aCP2akm5l twX+JNnAXGYSN0dUg0cOzq/W08vjkb7Ha1FbxAYewzUCiLqGg2MJzN2UMS3nPAmuy9Sc G6UkoSVzZ83BR5SAn8oPDpgOm2imanK0jib7urT8SHiKohRi323hZQV6wGl8n7D1CZIc phzEoZN8wvOm9WCrAAIaX3KqXzCvOBrMTKLBhOSmvNqc/fHLMDKzOFRYOu+0ewzirIIh +qIw== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MR1OtSco6SSmLaRGLL/1Vflw3CAtT+bf1A7vCaZrpeI=; b=UmZjwJDW3P1MUOZ/Qh7iyYJiumTJASozYpuXN6YbPH3j1ICxdTdUfB9Cf3cNFTX5rw 2ZH9A3V9NznsfK4Fyql5r7tSkPXLCQZAOGzhNQ0YsiCdHb04mkFNU+f84AZelJe9t55T itpvWH49+T1d/Ya3O1EZ3LqmvdHnCRMCM9UHhpT2bepiNTH+4H2pMP8MHUUl12T6wkTI zGbCqlLSBcCisdpm9OlNSlEcAXNgf1XhbqTSwHkkekS7FaZevCq+lmq3F7cb/+B8QNeq GUsvVGfYqRL0zLu3My9CPt1RNN+8IO1EaU4i8rvBdsMTTuoyIBMAgnZ04PkNX0MI7HM+ Yltg== X-Gm-Message-State: AEkoous5UZl+8aswrB+tDQ9VsbL326nTDsVxJPG9ONZHrHmeAcyIeIvjJejkOzXo7tqvXA== X-Received: by 10.28.61.11 with SMTP id k11mr5872655wma.34.1472102616149; Wed, 24 Aug 2016 22:23:36 -0700 (PDT) Received: from [192.168.2.105] (pD9F07741.dip0.t-ipconnect.de. [217.240.119.65]) by smtp.googlemail.com with ESMTPSA id p83sm13823126wma.18.2016.08.24.22.23.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Aug 2016 22:23:35 -0700 (PDT) To: Joe Touch , tsv-art@ietf.org References: <25986b7d-61d3-8e99-8b7b-bc792a23abaf@isi.edu> From: Martin Stiemerling Message-ID: <60f08956-1ca6-e831-c7c6-e2c9e96dc200@gmail.com> Date: Thu, 25 Aug 2016 07:23:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <25986b7d-61d3-8e99-8b7b-bc792a23abaf@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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: Thu, 25 Aug 2016 05:23:39 -0000 Am 24.08.16 um 23:28 schrieb Joe Touch: > > > On 8/23/2016 9:18 AM, Martin Stiemerling wrote: >> Documents that require TSV attention: >> - draft-ietf-6man-deprecate-atomfrag-generation Thanks! And time wise for the review: The draft is on the IESG telechat on 2016-09-01. I guess the ADs would like to have the review a couple of days earlier, e.g., on 08/29. Thank you! Martin From nobody Fri Aug 26 12:30:43 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 119CE12D0DD; Fri, 26 Aug 2016 12:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 Z-joraw_lMqp; Fri, 26 Aug 2016 12:30:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 63FD512D7F3; Fri, 26 Aug 2016 12:30:33 -0700 (PDT) Received: from [128.9.184.193] ([128.9.184.193]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7QJTdIo027716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Aug 2016 12:29:39 -0700 (PDT) From: Joe Touch To: 6man Message-ID: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> Date: Fri, 26 Aug 2016 12:29:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EC737707B399A92D0C88158E" 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-6man-deprecate-atomfrag-generation@ietf.org, Transport Area , IETF discussion list Subject: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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, 26 Aug 2016 19:30:38 -0000 This is a multi-part message in MIME format. --------------EC737707B399A92D0C88158E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, all, I've reviewed this document as part of the Transport Area Review Team's (TSVART) ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC ​tsv-art@ietf.org if you reply to or forward this review. Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6man-deprecate-atomfrag-generation Title: Generation of IPv6 Atomic Fragments Considered Harmful Reviewer: J. Touch Review Date: August 26, 2016 IETF Last Call Date: August 8, 2016 Summary: This draft is on the right track but has open issues, described in the review. The document has no issues directly applicable to transport protocols. The impact on transports is indirect, in the ability of RFC 6145-style IPv6/IPv4 translators to support IPv6-to-IPv4 translation and deal with IPv4-side fragmentation. However, there are some important non-transport issues that are noted below. Major issues: The impact of this change does not appear to have been explored. Section 3 ends with a claim that links where this translation issue would be a problem are rare, but there is no evidence presented as to whether current RFC 6145 translators would be capable of complying with the changes in this doc, e.g., to be able to generate IPv4 IDs as needed. I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 ID generation MUST be supported (and used), rather than MAY. The document concludes that the translator should create IPv4 IDs rather than relying on atomic fragments as a source of that information (as per RFC2460) because there is no benefit, but are two reasons why this method is directly hazardous as well: 1) RFC 2460 does not require that the IPv6 ID field is generated to ensure that the low 16-bits are unique as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 translation could result in collisions where two distinct IPv6 destinations are translated into the same IPv4 address, such that IDs that might have been generated to be unique in the IPv6 context could end up colliding when used in the translated IPv4 context. I.e., this does not require ECMP as implied in Section 3. Minor issues: IMO, it remains unwise to continue to imply that networks should treat packets with fragment headers as an attack. Fragmentation support is critical to tunneling (see draft-ietf-intarea-tunnels) and we need to find ways to support their use safely. The text should be edited to explain that the primary motivation here is to avoid generating erroneous IPv4 ID fields, rather than to react to the incorrect classification of fragment headers as incompatible with the Internet. The claim that links with IPv6 MTUs smaller than 1260 are rare needs to be supported with evidence. I appreciate that such evidence may be difficult to observe. In the absence of evidence, the statement should be more clear that there is no evidence to the contrary -- which is not the same as being able to claim that they *are* in fact rare. -- --------------EC737707B399A92D0C88158E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, all,

I've reviewed this document as part of the Transport Area Review Team's (TSVART) ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC ​tsv-art@ietf.org if you reply to or forward this review.

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-6man-deprecate-atomfrag-generation 
Title: Generation of IPv6 Atomic Fragments Considered Harmful
Reviewer: J. Touch
Review Date: August 26, 2016
IETF Last Call Date: August 8, 2016

Summary: This draft is on the right track but has open issues, described in the review.

The document has no issues directly applicable to transport protocols. The impact on transports is indirect, in the ability of RFC 6145-style IPv6/IPv4 translators to support IPv6-to-IPv4 translation and deal with IPv4-side fragmentation.

However, there are some important non-transport issues that are noted below.

Major issues:

The impact of this change does not appear to have been explored. Section 3 ends with a claim that links where this translation issue would be a problem are rare, but there is no evidence presented as to whether current RFC 6145 translators would be capable of complying with the changes in this doc, e.g., to be able to generate IPv4 IDs as needed. I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 ID generation MUST be supported (and used), rather than MAY.

The document concludes that the translator should create IPv4 IDs rather than relying on atomic fragments as a source of that information (as per RFC2460) because there is no benefit, but are two reasons why this method is directly hazardous as well: 1) RFC 2460 does not require that the IPv6 ID field is generated to ensure that the low 16-bits are unique as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 translation could result in collisions where two distinct IPv6 destinations are translated into the same IPv4 address, such that IDs that might have been generated to be unique in the IPv6 context could end up colliding when used in the translated IPv4 context. I.e., this does not require ECMP as implied in Section 3.

Minor issues:

IMO, it remains unwise to continue to imply that networks should treat packets with fragment headers as an attack. Fragmentation support is critical to tunneling (see draft-ietf-intarea-tunnels) and we need to find ways to support their use safely. The text should be edited to explain that the primary motivation here is to avoid generating erroneous IPv4 ID fields, rather than to react to the incorrect classification of fragment headers as incompatible with the Internet.

The claim that links with IPv6 MTUs smaller than 1260 are rare needs to be supported with evidence. I appreciate that such evidence may be difficult to observe. In the absence of evidence, the statement should be more clear that there is no evidence to the contrary -- which is not the same as being able to claim that they *are* in fact rare.

--



--------------EC737707B399A92D0C88158E-- From nobody Fri Aug 26 14:11:57 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 ED62212D816 for ; Fri, 26 Aug 2016 14:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 xhfCWCUmdy_C for ; Fri, 26 Aug 2016 14:11:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 1496F12D62D for ; Fri, 26 Aug 2016 14:11:54 -0700 (PDT) Received: from [128.9.184.193] ([128.9.184.193]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7QLBgAe015280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 26 Aug 2016 14:11:43 -0700 (PDT) To: Martin Stiemerling , tsv-art@ietf.org References: <25986b7d-61d3-8e99-8b7b-bc792a23abaf@isi.edu> <60f08956-1ca6-e831-c7c6-e2c9e96dc200@gmail.com> From: Joe Touch Message-ID: <47a5f83b-c100-4e33-77ee-d63595d093da@isi.edu> Date: Fri, 26 Aug 2016 14:11:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <60f08956-1ca6-e831-c7c6-e2c9e96dc200@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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, 26 Aug 2016 21:11:55 -0000 Done, FYI. Joe On 8/24/2016 10:23 PM, Martin Stiemerling wrote: > > > Am 24.08.16 um 23:28 schrieb Joe Touch: >> >> >> On 8/23/2016 9:18 AM, Martin Stiemerling wrote: >>> Documents that require TSV attention: >>> - draft-ietf-6man-deprecate-atomfrag-generation > > > Thanks! > > And time wise for the review: The draft is on the IESG telechat on > 2016-09-01. > > I guess the ADs would like to have the review a couple of days > earlier, e.g., on 08/29. > > Thank you! > > Martin From nobody Sun Aug 28 01:07:49 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 E8F2A12D1D5; Sun, 28 Aug 2016 01:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 bjRgyJd-HXpC; Sun, 28 Aug 2016 01:07:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA3B12D19E; Sun, 28 Aug 2016 01:07:40 -0700 (PDT) Received: from [10.10.15.71] (mail.interplazahotel.com.ar [201.216.217.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A4D0880292; Sun, 28 Aug 2016 10:07:32 +0200 (CEST) To: Joe Touch , 6man References: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> Date: Sat, 27 Aug 2016 19:37:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-art@ietf.org" , draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, Transport Area , IETF discussion list Subject: Re: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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: Sun, 28 Aug 2016 08:07:43 -0000 Hello, Joe, Thanks so much for your review! -- Please find my responses in-line... On 08/26/2016 04:29 PM, Joe Touch wrote: > > Document: draft-ietf-6man-deprecate-atomfrag-generation > Title: Generation of IPv6 Atomic Fragments Considered Harmful > Reviewer: J. Touch > Review Date: August 26, 2016 > IETF Last Call Date: August 8, 2016 > > Summary: This draft is on the right track but has open issues, described > in the review. > > The document has no issues directly applicable to transport protocols. > The impact on transports is indirect, in the ability of RFC 6145-style > IPv6/IPv4 translators to support IPv6-to-IPv4 translation and deal with > IPv4-side fragmentation. > > However, there are some important non-transport issues that are noted below. > > Major issues: > > The impact of this change does not appear to have been explored. Section > 3 ends with a claim that links where this translation issue would be a > problem are rare, but there is no evidence presented as to whether > current RFC 6145 translators would be capable of complying with the > changes in this doc, e.g., to be able to generate IPv4 IDs as needed. > I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 > ID generation MUST be supported (and used), rather than MAY. RFC 6145 has been revised as RFC7915. > The document concludes that the translator should create IPv4 IDs rather > than relying on atomic fragments as a source of that information (as per > RFC2460) because there is no benefit, but are two reasons why this > method is directly hazardous as well: 1) RFC 2460 does not require that > the IPv6 ID field is generated to ensure that the low 16-bits are unique > as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 > translation could result in collisions where two distinct IPv6 > destinations are translated into the same IPv4 address, such that IDs > that might have been generated to be unique in the IPv6 context could > end up colliding when used in the translated IPv4 context. I.e., this > does not require ECMP as implied in Section 3. mmm.. not sure I follow. When we refer to ECMP in Section 3 we're actually describing the only possible scenario in which relying on the ID in the Frag Header could be of use (i.e., possibly result in lower collision rates). > Minor issues: > > IMO, it remains unwise to continue to imply that networks should treat > packets with fragment headers as an attack. Fragmentation support is > critical to tunneling (see draft-ietf-intarea-tunnels) and we need to > find ways to support their use safely. The text should be edited to > explain that the primary motivation here is to avoid generating > erroneous IPv4 ID fields, rather than to react to the incorrect > classification of fragment headers as incompatible with the Internet. Not sure what you mean. We're not implying that packets employing FH are an attack. FWIW, I don't personally think so. We do think that, when employing fragmentation, you open the door to a number of attack vectors. See e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt. > The claim that links with IPv6 MTUs smaller than 1260 are rare needs to > be supported with evidence. I appreciate that such evidence may be > difficult to observe. In the absence of evidence, the statement should > be more clear that there is no evidence to the contrary -- which is not > the same as being able to claim that they *are* in fact rare. I see your point. Any suggestion on how to tweak the text? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 28 09:34:39 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 B7E9F12B03B; Sun, 28 Aug 2016 09:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 B5Fz0rGB0WFT; Sun, 28 Aug 2016 09:34:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 77AFE12B018; Sun, 28 Aug 2016 09:34:36 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7SGXsT9008088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 28 Aug 2016 09:33:56 -0700 (PDT) To: Fernando Gont , 6man References: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> From: Joe Touch Message-ID: <585f4689-d19e-dd54-e75b-4eb3644274ed@isi.edu> Date: Sun, 28 Aug 2016 09:33:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> 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-6man-deprecate-atomfrag-generation@ietf.org, Transport Area , IETF discussion list Subject: Re: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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: Sun, 28 Aug 2016 16:34:38 -0000 Hi, Fernando, First, I'd like to note something more important about this doc - the abstract itself argues that this change should update the core IPv6 spec. Given that is already well underway, why is this document even needed? That said, see below in-line... On 8/27/2016 3:37 PM, Fernando Gont wrote: > Hello, Joe, > > Thanks so much for your review! -- Please find my responses in-line... > > On 08/26/2016 04:29 PM, Joe Touch wrote: >> Document: draft-ietf-6man-deprecate-atomfrag-generation >> Title: Generation of IPv6 Atomic Fragments Considered Harmful >> Reviewer: J. Touch >> Review Date: August 26, 2016 >> IETF Last Call Date: August 8, 2016 >> >> Summary: This draft is on the right track but has open issues, described >> in the review. >> >> The document has no issues directly applicable to transport protocols. >> The impact on transports is indirect, in the ability of RFC 6145-style >> IPv6/IPv4 translators to support IPv6-to-IPv4 translation and deal with >> IPv4-side fragmentation. >> >> However, there are some important non-transport issues that are noted below. >> >> Major issues: >> >> The impact of this change does not appear to have been explored. Section >> 3 ends with a claim that links where this translation issue would be a >> problem are rare, but there is no evidence presented as to whether >> current RFC 6145 translators would be capable of complying with the >> changes in this doc, e.g., to be able to generate IPv4 IDs as needed. >> I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 >> ID generation MUST be supported (and used), rather than MAY. > RFC 6145 has been revised as RFC7915. The second sentence of this draft cites 6145. You raise a good point, but given 7915 obsoletes 6145 (rather than updating it), all references throughout should then refer to 7915 instead. > The document concludes that the translator should create IPv4 IDs rather >> than relying on atomic fragments as a source of that information (as per >> RFC2460) because there is no benefit, but are two reasons why this >> method is directly hazardous as well: 1) RFC 2460 does not require that >> the IPv6 ID field is generated to ensure that the low 16-bits are unique >> as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 >> translation could result in collisions where two distinct IPv6 >> destinations are translated into the same IPv4 address, such that IDs >> that might have been generated to be unique in the IPv6 context could >> end up colliding when used in the translated IPv4 context. I.e., this >> does not require ECMP as implied in Section 3. > mmm.. not sure I follow. When we refer to ECMP in Section 3 we're > actually describing the only possible scenario in which relying on the > ID in the Frag Header could be of use (i.e., possibly result in lower > collision rates). I'm not speaking of when the ID in the Frag Header can be useful. I'm speaking of other more likely cases where using the low 16 bits of the IPv6 ID field can generate IPv4 collisions. > >> Minor issues: >> >> IMO, it remains unwise to continue to imply that networks should treat >> packets with fragment headers as an attack. Fragmentation support is >> critical to tunneling (see draft-ietf-intarea-tunnels) and we need to >> find ways to support their use safely. The text should be edited to >> explain that the primary motivation here is to avoid generating >> erroneous IPv4 ID fields, rather than to react to the incorrect >> classification of fragment headers as incompatible with the Internet. > Not sure what you mean. > > We're not implying that packets employing FH are an attack. FWIW, I > don't personally think so. We do think that, when employing > fragmentation, you open the door to a number of attack vectors. See > e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt. Some of the attacks described are based on the widespread dropping of a valid IPv6 packet with valid IPv6 extension headers. IMO, it is important to be clear that this makes users of a legitimate IPv6 capability vulnerable because of incorrect behavior of routers. It seems important to remind readers that the real issue here is the non-compliant routers. If that information isn't present, it implies that it is the use of the EHs that is incorrect and should be avoided in general. That's impossible for fragmentation - it is a critical capability without which tunneling cannot exist. > >> The claim that links with IPv6 MTUs smaller than 1260 are rare needs to >> be supported with evidence. I appreciate that such evidence may be >> difficult to observe. In the absence of evidence, the statement should >> be more clear that there is no evidence to the contrary -- which is not >> the same as being able to claim that they *are* in fact rare. > I see your point. Any suggestion on how to tweak the text? It depends on what you know. AFAICT, we have no information on this issue. If that's the case, then the text should just state the impact on such links and say that "there is no evidence yet as to the prevalence of their use". Joe From nobody Mon Aug 29 15:06:23 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 3F5EA12B047; Mon, 29 Aug 2016 15:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 7WHubG7dVizW; Mon, 29 Aug 2016 15:06:00 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4B712B037; Mon, 29 Aug 2016 15:05:58 -0700 (PDT) Received: from [192.168.1.154] (mail.interplazahotel.com.ar [201.216.217.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4933B80145; Tue, 30 Aug 2016 00:05:48 +0200 (CEST) To: Joe Touch , 6man References: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> <585f4689-d19e-dd54-e75b-4eb3644274ed@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Mon, 29 Aug 2016 19:05:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <585f4689-d19e-dd54-e75b-4eb3644274ed@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-art@ietf.org" , draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, Transport Area , IETF discussion list Subject: Re: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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: Mon, 29 Aug 2016 22:06:02 -0000 On 08/28/2016 01:33 PM, Joe Touch wrote: > Hi, Fernando, > > First, I'd like to note something more important about this doc - the > abstract itself argues that this change should update the core IPv6 > spec. Given that is already well underway, why is this document even > needed? The document says it clearly: "documenting the motivation for removing this functionality in the revision of the core IPv6 protocol specification." You just don't remove a feature from a spec silently, without a rationale. And the place to include the rationale wasn't rfc2460bis -- hence this dcument. >>> The impact of this change does not appear to have been explored. Section >>> 3 ends with a claim that links where this translation issue would be a >>> problem are rare, but there is no evidence presented as to whether >>> current RFC 6145 translators would be capable of complying with the >>> changes in this doc, e.g., to be able to generate IPv4 IDs as needed. >>> I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 >>> ID generation MUST be supported (and used), rather than MAY. >> RFC 6145 has been revised as RFC7915. > The second sentence of this draft cites 6145. You raise a good point, > but given 7915 obsoletes 6145 (rather than updating it), all references > throughout should then refer to 7915 instead. Not really. We're documenting why this feature is being removed -- hence there's a place for referencing RFC6145 ("state of affairs before any updates") and RFC7915. All references to RFC6145 are of the form "legacy translators", or "RFC6145 was...". >> The document concludes that the translator should create IPv4 IDs rather >>> than relying on atomic fragments as a source of that information (as per >>> RFC2460) because there is no benefit, but are two reasons why this >>> method is directly hazardous as well: 1) RFC 2460 does not require that >>> the IPv6 ID field is generated to ensure that the low 16-bits are unique >>> as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 >>> translation could result in collisions where two distinct IPv6 >>> destinations are translated into the same IPv4 address, such that IDs >>> that might have been generated to be unique in the IPv6 context could >>> end up colliding when used in the translated IPv4 context. I.e., this >>> does not require ECMP as implied in Section 3. >> mmm.. not sure I follow. When we refer to ECMP in Section 3 we're >> actually describing the only possible scenario in which relying on the >> ID in the Frag Header could be of use (i.e., possibly result in lower >> collision rates). > > I'm not speaking of when the ID in the Frag Header can be useful. I'm > speaking of other more likely cases where using the low 16 bits of the > IPv6 ID field can generate IPv4 collisions. So you argue in favor of adding an extra bullet noting that RFC2460 does not require the lower 16 bits to be unique? (just double-checking). If so, fine with me. >>> Minor issues: >>> >>> IMO, it remains unwise to continue to imply that networks should treat >>> packets with fragment headers as an attack. Fragmentation support is >>> critical to tunneling (see draft-ietf-intarea-tunnels) and we need to >>> find ways to support their use safely. The text should be edited to >>> explain that the primary motivation here is to avoid generating >>> erroneous IPv4 ID fields, rather than to react to the incorrect >>> classification of fragment headers as incompatible with the Internet. >> Not sure what you mean. >> >> We're not implying that packets employing FH are an attack. FWIW, I >> don't personally think so. We do think that, when employing >> fragmentation, you open the door to a number of attack vectors. See >> e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt. > Some of the attacks described are based on the widespread dropping of a > valid IPv6 packet with valid IPv6 extension headers. > > IMO, it is important to be clear that this makes users of a legitimate > IPv6 capability vulnerable because of incorrect behavior of routers. 1) The attack I referenced is just one possible attack. If you employ fragmentation, an atacker could just send forged packets meant to cause collisions of frag IDs such that your packets are dropped -- clearly employing an extra feature (as in this case), creates an attack vector. 2) The bahavior in routers is a policy. We may not like it. BUt it's a policy, not incorrect behavior. > It > seems important to remind readers that the real issue here is the > non-compliant routers. If that information isn't present, it implies > that it is the use of the EHs that is incorrect and should be avoided in > general. That's impossible for fragmentation - it is a critical > capability without which tunneling cannot exist. Fragmentation has been considered harmful for ages. And yes, we're saying that if you *do not need it*, you shouldn't use it. >>> The claim that links with IPv6 MTUs smaller than 1260 are rare needs to >>> be supported with evidence. I appreciate that such evidence may be >>> difficult to observe. In the absence of evidence, the statement should >>> be more clear that there is no evidence to the contrary -- which is not >>> the same as being able to claim that they *are* in fact rare. >> I see your point. Any suggestion on how to tweak the text? > > It depends on what you know. AFAICT, we have no information on this > issue. If that's the case, then the text should just state the impact on > such links and say that "there is no evidence yet as to the prevalence > of their use". I'll talk to my co-authors about this one. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Aug 29 15:15:39 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 2B6AC12D8A6; Mon, 29 Aug 2016 15:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 dISJuX9lMAY7; Mon, 29 Aug 2016 15:15:16 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 8D44F12B03A; Mon, 29 Aug 2016 15:15:16 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7TMEumk029966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Aug 2016 15:14:58 -0700 (PDT) To: Fernando Gont , 6man References: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> <585f4689-d19e-dd54-e75b-4eb3644274ed@isi.edu> From: Joe Touch Message-ID: <6755d8bb-3b95-c107-cd72-b799cb2b32f1@isi.edu> Date: Mon, 29 Aug 2016 15:14:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: 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-6man-deprecate-atomfrag-generation@ietf.org, Transport Area , IETF discussion list Subject: Re: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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: Mon, 29 Aug 2016 22:15:18 -0000 Hi, Fernando, On 8/29/2016 3:05 PM, Fernando Gont wrote: > On 08/28/2016 01:33 PM, Joe Touch wrote: >> Hi, Fernando, >> >> First, I'd like to note something more important about this doc - the >> abstract itself argues that this change should update the core IPv6 >> spec. Given that is already well underway, why is this document even >> needed? > The document says it clearly: "documenting the > motivation for removing this functionality in the revision of the > core IPv6 protocol specification." > > You just don't remove a feature from a spec silently, without a > rationale. And the place to include the rationale wasn't rfc2460bis -- > hence this dcument. I don't agree. RFC2460bis should not need a roadmap to explain all of the associated changes and their rationales. That should be in 2460bis. Otherwise, changes need to be made incrementally - that's a lot of extra load on the IETF and a lot of complexity to figure out why things are the way the end up. > > > > > >>>> The impact of this change does not appear to have been explored. Section >>>> 3 ends with a claim that links where this translation issue would be a >>>> problem are rare, but there is no evidence presented as to whether >>>> current RFC 6145 translators would be capable of complying with the >>>> changes in this doc, e.g., to be able to generate IPv4 IDs as needed. >>>> I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 >>>> ID generation MUST be supported (and used), rather than MAY. >>> RFC 6145 has been revised as RFC7915. >> The second sentence of this draft cites 6145. You raise a good point, >> but given 7915 obsoletes 6145 (rather than updating it), all references >> throughout should then refer to 7915 instead. > Not really. We're documenting why this feature is being removed -- hence > there's a place for referencing RFC6145 ("state of affairs before any > updates") and RFC7915. > > All references to RFC6145 are of the form "legacy translators", or > "RFC6145 was...". I don't think it's useful to refer in this doc to a spec that is already obsoleted. This is further reason why it's not useful to issue separate change docs. It gets confusing as to what you're arguing and why. > >>> The document concludes that the translator should create IPv4 IDs rather >>>> than relying on atomic fragments as a source of that information (as per >>>> RFC2460) because there is no benefit, but are two reasons why this >>>> method is directly hazardous as well: 1) RFC 2460 does not require that >>>> the IPv6 ID field is generated to ensure that the low 16-bits are unique >>>> as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 >>>> translation could result in collisions where two distinct IPv6 >>>> destinations are translated into the same IPv4 address, such that IDs >>>> that might have been generated to be unique in the IPv6 context could >>>> end up colliding when used in the translated IPv4 context. I.e., this >>>> does not require ECMP as implied in Section 3. >>> mmm.. not sure I follow. When we refer to ECMP in Section 3 we're >>> actually describing the only possible scenario in which relying on the >>> ID in the Frag Header could be of use (i.e., possibly result in lower >>> collision rates). >> I'm not speaking of when the ID in the Frag Header can be useful. I'm >> speaking of other more likely cases where using the low 16 bits of the >> IPv6 ID field can generate IPv4 collisions. > So you argue in favor of adding an extra bullet noting that RFC2460 does > not require the lower 16 bits to be unique? (just double-checking). If > so, fine with me. Yes - specifically, 2460 does not require that the lower 16 bits of the ID are generated in a way that would comply with the expectations of using just those bits for IPv4. > >>>> Minor issues: >>>> >>>> IMO, it remains unwise to continue to imply that networks should treat >>>> packets with fragment headers as an attack. Fragmentation support is >>>> critical to tunneling (see draft-ietf-intarea-tunnels) and we need to >>>> find ways to support their use safely. The text should be edited to >>>> explain that the primary motivation here is to avoid generating >>>> erroneous IPv4 ID fields, rather than to react to the incorrect >>>> classification of fragment headers as incompatible with the Internet. >>> Not sure what you mean. >>> >>> We're not implying that packets employing FH are an attack. FWIW, I >>> don't personally think so. We do think that, when employing >>> fragmentation, you open the door to a number of attack vectors. See >>> e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt. >> Some of the attacks described are based on the widespread dropping of a >> valid IPv6 packet with valid IPv6 extension headers. >> >> IMO, it is important to be clear that this makes users of a legitimate >> IPv6 capability vulnerable because of incorrect behavior of routers. > 1) The attack I referenced is just one possible attack. If you employ > fragmentation, an atacker could just send forged packets meant to cause > collisions of frag IDs such that your packets are dropped -- clearly > employing an extra feature (as in this case), creates an attack vector. There are many possible attacks but you focus on the one where routers drop packets because they have frag EHs. > 2) The bahavior in routers is a policy. We may not like it. BUt it's a > policy, not incorrect behavior. EHs are not optional in RFC2460. Dropping because you see them is not policy - it forces the router to fail to support a required feature of IPv6. > >> It >> seems important to remind readers that the real issue here is the >> non-compliant routers. If that information isn't present, it implies >> that it is the use of the EHs that is incorrect and should be avoided in >> general. That's impossible for fragmentation - it is a critical >> capability without which tunneling cannot exist. > Fragmentation has been considered harmful for ages. And is finally being understood as fundamentally necessary for tunneling. > And yes, we're > saying that if you *do not need it*, you shouldn't use it. Yes, if you don't need tunnels, you shouldn't use them either, but that doesn't mean tunnels shouldn't be used in general. > >>>> The claim that links with IPv6 MTUs smaller than 1260 are rare needs to >>>> be supported with evidence. I appreciate that such evidence may be >>>> difficult to observe. In the absence of evidence, the statement should >>>> be more clear that there is no evidence to the contrary -- which is not >>>> the same as being able to claim that they *are* in fact rare. >>> I see your point. Any suggestion on how to tweak the text? >> It depends on what you know. AFAICT, we have no information on this >> issue. If that's the case, then the text should just state the impact on >> such links and say that "there is no evidence yet as to the prevalence >> of their use". > I'll talk to my co-authors about this one. AOK. Thanks, Joe From nobody Mon Aug 29 15:50:55 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 8425612D8A9; Mon, 29 Aug 2016 15:50:29 -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 qvOAlG_4IjEG; Mon, 29 Aug 2016 15:50:27 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0A712D8B8; Mon, 29 Aug 2016 15:50:03 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id ci2so631047pad.3; Mon, 29 Aug 2016 15:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4XL/4jlpxG2X/R/Md+DcVakCDkXRbeCip9Rze/t3mZQ=; b=o8WfhuKeiv44AnIlpiqf+0KQJHbr/f7nU8L90RZSXUMg3h9WoqDy9NDRAtBQr9rm5d CibklMLsANTGvCWOdM054M8WnyAf3jQbjOgqWTXixQTfxCN7buu8gzbammpfVOhsyHPc Yr9wZFgJdPH8RbxCUtf+teoxRQMzus4Zeg/njl6qwTYGR1kd9/miIEurD4wCLWrtdPgT GfopviiqB+I0SexnjNwXJF3d/vhvAOzgkaAdNKcf0v+1SAj6Air2HX7RI9Yu4boI2Goq XCKq+Cs32plInXqllFcDWf+LtRLg3q/FPNiyUyACR0pHVwlnw5aXVIqacvvx42gdb6p6 jYVA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4XL/4jlpxG2X/R/Md+DcVakCDkXRbeCip9Rze/t3mZQ=; b=ZVpq4ag38/Hwu5TZn8tyeZY9UBgLzPTFVDMTWMgzgAZWrfgjz8fIeR1csHzMjUli7U +7+I4Py/NaoXZcBTSGd9knfOiH2vTXaqo4Z9xOn2GYEq2kVkSrwIWf+2sXb8H2cvilfL odXqi/Dprp98T/S/xEHzN4KfzJ5dDfw5tdZuVBAvABGA7NT5ISXw56Jo9VantsXd8aEl QoRIQbrzIFsqHOSYN/iEGSDoBNsoXn+Qf4LrwAa1HgNpcZFWpAbt2+yCi7R614iEml6J kgF9egt1CtmWiBIeGYGSSILW6A+2GYIieYls209iUyExVsbpgFF8SGA33DRJ5Jj5xpuj x1YA== X-Gm-Message-State: AE9vXwN+TGOsykNewTbrQwR3laRuIIIaOPVLsR4HFo783pEZCT0c7EwiuGypUNXuCmADig== X-Received: by 10.67.7.170 with SMTP id dd10mr718783pad.152.1472511003053; Mon, 29 Aug 2016 15:50:03 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id n10sm51712132pap.16.2016.08.29.15.49.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 15:50:02 -0700 (PDT) To: Joe Touch , Fernando Gont , 6man References: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> <585f4689-d19e-dd54-e75b-4eb3644274ed@isi.edu> <6755d8bb-3b95-c107-cd72-b799cb2b32f1@isi.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 30 Aug 2016 10:50:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6755d8bb-3b95-c107-cd72-b799cb2b32f1@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-art@ietf.org" , Transport Area , draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, IETF discussion list Subject: Re: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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: Mon, 29 Aug 2016 22:50:30 -0000 On 30/08/2016 10:14, Joe Touch wrote: > Hi, Fernando, > > > On 8/29/2016 3:05 PM, Fernando Gont wrote: >> On 08/28/2016 01:33 PM, Joe Touch wrote: >>> Hi, Fernando, >>> >>> First, I'd like to note something more important about this doc - the >>> abstract itself argues that this change should update the core IPv6 >>> spec. Given that is already well underway, why is this document even >>> needed? >> The document says it clearly: "documenting the >> motivation for removing this functionality in the revision of the >> core IPv6 protocol specification." >> >> You just don't remove a feature from a spec silently, without a >> rationale. And the place to include the rationale wasn't rfc2460bis -- >> hence this dcument. > > I don't agree. RFC2460bis should not need a roadmap to explain all of > the associated changes and their rationales. That should be in 2460bis. 2460bis has pointers in such cases (and should include a pointer to deprecate-atomfrag when it becomes an RFC). I don't think it is helpful to readers of 2460bis to burden it with all the rationales. > Otherwise, changes need to be made incrementally - that's a lot of extra > load on the IETF and a lot of complexity to figure out why things are > the way the end up. I don't think 2460bis will be the end of history, any more than 791 was the end of IPv4 history. Incremental change will continue. Regards Brian > > >> >> >> >> >> >>>>> The impact of this change does not appear to have been explored. Section >>>>> 3 ends with a claim that links where this translation issue would be a >>>>> problem are rare, but there is no evidence presented as to whether >>>>> current RFC 6145 translators would be capable of complying with the >>>>> changes in this doc, e.g., to be able to generate IPv4 IDs as needed. >>>>> I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 >>>>> ID generation MUST be supported (and used), rather than MAY. >>>> RFC 6145 has been revised as RFC7915. >>> The second sentence of this draft cites 6145. You raise a good point, >>> but given 7915 obsoletes 6145 (rather than updating it), all references >>> throughout should then refer to 7915 instead. >> Not really. We're documenting why this feature is being removed -- hence >> there's a place for referencing RFC6145 ("state of affairs before any >> updates") and RFC7915. >> >> All references to RFC6145 are of the form "legacy translators", or >> "RFC6145 was...". > > I don't think it's useful to refer in this doc to a spec that is already > obsoleted. > > This is further reason why it's not useful to issue separate change > docs. It gets confusing as to what you're arguing and why. > >> >>>> The document concludes that the translator should create IPv4 IDs rather >>>>> than relying on atomic fragments as a source of that information (as per >>>>> RFC2460) because there is no benefit, but are two reasons why this >>>>> method is directly hazardous as well: 1) RFC 2460 does not require that >>>>> the IPv6 ID field is generated to ensure that the low 16-bits are unique >>>>> as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 >>>>> translation could result in collisions where two distinct IPv6 >>>>> destinations are translated into the same IPv4 address, such that IDs >>>>> that might have been generated to be unique in the IPv6 context could >>>>> end up colliding when used in the translated IPv4 context. I.e., this >>>>> does not require ECMP as implied in Section 3. >>>> mmm.. not sure I follow. When we refer to ECMP in Section 3 we're >>>> actually describing the only possible scenario in which relying on the >>>> ID in the Frag Header could be of use (i.e., possibly result in lower >>>> collision rates). >>> I'm not speaking of when the ID in the Frag Header can be useful. I'm >>> speaking of other more likely cases where using the low 16 bits of the >>> IPv6 ID field can generate IPv4 collisions. >> So you argue in favor of adding an extra bullet noting that RFC2460 does >> not require the lower 16 bits to be unique? (just double-checking). If >> so, fine with me. > > Yes - specifically, 2460 does not require that the lower 16 bits of the > ID are generated in a way that would comply with the expectations of > using just those bits for IPv4. > >> >>>>> Minor issues: >>>>> >>>>> IMO, it remains unwise to continue to imply that networks should treat >>>>> packets with fragment headers as an attack. Fragmentation support is >>>>> critical to tunneling (see draft-ietf-intarea-tunnels) and we need to >>>>> find ways to support their use safely. The text should be edited to >>>>> explain that the primary motivation here is to avoid generating >>>>> erroneous IPv4 ID fields, rather than to react to the incorrect >>>>> classification of fragment headers as incompatible with the Internet. >>>> Not sure what you mean. >>>> >>>> We're not implying that packets employing FH are an attack. FWIW, I >>>> don't personally think so. We do think that, when employing >>>> fragmentation, you open the door to a number of attack vectors. See >>>> e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt. >>> Some of the attacks described are based on the widespread dropping of a >>> valid IPv6 packet with valid IPv6 extension headers. >>> >>> IMO, it is important to be clear that this makes users of a legitimate >>> IPv6 capability vulnerable because of incorrect behavior of routers. >> 1) The attack I referenced is just one possible attack. If you employ >> fragmentation, an atacker could just send forged packets meant to cause >> collisions of frag IDs such that your packets are dropped -- clearly >> employing an extra feature (as in this case), creates an attack vector. > There are many possible attacks but you focus on the one where routers > drop packets because they have frag EHs. > >> 2) The bahavior in routers is a policy. We may not like it. BUt it's a >> policy, not incorrect behavior. > EHs are not optional in RFC2460. Dropping because you see them is not > policy - it forces the router to fail to support a required feature of IPv6. > > >> >>> It >>> seems important to remind readers that the real issue here is the >>> non-compliant routers. If that information isn't present, it implies >>> that it is the use of the EHs that is incorrect and should be avoided in >>> general. That's impossible for fragmentation - it is a critical >>> capability without which tunneling cannot exist. >> Fragmentation has been considered harmful for ages. > > And is finally being understood as fundamentally necessary for tunneling. > >> And yes, we're >> saying that if you *do not need it*, you shouldn't use it. > Yes, if you don't need tunnels, you shouldn't use them either, but that > doesn't mean tunnels shouldn't be used in general. > > >> >>>>> The claim that links with IPv6 MTUs smaller than 1260 are rare needs to >>>>> be supported with evidence. I appreciate that such evidence may be >>>>> difficult to observe. In the absence of evidence, the statement should >>>>> be more clear that there is no evidence to the contrary -- which is not >>>>> the same as being able to claim that they *are* in fact rare. >>>> I see your point. Any suggestion on how to tweak the text? >>> It depends on what you know. AFAICT, we have no information on this >>> issue. If that's the case, then the text should just state the impact on >>> such links and say that "there is no evidence yet as to the prevalence >>> of their use". >> I'll talk to my co-authors about this one. > > AOK. > > Thanks, > Joe > > From nobody Mon Aug 29 15:52: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 7B7A112D8A3; Mon, 29 Aug 2016 15:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 0_Xv4lwxSDJR; Mon, 29 Aug 2016 15:52:13 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C29312D7A4; Mon, 29 Aug 2016 15:52:13 -0700 (PDT) Received: from [192.168.1.154] (mail.interplazahotel.com.ar [201.216.217.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6878980ECC; Tue, 30 Aug 2016 00:52:09 +0200 (CEST) To: Joe Touch , 6man References: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> <585f4689-d19e-dd54-e75b-4eb3644274ed@isi.edu> <6755d8bb-3b95-c107-cd72-b799cb2b32f1@isi.edu> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Mon, 29 Aug 2016 19:51:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6755d8bb-3b95-c107-cd72-b799cb2b32f1@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tsv-art@ietf.org" , draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, Transport Area , IETF discussion list Subject: Re: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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: Mon, 29 Aug 2016 22:52:16 -0000 Hi, Joe, On 08/29/2016 07:14 PM, Joe Touch wrote: > > On 8/29/2016 3:05 PM, Fernando Gont wrote: >> On 08/28/2016 01:33 PM, Joe Touch wrote: >>> Hi, Fernando, >>> >>> First, I'd like to note something more important about this doc - the >>> abstract itself argues that this change should update the core IPv6 >>> spec. Given that is already well underway, why is this document even >>> needed? >> The document says it clearly: "documenting the >> motivation for removing this functionality in the revision of the >> core IPv6 protocol specification." >> >> You just don't remove a feature from a spec silently, without a >> rationale. And the place to include the rationale wasn't rfc2460bis -- >> hence this dcument. > > I don't agree. RFC2460bis should not need a roadmap to explain all of > the associated changes and their rationales. That should be in 2460bis. I don't think RFC2460bis is the place to add six pages about this. All other changes are similarly discussed in the respective updating documents. RFC7915 also references this doc for the rationale for deviating from the behavior in RFC6145. >>>>> The impact of this change does not appear to have been explored. Section >>>>> 3 ends with a claim that links where this translation issue would be a >>>>> problem are rare, but there is no evidence presented as to whether >>>>> current RFC 6145 translators would be capable of complying with the >>>>> changes in this doc, e.g., to be able to generate IPv4 IDs as needed. >>>>> I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4 >>>>> ID generation MUST be supported (and used), rather than MAY. >>>> RFC 6145 has been revised as RFC7915. >>> The second sentence of this draft cites 6145. You raise a good point, >>> but given 7915 obsoletes 6145 (rather than updating it), all references >>> throughout should then refer to 7915 instead. >> Not really. We're documenting why this feature is being removed -- hence >> there's a place for referencing RFC6145 ("state of affairs before any >> updates") and RFC7915. >> >> All references to RFC6145 are of the form "legacy translators", or >> "RFC6145 was...". > > I don't think it's useful to refer in this doc to a spec that is already > obsoleted. > > This is further reason why it's not useful to issue separate change > docs. It gets confusing as to what you're arguing and why. We just disagree here. This document explains why RFC7915 does not rely on atomic fragments anymore, and why the corresponding functionality is being removed from the spec. I don't see any complexity here. >>>> The document concludes that the translator should create IPv4 IDs rather >>>>> than relying on atomic fragments as a source of that information (as per >>>>> RFC2460) because there is no benefit, but are two reasons why this >>>>> method is directly hazardous as well: 1) RFC 2460 does not require that >>>>> the IPv6 ID field is generated to ensure that the low 16-bits are unique >>>>> as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145 >>>>> translation could result in collisions where two distinct IPv6 >>>>> destinations are translated into the same IPv4 address, such that IDs >>>>> that might have been generated to be unique in the IPv6 context could >>>>> end up colliding when used in the translated IPv4 context. I.e., this >>>>> does not require ECMP as implied in Section 3. >>>> mmm.. not sure I follow. When we refer to ECMP in Section 3 we're >>>> actually describing the only possible scenario in which relying on the >>>> ID in the Frag Header could be of use (i.e., possibly result in lower >>>> collision rates). >>> I'm not speaking of when the ID in the Frag Header can be useful. I'm >>> speaking of other more likely cases where using the low 16 bits of the >>> IPv6 ID field can generate IPv4 collisions. >> So you argue in favor of adding an extra bullet noting that RFC2460 does >> not require the lower 16 bits to be unique? (just double-checking). If >> so, fine with me. > > Yes - specifically, 2460 does not require that the lower 16 bits of the > ID are generated in a way that would comply with the expectations of > using just those bits for IPv4. Agreed. Will do. >>>>> Minor issues: >>>>> >>>>> IMO, it remains unwise to continue to imply that networks should treat >>>>> packets with fragment headers as an attack. Fragmentation support is >>>>> critical to tunneling (see draft-ietf-intarea-tunnels) and we need to >>>>> find ways to support their use safely. The text should be edited to >>>>> explain that the primary motivation here is to avoid generating >>>>> erroneous IPv4 ID fields, rather than to react to the incorrect >>>>> classification of fragment headers as incompatible with the Internet. >>>> Not sure what you mean. >>>> >>>> We're not implying that packets employing FH are an attack. FWIW, I >>>> don't personally think so. We do think that, when employing >>>> fragmentation, you open the door to a number of attack vectors. See >>>> e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt. >>> Some of the attacks described are based on the widespread dropping of a >>> valid IPv6 packet with valid IPv6 extension headers. >>> >>> IMO, it is important to be clear that this makes users of a legitimate >>> IPv6 capability vulnerable because of incorrect behavior of routers. >> 1) The attack I referenced is just one possible attack. If you employ >> fragmentation, an atacker could just send forged packets meant to cause >> collisions of frag IDs such that your packets are dropped -- clearly >> employing an extra feature (as in this case), creates an attack vector. > There are many possible attacks but you focus on the one where routers > drop packets because they have frag EHs. > >> 2) The bahavior in routers is a policy. We may not like it. BUt it's a >> policy, not incorrect behavior. > EHs are not optional in RFC2460. Dropping because you see them is not > policy - it forces the router to fail to support a required feature of IPv6. The same you could say about a device dropping packets because they are destined (or are not destined to) a specific port. The router does support EHs. The network just has a policy that don't want them. In any case, there' no need to argue a lot on this specific attack vector since, as noted, there are others. >>> It >>> seems important to remind readers that the real issue here is the >>> non-compliant routers. If that information isn't present, it implies >>> that it is the use of the EHs that is incorrect and should be avoided in >>> general. That's impossible for fragmentation - it is a critical >>> capability without which tunneling cannot exist. >> Fragmentation has been considered harmful for ages. > > And is finally being understood as fundamentally necessary for tunneling. And is necessary for UDP, too. Nobody is arguing against that. But the case in which we were producing atomic fragments wasn't a case in which you were really needed fragmentation: you were just using the FH as a signaling mechanism. -- for instance, an atomic fragment, hasn't really fragmented anything. >> And yes, we're >> saying that if you *do not need it*, you shouldn't use it. > Yes, if you don't need tunnels, you shouldn't use them either, but that > doesn't mean tunnels shouldn't be used in general. Where in the texxt do we say "you shouldn't use fragmentation in general"? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Aug 29 15:57:21 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 06699126FDC; Mon, 29 Aug 2016 15:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 Q2PpL-pLWFsL; Mon, 29 Aug 2016 15:57:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 4192B12B030; Mon, 29 Aug 2016 15:57:02 -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 boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7TMuMRd007908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Aug 2016 15:56:24 -0700 (PDT) To: Fernando Gont , 6man References: <786d5c2c-a88d-7539-9604-6df0b8ed68dd@isi.edu> <0f339ba8-cf63-e961-b19f-895c39585fb7@si6networks.com> <585f4689-d19e-dd54-e75b-4eb3644274ed@isi.edu> <6755d8bb-3b95-c107-cd72-b799cb2b32f1@isi.edu> From: Joe Touch Message-ID: Date: Mon, 29 Aug 2016 15:56:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: 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-6man-deprecate-atomfrag-generation@ietf.org, Transport Area , IETF discussion list Subject: Re: [Tsv-art] TSVART review of draft-ietf-6man-deprecate-atomfrag-generation 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: Mon, 29 Aug 2016 22:57:04 -0000 On 8/29/2016 3:51 PM, Fernando Gont wrote: > Where in the texxt do we say "you shouldn't use fragmentation in general"? It's the implication that follows from justifying this change based on whether frag EHs are dropped. IMO, that's simply irrelevant. The broader problem is using IPv6-generated IDs, which are not generated to be compliant in their bottom 16 bits with IPv4. That alone is more than sufficient rationale for not using this mechanism. Joe From nobody Tue Aug 30 07:13:32 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 9554312D68F for ; Tue, 30 Aug 2016 07:13:30 -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 gcjwNqspBkeM for ; Tue, 30 Aug 2016 07:13:25 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 13B1412D6A1 for ; Tue, 30 Aug 2016 07:12:30 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id z8so11937958ywa.1 for ; Tue, 30 Aug 2016 07:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kjwguXmifmNraqvLx5mzsR9IhHG1tkASLRXXlNf5v+I=; b=uclyfDQAZpvBl6uIWm/uQ6d9P7sI34Es8hYMrEK3lCgFb5CaD4XRh0Xu/kQgpxR3dS r2VcsEbmh4TgqMOBGP1zC2FZDyBfOBkelM9vsYW75i9TSuCSZ+UXMF2nDJGU3uVPwc/y 1g1J9CK7IXXj7JPINFPIgaPv8ap+ldlmBmZ2G1Xz+TWmp7663wCkZJFEb+1liaaIfAl+ U9Sifm67pwnXyqNyNIAqcaJzNbsIennH+W/XgLcoSYLjB+nG7VKuzKKDWJFQCqFW/JXE hlToC8k2WUkdM0osvs3eyKDJJewnjIj+71XqKsmqYpf04z7UBtdVb1GUucMxmJm86KRF h35g== 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=kjwguXmifmNraqvLx5mzsR9IhHG1tkASLRXXlNf5v+I=; b=eiLxLqigCi882RQP+lbGgW0M8QFNkmtpdtVoXXNEodSdIAFgIq7RHZX5WPMiXEobUV LvSTy4OVih2RYta/h1I4gJCU/4TGUBjJxGtLQxNjV236/5RTCpOyIJMxuNLtyzzWSfw1 S8msTNKUR8FbiBsAOtHdEznDuYgkF2G2Io1JcDH1T56ocvbletIkYQJAIqTDsRGvBn5f 7PvF7HpkBOdM7MvWZhNbpGhw4XOtrrFuHf4qUmCDVKjIEA1QiZF8Q2p2NJeUdZEId3Js w6/Qd4k1WBXFMfDYgj7kTI3lfSFA4QZGPEM7BwXnHTZnAwwnmiqXmaoEgC3lcbZgv1na Y9NA== X-Gm-Message-State: AE9vXwMAdvd+5gJwG3miWBZYXW4HBBsuus80H0dMmEkGJv7ZeOVkbg+rrhklIAi8csHrlcK7Br81oQfHPtzh0g== X-Received: by 10.13.200.5 with SMTP id k5mr3346635ywd.23.1472566349370; Tue, 30 Aug 2016 07:12:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.72.132 with HTTP; Tue, 30 Aug 2016 07:12:28 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 30 Aug 2016 09:12:28 -0500 Message-ID: To: Martin Stiemerling Content-Type: multipart/alternative; boundary=001a114e5624299959053b4a92f1 Archived-At: Cc: tsv-art@ietf.org Subject: Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 08/23 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, 30 Aug 2016 14:13:30 -0000 --001a114e5624299959053b4a92f1 Content-Type: text/plain; charset=UTF-8 Dear TSV-ART, On Tue, Aug 23, 2016 at 11:18 AM, Martin Stiemerling wrote: > > - draft-ietf-mpls-entropy-lsp-ping Martin had flagged this document for a possible review, and it's on this week's telechat. Could someone take a look at it? Thanks! Spencer --001a114e5624299959053b4a92f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TSV-ART,

On Tue, Aug 23, 2016 at 11:18 AM, Martin Stiemerling <ml= s.ietf@gmail.com> wrote:
- draft-ietf-mpls-entropy-lsp-ping

Mar= tin had flagged this document for a possible review, and it's on this w= eek's telechat. Could someone take a look at it?

Thanks!

Spencer=C2=A0
--001a114e5624299959053b4a92f1--