From nobody Mon May 2 11:17:34 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2A412D5D7 for ; Mon, 2 May 2016 11:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyi114ijqM5D for ; Mon, 2 May 2016 11:17:30 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053E112D169 for ; Mon, 2 May 2016 11:17:30 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id g17so155855427wme.1 for ; Mon, 02 May 2016 11:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:organization :mime-version:content-transfer-encoding; bh=8L/nrS4eIEFkJ5TJorFgIJVlbwH8bAge82CuS2dIoYM=; b=jrj3NVNfYO2BpjzDOKvA9o28OXIDnPFSSYWXGO74d6VTioIrT/0gtFQ2BJ9Oqcz/OR aT447Nu6Q7tKxYNxS752t3SFq2qHuWAqtF0/NQ/qHBbrB7b++ZkLpzHuTPUlL45BHof0 T4t3657jPYCuDAZCHzv9cK0KwtFgsOsJdAPVRYus/Z3h8959aVyspZyUGtDUW8nJ5o6l ChcfDxxS4DjD4zvOUOKOO86z8+xSTgejoCgf65fnxGNF25YQwgf3m2cw3BvpvLSnvFtP PS/3hs1cqvlWV18aHocw/4GqwcsG00/L3qt1e84ro2VPTlia4wAR2cIG691pBDMHtwJv +75g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :organization:mime-version:content-transfer-encoding; bh=8L/nrS4eIEFkJ5TJorFgIJVlbwH8bAge82CuS2dIoYM=; b=A6nA5Ug2FNmlq62ssiJfc7WOb9S18iRtf6hoa3SSytb1GZhJjmP+eze6T5Yuo3SOKV w0QnOl+1+Y7V5yWFDxVFv//GcjUqNzjI5jRnKlJ+S0aEzIDR88DMfi71JirtpvdNH+Ne oLLSxpyn19MFU0SZZtyWx9Dy0bR6JZcb22OvQPFxK/zUI4XZGF+2Tmufqlvgt2RAGd8J Gv9eEqwRsumJfcvGyQ6liGEHiGdaC7dIx5+Jr0iHl1/U0XuAlqtUZK/+SEJ9HWDeLmds aYyovMxeLp1IojCq7jyyP4NdS02t10dwQnEMx4pD8TmLj5niFzXpMnM0OFMsJDZjDlOi 6aIg== X-Gm-Message-State: AOPr4FUm2H+eL6P5XdnOJa0WrGUfxJvrEREOdK2+3V99/h9A2CDLC0AMfWCtUMZPd7WuZe4t X-Received: by 10.28.223.86 with SMTP id w83mr20557989wmg.95.1462213048478; Mon, 02 May 2016 11:17:28 -0700 (PDT) Received: from cjbc_dell.lan (85.251.161.16.dyn.user.ono.com. [85.251.161.16]) by smtp.gmail.com with ESMTPSA id by7sm31743455wjc.18.2016.05.02.11.17.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 11:17:27 -0700 (PDT) Message-ID: <1462213046.4232.31.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: int-dir@ietf.org, int-ads@ietf.org Date: Mon, 02 May 2016 20:17:26 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org Subject: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 18:17:33 -0000 Hi, I am an assigned INT directorate reviewer for draft-ietf-6man- deprecate-atomfrag-generation-06.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/direc torate.html. Overall, the document is mature, well written and I find it useful. I do not see any reason to hold up publication. Some minor detailed suggestions follow: - Section 1: The text says: 'Section 5 of [RFC2460] states that, when a host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination.' RFC2460 actually says 'In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280.' While the document states later that 'an IPv6 node cannot easily limit its exposure to the aforementioned attack vector by only generating IPv6 atomic fragments towards IPv4 destinations behind a stateless translator', it would help the reader to add that piece of context from the very beginning of the document. - Section 2: Again, I think it would help adding the context about RFC2460 using atomic fragments only for the purpose of helping an IPv6- to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. - Section 3: when discussing IPv4 Identification collision rates, it would be helpful adding some numbers/equations there to get an idea of what rates we are talking about. - Appendix A: what does 'Linux kernel current' mean? This is very minor, as this section is probably to be removed, but in case it remains after publication as RFC, current should be replaced by the kernel version number. Thanks, Carlos From nobody Mon May 2 11:33:59 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E974A12D153; Mon, 2 May 2016 11:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 8dZVgfej6yP7; Mon, 2 May 2016 11:33:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8AF312B012; Mon, 2 May 2016 11:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3407; q=dns/txt; s=iport; t=1462214035; x=1463423635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oefaI03Xlnv5MYUqCC8vDz+zfBrWkMYLpTrxAgYRS3c=; b=FGUimgqVK6lHdrge5f3xmDFBQo8shQwqZBOrlRQ3cafq8lQEpK7vmOGd yINXW6/uAwkJNu+A75zo72AxU6LiyBqHdNdTjwlU7XjwF1Fd3QCYXvzyu gy2nzRES/gTCnWIBp0A0PyPIrvXXV8PDHyA818bRYpF33MuhGak4hcmaX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgCBnCdX/5NdJa1egzhTfQa5dAENg?= =?us-ascii?q?XYXC4VuAoE0OBQBAQEBAQEBZSeEQQEBAQQBAQFrCwwEAgEIEQQBASgHJwsUCQg?= =?us-ascii?q?CBAENBQgBiCEOuxkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVim2CMoFohXkFjg+KB?= =?us-ascii?q?QGOEI8YjzABHgEBQoICHhaBNWyHSj5/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,568,1454976000"; d="scan'208";a="103768521" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 18:33:54 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u42IXsn1003798 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 18:33:54 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 13:33:54 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Mon, 2 May 2016 13:33:54 -0500 From: "Bernie Volz (volz)" To: "cjbc@it.uc3m.es" , "int-dir@ietf.org" , "int-ads@ietf.org" Thread-Topic: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation Thread-Index: AQHRpJ7qLlqoMRkhJkuLisO6VwGSMZ+l9qLw Date: Mon, 2 May 2016 18:33:53 +0000 Message-ID: <709d2969e3c84daeb02b9d72853c0f17@XCH-ALN-003.cisco.com> References: <1462213046.4232.31.camel@it.uc3m.es> In-Reply-To: <1462213046.4232.31.camel@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.200] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-6man-deprecate-atomfrag-generation@ietf.org" Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 18:33:58 -0000 A few other minor nits when I looked over this document: In section 3: - "2. The IPv4 node ... 1260 bytes". It might be useful to indicate how t= his 1260 came to be (as someone might easily confuse this with a typo for 1= 280?). This is really 1280 still but because the IPv4 header is 20 bytes sh= orter than the IPv6 header, the figure is 1260 for IPv4 packets. - The text "proposing as a workaround" is odd? Should "as" be dropped? In section 6, "some of [the] tests" (the is missing). Not a bit deal as I'm= sure RFC-Editor would fix. - Bernie -----Original Message----- From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Carlos Jes=FAs= Bernardos Cano Sent: Monday, May 02, 2016 2:17 PM To: int-dir@ietf.org; int-ads@ietf.org Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org Subject: [Int-dir] INT area directorate review for draft-ietf-6man-deprecat= e-atomfrag-generation Hi, I am an assigned INT directorate reviewer for draft-ietf-6man- deprecate-at= omfrag-generation-06.txt. These comments were written primarily for the ben= efit of the Internet Area Directors. Document editors and shepherd(s) shoul= d treat these comments just like they would treat comments from any other I= ETF contributors and resolve them along with any other Last Call comments t= hat have been received. For more details on the INT Directorate, see http:/= /www.ietf.org/iesg/direc torate.html. Overall, the document is mature, well written and I find it useful. I do no= t see any reason to hold up publication. Some minor detailed suggestions follow: - Section 1: The text says: 'Section 5 of [RFC2460] states that, when a hos= t receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising an MTU = smaller than 1280 bytes (the minimum IPv6 MTU), the host is not required to= reduce the assumed Path-MTU, but must simply include a Fragment Header in = all subsequent packets sent to that destination.' RFC2460 actually says 'In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IP= v4), the originating IPv6 node may receive an ICMP Packet Too Big message r= eporting a Next-Hop MTU less than 1280.' While the document states later that 'an IPv6 node cannot easily limit its = exposure to the aforementioned attack vector by only generating IPv6 atomic fragments towards IPv4 destinations behind a stateless translat= or', it would help the reader to add that piece of context from the very be= ginning of the document. - Section 2: Again, I think it would help adding the context about RFC2460 using atomic fragments only for the purpose of helping an IPv6- to-IPv4 translating router can obtain a suitable Identification value to us= e in resulting IPv4 fragments. - Section 3: when discussing IPv4 Identification collision rates, it would = be helpful adding some numbers/equations there to get an idea of what rates= we are talking about. - Appendix A: what does 'Linux kernel current' mean? This is very minor, as= this section is probably to be removed, but in case it remains after publi= cation as RFC, current should be replaced by the kernel version number. Thanks, Carlos _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir From nobody Mon May 2 12:10:18 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954B412D613 for ; Mon, 2 May 2016 12:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caNcX7YLt52H for ; Mon, 2 May 2016 12:10:14 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 EE0A112D607 for ; Mon, 2 May 2016 12:10:09 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id u64so198998670lff.3 for ; Mon, 02 May 2016 12:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fBJNJhVlpB1kxA3t07DwEnbVQOznDnapYXCOyHXefug=; b=xqmRAcIEzz6/AuQEIZcIfOPoYxTxcvPAcBBk5FiniIXrgNfE3SZo3gqSF3upyLHfE9 5X8RLBGTLY7DyykOmNkA9mDRqBOJHpNhgRyzPemZ4Po8o8m/cm6E4BkWXb16UcAXibz8 +54VwWBuDa4C000V20q/DG6YakGSjKJNtH0PCHLnrdA3quVSqwpe976GVhJRJKsJH4kH TgXPkDO+dC77SIz2ryJCcKZ1Fb8Qu48a3p3ZeP0VNz1dUIZl6MFZNY23WJr1wfzeL3AX +0s41GVWlsT8rC+zqHWj62Sy3PMCSAq8pd0vAJnHZve+Kza+uC6pFc6W2P2tcpg0gDoJ z1zQ== 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=fBJNJhVlpB1kxA3t07DwEnbVQOznDnapYXCOyHXefug=; b=ToiNHCDCliQi/gZH39MxCTE2tZdnciHfxt/J2MfzzmTqb4M8UNO6zWJl7zQ06L8zWy XUdYQOdEqtcs8i67I+r4WvWokVM0+dtdwuEqybUdJd+tDkFIbYJePtTPNjX5RrY32OvW //A49KPMjckJZ/7updQb3fkxZErQMlj3LUMPnWO+at5k4uLzi05y5FtTRsM4d4DuJ3iO JJt5iDsgmbO5MiNI0Var8z294hqvDwFGk6vuwo7eHb7emnXUGHdUDjMZxnSejCo7e83a Ag9mVXJtjfMgyDPUg15hzfkvLPz6Re8yE+o+5Kdzy+zoo8JghXDtAWxMs19xtcGfUR/N 3LuQ== X-Gm-Message-State: AOPr4FV2usmH2EUIz8eRZiYngaA8bwkFoeovCYDSxsFLSkmJwREp/b6H9CmCjMQYWZasDmJIxF6EPLUVMQOARA== X-Received: by 10.112.159.70 with SMTP id xa6mr15212282lbb.87.1462216208107; Mon, 02 May 2016 12:10:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.213.19 with HTTP; Mon, 2 May 2016 12:09:28 -0700 (PDT) X-Originating-IP: [71.233.41.235] In-Reply-To: <709d2969e3c84daeb02b9d72853c0f17@XCH-ALN-003.cisco.com> References: <1462213046.4232.31.camel@it.uc3m.es> <709d2969e3c84daeb02b9d72853c0f17@XCH-ALN-003.cisco.com> From: Ted Lemon Date: Mon, 2 May 2016 15:09:28 -0400 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a11c28608ab63480531e0bd98 Archived-At: Cc: "draft-ietf-6man-deprecate-atomfrag-generation@ietf.org" , "int-ads@ietf.org" , "cjbc@it.uc3m.es" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 19:10:16 -0000 --001a11c28608ab63480531e0bd98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No problem, just wanted to make sure. :) On Mon, May 2, 2016 at 2:33 PM, Bernie Volz (volz) wrote: > A few other minor nits when I looked over this document: > > In section 3: > > - "2. The IPv4 node ... 1260 bytes". It might be useful to indicate how > this 1260 came to be (as someone might easily confuse this with a typo fo= r > 1280?). This is really 1280 still but because the IPv4 header is 20 bytes > shorter than the IPv6 header, the figure is 1260 for IPv4 packets. > > - The text "proposing as a workaround" is odd? Should "as" be dropped? > > > In section 6, "some of [the] tests" (the is missing). Not a bit deal as > I'm sure RFC-Editor would fix. > > - Bernie > > -----Original Message----- > From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Carlos Jes= =C3=BAs > Bernardos Cano > Sent: Monday, May 02, 2016 2:17 PM > To: int-dir@ietf.org; int-ads@ietf.org > Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org > Subject: [Int-dir] INT area directorate review for > draft-ietf-6man-deprecate-atomfrag-generation > > Hi, > > I am an assigned INT directorate reviewer for draft-ietf-6man- > deprecate-atomfrag-generation-06.txt. These comments were written primari= ly > for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat commen= ts > from any other IETF contributors and resolve them along with any other La= st > Call comments that have been received. For more details on the INT > Directorate, see http://www.ietf.org/iesg/direc torate.html. > > Overall, the document is mature, well written and I find it useful. I do > not see any reason to hold up publication. > > Some minor detailed suggestions follow: > > - Section 1: The text says: 'Section 5 of [RFC2460] states that, when a > host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising an > MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not > required to reduce the assumed Path-MTU, but must simply include a Fragme= nt > Header in all subsequent packets sent to that destination.' > > RFC2460 actually says 'In response to an IPv6 packet that is sent to an > IPv4 destination (i.e., a packet that undergoes translation from IPv6 to > IPv4), the originating IPv6 node may receive an ICMP Packet Too Big messa= ge > reporting a Next-Hop MTU less than 1280.' > > While the document states later that 'an IPv6 node cannot easily limit it= s > exposure to the aforementioned attack vector by only generating > IPv6 atomic fragments towards IPv4 destinations behind a stateless > translator', it would help the reader to add that piece of context from t= he > very beginning of the document. > > - Section 2: Again, I think it would help adding the context about > RFC2460 using atomic fragments only for the purpose of helping an IPv6- > to-IPv4 translating router can obtain a suitable Identification value to > use in resulting IPv4 fragments. > > - Section 3: when discussing IPv4 Identification collision rates, it woul= d > be helpful adding some numbers/equations there to get an idea of what rat= es > we are talking about. > > - Appendix A: what does 'Linux kernel current' mean? This is very minor, > as this section is probably to be removed, but in case it remains after > publication as RFC, current should be replaced by the kernel version numb= er. > > Thanks, > > Carlos > > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir > > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir > --001a11c28608ab63480531e0bd98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No problem, just wanted to make sure. =C2=A0:)

On Mon, May 2, 2016 at = 2:33 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
A few other minor nits when I looked over this docum= ent:

In section 3:

- "2.=C2=A0 The IPv4=C2=A0 node ... 1260 bytes". It might be usef= ul to indicate how this 1260 came to be (as someone might easily confuse th= is with a typo for 1280?). This is really 1280 still but because the IPv4 h= eader is 20 bytes shorter than the IPv6 header, the figure is 1260 for IPv4= packets.

- The text "proposing as a workaround" is odd? Should "as&qu= ot; be dropped?


In section 6, "some of [the] tests" (the is missing). Not a bit d= eal as I'm sure RFC-Editor would fix.

- Bernie

-----Original Message-----
From: Int-dir [mailto:int-dir-b= ounces@ietf.org] On Behalf Of Carlos Jes=C3=BAs Bernardos Cano
Sent: Monday, May 02, 2016 2:17 PM
To: int-dir@ietf.org; int-ads@ietf.org
Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org
Subject: [Int-dir] INT area directorate review for draft-ietf-6man-deprecat= e-atomfrag-generation

Hi,

I am an assigned INT directorate reviewer for draft-ietf-6man- deprecate-at= omfrag-generation-06.txt. These comments were written primarily for the ben= efit of the Internet Area Directors. Document editors and shepherd(s) shoul= d treat these comments just like they would treat comments from any other I= ETF contributors and resolve them along with any other Last Call comments t= hat have been received. For more details on the INT Directorate, see h= ttp://www.ietf.org/iesg/direc torate.html.

Overall, the document is mature, well written and I find it useful. I do no= t see any reason to hold up publication.

Some minor detailed suggestions follow:

- Section 1: The text says: 'Section 5 of [RFC2460] states that, when a= host receives an ICMPv6 "Packet Too Big" message [RFC4443] adver= tising an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is n= ot required to reduce the assumed Path-MTU, but must simply include a Fragm= ent Header in all subsequent packets sent to that destination.'

RFC2460 actually says 'In response to an IPv6 packet that is sent to an=
IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IP= v4), the originating IPv6 node may receive an ICMP Packet Too Big message r= eporting a Next-Hop MTU less than 1280.'

While the document states later that 'an IPv6 node cannot easily limit = its exposure to the aforementioned attack vector by only generating
IPv6 atomic fragments towards IPv4 destinations behind a stateless translat= or', it would help the reader to add that piece of context from the ver= y beginning of the document.

- Section 2: Again, I think it would help adding the context about
RFC2460 using atomic fragments only for the purpose of helping an IPv6-
to-IPv4 translating router can obtain a suitable Identification value to us= e in resulting IPv4 fragments.

- Section 3: when discussing IPv4 Identification collision rates, it would = be helpful adding some numbers/equations there to get an idea of what rates= we are talking about.

- Appendix A: what does 'Linux kernel current' mean? This is very m= inor, as this section is probably to be removed, but in case it remains aft= er publication as RFC, current should be replaced by the kernel version num= ber.

Thanks,

Carlos

_______________________________________________
Int-dir mailing list
Int-dir@ietf.org
https://www.ietf.org/mailman/listinfo/int-dir

_______________________________________________
Int-dir mailing list
Int-dir@ietf.org
https://www.ietf.org/mailman/listinfo/int-dir

--001a11c28608ab63480531e0bd98-- From nobody Tue May 3 14:19:56 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351D312D90C; Tue, 3 May 2016 14:19:55 -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 Wg8sEZckt9aL; Tue, 3 May 2016 14:19:53 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 25A2C12D8ED; Tue, 3 May 2016 14:19:51 -0700 (PDT) Received: by mail-qg0-x22c.google.com with SMTP id w36so14503442qge.3; Tue, 03 May 2016 14:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=YrPM0ZRwJADr/7QQydCwnXPWQ8DTv2+t5FqJ5tRDNPo=; b=hiA5rG4zQ23I+/ZmY2REJEb88pTconxqQYysCKRuNOoZ7W5mpJ2clYYl6o8YAyrEyC sR5KmE5adIrJ6i/+mxAasshBRmRlE11CjrMrbGYGEIxO9SbO0pC6dkvv7pEaxDmIN1iu 8buv0UzawLXJVN0tb914poJeM548OzCA44PsvRE10k0cDdEARVcJxc0aVqmTqkoQpDEv 7kLRHWkqeI3PYk8j72cOOVfWtBbZN01lpJuLvxdmEBwHo76NhNIPizQOXfl6hUbt497v L2qJ0H5GBI1zqCT7zl2NPGXCR7xv7O28p82zvWOeQCOnTunh48sagM7zZG1LtJSM+EqZ WwKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=YrPM0ZRwJADr/7QQydCwnXPWQ8DTv2+t5FqJ5tRDNPo=; b=N6os8+DOyYuiQqGlqITup49aVaN3uoEjXSGruzGpPxPYMz63aMzowQU+tKsVHwZAto 0Y7G0GBdeC/4TRvXtHd1umQKftYTX4zytM6nIFRxgalj2vWw7BWJsnxs5q3W77SM09Sf Avy9FR6tN8YvGqjmquescwtktZVBS5ysoDqzYfN3hwzQvwT0c1yJcebP+RjZSmWShltZ +JRPaxJ09NGB5Yau6DWKs7OCsaPRxY9QALr2qiWnMBuRQHkj0BYYCCZIn+7YNze65wUy 8fCJjxnqrIJyOxfRcQPVTI5DmVGqPUSu2ezPjcwpg2bYO1PSLhtuX77lI/5xXN6Pizec ljUg== X-Gm-Message-State: AOPr4FWxi5CQPUNdNLXGXhNoqncZAm4ePsEem8aJFFzDSS7QhEg7/97jd1+w3xB0QaAmZA== X-Received: by 10.140.235.14 with SMTP id g14mr5096730qhc.86.1462310391153; Tue, 03 May 2016 14:19:51 -0700 (PDT) Received: from [192.168.1.114] (c-24-62-230-192.hsd1.ma.comcast.net. [24.62.230.192]) by smtp.gmail.com with ESMTPSA id 23sm132513qkd.8.2016.05.03.14.19.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 May 2016 14:19:50 -0700 (PDT) From: Ralph Droms X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_F0F97785-5018-4FF4-BAD9-38CF3A8C1481"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Tue, 3 May 2016 17:15:36 -0400 Message-Id: To: "" , int-ads@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-mif-happy-eyeballs-extension.all@tools.ietf.org Subject: [Int-dir] INTDIR review of draft-ietf-mif-happy-eyeballs-extension-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 21:19:55 -0000 --Apple-Mail=_F0F97785-5018-4FF4-BAD9-38CF3A8C1481 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I am an assigned INT directorate reviewer for draft-ietf-mif-happy-eyeballs-extension-09. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. In my opinion, the documents lacks - and needs - a clear statement of purpose. What result is the document trying to achieve? Who is the audience? How would the audience put the contents of the document to use? The document must be edited carefully for english language usage before publication. I would consider this issue to be worthy of a "Discuss" on the document. I found that the document is unclear in several areas, which prevented me from understanding the meaning of that text. For example, in section 2, does "within a single home." mean a device in one home or a device with just one interface? In section 5.1, does: users may dedicatedly prefer a 3GPP network interface to seek high-reliability or security benefits even to manually turn off WiFi interface. mean: users may turn off a device's WiFi interface to guarantee use of a 3GPP network interface to assure higher reliability or security. Some sections seem to make observations about conditions that might have an influence on an implementation of MIF-HE, but don't have any actionable guidance for implementors. This lack of clarity is related to the lack of a clear statement of purpose for the document. For example, in section 5.1: The decision on mergence of policies may be made by implementations, by node administrators, even by other standards investigating customer behavior. However, it's worth to note that a demand from users should be normally considered higher priority than from other actors. I don't see anything in this text that I would consider actionable as an implementor. It is unclear where the document explicitly choosing one interface as "faster". Section 5.2 includes text about "the outcome of each connection attempt"; does this text refer to recording the connection time and using that time as the basis for future interface selection? How does HE-MIF interact with HE for selecting between IPv4 and IPv6? --Apple-Mail=_F0F97785-5018-4FF4-BAD9-38CF3A8C1481 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 - http://gpgtools.org iQIcBAEBCAAGBQJXKRT5AAoJEINeeBNmFjV5PGAQAKSTW1D+SDt+d3ZLmq53UUWb lKw1je2rqipSCP2kxX6DmE/f556aKaY3mp9QLvg8AHcr+gtM8XuRrArwhU74f12k meHdnX3zX3Io8OTzb3PQ/v6j65e54qxymj4/0Arfy1wHMH5vetjaKEVl7ectEx6W 0qcLiMSMVXsR8c8CJRgATgOiZk+RVUkoJGY5GWZ8AMjRtJ816w9NboZmOdz0PUYe BCOPGoXtYSAY4hNcy4H0zVT14UJKVXxfw8qzUYr30Jy/zjaNkEF+wu3hqK7zrFZd q9E+9to7wNi/THB4xudZvq1949bawBLmPzJx32U82gMXhsRjiyV3RcnFsstl8Uh7 aBNubr0JDMmNU29Qicy9uwHe5CVqBzQFa+34gNHVTtxGj6ZTQPSw0REfJWRaKiqo NRt1TRcJzI5gYqFK49OHLjbsV9tgjShX7T/56H33n9hkc6JMDadZtDd4ko7HWni6 5wK3cRPleVs+t3UkTB7r2ArhcgMzzw/yvy/RHX6KALGQo+6Z06a18m1dxHvGbLn9 wsnGcT/Yea2HANw5WCt8tCtZQAerWX9MynwDHXFuDBK3QPqA1JlEUqqDKbtU6dUD p4e/fWlwIim/P02huewzfNq9fP/1hx1NozOyc0FVnnhDcAUWa2aER3U2vX8vUbYi r7lGpSlDxRPfHXEaWFD1 =A9Fv -----END PGP SIGNATURE----- --Apple-Mail=_F0F97785-5018-4FF4-BAD9-38CF3A8C1481-- From nobody Thu May 12 10:14:47 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39312D6F9 for ; Thu, 12 May 2016 10:14:43 -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 SB9n2KsTCLOt for ; Thu, 12 May 2016 10:14:37 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 A177712D6CC for ; Thu, 12 May 2016 10:14:37 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id 77so32603900pfv.2 for ; Thu, 12 May 2016 10:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=WwXEen1GYDchDGjbXtSvd0uQo19FPb/kicN8FOCCECQ=; b=lSK6mcpb9j2kLsHk4N9chKEfwSJqU2xqatifVDqxLFfVtxtzG8SevtcdaciHnZmdeq RrdcqMiJNor7wczsa/WeT2miqJizvwyW3HdpSesRO7tgptet4XOf/FW/k1CIwCebwHsl G7HaoND2FrYVC7sYhLASdsa80w8jLT7mofhm0KABWKd4YvUpPZUGS+dts/ia1xwb9rov 8P8ONDrx1vRBmjpLivqfOEd9zP2m4pq9mppFbhZVasZhnufFs/OJwjNgVN1OjfOtEl7g YlYi58Z1u3/X7l4WhvPzAV4YjU9NFophEn7f5hVOQyRG41oM8fvxDX0EIYhMAx/dXEBk ODfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:from:subject:to:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=WwXEen1GYDchDGjbXtSvd0uQo19FPb/kicN8FOCCECQ=; b=h7EmTnvobjxqnpAYgPoQUpwPS9ICl6v91SfXLpTS4rLngCahsqw/3ZCrMc13v5OCqs dC5sArL66Mu3y/A4VQyMSk+UsRXD2CBd38NGSygKYgmD4sPb42zj7WvVmyrV2LQGqRNg NSd0ywTGHDlWosX/vgdRf9gBL89oN5mOxsOsqj7aaIcw7tAyAGFLfTN3Xw8lXiaMgVr4 TH0npwo8NgDw+It65Olr25aFz4V+u1JjmYjjWD2bKQxPaqNXtylOJcUE+zSYYGctM9/T WB1Qgw/z3pO1BYWLvRQz3YmtWY/BqZOnb6cHCr4507C3GSg88vrz+pu1ohGBdK8Lwhc3 sZ0g== X-Gm-Message-State: AOPr4FXOgDw+2NP+Ij/DpGBoBgaDq0LStB6uT2nxrC0CWUHq4OaNT3WcN6sPnqrvuRWyzg== X-Received: by 10.98.87.220 with SMTP id i89mr15355612pfj.107.1463073277269; Thu, 12 May 2016 10:14:37 -0700 (PDT) Received: from [10.16.84.45] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id y128sm21243746pfb.13.2016.05.12.10.14.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 10:14:36 -0700 (PDT) From: Jouni Korhonen To: "" , draft-ietf-mif-happy-eyeballs-extension.all@tools.ietf.org Message-ID: <5734B9F9.1070309@gmail.com> Date: Thu, 12 May 2016 10:14:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Int-dir] INT-DIR review of draft-ietf-mif-happy-eyeballs-extension-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.nospam@gmail.com List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 17:14:43 -0000 I am an assigned INT directorate reviewer for draft-ietf-mif-happy-eyeballs-extension-09. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. I recon the review is way late but I am doing it still. * The document is not ready for publication. The first issues that comes out is the language and grammar, which needs a major facelift. In many places the reader is left wondering what exactly was meant on the first few reads. The second issue really is the technical recommendations how to implement HE-MIF enabled device. I cannot say Section 5 describes the behaviour well enough for me to be able to implement anything (I do realize this is an Informational document but still..). Furthermore, Section 6 implementation framework description is somewhat thin. * Some acronyms such as MIF and PVD are never expanded while some are multiple times (like HE). * The document uses "fast interface" and "most fast path".. Does it mean fast by link bandwidth or actually the smallest connection RTT? All references to "fast" should be revisited and clarified what is actually meant. * HE-MIF is described as adopting happy eyeballs to MPVD. After reading the document this connection is somewhat vague. The document should be a bit more concrete on how to apply MPVD specifically to happy eyeballs. * Use case WiFi is broken: 121 might not be the case for several reasons, such as authentication 122 requirements, instability at layer 2, or even, perhaps, the WiFi It is unclear to me how "authentication requirements" applies here. Does it actually try to mean captive portal type scenario? Also, it is unclear to me how "instability at layer 2" applies here. Does it mean the connection is so bad that no packets go through? In that case it is likely the device would not be able to acquire or keep its IP address either on that interface. * WiFi use case makes a sudden assumption the device is a mobile phone. While this is probably the case the use case description starts off with "MIF node".. recommend using something like "MIF enabled mobile device". * I do not understand what the "time slot" means here: 127 to wait an appropriate time slot but not forever. After the timer is * No Reference to ANDSF.. most readers are linkely unfamiliar with it. * Sections 5 should really be more concrete with its guidance to implementers what to do. - Jouni From nobody Thu May 12 11:04:57 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC5512D0F4 for ; Thu, 12 May 2016 11:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 giS4Ek0zlBST for ; Thu, 12 May 2016 11:04:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854CF12D0EE for ; Thu, 12 May 2016 11:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3411; q=dns/txt; s=iport; t=1463076293; x=1464285893; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sxDG+pi6YlLsQ+a1qyONq198shUrS0uX9IwaottlLzg=; b=g2PkIYNJ46zgdzY8GMxoEq7pNsbmw7wb/GepqYiAM21aqUm01gH5yBXO Ssm4O88l6CrsKKTbj4OzMrPi5BC3Lvbc/31aejjIKuJf4fOCxM3mE/2PN Vyuu0RmIO91gh/URmzXoKPTm60GCJOr7NCi2MauFb7FOlbFrXef2eg6IT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQDtxDRX/4QNJK1egzhVfga5WQENg?= =?us-ascii?q?XYXC4VyAoE5OBQBAQEBAQEBZSeEQgEBAQQBAQE3NBcGAQgRBAEBHwkuCxQJCQE?= =?us-ascii?q?EARIIAYgmDr0KAQEBAQEBAQMBAQEBAQEBAQEeinGCEIJhhScFmCcBjhaPII9AA?= =?us-ascii?q?R4BAUKDa24BhzF/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,610,1454976000"; d="scan'208";a="101576016" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2016 18:04:52 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4CI4qd6000584 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2016 18:04:52 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 May 2016 13:04:52 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Thu, 12 May 2016 13:04:52 -0500 From: "Bernie Volz (volz)" To: "jouni.nospam@gmail.com" , "" , "draft-ietf-mif-happy-eyeballs-extension.all@tools.ietf.org" Thread-Topic: [Int-dir] INT-DIR review of draft-ietf-mif-happy-eyeballs-extension-09 Thread-Index: AdGseLNJ4BpCqwdIQ7mT+6xT/rcwxA== Date: Thu, 12 May 2016 18:04:51 +0000 Message-ID: <0828080abc414404a0c89e36e0012d7b@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.76.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] INT-DIR review of draft-ietf-mif-happy-eyeballs-extension-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:04:56 -0000 Thanks much Jouni! (And seems to be in agreement with Ralph's and my assess= ment.) - Bernie -----Original Message----- From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Thursday, May 12, 2016 1:15 PM To: ; draft-ietf-mif-happy-eyeballs-ex= tension.all@tools.ietf.org Subject: [Int-dir] INT-DIR review of draft-ietf-mif-happy-eyeballs-extensio= n-09 I am an assigned INT directorate reviewer for draft-ietf-mif-happy-eyeballs-extension-09. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. I recon the review is way late but I am doing it still. * The document is not ready for publication. The first issues that comes=20 out is the language and grammar, which needs a major facelift. In many=20 places the reader is left wondering what exactly was meant on the first=20 few reads. The second issue really is the technical recommendations how=20 to implement HE-MIF enabled device. I cannot say Section 5 describes the=20 behaviour well enough for me to be able to implement anything (I do=20 realize this is an Informational document but still..). Furthermore,=20 Section 6 implementation framework description is somewhat thin. * Some acronyms such as MIF and PVD are never expanded while some are=20 multiple times (like HE). * The document uses "fast interface" and "most fast path".. Does it mean=20 fast by link bandwidth or actually the smallest connection RTT? All=20 references to "fast" should be revisited and clarified what is actually=20 meant. * HE-MIF is described as adopting happy eyeballs to MPVD. After reading=20 the document this connection is somewhat vague. The document should be a=20 bit more concrete on how to apply MPVD specifically to happy eyeballs. * Use case WiFi is broken: 121 might not be the case for several reasons, such as authentication 122 requirements, instability at layer 2, or even, perhaps, the WiFi It is unclear to me how "authentication requirements" applies here. Does it actually try to mean captive portal type scenario? Also, it is unclear to me how "instability at layer 2" applies here. Does it mean the connection is so bad that no packets go through? In that case it is likely the device would not be able to acquire or keep its IP address either on that interface. * WiFi use case makes a sudden assumption the device is a mobile phone. While this is probably the case the use case description starts off with "MIF node".. recommend using something like "MIF enabled mobile device". * I do not understand what the "time slot" means here: 127 to wait an appropriate time slot but not forever. After the timer is * No Reference to ANDSF.. most readers are linkely unfamiliar with it. * Sections 5 should really be more concrete with its guidance to implementers what to do. - Jouni _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir From nobody Thu May 12 20:48:12 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23E412B078 for ; Thu, 12 May 2016 20:48:09 -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=unavailable 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 qxSpSsgwb-Cm for ; Thu, 12 May 2016 20:47:56 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823F412B061 for ; Thu, 12 May 2016 20:47:56 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id i75so113136214ioa.3 for ; Thu, 12 May 2016 20:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/5G7rHg+V6Rr54paWElXjUXOS2Nl2F/JqKqZNyXs22I=; b=cVDaUhHowkCtMBSDkAulIXOha1QgkiGnwACntXj8EjKRJ44OgeKfgq4FjXCGRTmZ3+ 68W71aYegljRJ03bKv6oaLjjNoUR1V7INomom4gZ9SKUcDiiiCOJUDqWx+lE1Yyc++AH nucoOJ2i8PWg+2nv7f/R5pJ/8ZaGlAFQns3TibK+QfGa7Vkffm7dnR4TQkd1rYMpdAWH 7LCXgyE/+CRnJBJxdBj43Hcw3rfmYbZVmVyx9W9X0N0lk0Qpavf710WDKvNHS63RGDOT 5kIKrjikbobcI+dBr4uzCVOG+r3B/7ZTul991biAf8SJZrElyfCsgFK41R95I1Rlx46T sSsA== 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:date :message-id:subject:from:to:cc; bh=/5G7rHg+V6Rr54paWElXjUXOS2Nl2F/JqKqZNyXs22I=; b=YJ9bUYUTPa7m5AHQcafJVaCQ2//luUv8ZAP5RhsxldXBgzjy8LIPF4EvM7pVpOp3nN EeI7FtM0QMBVo2uRt8tYkRwN/Zf2eRhhyeA4AR12h0qIXbahy2inisKM9jJjUwf7eXkY AMqsRvwaqy6D5eoMasOEprKdJwOYKl2SIld9Y2EuwZkGnmwhJNX6dRbgCicw+u5/TZ4/ ikYWsqopBNCIkVyDa1pxESrjdg/VKeLElszi89wodD1JS220DVDO7T691cCgeIZfdCj1 r8Hfpduw96aCxA8mmNFEguCDoUoiAtbqNw2rT7USIqCIvCaNOwn40x8yjzws5S6v688+ INbw== X-Gm-Message-State: AOPr4FVA4dXQO0ydL4O30T6JP5hnb1P3/VvuCY+BeW0Pqj/iLk1ihBfLYs7oI1nGqkYaqwYi6cKnQG9XXTFBWQ== MIME-Version: 1.0 X-Received: by 10.36.36.4 with SMTP id f4mr436573ita.29.1463111275823; Thu, 12 May 2016 20:47:55 -0700 (PDT) Received: by 10.36.149.2 with HTTP; Thu, 12 May 2016 20:47:55 -0700 (PDT) In-Reply-To: <5734B9F9.1070309@gmail.com> References: <5734B9F9.1070309@gmail.com> Date: Fri, 13 May 2016 11:47:55 +0800 Message-ID: From: GangChen To: jouni.nospam@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-mif-happy-eyeballs-extension.all@tools.ietf.org, "" Subject: Re: [Int-dir] INT-DIR review of draft-ietf-mif-happy-eyeballs-extension-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 03:48:09 -0000 Hi Jouni, thank you for the comments. 2016-05-13 1:14 GMT+08:00, Jouni Korhonen : > I am an assigned INT directorate reviewer for > draft-ietf-mif-happy-eyeballs-extension-09. These comments were > written primarily for the benefit of the Internet Area > Directors. Document editors and shepherd(s) should treat these > comments just like they would treat comments from any other IETF > contributors and resolve them along with any other Last Call comments > that have been received. For more details on the INT Directorate, see > http://www.ietf.org/iesg/directorate.html. > > I recon the review is way late but I am doing it still. > > * The document is not ready for publication. The first issues that comes > out is the language and grammar, which needs a major facelift. In many > places the reader is left wondering what exactly was meant on the first > few reads. The second issue really is the technical recommendations how > to implement HE-MIF enabled device. I cannot say Section 5 describes the > behaviour well enough for me to be able to implement anything (I do > realize this is an Informational document but still..). Furthermore, > Section 6 implementation framework description is somewhat thin. We will try to improve the readability through the revision. > * Some acronyms such as MIF and PVD are never expanded while some are > multiple times (like HE). > > * The document uses "fast interface" and "most fast path".. Does it mean > fast by link bandwidth or actually the smallest connection RTT? All > references to "fast" should be revisited and clarified what is actually > meant. "fast interface" and "most fast path" actually mean the shortest RTT. > * HE-MIF is described as adopting happy eyeballs to MPVD. After reading > the document this connection is somewhat vague. The document should be a > bit more concrete on how to apply MPVD specifically to happy eyeballs. That will be also clarified in the next revision. > * Use case WiFi is broken: > 121 might not be the case for several reasons, such as authentication > 122 requirements, instability at layer 2, or even, perhaps, the WiFi > > It is unclear to me how "authentication requirements" applies here. > Does it actually try to mean captive portal type scenario? You are right. It indicates the captive portal scenario. > Also, it is unclear to me how "instability at layer 2" applies here. > Does it mean the connection is so bad that no packets go through? In > that case it is likely the device would not be able to acquire or > keep its IP address either on that interface. The case indicate a weak wifi signal along a moving. Device get the IP at bootstrap but still detects the signalling so it keeps IP addrsss. > * WiFi use case makes a sudden assumption the device is a mobile phone. > While this is probably the case the use case description starts off > with "MIF node".. recommend using something like "MIF enabled mobile > device". we will update the draft accordingly. > * I do not understand what the "time slot" means here: > 127 to wait an appropriate time slot but not forever. After the > timer is > > * No Reference to ANDSF.. most readers are linkely unfamiliar with it. > > * Sections 5 should really be more concrete with its guidance to > implementers what to do. That will be enhanced. BRs Gang > - Jouni > > From nobody Wed May 25 05:03:03 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752DD12DB1B for ; Wed, 25 May 2016 05:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gFI3ByH3So0 for ; Wed, 25 May 2016 05:03:00 -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 C2CC112DB11 for ; Wed, 25 May 2016 05:02:49 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n129so59858799wmn.1 for ; Wed, 25 May 2016 05:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:organization :mime-version:content-transfer-encoding; bh=PcIwB6esm6CUovzZRAhn2BvNIntJjT2rUreCfYjZ+xY=; b=vGVtj15ONjL/5E35j3hLGRYgKAxRxYpLvOBjdMcfekpUjy1VyLrXkHA1aeMV4ma2Jr DWfP7p6t1w+DqyDNpUeI9BqD6OGizB2k2R9KB3FyEDaS+LOv7CNfB6Bygf26SGb8mLaj ZQ/SoCR3DS2oV1bRALsXUXeXKpChHi65T5K4PFDU1zxVHl+CIowVXwHBiBE0ZlpXRdY3 hHnluxDBBJt3ty4mxLbZklFY8iAFfrLml8/1yLRdwZ6YOjkXdVg1RAqsPazUQXhyNduG gDco3zlNlvOZM4jvNKIo29CRMLldr3Xhfpi21+64lVFdqUbTxiHYOsulzhOazocJS/1Y 5Ctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :organization:mime-version:content-transfer-encoding; bh=PcIwB6esm6CUovzZRAhn2BvNIntJjT2rUreCfYjZ+xY=; b=Dreguk3L/GoBz/IuaS0nTsxBcdqdEidKl2B0UKaIy+wHiYlZEEbJIT9qdko79O4oa+ QKkDIoE9rY4Zn4ZOKp6a+B4YOtHcTR/2c29F+svMjMSu2KDTsi4HsV7kpTKkURQHvhZV 1CQcfCmIGwcN4eK6wNGu5uTxHPjtPO796nQpTP4940tg5Gw7CIyAtsEiYXdg2AfKGhoL 2j/4CZTeL29Ly+aSTgAUO3N+APneIPlwVlVsQwBVQXGQqnuhsviUIj+vD3JFirQxIUcx 0XTLAOKuF+Yn7QlXVulJaX36vGw4GRYLRzvEOZRSUKx+6LLYR25Xg3Z3wxG8vr4ifsNr eSpA== X-Gm-Message-State: ALyK8tJXBFmkl+EmxVvbxMmWXfLQ9XDTF0cX5Zdn0w6M3mnCGnGxIJFIy0P69m5BB0JSRAFL X-Received: by 10.194.148.142 with SMTP id ts14mr3460938wjb.39.1464177768043; Wed, 25 May 2016 05:02:48 -0700 (PDT) Received: from [172.20.10.4] ([31.4.241.81]) by smtp.gmail.com with ESMTPSA id jd4sm8410877wjb.43.2016.05.25.05.02.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 05:02:47 -0700 (PDT) Message-ID: <1464177756.3277.18.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: int-dir@ietf.org, int-ads@ietf.org Date: Wed, 25 May 2016 14:02:36 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-multi-homed-host-06@ietf.org Subject: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 12:03:01 -0000 Hi, I am an assigned INT directorate reviewer for draft-ietf-6man-multi- homed-host-06.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/direc torate.html. Overall, the document is mature, well written and I find it useful. I do not see any reason to hold up publication. Some suggestions/comments follow: - Abstract: it talks about 'expected IPv6 behavior in a network that has more than one prefix'. I think the use of the word "network" might be misleading, because the scenarios covered are not limited to a host connected to a single multihomed network. Also a multihomed host connected to multiple networks is covered (as shown in Figure 2, right side). I think it would be good to use a different wording to be more inclusive of all the scenarios covered. - Section 1.1: expand "RA". - Section 1.1: it would be good to clarify a bit more the example of a host with a link-local-interface can have a default route pointing to that route. It is implicit that that host has some other interface with a routable address, but this is not explicitly mentioned and the example might not be easy to follow. - Section 3.1, Figure 3: is Bob connected to one single multihomed network or to two networks? In the figure it seems that is the latter, but the text refers to 'Bob's network is multihomed'. As in the abstract, the text is not completely clear. - Section 4: not sure it is necessary to mention that one of the authors' network setup is as described in the example. Thanks, Carlos From nobody Wed May 25 05:06:36 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21C12B01B for ; Wed, 25 May 2016 05:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSicd-VdlMy9 for ; Wed, 25 May 2016 05:06:29 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 2C54B12DACE for ; Wed, 25 May 2016 05:06:29 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a136so122016079wme.0 for ; Wed, 25 May 2016 05:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:organization :mime-version:content-transfer-encoding; bh=tgqDivGg+ebbkWsKwVyIEx3cV3CdGxhbOmwhiAr9KY0=; b=14zWAMr6gvMI6ejm0MsHxAdvwqo0I/wUX1Jx7DeDW5zT4kcqxdB8YLDRdiHojTJCxF +gegYVFhwDHAZoR/+VPb4cwgTIUWLFrBdNRhoPe+uT5E5F3hA/ZPnMyXbDfu8JkS88hD y/M3Z7k4XVemRrr/5bvFNm7tU1jZwoMkP2FpXD+MuxPsjbfjfYf7zFbBw4U1koON9Bl4 ADQcUJSLZpdhMbN+ekgLgeN6QDFkxnZ74NazKdK0Kze0QmklBhUVqb06Sjk4s4xI3Xah AbC47puEkbC/NfmdQS3vC0jq3NbE4Pk8946Ht82xvARW3CRisNm8x9TvXuQivpX2Bcd6 t2Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :organization:mime-version:content-transfer-encoding; bh=tgqDivGg+ebbkWsKwVyIEx3cV3CdGxhbOmwhiAr9KY0=; b=fNPDJxbDmlWg09+INLsWXMyBrwGHvzZPZn6KTTg9ahBhP2iasjgsn4Ee3CT6TBxopa XWtZwqTX91VgaF9egjATLbI59SLwfpZoB9d3bXxfTYQTVWWlq7Ao1UkFtWBEO1wBtuwX GIthSioyi17C0+5z3ihaxhnA1e56rlq+kQn0jLF5xGt0vFLus/FeDcPOR8HgA/iI7z+c W6ZfMZlR0/AoRzrbeeGnY/9YycNhlUwgJMKZJ81jVnDlA/UX2IGxGm3Kfp7kHsSOLjt1 qPqj3LIPiJlKMRXpuENI+ZVvH5zevsv4EIgWV60d4kMpGiRQhDcCx9Q+dLfw9Qr9dB5i bnHQ== X-Gm-Message-State: ALyK8tKBN4PniQtraaJnrG4ItiNA+g0uGSgB0Ym/8JrIyhRg2h1Cn6dXmzyKtC1tWHHdR9x1 X-Received: by 10.194.18.34 with SMTP id t2mr3441102wjd.180.1464177987592; Wed, 25 May 2016 05:06:27 -0700 (PDT) Received: from [172.20.10.4] ([31.4.241.81]) by smtp.gmail.com with ESMTPSA id jr8sm8462130wjb.15.2016.05.25.05.06.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 05:06:27 -0700 (PDT) Message-ID: <1464177974.3277.21.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: int-dir@ietf.org, int-ads@ietf.org Date: Wed, 25 May 2016 14:06:14 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-multi-homed-host@ietf.org Subject: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 12:06:35 -0000 (resending again because I use a wrong draft authors alias address, apologies) Hi, I am an assigned INT directorate reviewer for draft-ietf-6man-multi- homed-host-06.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/direc torate.html. Overall, the document is mature, well written and I find it useful. I do not see any reason to hold up publication. Some suggestions/comments follow: - Abstract: it talks about 'expected IPv6 behavior in a network that has more than one prefix'. I think the use of the word "network" might be misleading, because the scenarios covered are not limited to a host connected to a single multihomed network. Also a multihomed host connected to multiple networks is covered (as shown in Figure 2, right side). I think it would be good to use a different wording to be more inclusive of all the scenarios covered. - Section 1.1: expand "RA". - Section 1.1: it would be good to clarify a bit more the example of a host with a link-local-interface can have a default route pointing to that route. It is implicit that that host has some other interface with a routable address, but this is not explicitly mentioned and the example might not be easy to follow. - Section 3.1, Figure 3: is Bob connected to one single multihomed network or to two networks? In the figure it seems that is the latter, but the text refers to 'Bob's network is multihomed'. As in the abstract, the text is not completely clear. - Section 4: not sure it is necessary to mention that one of the authors' network setup is as described in the example. Thanks, Carlos From nobody Wed May 25 13:29:46 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B2A12DD1B; Wed, 25 May 2016 13:29:44 -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 8tOBoCd_f1L4; Wed, 25 May 2016 13:29:42 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 9D98E12DD0F; Wed, 25 May 2016 13:29:41 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id b124so21910325pfb.0; Wed, 25 May 2016 13:29:41 -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=27J+WbmhY3keeMIcfLmn2PiF7+a5iBHmdlHzEE8M7sg=; b=UE7YLSQke7Bwgfp4csgHXOaW0gUmmqvB/eb5TW8W8NGjY3/C6qFUu6hYbzjjOHijcZ +sYj2EXhBLslzlNTZa9WnVakCyqAvWz67vGvpIRjo2FG0Y70FuHqjc7r9WoonCehVJ3W wdUgonHTDxpO6lvWhkwgjavGcOBrKCsPC7ldRDHcvqPPXcJi41gOG0BfNmIRFzP3Q3kv eQFPysjdPI4+x0Nrsa3FUtBdK6ImHJIrV7SwuZSR61jxt3uB0Hkyd0flXp+tbE2kvQjz IddZvCfV53cy8ISjyeTyUKBUHirPA/sEzOprplsUu9H61Jr+KIRtKX+G5zIJWQdR6f9c nDmA== 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=27J+WbmhY3keeMIcfLmn2PiF7+a5iBHmdlHzEE8M7sg=; b=foAFNoBTrgdN8JgVHotqnHPkTJdZ6eUYO4VHsf6yRoS/Pw22/vLhwZvJfCovMbiIHn a0b1RmjwqIt37yA59hUxn2lGKvu9Z3pmKVIH5WozdeupdKxN8A2fRBoFRTO56OEb5qec RjNOQHNoSGu1hLRhJTSy5Qtwe4hD2AyPhkAeb3FjDxg4msOaEkfcMALG5gaPTL1KLYfo /SlUdwFzcubFnNEmaTTc24zCBZ83UmJeBJRlLi/TjUvhuYIThANu3eb6f/2IqJkJsK9I 5sVbJvzrUz5vNpVeX7aOEiCznzg842ZXGZ/bpE6rDg3ofoardrPBTrU/8/CUx0QACN17 rH1g== X-Gm-Message-State: ALyK8tIaJ1U9ct1/VaGdgDoPe+dvZwdETcWO4OciibP4UgAqavlSm1ygJ23/TKR6PU0F+A== X-Received: by 10.98.67.150 with SMTP id l22mr8648321pfi.85.1464208181035; Wed, 25 May 2016 13:29:41 -0700 (PDT) Received: from ?IPv6:2406:e007:61a8:1:e0e0:7916:dfab:ea1c? ([2406:e007:61a8:1:e0e0:7916:dfab:ea1c]) by smtp.gmail.com with ESMTPSA id i75sm496746pfj.51.2016.05.25.13.29.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 13:29:40 -0700 (PDT) To: cjbc@it.uc3m.es, int-dir@ietf.org, int-ads@ietf.org References: <1464177974.3277.21.camel@it.uc3m.es> From: Brian E Carpenter Organization: University of Auckland Message-ID: <94edf13a-9d49-06b4-a5fc-8db1ca43dc39@gmail.com> Date: Thu, 26 May 2016 08:29:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <1464177974.3277.21.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-6man-multi-homed-host@ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 20:29:44 -0000 On 26/05/2016 00:06, Carlos Jes=C3=BAs Bernardos Cano wrote: > (resending again because I use a wrong draft authors alias address, > apologies) Thanks for the review. I guess we will wait for instructions before updating the draft. My comments below: >=20 > Hi, >=20 > I am an assigned INT directorate reviewer for draft-ietf-6man-multi- > homed-host-06.txt. These comments were written > primarily for the benefit of the Internet Area Directors. Document > editors and shepherd(s) should treat these comments just like they > would treat comments from any other IETF contributors and resolve them > along with any other Last Call comments that have been received. For > more details on the INT Directorate, see http://www.ietf.org/iesg/direc= > torate.html. >=20 > Overall, the document is mature, well written and I find it useful. I > do not see any reason to hold up publication. >=20 > Some suggestions/comments follow: >=20 > - Abstract: it talks about 'expected IPv6 behavior in a network that > has more than one prefix'. I think the use of the word "network" might > be misleading, because the scenarios covered are not limited to a host > connected to a single multihomed network. Also a multihomed host > connected to multiple networks is covered (as shown in Figure 2, right > side). I think it would be good to use a different wording to be more > inclusive of all the scenarios covered. Well, it all depends on how you interpret the word "network" but yes, we could use a more neutral word like "scenario". > - Section 1.1: expand "RA". OK > - Section 1.1: it would be good to clarify a bit more the example of a > host with a link-local-interface can have a default route pointing to > that route. It is implicit that that host has some other interface with= > a routable address, but this is not explicitly mentioned and the > example might not be easy to follow. I'll leave Fred to disentangle that; reading it again, I am confused myself... >=20 > - Section 3.1, Figure 3: is Bob connected to one single multihomed > network or to two networks? In the figure it seems that is the latter, > but the text refers to 'Bob's network is multihomed'. As in the > abstract, the text is not completely clear. "Bob's network" consists at least of Bob (the computer), 2 routers (Bob-A and Bob-B), and the links between them. If we weren't limited by ASCII art, that would be made clear by a blob containing them. It would be pretty ugly to add it in ASCII art, something like: . . . . . . . . . . . . / \ . +---------+ | .= ( ISP A ) - + Bob-A +--+ +-----+ .= +-------+ / . +---------+ +--+ | .= | | / . | | | .= | Alice +--/--( The Internet ) . | Bob | .= | | \ . | | | .= +-------+ \ . +---------+ +--+ | .= ( ISP B ) - + Bob-B +--+ +-----+ .= . +---------+ | .= \ . . . . . . . . . . . . /= >=20 > - Section 4: not sure it is necessary to mention that one of the > authors' network setup is as described in the example. OK Regards Brian From nobody Sun May 29 08:22:49 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B665712B020 for ; Sun, 29 May 2016 08:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az9679bZIXNM for ; Sun, 29 May 2016 08:22:46 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D437C12D09F for ; Sun, 29 May 2016 08:22:42 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n129so53758444wmn.1 for ; Sun, 29 May 2016 08:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=1aPZ9RGuA7lEA8tgtPSTRGUpDfqNU0yXKtluFGbLeX8=; b=RBwLxMkF8RYd+Mb12sKsNrT13SWIHCJXPSjMwnTz7/V892KYIkSyt4LaYXwdoq1mdi keOdcbRJ2ipEABwGx9aPOCfLPlNV/xt/i9ngvTjM8B6z3NCmigsMjsn+RZdYf0VtO4oA lIxHWXl4if+SYxSZOxuDX4C5K6Ex8w5eDpvWLjP6W4DcErador7LRGckM0dbMgflWPXV xDiQtC1L8jNXR5M29XekjVXZZ8wvgHuWTDclnujwyClCfI3PZCV+ptcR4boPvY+FpQJ7 D9t0nQk0iNhauuRQT7/HY6oT3irst7UvbYAC1gM+DbJ8Tfa5bDN0ROzTLpN0tWm+mdvC i/jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=1aPZ9RGuA7lEA8tgtPSTRGUpDfqNU0yXKtluFGbLeX8=; b=BG7tMFEmZIv0gphVBOhbiLSz4Fxmnq9Wswi8tynf/edbdyf3JNK7YtfIoqrvg65HHi 9rx9F5cuNruEsHdahsCH+6GY3XcOrErBHRiboA7MH8iZ0ar+h/rRLLZWnpyF2djoPZul +bLUUjio/Eu/6lh5kClTZyVwz/h38qV0X1c7ntTbcDG/fUX9xQd7/0efEheofdIxTbUG fpGYo4tfocKOlLRg0IfrXrBzkR4tzSXJ/rlvhTpjbWqn6Y9CEuBxxGlfzGWzJUhk41Jh bQZrLqKYXbxxrWdbiLUzaOLqvHyIsBCTAM5r8imo4dlHdHohunhOZktU6v7R8AQqzebj dNfg== X-Gm-Message-State: ALyK8tL8QOUNlXcSMDA0ZSoilzNWPcn1+5XyTHMHGUKph3vVC3nXQAnJKChDvTJVNGyvMRZK X-Received: by 10.28.137.210 with SMTP id l201mr6597558wmd.31.1464535361148; Sun, 29 May 2016 08:22:41 -0700 (PDT) Received: from cjbc_dell.lan (85.251.161.16.dyn.user.ono.com. [85.251.161.16]) by smtp.gmail.com with ESMTPSA id 75sm6959120wml.15.2016.05.29.08.22.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 May 2016 08:22:40 -0700 (PDT) Message-ID: <1464535359.4206.66.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian E Carpenter , int-dir@ietf.org, int-ads@ietf.org Date: Sun, 29 May 2016 17:22:39 +0200 In-Reply-To: <94edf13a-9d49-06b4-a5fc-8db1ca43dc39@gmail.com> References: <1464177974.3277.21.camel@it.uc3m.es> <94edf13a-9d49-06b4-a5fc-8db1ca43dc39@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-6man-multi-homed-host@ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 15:22:48 -0000 Hi Brian, Thanks for your comments. Some inline below. On Thu, 2016-05-26 at 08:29 +1200, Brian E Carpenter wrote: > On 26/05/2016 00:06, Carlos Jesús Bernardos Cano wrote: > > > > (resending again because I use a wrong draft authors alias address, > > apologies) > Thanks for the review. I guess we will wait for instructions before > updating the draft. My comments below: > > > > > > > Hi, > > > > I am an assigned INT directorate reviewer for draft-ietf-6man- > > multi- > > homed-host-06.txt. These comments were written > > primarily for the benefit of the Internet Area Directors. Document > > editors and shepherd(s) should treat these comments just like they > > would treat comments from any other IETF contributors and resolve > > them > > along with any other Last Call comments that have been received. > > For > > more details on the INT Directorate, see http://www.ietf.org/iesg/d > > irec > > torate.html. > > > > Overall, the document is mature, well written and I find it useful. > > I > > do not see any reason to hold up publication. > > > > Some suggestions/comments follow: > > > > - Abstract: it talks about 'expected IPv6 behavior in a network > > that > > has more than one prefix'. I think the use of the word "network" > > might > > be misleading, because the scenarios covered are not limited to a > > host > > connected to a single multihomed network. Also a multihomed host > > connected to multiple networks is covered (as shown in Figure 2, > > right > > side). I think it would be good to use a different wording to be > > more > > inclusive of all the scenarios covered. > Well, it all depends on how you interpret the word "network" but yes, > we could use a more neutral word like "scenario". [Carlos] OK. If "scenario" is used, then the text can be reviewed to ensure that "multihomed host" and "multihomed network" are properly used (if used). > > > > > - Section 1.1: expand "RA". > OK > > > > > - Section 1.1: it would be good to clarify a bit more the example > > of a > > host with a link-local-interface can have a default route pointing > > to > > that route. It is implicit that that host has some other interface > > with > > a routable address, but this is not explicitly mentioned and the > > example might not be easy to follow. > I'll leave Fred to disentangle that; reading it again, I am confused > myself... [Carlos] OK. > > > > > > > - Section 3.1, Figure 3: is Bob connected to one single multihomed > > network or to two networks? In the figure it seems that is the > > latter, > > but the text refers to 'Bob's network is multihomed'. As in the > > abstract, the text is not completely clear. > "Bob's network" consists at least of Bob (the computer), 2 routers > (Bob-A and Bob-B), and the links between them. If we weren't limited [Carlos] OK, then I think it's worth clarifying that in the text. Thanks, Carlos > by ASCII art, that would be made clear by a blob containing them. > It would be pretty ugly to add it in ASCII art, something like: > >                                                 . . . . . . . . . . . > . >                                                /                      >   \ >                                               . +--------- > +  |          . >                                     ( ISP A ) - +  Bob-A  +--+  +-- > ---+ . >     +-------+                      /          . +---------+  + > --+     | . >     |       |                     /           .              |  |     >  | . >     | Alice +--/--( The Internet )            .                 | Bob > | . >     |       |                     \           .              |  |     >  | . >     +-------+                      \          . +---------+  + > --+     | . >                                     ( ISP B ) - +  Bob-B  +--+  +-- > ---+ . >                                               . +--------- > +  |          . >                                               \ . . . . . . . . . . . > . / > > > > > > > - Section 4: not sure it is necessary to mention that one of the > > authors' network setup is as described in the example. > OK > > Regards >     Brian >