From nobody Mon Dec 7 13:09:21 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B581A88D2 for ; Mon, 7 Dec 2015 13:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD2w_bu6JKmO for ; Mon, 7 Dec 2015 13:09:19 -0800 (PST) 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 EBD8D1A88CF for ; Mon, 7 Dec 2015 13:09:18 -0800 (PST) Received: by qgec40 with SMTP id c40so154613454qge.2 for ; Mon, 07 Dec 2015 13:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4FZn7nrF9nf5bzyk2B4a4KmWzoqofHGx9dT4b+IMVuU=; b=fnP8bL1qYuCCk8gRDTlI4E2GdHRolLbXRq+idLNU8pKK/HSb41FWi9hXObJG0eQh/+ GVdHzQqP9pQ/KG027ROTSQw9JVuhzHI0lFryRqqPOL4Duad8OV1bBnqkISrxQN/OykfK Y+KlVvx38eimuNdJry6nDNVinWa+OieldLQDc+pqFcnwTlCoK+TLXe0zuFncwtHB7tJ1 N/p/1Ic0nFrXInU4PicC/egBsn3y4L5yKM1OsjTQoChJ9Nt8geKmdWZtcBEie80EIyXP dDVOg2zyLz5/KKPayohx6aCR9yMmqccsU2aV2FsU3OYUTDxHAQ18EpHn+GJwM5m7QbYY PeFA== X-Received: by 10.140.232.65 with SMTP id d62mr41614265qhc.27.1449522558232; Mon, 07 Dec 2015 13:09:18 -0800 (PST) Received: from new-host-3.home (pool-108-7-232-158.bstnma.fios.verizon.net. [108.7.232.158]) by smtp.gmail.com with ESMTPSA id e11sm9301653qkb.39.2015.12.07.13.09.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Dec 2015 13:09:17 -0800 (PST) From: Margaret Wasserman X-Google-Original-From: Margaret Wasserman Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) In-Reply-To: Date: Mon, 7 Dec 2015 16:09:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <22D45405-A111-47D7-A0EC-6C78776FF0DF@gmail.com> References: To: Hui Deng X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Concensus call on host behavior of MPVD NDP document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 21:09:21 -0000 There was some discussion during the API segment that we might want to = have a separate document describing the behavior of MIF hosts. I, = personally, would be in favor of publishing that document (it might be = called "MIF Host Requirements" or something similar), but I do not think = that we should describe that behavior in the different MPVD-related = mechanism documents. Margaret On Nov 22, 2015, at 8:09 AM, Hui Deng wrote: > Hello all > =20 > There was one concensus call on whether MPVD NDP document should not = contain what the host does: > 8 people think it should not > 0 people think it should > https://www.ietf.org/id/draft-ietf-mif-mpvd-ndp-support-02.txt > =20 > Here we confirm in the mailing list again > =20 > cochairs > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From nobody Mon Dec 7 13:24:49 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A01A8ACC for ; Mon, 7 Dec 2015 13:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc5Wx9RQucCz for ; Mon, 7 Dec 2015 13:24:47 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6F41A8937 for ; Mon, 7 Dec 2015 13:24:46 -0800 (PST) Received: by qgcc31 with SMTP id c31so84378qgc.3 for ; Mon, 07 Dec 2015 13:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=/Fh6CiVwtSc6B1L5rW9zrPkhQTOoLtzjT2vkTRz612o=; b=ihWLC00n0Dw44+saasmgcs5RIEiIf9Gcw6gLi9t6TRVw+HTzOxIqYcQUIwlORboWcC NfQN08W/N25HI90i8H55vQ8dOhAMNktwIKe9tutLqycL63J7wFR/ilZ7IL0KCTlcTpDK rZfoY7QombCQO3wdpEvW0IjmlfBEh3XX4fp+Q0yN4tn9K6amq3pE0Ks7Fyx4ktXrFJz8 gOdQvxqPgcSuDgoD7D3VCcAT4GtZQlCoYt6iVnYrQajPWynvCtH1jZV77xloWkVyvVZR 4bHheJpzjBO27/vrTi4xSV+A8O3pfRNiCoB/TpMFbUsVQQ7bocU29PICKNwg/HIuTMU1 rNJw== X-Received: by 10.140.250.70 with SMTP id v67mr42661187qhc.43.1449523486009; Mon, 07 Dec 2015 13:24:46 -0800 (PST) Received: from new-host-3.home (pool-108-7-232-158.bstnma.fios.verizon.net. [108.7.232.158]) by smtp.gmail.com with ESMTPSA id r83sm12372314qhc.8.2015.12.07.13.24.44 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Dec 2015 13:24:45 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1DF5871E-80A1-46D6-BA16-0B0CC4E1BEBC@gmail.com> Date: Mon, 7 Dec 2015 16:24:43 -0500 To: "mif@ietf.org List" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Subject: [mif] Microsoft IPR Claim on MIF API Document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 21:24:48 -0000 FYI -- As of 5-December-2015, Microsoft has issued an IPR claim regarding the = MIF API Document discussed at our last meeting = (draft-kline-mif-mpvd-api-reqs). The IPR claim can be found here: http://datatracker.ietf.org/ipr/2722/ The claim is related to US Patent No. 7,568,236 granted July 28, 2009. The terms are RAND with the possibility of a royalty-free license. I have not read the patent, so I have no opinion regarding its = relevance. I just thought the WG should know about this ASAP. Margaret From nobody Tue Dec 8 03:47:15 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490141B2C13 for ; Tue, 8 Dec 2015 03:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2N_Wy8FtFGd for ; Tue, 8 Dec 2015 03:47:11 -0800 (PST) Received: from COL004-OMC2S10.hotmail.com (col004-omc2s10.hotmail.com [65.55.34.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C191B2C0C for ; Tue, 8 Dec 2015 03:47:11 -0800 (PST) Received: from COL125-W38 ([65.55.34.71]) by COL004-OMC2S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 8 Dec 2015 03:47:11 -0800 X-TMN: [/twUtZfM2uwFdQs9gimCEoNWSc9LN7ges8f8vM7KHIM=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b5c63ab9-021a-4a1b-9118-7fed2cdbac0c_" From: Hui Deng To: "mif@ietf.org" , Margaret Date: Tue, 8 Dec 2015 19:47:10 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2015 11:47:11.0455 (UTC) FILETIME=[2CB476F0:01D131AE] Archived-At: Subject: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 11:47:14 -0000 --_b5c63ab9-021a-4a1b-9118-7fed2cdbac0c_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQogDQpXZSBoYXZlIHR3byB3ZWVrcyBXRyBsYXN0IGNhbGwgZm9yIGJlbG93IGRv Y3VtZW50Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1jaGVuLW1pZi1o YXBweS1leWViYWxscy1leHRlbnNpb24tMDQudHh0DQogDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzIHRvIHRoaXMgdGhyZWFkLg0KVGhpcyBXR0xDIHdpbGwgZW5kIG9uIERlYy4gMjJuZC4NCiAN CkJlc3QgcmVnYXJkcywNCiANCkNvY2hhaXJzLg0KIA0KIAkJIAkgICAJCSAg --_b5c63ab9-021a-4a1b-9118-7fed2cdbac0c_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5XZSBoYXZlIHR3 byB3ZWVrcyBXRyZuYnNwO2xhc3QgY2FsbCBmb3ImbmJzcDtiZWxvdyBkb2N1bWVudDo8QlI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1jaGVuLW1pZi1oYXBw eS1leWViYWxscy1leHRlbnNpb24tMDQudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZl L2lkL2RyYWZ0LWNoZW4tbWlmLWhhcHB5LWV5ZWJhbGxzLWV4dGVuc2lvbi0wNC50eHQ8L2E+PEJS PiZuYnNwOzxCUj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgdGhyZWFkLjxCUj5U aGlzIFdHTEMgd2lsbCBlbmQgb24gRGVjLiAyMm5kLjxCUj4mbmJzcDs8QlI+QmVzdCByZWdhcmRz LDxCUj4mbmJzcDs8QlI+Q29jaGFpcnMuPEJSPiZuYnNwOzxCUj4gCQkgCSAgIAkJICA8L2Rpdj48 L2JvZHk+DQo8L2h0bWw+ --_b5c63ab9-021a-4a1b-9118-7fed2cdbac0c_-- From nobody Tue Dec 8 03:50:45 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386DE1B2C4F; Tue, 8 Dec 2015 03:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhgw62ImrAnQ; Tue, 8 Dec 2015 03:50:41 -0800 (PST) Received: from COL004-OMC2S6.hotmail.com (col004-omc2s6.hotmail.com [65.55.34.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C50F1B2C4A; Tue, 8 Dec 2015 03:50:41 -0800 (PST) Received: from COL125-W21 ([65.55.34.71]) by COL004-OMC2S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 8 Dec 2015 03:50:41 -0800 X-TMN: [K1MFP3NRiZFQr86tCKm4600/RlcwvHVcKVVBxiI+Rsw=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c8da7663-50a8-405b-a293-dee9d473fccb_" From: Hui Deng To: "mif@ietf.org" , "homenet@ietf.org" Date: Tue, 8 Dec 2015 19:50:40 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2015 11:50:41.0070 (UTC) FILETIME=[A9A52CE0:01D131AE] Archived-At: Subject: [mif] 6man WG document about multi homed host X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 11:50:43 -0000 --_c8da7663-50a8-405b-a293-dee9d473fccb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQogDQpJIGhhcHBlbiB0byBzZWUgdGhpcyBkb2N1bWVudCB3aGljaCBoYXMgYmVl biBhZG9wdGVkIGJ5IDZNQU4sIGFuZCBpcyBjbG9zZSB0byBNSUYgYW5kIEhvbWVuZXQncyB3b3Jr IHRvZGF5Lg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9t ZWQtaG9zdC0wMi50eHQNCiANCkp1c3Qgd2FudCB0byBzZW5kIGEgcmVtaW5kIGFuZCBwbGVhc2Ug Z28gYW5kIHJlYWQgdGhlIGRvY3VtZW50DQpCZXN0IHJlZ2FyZHMsDQogDQpERU5HIEh1aQ0KIA0K IAkJIAkgICAJCSAg --_c8da7663-50a8-405b-a293-dee9d473fccb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5JIGhhcHBlbiB0 byBzZWUgdGhpcyBkb2N1bWVudCB3aGljaCBoYXMgYmVlbiBhZG9wdGVkIGJ5IDZNQU4sIGFuZCBp cyBjbG9zZSB0byBNSUYgYW5kIEhvbWVuZXQncyB3b3JrIHRvZGF5LjxCUj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBmb250LXNp emU6IDEwLjVwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1m b250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mYXJl YXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5v ci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tYmlk aS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBOyc+PGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9z dC0wMi50eHQiPjxmb250IGNvbG9yPSIjMDAwMGZmIj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWlldGYtNm1hbi1tdWx0aS1ob21lZC1ob3N0LTAyLnR4dDwvZm9udD48L2E+PC9zcGFuPjxC Uj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOyBmb250LXNpemU6IDEwLjVwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1z by1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IMvOzOU7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10 aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcg Um9tYW4iOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6 IEFSLVNBOyc+PC9zcGFuPiZuYnNwOzxCUj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9J2ZvbnQt ZmFtaWx5OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDEwLjVwdDsgbXNvLWJp ZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsg bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1p bm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGkt Zm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5v ci1iaWRpOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBa SC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBOyc+SnVzdCB3YW50IHRvIHNlbmQgYSByZW1p bmQgYW5kIHBsZWFzZSBnbyBhbmQgcmVhZCB0aGUgZG9jdW1lbnQ8L3NwYW4+PEJSPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0nZm9udC1mYW1pbHk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IGZv bnQtc2l6ZTogMTAuNXB0OyBtc28tYmlkaS1mb250LXNpemU6IDExLjBwdDsgbXNvLWFzY2lpLXRo ZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNv LWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6 IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogIlRpbWVzIE5ldyBSb21hbiI7IG1z by1iaWRpLXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0E7Jz5C ZXN0IHJlZ2FyZHMsPC9zcGFuPjxCUj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9J2ZvbnQtZmFt aWx5OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDEwLjVwdDsgbXNvLWJpZGkt Zm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9y LWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28tYmlkaS10aGVtZS1mb250OiBtaW5vci1i aWRpOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1D TjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBOyc+PC9zcGFuPiZuYnNwOzxCUj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9J2ZvbnQtZmFtaWx5OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBmb250 LXNpemU6IDEwLjVwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVt ZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1m YXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1oYW5zaS10aGVtZS1mb250OiBt aW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iOyBtc28t YmlkaS10aGVtZS1mb250OiBtaW5vci1iaWRpOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1z by1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBOyc+REVO RyBIdWk8L3NwYW4+PEJSPiZuYnNwOzxCUj4gCQkgCSAgIAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0 bWw+ --_c8da7663-50a8-405b-a293-dee9d473fccb_-- From nobody Tue Dec 8 04:45:43 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E371ACEAF for ; Tue, 8 Dec 2015 04:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkh0EjE0sdVU for ; Tue, 8 Dec 2015 04:45:36 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 E0B661ACE72 for ; Tue, 8 Dec 2015 04:45:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3A755A3; Tue, 8 Dec 2015 13:45:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1449578732; bh=t+BtlhZuznqp4cxOr/Nv72Es2LAfXCcMFPjLe71dC60=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FDgRQ7vjqDtAoPu6gSM5P5xlarDpgAmpccah6gryzI4F1gMLloRQ0cd1OsMR1jCsB N/SsPvGZX0aHXs9shemk31UEJULPBG4efUA0dobHK3r912h80+hmaAoihgI6Jpxa2V L/0Z8h5Lyknwy+N1V3NUi0R4tgwJB5+SPmZTA0qs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 36884A2; Tue, 8 Dec 2015 13:45:32 +0100 (CET) Date: Tue, 8 Dec 2015 13:45:32 +0100 (CET) From: Mikael Abrahamsson To: Hui Deng In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Margaret , "mif@ietf.org" Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 12:45:42 -0000 On Tue, 8 Dec 2015, Hui Deng wrote: > Hello all > > We have two weeks WG last call for below document: > https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt > > Please send your comments to this thread. > This WGLC will end on Dec. 22nd. The above link is wrong, it links to a 3 year old revision of the document. https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 seems to be the latest. It's also my opinion that I would not want this document sent off until we have decided what to do with the rest of the MIF documents, it's my opinion that the WGLC call is premature. I believe that MIF-HE is important, but I also think we should be more ready with the rest of the architecture before we ship this document off. Some other comments: I would like to see "3/4G interface" replaced with "mobile data interface" or "3GPP interface" or something else. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Dec 8 05:04:10 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6A1B2D6A for ; Tue, 8 Dec 2015 05:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxE-SvZmmhpZ for ; Tue, 8 Dec 2015 05:04:07 -0800 (PST) Received: from COL004-OMC1S5.hotmail.com (col004-omc1s5.hotmail.com [65.55.34.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D641B2D80 for ; Tue, 8 Dec 2015 05:03:58 -0800 (PST) Received: from COL125-W6 ([65.55.34.8]) by COL004-OMC1S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 8 Dec 2015 05:03:57 -0800 X-TMN: [xY5FmQX2CMN4iGm/YYG/OELQzkpH8qzyKt03JWaNlHw=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_dc816353-05db-459c-8c38-faa3db7677cc_" From: Hui Deng To: Mikael Abrahamsson Date: Tue, 8 Dec 2015 21:03:57 +0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2015 13:03:57.0732 (UTC) FILETIME=[E6428E40:01D131B8] Archived-At: Cc: Margaret , "mif@ietf.org" Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 13:04:09 -0000 --_dc816353-05db-459c-8c38-faa3db7677cc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QXBvbG9naXplIGZvciBtaXN0YWtlLCB0aGFua3MgYSBsb3QgZm9yIE1pa2FlbCdzIGNvcnJlY3Qs DQogDQpQbGVhc2UgZ28gd2l0aCB0aGF0IGxpbmsNCiANCkJlc3QgcmVnYXJkcywNCiANCkRFTkcg SHVpIA0KIA0KPiBEYXRlOiBUdWUsIDggRGVjIDIwMTUgMTM6NDU6MzIgKzAxMDANCj4gRnJvbTog c3dtaWtlQHN3bS5wcC5zZQ0KPiBUbzogZGVuZ2h1aTAyQGhvdG1haWwuY29tDQo+IENDOiBtaWZA aWV0Zi5vcmc7IG1hcmdhcmV0dzQyQGdtYWlsLmNvbQ0KPiBTdWJqZWN0OiBSZTogW21pZl0gV0dM QyBmb3IgTUlGIGhhcHB5IGV5ZWJhbGxzDQo+IA0KPiBPbiBUdWUsIDggRGVjIDIwMTUsIEh1aSBE ZW5nIHdyb3RlOg0KPiANCj4gPiBIZWxsbyBhbGwNCj4gPg0KPiA+IFdlIGhhdmUgdHdvIHdlZWtz IFdHIGxhc3QgY2FsbCBmb3IgYmVsb3cgZG9jdW1lbnQ6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvYXJjaGl2ZS9pZC9kcmFmdC1jaGVuLW1pZi1oYXBweS1leWViYWxscy1leHRlbnNpb24tMDQu dHh0DQo+ID4NCj4gPiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgdGhyZWFkLg0K PiA+IFRoaXMgV0dMQyB3aWxsIGVuZCBvbiBEZWMuIDIybmQuDQo+IA0KPiBUaGUgYWJvdmUgbGlu ayBpcyB3cm9uZywgaXQgbGlua3MgdG8gYSAzIHllYXIgb2xkIHJldmlzaW9uIG9mIHRoZSANCj4g ZG9jdW1lbnQuDQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t aWYtaGFwcHktZXllYmFsbHMtZXh0ZW5zaW9uLTA3IA0KPiBzZWVtcyB0byBiZSB0aGUgbGF0ZXN0 Lg0KPiANCj4gSXQncyBhbHNvIG15IG9waW5pb24gdGhhdCBJIHdvdWxkIG5vdCB3YW50IHRoaXMg ZG9jdW1lbnQgc2VudCBvZmYgdW50aWwgd2UgDQo+IGhhdmUgZGVjaWRlZCB3aGF0IHRvIGRvIHdp dGggdGhlIHJlc3Qgb2YgdGhlIE1JRiBkb2N1bWVudHMsIGl0J3MgbXkgDQo+IG9waW5pb24gdGhh dCB0aGUgV0dMQyBjYWxsIGlzIHByZW1hdHVyZS4gSSBiZWxpZXZlIHRoYXQgTUlGLUhFIGlzIA0K PiBpbXBvcnRhbnQsIGJ1dCBJIGFsc28gdGhpbmsgd2Ugc2hvdWxkIGJlIG1vcmUgcmVhZHkgd2l0 aCB0aGUgcmVzdCBvZiB0aGUgDQo+IGFyY2hpdGVjdHVyZSBiZWZvcmUgd2Ugc2hpcCB0aGlzIGRv Y3VtZW50IG9mZi4NCj4gDQo+IFNvbWUgb3RoZXIgY29tbWVudHM6DQo+IA0KPiBJIHdvdWxkIGxp a2UgdG8gc2VlICIzLzRHIGludGVyZmFjZSIgcmVwbGFjZWQgd2l0aCAibW9iaWxlIGRhdGEgaW50 ZXJmYWNlIiANCj4gb3IgIjNHUFAgaW50ZXJmYWNlIiBvciBzb21ldGhpbmcgZWxzZS4NCj4gDQo+ IC0tIA0KPiBNaWthZWwgQWJyYWhhbXNzb24gICAgZW1haWw6IHN3bWlrZUBzd20ucHAuc2UNCiAJ CSAJICAgCQkgIA== --_dc816353-05db-459c-8c38-faa3db7677cc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+QXBvbG9naXplIGZvciBtaXN0YWtlLCB0aGFua3MgYSBs b3QgZm9yIE1pa2FlbCdzIGNvcnJlY3QsPEJSPiZuYnNwOzxCUj5QbGVhc2UgZ28gd2l0aCB0aGF0 IGxpbms8QlI+Jm5ic3A7PEJSPkJlc3QgcmVnYXJkcyw8QlI+Jm5ic3A7PEJSPkRFTkcgSHVpJm5i c3A7PEJSPjxiciAvPiZuYnNwOzxCUj48ZGl2Pj4gRGF0ZSYjNTg7IFR1ZSwgOCBEZWMgMjAxNSAx MyYjNTg7NDUmIzU4OzMyICYjNDM7MDEwMDxicj4+IEZyb20mIzU4OyBzd21pa2UmIzY0O3N3bS5w cC5zZTxicj4+IFRvJiM1ODsgZGVuZ2h1aTAyJiM2NDtob3RtYWlsLmNvbTxicj4+IENDJiM1ODsg bWlmJiM2NDtpZXRmLm9yZyYjNTk7IG1hcmdhcmV0dzQyJiM2NDtnbWFpbC5jb208YnI+PiBTdWJq ZWN0JiM1ODsgUmUmIzU4OyAmIzkxO21pZiYjOTM7IFdHTEMgZm9yIE1JRiBoYXBweSBleWViYWxs czxicj4+IDxicj4+IE9uIFR1ZSwgOCBEZWMgMjAxNSwgSHVpIERlbmcgd3JvdGUmIzU4Ozxicj4+ IDxicj4+ICYjNjI7IEhlbGxvIGFsbDxicj4+ICYjNjI7PGJyPj4gJiM2MjsgV2UgaGF2ZSB0d28g d2Vla3MgV0cgbGFzdCBjYWxsIGZvciBiZWxvdyBkb2N1bWVudCYjNTg7PGJyPj4gJiM2MjsgaHR0 cHMmIzU4Oy8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtY2hlbi1taWYtaGFwcHktZXll YmFsbHMtZXh0ZW5zaW9uLTA0LnR4dDxicj4+ICYjNjI7PGJyPj4gJiM2MjsgUGxlYXNlIHNlbmQg eW91ciBjb21tZW50cyB0byB0aGlzIHRocmVhZC48YnI+PiAmIzYyOyBUaGlzIFdHTEMgd2lsbCBl bmQgb24gRGVjLiAyMm5kLjxicj4+IDxicj4+IFRoZSBhYm92ZSBsaW5rIGlzIHdyb25nLCBpdCBs aW5rcyB0byBhIDMgeWVhciBvbGQgcmV2aXNpb24gb2YgdGhlIDxicj4+IGRvY3VtZW50Ljxicj4+ IDxicj4+IGh0dHBzJiM1ODsvL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1taWYtaGFw cHktZXllYmFsbHMtZXh0ZW5zaW9uLTA3IDxicj4+IHNlZW1zIHRvIGJlIHRoZSBsYXRlc3QuPGJy Pj4gPGJyPj4gSXQmIzM5O3MgYWxzbyBteSBvcGluaW9uIHRoYXQgSSB3b3VsZCBub3Qgd2FudCB0 aGlzIGRvY3VtZW50IHNlbnQgb2ZmIHVudGlsIHdlIDxicj4+IGhhdmUgZGVjaWRlZCB3aGF0IHRv IGRvIHdpdGggdGhlIHJlc3Qgb2YgdGhlIE1JRiBkb2N1bWVudHMsIGl0JiMzOTtzIG15IDxicj4+ IG9waW5pb24gdGhhdCB0aGUgV0dMQyBjYWxsIGlzIHByZW1hdHVyZS4gSSBiZWxpZXZlIHRoYXQg TUlGLUhFIGlzIDxicj4+IGltcG9ydGFudCwgYnV0IEkgYWxzbyB0aGluayB3ZSBzaG91bGQgYmUg bW9yZSByZWFkeSB3aXRoIHRoZSByZXN0IG9mIHRoZSA8YnI+PiBhcmNoaXRlY3R1cmUgYmVmb3Jl IHdlIHNoaXAgdGhpcyBkb2N1bWVudCBvZmYuPGJyPj4gPGJyPj4gU29tZSBvdGhlciBjb21tZW50 cyYjNTg7PGJyPj4gPGJyPj4gSSB3b3VsZCBsaWtlIHRvIHNlZSAmIzM0OzMvNEcgaW50ZXJmYWNl JiMzNDsgcmVwbGFjZWQgd2l0aCAmIzM0O21vYmlsZSBkYXRhIGludGVyZmFjZSYjMzQ7IDxicj4+ IG9yICYjMzQ7M0dQUCBpbnRlcmZhY2UmIzM0OyBvciBzb21ldGhpbmcgZWxzZS48YnI+PiA8YnI+ PiAtLSA8YnI+PiBNaWthZWwgQWJyYWhhbXNzb24gICAgZW1haWwmIzU4OyBzd21pa2UmIzY0O3N3 bS5wcC5zZTxicj48L2Rpdj4gCQkgCSAgIAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_dc816353-05db-459c-8c38-faa3db7677cc_-- From nobody Tue Dec 8 17:28:16 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7401A893E for ; Mon, 7 Dec 2015 13:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHb6B81n-XmL for ; Mon, 7 Dec 2015 13:14:37 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832A21A893C for ; Mon, 7 Dec 2015 13:14:37 -0800 (PST) Received: by qgeb1 with SMTP id b1so156346685qge.1 for ; Mon, 07 Dec 2015 13:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bQRcizQw7YhvSed3x1ZSk19s5woF228CuVNtFFM3FUA=; b=zZImKQE48lgUFg0bD4gLZc1Xq86coNI3TNQ6Ipv1wxyWJa84n9Aa/Y4qdrSltldp0O GJSiRR1bK5nrpiLL2WfLNG0KlGeBvSoAV5Tn2wRC2x16rO6cEE1TEpLS0jkTyrP0F+uK TPJaLBLtS70fvamYxkrcTinUKB9OXPsjW68IM2lFU+Ski3h2moFEUS6/PFHGpY5a28XQ IbmngbWd82d9/r260YV9wzcT4K8LYW4F3Wvam4QF6zntnFJ3B2OT9HC+X59jmx2zkFNe ZJTum2liCKZ3ittCfdxjbMOIyAXBUstAvkztPTBheMMPnndD4HEoCFcEqbjN8r3n6jdP F+6Q== X-Received: by 10.140.128.87 with SMTP id 84mr40442430qha.54.1449522876767; Mon, 07 Dec 2015 13:14:36 -0800 (PST) Received: from new-host-3.home (pool-108-7-232-158.bstnma.fios.verizon.net. [108.7.232.158]) by smtp.gmail.com with ESMTPSA id p17sm12326691qhb.34.2015.12.07.13.14.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Dec 2015 13:14:36 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Cullen In-Reply-To: <56536A51.4010001@fer.hr> Date: Mon, 7 Dec 2015 16:14:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1AF08278-4AB7-4649-8BEB-778173865340@gmail.com> References: <20151123192422.32415.11982.idtracker@ietfa.amsl.com> <56536A51.4010001@fer.hr> To: =?windows-1252?Q?Stjepan_Gro=9A?= X-Mailer: Apple Mail (2.1510) Archived-At: X-Mailman-Approved-At: Tue, 08 Dec 2015 17:28:15 -0800 Cc: "mif@ietf.org" Subject: Re: [mif] New Version Notification for draft-sgros-dhcp-and-ipr-claim-analysis-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 21:14:39 -0000 Hi Stjepan, While it is your prerogative to write a draft about anything you like, = it is not the job of an IETF WG to determine the validity of any IPR = claims that is made against a WG document. The IPR claim exists, and it = is up to each individual company to determine how/if any IPR claim does = or does not apply to that company's implementation of any specification. = In this case, the IPR holder has only made an IPR claim against the MIF = MPVD DHCP option document. The first question for the MIF WG in this situation is whether we want = to continue to work on the MPVD DHCP option given the IPR claim or not. = That question is the subject of a separate consensus call to the list = (Subject: Consensus to drop MIF mpvd dhcp document), and any comment on = that question should be made in that thread. Margaret On Nov 23, 2015, at 2:34 PM, Stjepan Gro=9A wrote: > Hi everyone! >=20 > We did an analysis of Huawei's IPR claim and wrote a draft about our = findings. In the end, our opinion is that this IPR doesn't matter. But = in worst case it only partially covers what MIF did. Anyway, we are not = lawyers and would appreciate a feedback. >=20 > SG >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-sgros-dhcp-and-ipr-claim-analysis-00.txt > Date: Mon, 23 Nov 2015 11:24:22 -0800 > From: internet-drafts@ietf.org > To: Leonardo Jelenkovic , Dejan Skvorc = , Stjepan Gros >=20 > A new version of I-D, draft-sgros-dhcp-and-ipr-claim-analysis-00.txt > has been successfully submitted by Stjepan Gros and posted to the > IETF repository. >=20 > Name: draft-sgros-dhcp-and-ipr-claim-analysis > Revision: 00 > Title: DHCP configuration in MIF and associated IPR = claim > Document date: 2015-11-23 > Group: Individual Submission > Pages: 11 > URL: =20 > = https://www.ietf.org/internet-drafts/draft-sgros-dhcp-and-ipr-claim-analys= is-00.txt >=20 > Status: =20 > = https://datatracker.ietf.org/doc/draft-sgros-dhcp-and-ipr-claim-analysis/ >=20 > Htmlized: =20 > https://tools.ietf.org/html/draft-sgros-dhcp-and-ipr-claim-analysis-00 >=20 >=20 >=20 > Abstract: > The purpose of this draft is to analyze different options on how = DHCP > can be used to configure PvD aware client. This is done in light = of > IPR claim made by Huawei and the necessity to find an option for > implementation. In order for an option to be selected it obviously > must not interfere with IPR, or, IPR has to be somehow invalidated. >=20 > = =20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From nobody Tue Dec 8 23:39:40 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B5C1AD21C; Tue, 8 Dec 2015 23:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMhe8945pewS; Tue, 8 Dec 2015 23:39:36 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 9020D1AD23D; Tue, 8 Dec 2015 23:39:33 -0800 (PST) Received: by igvg19 with SMTP id g19so118539753igv.1; Tue, 08 Dec 2015 23:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qlsCTMlgkzBDOIAG0bL2oH7lVCfETGxFGT6sQFfwXgI=; b=aISH4m0xEJ9G5FBfLLUVTfjigZJvwy5rICUzdOChG4jtAcBj8DgjXx+QVjtRY9vZkt GvtBwe/hDIlO6OgXhNx/R3abBJM+cfevMDzq1UY1XVOhq+B78oXB7KMZoIQrW0VLdy4k FWTF1UJt23g3LoKJDWfei1sQ32FPPI4M0gaJQc+dTU+eUybFRIXDLlH7Zq5gmIBpFQUS oO61hW47RXpEH5ZswdFzzVt2lTjY/iGm1v3jvLOy/xnTF/yzC+z2V3qINvHIGdwG8IFq lYW8/nYQurao0eONKDUA4rhHVRPPsfD+LHssREU9nnpQkPb3zlQladtlbalK4/piLtYT qxPA== MIME-Version: 1.0 X-Received: by 10.50.3.4 with SMTP id 4mr8503935igy.87.1449646772839; Tue, 08 Dec 2015 23:39:32 -0800 (PST) Received: by 10.36.154.3 with HTTP; Tue, 8 Dec 2015 23:39:32 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Dec 2015 15:39:32 +0800 Message-ID: From: GangChen To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Margaret , "mif@ietf.org" , Hui Deng , draft-ietf-mif-happy-eyeballs-extension@ietf.org Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 07:39:38 -0000 Mikael, Many thanks for the comments. 2015-12-08 20:45 GMT+08:00, Mikael Abrahamsson : > On Tue, 8 Dec 2015, Hui Deng wrote: > >> Hello all >> >> We have two weeks WG last call for below document: >> https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt >> >> Please send your comments to this thread. >> This WGLC will end on Dec. 22nd. > > The above link is wrong, it links to a 3 year old revision of the > document. > > https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 > seems to be the latest. > > It's also my opinion that I would not want this document sent off until we > have decided what to do with the rest of the MIF documents, it's my > opinion that the WGLC call is premature. I believe that MIF-HE is > important, but I also think we should be more ready with the rest of the > architecture before we ship this document off. It's true to desirably have very clear views of relevant mif documents before the send-off. Yet, I still see the chance to collect wglc comments considering the follows: 1) MIF-HE is not a draft of MPVD cluster. 2) wglc is MIF-HE targeted. We seek wg revisiting on the wg product quality and fix bugs. > Some other comments: > > I would like to see "3/4G interface" replaced with "mobile data interface" > or "3GPP interface" or something else. Sure. It will be fixed. thank you. BRs Gang > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Tue Dec 15 11:00:25 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689BE1AC3D7; Tue, 15 Dec 2015 11:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UVgOOLAFsoz; Tue, 15 Dec 2015 11:00:22 -0800 (PST) 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 886101A92B3; Tue, 15 Dec 2015 11:00:21 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l126so7910259wml.1; Tue, 15 Dec 2015 11:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=khFN0TdQXpGA/JGtmV5yMBFvHgxq1SthnvLWkB0vNoE=; b=UYeo2IgDcxKYBhkPcUO0bkS43pVUuGSkf3wry7FioMTulk2KiWMXtB511wbkChvPZ6 GvS57Cm0sDjiSPSj1iVgbVWLiGNw2ZnXv40w96vcEBhOJ0i31nlISrSzbiATYnq01sXR O0BcTzgy+mLoWDqgNZb7X2DCuzr/IgyE0SZpWo7Z1crHk54De1JJcUa9dU0dZ+eh5kS5 QsOQGBN43QWXFRLmFNh1iLyorTqr2wSHHJ7DhS6ZkkU8f3xbxYk3D62a2bSiHSZAFtA8 E0sWuCf7pvK/YmfwEAju8lixGAPbx0UCBLKQUB0uKAhxuBTcb7VtXuftRFGNKoPSxQGv oH+g== MIME-Version: 1.0 X-Received: by 10.194.201.134 with SMTP id ka6mr46836125wjc.116.1450206020181; Tue, 15 Dec 2015 11:00:20 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Tue, 15 Dec 2015 11:00:20 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2015 14:00:20 -0500 X-Google-Sender-Auth: 94NgI-FnBWpKSNBmD3eCdak8zR8 Message-ID: From: Daniel Migault To: GangChen Content-Type: multipart/alternative; boundary=047d7ba97e64af2b970526f466ae Archived-At: Cc: "mif@ietf.org" , draft-ietf-mif-happy-eyeballs-extension@ietf.org, Margaret , Hui Deng Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 19:00:24 -0000 --047d7ba97e64af2b970526f466ae Content-Type: text/plain; charset=UTF-8 Hi, Please see my comments for https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07. I think it is important for the WG to have such a document. BR, Daniel Section Introduction: """ In multiple interface context, the problems raised by hosts with multiple interfaces have been discussed. The MIF problem statement[RFC6418] described the various issues when using a wrong domain selection on a MIF node. """ I think the first sentence should be removed. It does not bring any information. In addition, it seems contradicting the second sentence with one problem and multiple issues. s/the most fast/fastest/ I assume the goal of the document is describe MIF-HE to adapt the HE concept to the multiple provisionning domain architecture. If I am correct, I think it would be good to have it explicitely mentioned. MIF-HE should be in the terminology section. I am not an english native speaker, but I guess this sentence should checked. I also suspect there are multiple nits that should be fixed. s/A MIF node has both 3/4G and WiFi interface./Assume a MIF node has both a 3/4 G interface and a Wifi interface/ s/it' cheap/it is cheap/ maybe cheap should be avoided as well. s/User/The user/ s/got IP/got an IP/ s/users have/the user has/ s/Users may won't want /Users may not want/ """For instance, they may prefer to wait a little bit of time but not forever.""" I do not think that is correct. The user may rather accept to define an appropriate time slot for the node to attend to set a Wifi connexion. """Users may won't want the wait time too short, because the 3G path for most people is more expensive than WiFi path.""" This sentence is not clear to me. I assume that if 3G/4G is more expensive, the user is more likely to provide the Wifi more time to set a communication. Section 3. s/Hard set/Hard Set/ Section 4.2 The section mentions a bootstart URL and then enumerates "e.g. Windows Vista, Windows 7, Windows Server 2008 and iOS." I think what you mean is that the URL may not be standardized but may be specific to each OS. If I am correct, I do not think that is relevant, since it may be provided by anyone including the ISPs. Maybe that is obvious, but I think we shoudl specify that L2 connectivity has been checked. Otherwise I am not sur ethis is the only possibility. It could also be a firewall for example in an corporate environment. Maybe it would be good to specify the assumption that leads to this conclusion, so if this assumption changes, the document may still be valid. In other words, we should avoid to hav ethat document bound to such assumption. Maybe another alternative is to restrict the scope of the draft to captive portable as it seems this is the main use case addressed. """If anything is abnormal, it assumes there is a proxy on the path. """ The following sentence is not clear to me: """Parameters in a soft set should considered at this stage.""" s/option[RFC6731]/option [RFC6731]/ """Those information may weight a particular interface to be preferred [one prior] to others sending resolving requests.""" There should be a white space before [RFC as well as "(". On Wed, Dec 9, 2015 at 2:39 AM, GangChen wrote: > Mikael, > > Many thanks for the comments. > > 2015-12-08 20:45 GMT+08:00, Mikael Abrahamsson : > > On Tue, 8 Dec 2015, Hui Deng wrote: > > > >> Hello all > >> > >> We have two weeks WG last call for below document: > >> > https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt > >> > >> Please send your comments to this thread. > >> This WGLC will end on Dec. 22nd. > > > > The above link is wrong, it links to a 3 year old revision of the > > document. > > > > https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 > > seems to be the latest. > > > > It's also my opinion that I would not want this document sent off until > we > > have decided what to do with the rest of the MIF documents, it's my > > opinion that the WGLC call is premature. I believe that MIF-HE is > > important, but I also think we should be more ready with the rest of the > > architecture before we ship this document off. > > It's true to desirably have very clear views of relevant mif documents > before the send-off. Yet, I still see the chance to collect wglc > comments considering the follows: > 1) MIF-HE is not a draft of MPVD cluster. > 2) wglc is MIF-HE targeted. We seek wg revisiting on the wg product > quality and fix bugs. > > > Some other comments: > > > > I would like to see "3/4G interface" replaced with "mobile data > interface" > > or "3GPP interface" or something else. > > Sure. It will be fixed. thank you. > > BRs > > Gang > > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --047d7ba97e64af2b970526f466ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please see my comments for https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07= .
I think it is important for the WG to have such a document.

BR,

Daniel

Section I= ntroduction:
"""   In multiple inter=
face context, the problems raised by hosts with
   multiple interfaces have been discussed.  The MIF problem
   statement[RFC6418] described the various issues when using a wrong
   domain selection on a MIF node.  """

I think the first sentence should be removed. It does not bring an=
y information. In addition, it seems contradicting the second sentence with=
 one problem and multiple issues.

s/the most fast/fastest/
=
I assume the goal of the document is describe MIF-HE to adap= t the HE concept to the multiple provisionning domain architecture. If I am= correct, I think it would be good to have it explicitely mentioned.
MIF-HE should be in the terminology section.

= I am not an english native speaker, but I guess this sentence should checke= d. I also suspect there are multiple nits that should be fixed.
s/A MIF node has both 3/4G and WiFi interface./Assume a =
MIF node has both a 3/4 G interface and a Wifi interface/
s/it' cheap/it is cheap/ maybe cheap should be avoided as well.=

s/User/The user/
s/got I=
P/got an IP/
s/users have/the user has/
<= pre class=3D"">s/Users may won't want /Users may not want/
"""For instance, they may prefer to wait a little bit of time but not forever.""" I do not= think that is correct. The user may rather accept to define an appropriate= time slot for the node to attend to set a Wifi connexion.

"&qu= ot;"Users may won't want the wait time too short, because the 3G path for most people is more expensive than WiFi path."""

This sentence is not= clear to me. I assume that if 3G/4G is more expensive, the user is more li= kely to provide the Wifi more time to set a communication.

Section 3.

s/Hard set/Hard Set/

Sect= ion 4.2

The section mentions a bootstart URL and then enu= merates "e.g. Windows Vista, Windows 7, Windows Server 2008 and iOS." I think what you mean is that the URL= may not be standardized but may be specific to each OS. If I am correct, I= do not think that is relevant, since it may be provided by anyone includin= g the ISPs.

Maybe that is obvious, but I think we shoudl specify tha= t L2 connectivity has been checked. Otherwise I am not sur ethis is the onl= y possibility. It could also be a firewall for example in an corporate envi= ronment. Maybe it would be good to specify the assumption that leads to thi= s conclusion, so if this assumption changes, the document may still be vali= d. In other words, we should avoid to hav ethat document bound to such assu= mption. Maybe another alternative is to restrict the scope of the draft to = captive portable as it seems this is the main use case addressed.=C2=A0
"""If anything is abnormal, it assumes there is a proxy on the path. """

The following se= ntence is not clear to me:

"""Parameters in a soft set should considered at this stage."""
s/option[RFC6731]/option [RFC6731]/

=C2=A0
&q=
uot;""Those information may weight a
   particular interface to be preferred [one prior] to others sending
   resolving requests."""

There=
 should be a white space before [RFC as well as "(".


<=
/pre>
=C2=A0=C2=A0

On Wed, Dec 9, 2015 at 2:39 AM, GangChen <phdgang@gm= ail.com> wrote:
Mikael,

Many thanks for the comments.

2015-12-08 20:45 GMT+08:00, Mikael Abrahamsson <swmike@swm.pp.se>:
> On Tue, 8 Dec 2015, Hui Deng wrote:
>
>> Hello all
>>
>> We have two weeks WG last call for below document:
>> https://www.i= etf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt
>>
>> Please send your comments to this thread.
>> This WGLC will end on Dec. 22nd.
>
> The above link is wrong, it links to a 3 year old revision of the
> document.
>
> https://tools.ietf.org/ht= ml/draft-ietf-mif-happy-eyeballs-extension-07
> seems to be the latest.
>
> It's also my opinion that I would not want this document sent off = until we
> have decided what to do with the rest of the MIF documents, it's m= y
> opinion that the WGLC call is premature. I believe that MIF-HE is
> important, but I also think we should be more ready with the rest of t= he
> architecture before we ship this document off.

It's true to desirably have very clear views of relevant mif doc= uments
before the send-off. Yet, I still see the chance to collect wglc
comments considering the follows:
1) MIF-HE is not a draft of MPVD cluster.
2) wglc is MIF-HE targeted. We seek wg revisiting on the wg product
quality and fix bugs.

> Some other comments:
>
> I would like to see "3/4G interface" replaced with "mob= ile data interface"
> or "3GPP interface" or something else.

Sure. It will be fixed. thank you.

BRs

Gang

>
> --
> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>

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

--047d7ba97e64af2b970526f466ae-- From nobody Tue Dec 15 23:14:53 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD61A21BF; Tue, 15 Dec 2015 23:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qu_g32U-_iw; Tue, 15 Dec 2015 23:14:49 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 27FEC1A01D6; Tue, 15 Dec 2015 23:14:49 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id mv3so122950172igc.0; Tue, 15 Dec 2015 23:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tINrEFq4To3PUuSZhRDfF0EkM0DgXNAEW6InJfRyKbY=; b=iyx3qmpKYFxNdz+Zom7uMi35KaW+bDQUkiiPsY6hHHcNyDCVnrZnVACfulK/CmXY+u CzW/Gvd1CVtRbb5xj1TWDbWuuSDpZ1NXgX9zaphBZggS/Sc535PqMQi7KbUl96r1Uwi1 QhEf0ECYImzP5MzauXizHFOy/B2N4d9TUHPvtAV0nKeCGQ7JsBteK0hfuVbZGP05CpMO EJTCtq6IOzgtG/AEla7uytImd3fR861fL9IL6gqRnekeaBfAHQeo/YEp4i1NDnrMes7S HoePBK2hci6PNZlfJq0iPAV6FOQ/x+kKkTsH4abL9y8k4OnPvo9nLb+VuWEgqE/TnQS1 z+GQ== MIME-Version: 1.0 X-Received: by 10.107.168.203 with SMTP id e72mr154238ioj.96.1450250088594; Tue, 15 Dec 2015 23:14:48 -0800 (PST) Received: by 10.36.154.3 with HTTP; Tue, 15 Dec 2015 23:14:48 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 15:14:48 +0800 Message-ID: From: GangChen To: Daniel Migault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mif@ietf.org" , draft-ietf-mif-happy-eyeballs-extension@ietf.org, Margaret , Hui Deng Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 07:14:52 -0000 2015-12-16 3:00 GMT+08:00, Daniel Migault : > Hi, > > Please see my comments for > https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07. > I think it is important for the WG to have such a document. Thank you, Daniel. Please see my reply inline. > > BR, > > Daniel > > Section Introduction: > > """ In multiple interface context, the problems raised by hosts with > multiple interfaces have been discussed. The MIF problem > statement[RFC6418] described the various issues when using a wrong > domain selection on a MIF node. """ > > I think the first sentence should be removed. It does not bring any > information. In addition, it seems contradicting the second sentence > with one problem and multiple issues. > > s/the most fast/fastest/ Agree. I have updated in my local copy. > > I assume the goal of the document is describe MIF-HE to adapt the HE > concept to the multiple provisionning domain architecture. If I am correct, > I think it would be good to have it explicitely mentioned. > > MIF-HE should be in the terminology section. Good suggestion. I add new terminology section. For the completeness, the new section will mention both HE and HE-MIF.
This document makes use of following terms: Happy Eyeballs (HE): it specifies requirements [RFC6555] for algorithms that reduce user-visible delay of dual-stack hosts within a single home. HE-MIF: it adopts HE methodology to the multiple provisioning domain architecture. It describes requirements for algorithms that offer connectivity tests to the PVD-aware and non-PVD-aware nodes [RFC7556].
> > I am not an english native speaker, but I guess this sentence should > checked. I also suspect there are multiple nits that should be fixed. > > s/A MIF node has both 3/4G and WiFi interface./Assume a MIF node has > both a 3/4 G interface and a Wifi interface/ > > s/it' cheap/it is cheap/ maybe cheap should be avoided as well. I edit the sentence as follows: [OLD] A MIF node has both 3/4G and WiFi interface. When the node enters a WiFi area, a common practice would always prefer WiFi because it' cheap and fast-speed normally. [NEW] Assuming a MIF node has both 3GPP mobile network interface and WiFi interface, a common practice would always prefer WiFi connection when the node enters a WiFi area. > > s/User/The user/ > > s/got IP/got an IP/ > > s/users have/the user has/ > > s/Users may won't want /Users may not want/ Those have been corrected. thank you. > > """For instance, they may prefer to wait a little bit of time but not > forever.""" I do not think that is correct. The user may rather accept to > define an appropriate time slot for the node to attend to set a Wifi > connexion. The sentence in the draft doesn't conflict with your thoughts. It may get clear if change some words. [OLD] For instance, they may prefer to wait a little bit of time but not forever. [NEW] For instance, they may prefer to wait an appropriate time slot but not forever. > """Users may won't want the wait time too short, because the 3G path for > most people is more expensive than WiFi path.""" > > This sentence is not clear to me. I assume that if 3G/4G is more expensive, > the user is more likely to provide the Wifi more time to set a > communication. As you mentioned, the user may accept an appropriate time slot to wait on wifi connection. Once the time slot is expired, the user likely switch over to 3G/4G path to get connection. This sentence intend to say this time slot can't set too short, as user likely gives several tries on free wifi. I try to make following changes. [OLD] After the timer is expired, users would finally give up the WiFi path and try to establish connection over 3G path. Users may won't want the wait time too short, because the 3G path for most people is more expensive than WiFi path. [NEW] After the timer is expired, users may finally give up the WiFi path and try to establish connection over 3GPP mobile network path. Users may not want a very short timer, because the mobile network path for most people is more expensive than WiFi path. An appropriate timer is desired to balance user experience and expenditure. > Section 3. > > s/Hard set/Hard Set/ > > Section 4.2 > > The section mentions a bootstart URL and then enumerates "e.g. Windows > Vista, Windows 7, Windows Server 2008 and iOS." I think what you mean is > that the URL may not be standardized but may be specific to each OS. If I > am correct, I do not think that is relevant, since it may be provided by > anyone including the ISPs. You may suggest to not limited to specific OS implementation if I understand correctly. This draft doesn't mandate any implementation, it's just a example. The draft could change the description similar with RFC7556 "In current implementations, some nodes already implement this, e.g., by trying to reach a dedicated web server (see [RFC6419])." > Maybe that is obvious, but I think we shoudl specify that L2 connectivity > has been checked. Otherwise I am not sur ethis is the only possibility. It > could also be a firewall for example in an corporate environment. Maybe it > would be good to specify the assumption that leads to this conclusion, so > if this assumption changes, the document may still be valid. In other > words, we should avoid to hav ethat document bound to such assumption. > Maybe another alternative is to restrict the scope of the draft to captive > portable as it seems this is the main use case addressed. Captive portable is the major use case. I'm unable to figure out a good way to avoid the restriction. It's much appreciated if you have good texts added to the draft. > """If anything is abnormal, it assumes there is a proxy on the path. """ > The following sentence is not clear to me: > > """Parameters in a soft set should considered at this stage.""" The parameters in the soft set is defined in section 3. I will the reference like [NEW] """The soft set parameters defined in section 3 should considered at this stage.""" > > s/option[RFC6731]/option [RFC6731]/ > > > > """Those information may weight a > particular interface to be preferred [one prior] to others sending > resolving requests.""" > > There should be a white space before [RFC as well as "(". > That will be modified many thanks BRs Gang > > > On Wed, Dec 9, 2015 at 2:39 AM, GangChen wrote: > >> Mikael, >> >> Many thanks for the comments. >> >> 2015-12-08 20:45 GMT+08:00, Mikael Abrahamsson : >> > On Tue, 8 Dec 2015, Hui Deng wrote: >> > >> >> Hello all >> >> >> >> We have two weeks WG last call for below document: >> >> >> https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt >> >> >> >> Please send your comments to this thread. >> >> This WGLC will end on Dec. 22nd. >> > >> > The above link is wrong, it links to a 3 year old revision of the >> > document. >> > >> > https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 >> > seems to be the latest. >> > >> > It's also my opinion that I would not want this document sent off until >> we >> > have decided what to do with the rest of the MIF documents, it's my >> > opinion that the WGLC call is premature. I believe that MIF-HE is >> > important, but I also think we should be more ready with the rest of >> > the >> > architecture before we ship this document off. >> >> It's true to desirably have very clear views of relevant mif documents >> before the send-off. Yet, I still see the chance to collect wglc >> comments considering the follows: >> 1) MIF-HE is not a draft of MPVD cluster. >> 2) wglc is MIF-HE targeted. We seek wg revisiting on the wg product >> quality and fix bugs. >> >> > Some other comments: >> > >> > I would like to see "3/4G interface" replaced with "mobile data >> interface" >> > or "3GPP interface" or something else. >> >> Sure. It will be fixed. thank you. >> >> BRs >> >> Gang >> >> > >> > -- >> > Mikael Abrahamsson email: swmike@swm.pp.se >> > >> > _______________________________________________ >> > mif mailing list >> > mif@ietf.org >> > https://www.ietf.org/mailman/listinfo/mif >> > >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > From nobody Wed Dec 16 17:25:04 2015 Return-Path: <7riw77@gmail.com> X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468B51A1A1E for ; Wed, 16 Dec 2015 16:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uji_obUH6H4 for ; Wed, 16 Dec 2015 16:24:45 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 687981A002C for ; Wed, 16 Dec 2015 16:24:45 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id p130so451187yka.1 for ; Wed, 16 Dec 2015 16:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=QeF64DnusKhHQ7tK4su8pxZfcwopD4eP/RzYwiyYN9Q=; b=LiASclZljVo969sDlusS+vkRKcvrU2x1pPNKHmSZ57i+LgzCLtFe1sCfrubkvUcyiQ vlRBA5amskaE8iLsmrye0RyAuTlJeiM+vQYPzcdA3sFkN+irSMw1LI8WTKwQMIqRvKqn fqpveiAT8LF/Hd9PpkeFMxTauUeSNCBIu/GxB3cnZ5ow5S2hNLnhBDeTnTr/pR04Eont Aw4zdsPWMoTO+5D9S7PA2G0IUBqRyULlVAoujhCL3xRsnIFLpput/Fjr5blCsCpgNxLi VDzjXVgwz/dM+GuGyCyEF4okPECqicf21zg1Sous4oURdXsSGB33iyLI1RPeEcsUmyoz QscQ== X-Received: by 10.129.95.6 with SMTP id t6mr11394768ywb.113.1450311884660; Wed, 16 Dec 2015 16:24:44 -0800 (PST) Received: from Russ ([2602:30a:2e5b:44d0:4cf1:b26f:8d60:b57f]) by smtp.gmail.com with ESMTPSA id i125sm7528028ywi.28.2015.12.16.16.24.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Dec 2015 16:24:44 -0800 (PST) From: "Russ White" <7riw77@gmail.com> To: Date: Wed, 16 Dec 2015 19:24:37 -0500 Message-ID: <027b01d13861$509af210$f1d0d630$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdE4YTnn/nbfiIDbRQe/Up9JE3XGHg== Content-Language: en-us Archived-At: X-Mailman-Approved-At: Wed, 16 Dec 2015 17:25:02 -0800 Subject: [mif] Comments on draft-ietf-mif-happy-eyeballs-extension-07 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 00:24:47 -0000 I'm not on the MIF mailing list (I don't think), but some comments based on my reading of the draft, at any rate -- == In multiple interface context, the problems raised by hosts with multiple interfaces have been discussed. I would remove this sentence. == Happy Eyeballs (HE) [RFC6555] described how a dual-stack client can determine the functioning path to a dual-stack server. It's using stateful algorithm to help applications quickly determine if IPv6 or IPv4 is the most fast path to connect a server. I would reword -- perhaps -- Happy Eyeballs (HE) [RFC6555] describes how a dual-stack client can determine the fastest path to a dual-stack server by employing a stateful algorithm to quickly discover if the IPv4 or IPv6 path is faster. == That is a good method to achieve smart path selection. However, the assumption is a single-homed context. The interaction with multiple interfaces is deferred for further study. Perhaps -- While this is a good method to achieve smart path selection, it assumes a single-homed device. Interaction with multiple interfaces was deferred for further study. Although the problem here is I'm not certain if this is supposed to be a single device, or a single interface device, or ... When I read "single homed," I tend to think of a device with a single upstream connection, rather than a device with multiple interfaces. The two concepts -- dual homing and multiple interfaces -- are actually unrelated. I think multiple interfaces is meant here, rather than single homed (?). == This memo has been proposed to extend happy eyeballs algorithm to fit into the multiple interfaces architecture. Several additional considerations have been elaborated to analyze the user demands and initiate HE-MIF connections. It allows a node with multiple interfaces picking a fast flow path. Perhaps -- This memo proposes extensions to the HE algorithm defined in [RFC6555] to support multiple interfaces, such that a node with multiple interfaces can choose the fastest available path for any particular flow. == would always prefer WiFi because it' cheap and fast-speed normally. Should be something like -- would normally be to prefer the WiFi connection because it's both less expensive and has a higher available bandwidth. == User assumes the WiFi is working, because the node already got IP address from WiFi. However, he can't run applications due to Internet connectivity being unavailable. I don't know that the user is assuming anything -- rather the device is choosing which link to use for what, so it's the software on the device that's doing the assuming here, I think. Perhaps -- In this situation, a device might assume the WiFi link can reach destinations on the global Internet, for instance because a valid IP address has been assigned through some process on the interface. However, this might not be the case for several reasons, such as authentication requirements, instability at layer 2, or even, perhaps, the WiFi being connected to a local network with no global Internet reachability. == With HE-MIF, users can indicate their desire with some setting on the phone. For instance, they may prefer to wait a little bit of time but not forever. After the timer is expired, users would finally give up the WiFi path and try to establish connection over 3G path. Users may won't want the wait time too short, because the 3G path for most people is more expensive than WiFi path. This is a bit difficult to understand. I think what is probably meant here is something like -- With the extensions described in this draft, users could indicate their willingness to switch from the apparently higher speed WiFI link to the lower speed, and more expensive, mobile wireless connection. This switchover could be accomplished by the user setting a timer indicating how long they are willing to wait for a connection to establish across a less expensive link before reverting to a more expensive link. == A node has WiFi and 3/4G access simultaneously. In mobile network, IPv6-only may be preferable since IPv6 has the potential to be simpler than dual-stack. WiFi access still remains on IPv4. The problem is caused by policy confliction. I'm not certain what this section is trying to say, other than the commonsense -- if IPv6 isn't available on a particular connection, then IPv6 flows shouldn't be sent across that connection? == It serves upper applications and initiates HE-MIF connections to below level API subsequently. Going through the process, MIF nodes could pick an appropriate interface which would correspond to user demands. I'm not certain what this means... What is "upper" and "lower" in relation to here? == Hard Set: It contains The "it" isn't needed here -- Hard Set: Contains... == This might provide an interface for applications constraints or delivering operator's policies. Is this a set of parameters, or an interface to a set of parameters? It seems unclear here. I suspect this is just a set of paramenters, so this section might want to say -- Contains parameters which must be complied with when choosing which interface and protocol through which a particular flow should be directed. These should be seen as constraints on the choice, such as provider policies, support for IPv4 or IPv6, and other parameters which would prevent a particular interface and transport from being used by a particular flow. Parameters in the hard set should be easy to use and understand; when several parameters in the hard set are in conflict, the user's preference should be prioritized. I'm not certain about the point of the last sentence -- it seems, to me, that the provider might want the right to enforce a specific rule. I don't know if this is fully accounted for here or not. == deliver the customized policies in particular network environments due to Should probably be -- deliver policies in particular network environments because of ... == Soft Set: It contains factors involving in the selection of the fastest path. The following is considered as for the justification. Might be better as -- Soft Set: Contains factors which impact the selection of the path across which a particular flow should be transmitted among the available interfaces and transports which meet the hard set requirements described above. Examples might include: == Corresponding to the two sets of parameters, a HE-MIF node may take a two-steps approach. I don't know why this should be a "may." It seems, to me, based on the way the hard set parameters are defined in the draft, any and all hard set parameters must be satisfied before a link/transport pair can be used at all for a particular flow. == HTH... :-) Russ From nobody Wed Dec 16 20:43:54 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0DB1ACD5D for ; Wed, 16 Dec 2015 20:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPTFKyD7YPmh for ; Wed, 16 Dec 2015 20:43:51 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 30DB31ACD5B for ; Wed, 16 Dec 2015 20:43:51 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id q126so43147823iof.2 for ; Wed, 16 Dec 2015 20:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W8Rw9TbZPc0RkLbv9oK7omxCVS9xdR6bqJUwz7+HnJg=; b=kFAKSHrVBgvTJcQPyCuxUsHn+VwXjybywspiU6VH9s9jk1i/crzHN+EhUS6csj+r2x 15/9lxRIjgR7cCYiXIa1boenksWR6WGUffnelb7N9/GwfUPIjb1Jva91CkhLHJCefItp 0Yk3DTj9QRZMX5R9NuytezhYD8m1nhx8NYwh4oq2Ciyz9YfxIBednyaoiF78tPA31JIY s1xQB85lLDqtwEcrcOg7vfv1P+N3596l9AFINvcVf4FyzxcJXpRv6f1rUglgp1xZIWgq Hdg1XxzGzCMCvJbUcMdTF8BlY24E2UWZtx4zMruABi1II84yQF92s8uS34tZ1jsFHzxM 9n0Q== MIME-Version: 1.0 X-Received: by 10.107.11.68 with SMTP id v65mr32446ioi.188.1450327430612; Wed, 16 Dec 2015 20:43:50 -0800 (PST) Received: by 10.36.154.3 with HTTP; Wed, 16 Dec 2015 20:43:50 -0800 (PST) In-Reply-To: <027b01d13861$509af210$f1d0d630$@gmail.com> References: <027b01d13861$509af210$f1d0d630$@gmail.com> Date: Thu, 17 Dec 2015 12:43:50 +0800 Message-ID: From: GangChen To: Russ White <7riw77@gmail.com> Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-ietf-mif-happy-eyeballs-extension-07 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 04:43:54 -0000 Hello Russ, thank you for the comments. My reply is inline. 2015-12-17 8:24 GMT+08:00, Russ White <7riw77@gmail.com>: > > I'm not on the MIF mailing list (I don't think), but some comments based on > my reading of the draft, at any rate -- > > > == > In multiple interface context, the problems raised by hosts with multiple > interfaces have been discussed. > > I would remove this sentence. Same comment is in another thread. I will remove the sentence. > == > Happy Eyeballs (HE) [RFC6555] > described how a dual-stack client can determine the functioning path > to a dual-stack server. It's using stateful algorithm to help > applications quickly determine if IPv6 or IPv4 is the most fast path > to connect a server. > > I would reword -- perhaps -- > > Happy Eyeballs (HE) [RFC6555] describes how a dual-stack client can > determine the fastest path to a dual-stack server by employing a stateful > algorithm to quickly discover if the IPv4 or IPv6 path is faster. good to me. To combine the comments from the another thread, "fastest" will be changed to "the most fast" > == > That is a good method to achieve smart path > selection. However, the assumption is a single-homed context. The > interaction with multiple interfaces is deferred for further study. > > Perhaps -- > > While this is a good method to achieve smart path selection, it assumes a > single-homed device. Interaction with multiple interfaces was deferred for > further study. > > Although the problem here is I'm not certain if this is supposed to be a > single device, or a single interface device, or ... When I read "single > homed," I tend to think of a device with a single upstream connection, > rather than a device with multiple interfaces. The two concepts -- dual > homing and multiple interfaces -- are actually unrelated. I think multiple > interfaces is meant here, rather than single homed (?). HE(Happy Eyeball,RFC6555) is single-homed assumed. HE-MIF is for a multi-homed node. Referring to the terminology in RC6418, multi-homing node and the node with multiple interfaces are interchangeable. I like the sentence you proposed. Only the "device" may be better to be changed as "node": "While this is a good method to achieve smart path selection, it assumes a single-homed node targeted. Interaction with multiple interfaces was deferred for further study. > == > This memo has been proposed to extend happy eyeballs algorithm to fit > into the multiple interfaces architecture. Several additional > considerations have been elaborated to analyze the user demands and > initiate HE-MIF connections. It allows a node with multiple > interfaces picking a fast flow path. > > Perhaps -- > > This memo proposes extensions to the HE algorithm defined in [RFC6555] to > support multiple interfaces, such that a node with multiple interfaces can > choose the fastest available path for any particular flow. Combining with previous comments, I will avoid using the word of "algorithm". Since RFC6555 only define the requirements for the algorithm, HE-MIF also only produces the requirement. Another concern is to state "any particular flow". HE-MIF is mainly for connection-oriented transports (e.g., TCP, SCTP). Flow may have broader scope. Here is a change proposal. "This memo proposes extensions to the Happy Eyeball(HE) defined in [RFC6555] to fit into multiple provisioning domain architecture, such that a node with multiple interfaces can choose the most fast path for a particular connection-oriented flow." > == > would always prefer WiFi because it' > cheap and fast-speed normally. > > Should be something like -- > > would normally be to prefer the WiFi connection because it's both less > expensive and has a higher available bandwidth. > > == > User assumes the WiFi is working, > because the node already got IP address from WiFi. However, he can't > run applications due to Internet connectivity being unavailable. > > I don't know that the user is assuming anything -- rather the device is > choosing which link to use for what, so it's the software on the device > that's doing the assuming here, I think. > > Perhaps -- > > In this situation, a device might assume the WiFi link can reach > destinations on the global Internet, for instance because a valid IP > address > has been assigned through some process on the interface. However, this > might > not be the case for several reasons, such as authentication requirements, > instability at layer 2, or even, perhaps, the WiFi being connected to a > local network with no global Internet reachability. That is a good suggestion. just a little bit of wording: In this situation, a node might assume the WiFi link can reach destinations on the global Internet, because a valid IP address has been assigned on the interface. However, this might not be the case for several reasons, such as authentication requirements, instability at layer 2, or even, perhaps, the WiFi being connected to a local network with no global Internet reachability. > == > With HE-MIF, users can indicate their > desire with some setting on the phone. For instance, they may prefer > to wait a little bit of time but not forever. After the timer is > expired, users would finally give up the WiFi path and try to > establish connection over 3G path. Users may won't want the wait > time too short, because the 3G path for most people is more expensive > than WiFi path. > > This is a bit difficult to understand. I think what is probably meant here > is something like -- > > With the extensions described in this draft, users could indicate their > willingness to switch from the apparently higher speed WiFI link to the > lower speed, and more expensive, mobile wireless connection. This > switchover > could be accomplished by the user setting a timer indicating how long they > are willing to wait for a connection to establish across a less expensive > link before reverting to a more expensive link. This sentence is also commented in another thread. You may want to review the current sentence: With HE-MIF, users can indicate their desire with some setting on the phone. For instance, they may prefer to wait an appropriate time slot but not forever. After the timer is expired, users may finally give up the WiFi path and try to establish connection over 3GPP mobile network path. Users may not want a very short timer, because the mobile network path for most people is more expensive than WiFi path. An appropriate timer is desired to balance user experience and expenditure. For the bandwidth of wifi comparing to wireless link, it's almost same if user swith to 4G link. 4G has 100Mbps speed. > == > A node has WiFi and 3/4G access simultaneously. In mobile network, > IPv6-only may be preferable since IPv6 has the potential to be > simpler than dual-stack. WiFi access still remains on IPv4. The > problem is caused by policy confliction. > > I'm not certain what this section is trying to say, other than the > commonsense -- if IPv6 isn't available on a particular connection, then > IPv6 > flows shouldn't be sent across that connection? This section intends to describe the confliction btw source address selection principle and user preference. If IPv6 on the wireless link and Ipv4 on the wifi link, wireless link will be selected according to the source address selection principle but user may prefer the wifi link. > == > It serves upper > applications and initiates HE-MIF connections to below level API > subsequently. Going through the process, MIF nodes could pick an > appropriate interface which would correspond to user demands. > > I'm not certain what this means... What is "upper" and "lower" in relation > to here? The sense of "upper" originally is derived from MIF API framework. I guess "upper" can be removed here. > == > Hard Set: It contains > > The "it" isn't needed here -- > > Hard Set: Contains... > > == > This might provide an > interface for applications constraints or delivering operator's > policies. > > Is this a set of parameters, or an interface to a set of parameters? It > seems unclear here. I suspect this is just a set of parameters, so this > section might want to say -- > > Contains parameters which must be complied with when choosing which > interface and protocol through which a particular flow should be directed. > These should be seen as constraints on the choice, such as provider > policies, support for IPv4 or IPv6, and other parameters which would > prevent > a particular interface and transport from being used by a particular flow. > Parameters in the hard set should be easy to use and understand; when > several parameters in the hard set are in conflict, the user's preference > should be prioritized. > > I'm not certain about the point of the last sentence -- it seems, to me, > that the provider might want the right to enforce a specific rule. I don't > know if this is fully accounted for here or not. thank you for the proposal, i will update accordingly. The last sentence is to weight user choice. Once the confliction btw provider enforced rules and user preference, hard set should take user choice as first priority. > == > deliver the customized > policies in particular network environments due to > > Should probably be -- > > deliver policies in particular network environments because of ... Ack > == > Soft Set: It contains factors involving in the selection of the > fastest path. The following is considered as for the > justification. > > Might be better as -- > > Soft Set: Contains factors which impact the selection of the path across > which a particular flow should be transmitted among the available > interfaces > and transports which meet the hard set requirements described above. > Examples might include: good to me. > == > Corresponding to the two sets of parameters, a HE-MIF node may take a > two-steps approach. > > I don't know why this should be a "may." It seems, to me, based on the way > the hard set parameters are defined in the draft, any and all hard set > parameters must be satisfied before a link/transport pair can be used at > all > for a particular flow. That was discussed backing to 2012.10. "may" indicates the case if only one interface is left after the firs step, second step is not executed. BRs Gang > == > > HTH... > > :-) > > Russ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Thu Dec 17 06:34:29 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E271B1B2E3A for ; Thu, 17 Dec 2015 06:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t77uPgk6a-zJ for ; Thu, 17 Dec 2015 06:34:24 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 19C331B2E2E for ; Thu, 17 Dec 2015 06:34:24 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id 140so20390439ykp.0 for ; Thu, 17 Dec 2015 06:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a3+B1lCAF9WnPsakTQ89uJUj6yPzldJ5yj8Fhd7lRz4=; b=DAs5xCm9YGA0BTlfht0XAZ9x3LZLtYo00ZEZEuDXSGaE563Mjw8AHtGwjLfG5mrZJO LoQjKvDORT4Nx+f//S7i5PLuUOH3uNqLB/6rTdLfj82ap5x3CQjNwV8T2USghJRemlA9 v0s8DvglIyl7wcVUPmRmWZkYDZ0esrQ9NjozesUwbkVPCKWQPdF0/16AR26+CGwhc+Mr VugPB5P6OEhJk6tVFsBWHEUThhe+RPFMmd0SNtPaM+FsKS/9gu9FWfjOXdu8BMCi/hQ9 gTFFCEDeNMje5PUGf+LIei+3mxpPNlVCFoN2Zy7leNqitaQ8rdGob/KTRD2bhfWZZDMG c9CA== MIME-Version: 1.0 X-Received: by 10.129.72.130 with SMTP id v124mr16731561ywa.87.1450362863374; Thu, 17 Dec 2015 06:34:23 -0800 (PST) Received: by 10.129.110.132 with HTTP; Thu, 17 Dec 2015 06:34:23 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2015 15:34:23 +0100 Message-ID: From: Zhen Cao To: Hui Deng Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Margaret , "mif@ietf.org" Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 14:34:28 -0000 Dear All, To clarify, I read the draft indicated by this link https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 I find the document is ready to be published. (Actually it should be published earlier. This problem was well recognized at the very beginning, but now it seems the interest has declined. ) Some editorial comments to the abstract: Old: Currently the interface selection in multi-interface environment is exclusive - only one interface can be used at the time, frequently needing manual intervention. - I do like this argument, neither should any MIFers, since the MIF wg has developed many solutions to help interface selection based on domain names, APNs, PvDs. Cheers, Zhen On Tue, Dec 8, 2015 at 12:47 PM, Hui Deng wrote: > Hello all > > We have two weeks WG last call for below document: > https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt > > Please send your comments to this thread. > This WGLC will end on Dec. 22nd. > > Best regards, > > Cochairs. > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Thu Dec 17 17:42:12 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A18D1B31E5 for ; Thu, 17 Dec 2015 17:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h146hVzfFuTJ for ; Thu, 17 Dec 2015 17:42:09 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 BD0B61B31E4 for ; Thu, 17 Dec 2015 17:42:09 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id to18so24786110igc.0 for ; Thu, 17 Dec 2015 17:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lr02oXY56+3UQXilx5o+F05y3zWLva1bQVg5Vxknbck=; b=wJt3dQSS/UIkgjKoRwSWefhiyTxsfhXhq0oe6+pJWM4TjwhuH0yC2SFPlAWYGmbBq2 N8KYK0dgrX9L7mTr7+THHtTonnmN75+uYVE76f7E6mw8xBv3ziw/WNykogD+ZdmOhdGi AGZw3bOWeDoP6z5NcF/Vv6fBVz6OhdIA6VWEbE2U9aoJ1VgSHwO2+7G1AusmVBz/+jNP st0SiqgCN8YJLrPtzlax/b5shnZmh75BnfgeRvLzxdmKA/j6tGSH6elYp8TEw5TPoEuP j3/b3f211+XvAg0GKufvG3MWVfVxuEujWE78M5cbNaf2HkdMPtR2axNXl2NzhWPL7qGb EtFw== MIME-Version: 1.0 X-Received: by 10.50.20.36 with SMTP id k4mr612749ige.87.1450402929089; Thu, 17 Dec 2015 17:42:09 -0800 (PST) Received: by 10.36.154.3 with HTTP; Thu, 17 Dec 2015 17:42:08 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 09:42:08 +0800 Message-ID: From: GangChen To: Zhen Cao Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Margaret , "mif@ietf.org" , Hui Deng Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 01:42:11 -0000 Hello Zhen, Thank you for the comments. I would like to propose the following new texts for the abstract: This memo proposes extensions to the Happy Eyeball(HE) defined in RFC6555 to fit into multiple provisioning domain architecture. Happy Eyeballs in MIF would make the selection process smoother by using the connectivity checks over a pre-filtered interfaces according to defined policy. This would choose the fastest interface with an automatic fallback. Please kindly to check. BRs Gang 2015-12-17 22:34 GMT+08:00, Zhen Cao : > Dear All, > > To clarify, I read the draft indicated by this link > https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 > > I find the document is ready to be published. (Actually it should be > published earlier. This problem was well recognized at the very > beginning, but now it seems the interest has declined. ) > > Some editorial comments to the abstract: > > Old: Currently the interface selection in multi-interface environment is > exclusive - only one interface can be used at the time, frequently > needing manual intervention. > > - I do like this argument, neither should any MIFers, since the MIF wg > has developed many solutions to help interface selection based on > domain names, APNs, PvDs. > > > Cheers, > Zhen > > On Tue, Dec 8, 2015 at 12:47 PM, Hui Deng wrote: >> Hello all >> >> We have two weeks WG last call for below document: >> https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt >> >> Please send your comments to this thread. >> This WGLC will end on Dec. 22nd. >> >> Best regards, >> >> Cochairs. >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Fri Dec 18 01:53:12 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D3F1B350D for ; Fri, 18 Dec 2015 01:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRJJWudvmzwc for ; Fri, 18 Dec 2015 01:53:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DF51B34C8 for ; Fri, 18 Dec 2015 01:53:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFP73434; Fri, 18 Dec 2015 09:53:03 +0000 (GMT) Received: from lhreml704-cah.china.huawei.com (10.201.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Dec 2015 09:52:30 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 18 Dec 2015 09:52:29 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 17:52:22 +0800 From: "Liubing (Leo)" To: "mif@ietf.org" Thread-Topic: [mif] WGLC for MIF happy eyeballs Thread-Index: AQHRMa41mM9v5phE2Umd5ryGXUF2tJ7Agy0AgAAFJYCAD85hcA== Date: Fri, 18 Dec 2015 09:52:21 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D31582@nkgeml514-mbx.china.huawei.com> References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D31582nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5673D780.00BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 12b6aecffe68fc4208296e569d15ce60 Archived-At: Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 09:53:11 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D31582nkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I support moving forward this document as an informational RFC. It provides= valuable information for application developers to consider. Minor comments: 1) Regarding the document name In my mind, I already have the impression that "Happy Eyeballs" mainly rega= rding to IPv4/IPv6 selection; and besides, it is a concrete algorithm that = machine could behave accordingly. In comparison, this document in my mind i= s more like a guidance on "Interface selection" than a concrete algorithm, = and it doesn't focus on IPv4/IPv6 priority issue. But I won't fight for the document naming issue. Just a personal feeling. I= f others are ok with the current name, I'm ok too. 2) Section 5 In this section, there are two implementation approaches provided. One is a= pplication internal implementation, which requires no additional API work; = the other is the enhanced MIF-API. The two approaches seem more or less contrary to me. So, the section 5 seem= s like an open question, that which approach is better. Does this document = have some preference between the two? 3) Section 6.4 "Interface changing should only happen at the beginning of new session in order to keep flow continuity for ongoing TCP session." There might be always multiple sessions running in a phone at the same time= , so I guess it would be very difficult to achieve this. So, maybe simply s= aying this is also out of scope. Best regards, Bing From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng Sent: Tuesday, December 08, 2015 9:04 PM To: Mikael Abrahamsson Cc: Margaret; mif@ietf.org Subject: Re: [mif] WGLC for MIF happy eyeballs Apologize for mistake, thanks a lot for Mikael's correct, Please go with that link Best regards, DENG Hui > Date: Tue, 8 Dec 2015 13:45:32 +0100 > From: swmike@swm.pp.se > To: denghui02@hotmail.com > CC: mif@ietf.org; margaretw42@gmail.com > Subject: Re: [mif] WGLC for MIF happy eyeballs > > On Tue, 8 Dec 2015, Hui Deng wrote: > > > Hello all > > > > We have two weeks WG last call for below document: > > https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension= -04.txt > > > > Please send your comments to this thread. > > This WGLC will end on Dec. 22nd. > > The above link is wrong, it links to a 3 year old revision of the > document. > > https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 > seems to be the latest. > > It's also my opinion that I would not want this document sent off until w= e > have decided what to do with the rest of the MIF documents, it's my > opinion that the WGLC call is premature. I believe that MIF-HE is > important, but I also think we should be more ready with the rest of the > architecture before we ship this document off. > > Some other comments: > > I would like to see "3/4G interface" replaced with "mobile data interface= " > or "3GPP interface" or something else. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D31582nkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

I support = moving forward this document as an informational RFC. It provides valuable = information for application developers to consider.

 = ;

Minor comm= ents:

1) Regardi= ng the document name

In my mind= , I already have the impression that ”Happy Eyeballs” mainly re= garding to IPv4/IPv6 selection; and besides, it is a concrete algorithm that machine could behave accordingly. In comparison, this document in my = mind is more like a guidance on “Interface selection” than a co= ncrete algorithm, and it doesn’t focus on IPv4/IPv6 priority issue.

But I won&= #8217;t fight for the document naming issue. Just a personal feeling. If ot= hers are ok with the current name, I’m ok too.

 = ;

2) Section= 5

In this se= ction, there are two implementation approaches provided. One is application= internal implementation, which requires no additional API work; the other is the enhanced MIF-API.

The two ap= proaches seem more or less contrary to me. So, the section 5 seems like an = open question, that which approach is better. Does this document have some preference between the two?

 = ;

 = ;

3) Section= 6.4

“Int= erface changing should only happen at the beginning of

new sessio= n in order to keep flow continuity for ongoing TCP session.”

There migh= t be always multiple sessions running in a phone at the same time, so I gue= ss it would be very difficult to achieve this. So, maybe simply saying this is also out of scope.

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

 = ;

From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng
Sent: Tuesday, December 08, 2015 9:04 PM
To: Mikael Abrahamsson
Cc: Margaret; mif@ietf.org
Subject: Re: [mif] WGLC for MIF happy eyeballs

 

Apologize for mistake, thanks a lot for M= ikael's correct,
 
Please go with that link
 
Best regards,
 
DENG Hui 

 

> Date: Tue, 8 Dec 2015 13:45:32 += 0100
> From: swmike@swm.pp.se
> To: denghui02@hotmail.com=
> CC: mif@ietf.org; margaretw42@gmail.com
> Subject: Re: [mif] WGLC for MIF happy eyeballs
>
> On Tue, 8 Dec 2015, Hui Deng wrote:
>
> > Hello all
> >
> > We have two weeks WG last call for below document:
> > https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.= txt
> >
> > Please send your comments to this thread.
> > This WGLC will end on Dec. 22nd.
>
> The above link is wrong, it links to a 3 year old revision of the
> document.
>
> https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 =
> seems to be the latest.
>
> It's also my opinion that I would not want this document sent off unti= l we
> have decided what to do with the rest of the MIF documents, it's my > opinion that the WGLC call is premature. I believe that MIF-HE is
> important, but I also think we should be more ready with the rest of t= he
> architecture before we ship this document off.
>
> Some other comments:
>
> I would like to see "3/4G interface" replaced with "mob= ile data interface"
> or "3GPP interface" or something else.
>
> --
> Mikael Abrahamsson email: swmike@s= wm.pp.se

--_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2D31582nkgeml514mbxchi_-- From nobody Sat Dec 19 03:04:40 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84951A8857 for ; Sat, 19 Dec 2015 03:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUPINuB4SmD0 for ; Sat, 19 Dec 2015 03:04:37 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 0C1231A8856 for ; Sat, 19 Dec 2015 03:04:37 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id q126so114308282iof.2 for ; Sat, 19 Dec 2015 03:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lGS7x8YyRftWXOSeko1wzIpNNv8JCuvoFrd0AwZ0VRc=; b=qz9G+pSe3IgjAQRVluaAUbdGOhWP6oLbjtC4nCnAJt3BvBrERVSJvq0aC/XgpHCf+Y L7UdXarKj4+puFY8uWHYjSrE8KqASQVpbPq6MKDNWgJwVGh261rHpHVlSTD8nZrcvhkf dgmLl03Ut5hRVS6TQNltSI9A8ARxG4yP94un4JX2cnTnlsW3vkEXU78bV07YrYAEpyj5 tqOo2IIqk8LOFM8yKmqApPz0NH02wGkgX4i/nbnYh2h9RH1TxGebbv1jJ0K3XZG9l3le AbEILB4t31FzNdFdNXVzapgOJ0GcN9rY/tNsvj56MU686YVCKBrxW7IRBqqU97ynIuA+ EMUw== MIME-Version: 1.0 X-Received: by 10.107.129.149 with SMTP id l21mr9502102ioi.174.1450521239019; Sat, 19 Dec 2015 02:33:59 -0800 (PST) Received: by 10.36.154.3 with HTTP; Sat, 19 Dec 2015 02:33:58 -0800 (PST) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D31582@nkgeml514-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F45C2D31582@nkgeml514-mbx.china.huawei.com> Date: Sat, 19 Dec 2015 18:33:58 +0800 Message-ID: From: GangChen To: "Liubing (Leo)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 11:04:38 -0000 Hello Bing, Thank you for the comments. My reply is inline. 2015-12-18 17:52 GMT+08:00, Liubing (Leo) : > Hi all, > > I support moving forward this document as an informational RFC. It provides > valuable information for application developers to consider. > > Minor comments: > 1) Regarding the document name > In my mind, I already have the impression that "Happy Eyeballs" mainly > regarding to IPv4/IPv6 selection; and besides, it is a concrete algorithm > that machine could behave accordingly. In comparison, this document in my > mind is more like a guidance on "Interface selection" than a concrete > algorithm, and it doesn't focus on IPv4/IPv6 priority issue. > But I won't fight for the document naming issue. Just a personal feeling. If > others are ok with the current name, I'm ok too. Just state my thought: Several major considerations, such as connectivity testing and fastest path selection, are derived from happy eyeballs. Adoption in the document title intends to describe a view of documented mechnism as heuristic as possible. > 2) Section 5 > In this section, there are two implementation approaches provided. One is > application internal implementation, which requires no additional API work; > the other is the enhanced MIF-API. > The two approaches seem more or less contrary to me. So, the section 5 seems > like an open question, that which approach is better. Does this document > have some preference between the two? The HE-MIF could accomandate those two approaches. Preference to any specific implementation is going beyond the document scope. I guess best way is to live in the reality. > > 3) Section 6.4 > "Interface changing should only happen at the beginning of > new session in order to keep flow continuity for ongoing TCP session." > There might be always multiple sessions running in a phone at the same time, > so I guess it would be very difficult to achieve this. So, maybe simply > saying this is also out of scope. Thank you for pointing this out. New texts would be: "The flow continuity due to interface change is beyond the scope of this document" BRs Gang > > Best regards, > Bing > > > From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Hui Deng > Sent: Tuesday, December 08, 2015 9:04 PM > To: Mikael Abrahamsson > Cc: Margaret; mif@ietf.org > Subject: Re: [mif] WGLC for MIF happy eyeballs > > Apologize for mistake, thanks a lot for Mikael's correct, > > Please go with that link > > Best regards, > > DENG Hui > > >> Date: Tue, 8 Dec 2015 13:45:32 +0100 >> From: swmike@swm.pp.se >> To: denghui02@hotmail.com >> CC: mif@ietf.org; >> margaretw42@gmail.com >> Subject: Re: [mif] WGLC for MIF happy eyeballs >> >> On Tue, 8 Dec 2015, Hui Deng wrote: >> >> > Hello all >> > >> > We have two weeks WG last call for below document: >> > https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt >> > >> > Please send your comments to this thread. >> > This WGLC will end on Dec. 22nd. >> >> The above link is wrong, it links to a 3 year old revision of the >> document. >> >> https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 >> seems to be the latest. >> >> It's also my opinion that I would not want this document sent off until >> we >> have decided what to do with the rest of the MIF documents, it's my >> opinion that the WGLC call is premature. I believe that MIF-HE is >> important, but I also think we should be more ready with the rest of the >> architecture before we ship this document off. >> >> Some other comments: >> >> I would like to see "3/4G interface" replaced with "mobile data >> interface" >> or "3GPP interface" or something else. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se > From nobody Sun Dec 20 21:47:24 2015 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D521A8963; Sun, 20 Dec 2015 21:47:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151221054721.16095.84280.idtracker@ietfa.amsl.com> Date: Sun, 20 Dec 2015 21:47:21 -0800 Archived-At: Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-happy-eyeballs-extension-08.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 05:47:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Happy Eyeballs Extension for Multiple Interfaces Authors : Gang Chen Carl Williams Dan Wing Andrew Yourtchenko Filename : draft-ietf-mif-happy-eyeballs-extension-08.txt Pages : 11 Date : 2015-12-20 Abstract: This memo proposes extensions to the Happy Eyeball(HE) defined in RFC6555 and fit into a multiple provisioning domain architecture. Happy Eyeballs in MIF would make the selection process smoother by using connectivity tests over pre-filtered interfaces according to defined policy. This would choose the most fast interface with an automatic fallback mechnism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mif-happy-eyeballs-extension-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 20 21:54:05 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D0A1A8968 for ; Sun, 20 Dec 2015 21:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUSADNDFDFbm for ; Sun, 20 Dec 2015 21:54:01 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 8DAE71A8969 for ; Sun, 20 Dec 2015 21:54:01 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id 186so146500864iow.0 for ; Sun, 20 Dec 2015 21:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WzWkMr654MLRPfyRraTCCagUvTH8fdX1w2C3HBWYtSg=; b=DMPwxBDDStdM32hrsrhM0T9vmikjO2qL+u9jQ7O0IJen6GOXq+xi/j8jOLIvIla6bH 68gA4yKYr0ocyXXKK3cg0WWHKIZR2hoJBegdYL81o+sAWAHtp6saR4/8dxl6AjihlMLT JteneO/qgCspdDO9e97UestIbaejsy4Fkhgti4ie93Evkkfs6slbMVF+zGDXxQUbghbK 86gzipcYNmwVT+s5kIz2hpR2yBUC6WqWkrdXqPUCI/XNSAMWMKp4fqPWA4LtcHHRbFL3 o1L9IezygheqWmC0vXPtP9qxhGiHAXN2OhFvQZlPqLFjgEEagUsDqVOf8KXsus3IYDmv 8Qtw== MIME-Version: 1.0 X-Received: by 10.107.129.149 with SMTP id l21mr16667066ioi.174.1450677240922; Sun, 20 Dec 2015 21:54:00 -0800 (PST) Received: by 10.36.154.3 with HTTP; Sun, 20 Dec 2015 21:54:00 -0800 (PST) Date: Mon, 21 Dec 2015 13:54:00 +0800 Message-ID: From: GangChen To: mif , Daniel Migault , "Liubing (Leo)" , Zhen Cao , swmike@swm.pp.se, Russ White <7riw77@gmail.com>, Hui Deng , Margaret Wasserman Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [mif] new draft produced: I-D Action: draft-ietf-mif-happy-eyeballs-extension-08.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 05:54:03 -0000 wg, I put all comments received together and produce a new draft for your kind check. Many thanks Gang ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Sun, 20 Dec 2015 21:47:21 -0800 Subject: I-D Action: draft-ietf-mif-happy-eyeballs-extension-08.txt To: i-d-announce@ietf.org Cc: mif@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Happy Eyeballs Extension for Multiple Interfaces Authors : Gang Chen Carl Williams Dan Wing Andrew Yourtchenko Filename : draft-ietf-mif-happy-eyeballs-extension-08.txt Pages : 11 Date : 2015-12-20 Abstract: This memo proposes extensions to the Happy Eyeball(HE) defined in RFC6555 and fit into a multiple provisioning domain architecture. Happy Eyeballs in MIF would make the selection process smoother by using connectivity tests over pre-filtered interfaces according to defined policy. This would choose the most fast interface with an automatic fallback mechnism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mif-happy-eyeballs-extension-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Dec 22 18:55:31 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABE31A90EE for ; Tue, 22 Dec 2015 18:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJTQDI9UvsNv for ; Tue, 22 Dec 2015 18:55:28 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 34A551A90EA for ; Tue, 22 Dec 2015 18:55:28 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id p130so182746826yka.1 for ; Tue, 22 Dec 2015 18:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V+Yuazu0LtBKpj1TmfYDvZ+EiOat9zFkfuyXgOxeAQk=; b=Y3QJRjPzHHysFsSmFQCei/KVCCrLuWMDGr/lF49h3RvJdaHvKVsBFenZ27LRuLjjUg 5WZRjUfnNXE3/3bhVZcEbAEi62P9fA1DZoeOOjpnbfO8hx9j/1gDUXaHvNt/XDUGZXEU 1cXf8j4Csd/ZnTTVgQdCm5WY3CjIccFkvkZCYx2Aq9OLUID9RddDqMx/h964vIQUJDjU jgv6AQxPfP4eFJNO41OQ7WC02MG8TAZhW5FzBvjNvsgHTnX5x2lW7KLdFVW55H+cX8VK JmFtuk5xa/z46DcIyvoH+oOdFdPHcpIANyaFjksS0kAzGUoNlHZHNY/J8sJWW82ZA54a wzKg== MIME-Version: 1.0 X-Received: by 10.129.41.193 with SMTP id p184mr21453681ywp.278.1450839327466; Tue, 22 Dec 2015 18:55:27 -0800 (PST) Received: by 10.129.145.85 with HTTP; Tue, 22 Dec 2015 18:55:27 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Dec 2015 10:55:27 +0800 Message-ID: From: Zhen Cao To: GangChen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Margaret , "mif@ietf.org" , Hui Deng Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 02:55:30 -0000 The new text looks fine to me. Thanks. On Fri, Dec 18, 2015 at 9:42 AM, GangChen wrote: > Hello Zhen, > > Thank you for the comments. > I would like to propose the following new texts for the abstract: > > This memo proposes extensions to the Happy Eyeball(HE) defined in RFC6555 to > fit into multiple provisioning domain architecture. Happy Eyeballs in > MIF would make the > selection process smoother by using the connectivity checks over a > pre-filtered interfaces according to defined policy. This would > choose the fastest interface with an automatic fallback. > > Please kindly to check. > > BRs > > Gang > > 2015-12-17 22:34 GMT+08:00, Zhen Cao : >> Dear All, >> >> To clarify, I read the draft indicated by this link >> https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 >> >> I find the document is ready to be published. (Actually it should be >> published earlier. This problem was well recognized at the very >> beginning, but now it seems the interest has declined. ) >> >> Some editorial comments to the abstract: >> >> Old: Currently the interface selection in multi-interface environment is >> exclusive - only one interface can be used at the time, frequently >> needing manual intervention. >> >> - I do like this argument, neither should any MIFers, since the MIF wg >> has developed many solutions to help interface selection based on >> domain names, APNs, PvDs. >> >> >> Cheers, >> Zhen >> >> On Tue, Dec 8, 2015 at 12:47 PM, Hui Deng wrote: >>> Hello all >>> >>> We have two weeks WG last call for below document: >>> https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt >>> >>> Please send your comments to this thread. >>> This WGLC will end on Dec. 22nd. >>> >>> Best regards, >>> >>> Cochairs. >>> >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> From nobody Wed Dec 23 01:58:11 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEC71ACE37 for ; Wed, 23 Dec 2015 01:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOfm73ZUxLCM for ; Wed, 23 Dec 2015 01:58:07 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 7F7261ACE36 for ; Wed, 23 Dec 2015 01:58:07 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id o11so73296571qge.2 for ; Wed, 23 Dec 2015 01:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=WqEuBxWHY5nZAt6/29bUtoeVAyq09KMEoAgdUYwM4HI=; b=PlRt2fAe2ah4QfUWU5XyGRSwyHC8eFKQFABklcYwIhomBfwXqlH7Zqb6eAyJXcE9mo zWRguvHGOBn8FzgSCLtCa/8Yzak45lWfBPHPZOsBd0xqJI+DnwPhPwdqVqlQ6QtdWY56 pUVm4XNdbF+mZRMpgVbUYXCo5rPmvvOWGQdsUqnzIUTIahkTc+aMbMHE4mrYjw74eFM7 G7N9IJD1I/wiZlBo2khE8u9szvEoEL28nIeiSFB84wpAuwcfbyRQPo+JiUSp+9alKk85 9W0L49VX5ssHjlez6KgZ8cSQ8cblcPbzVMFB1X2WGPlxR+Jt1mrWxV9A5Mq6IvxErAm7 G4zg== X-Received: by 10.140.139.71 with SMTP id 68mr19586028qhl.51.1450864686736; Wed, 23 Dec 2015 01:58:06 -0800 (PST) Received: from hedwig-33.prd.orcali.com (ec2-54-85-253-40.compute-1.amazonaws.com. [54.85.253.40]) by smtp.gmail.com with ESMTPSA id 17sm17674939qhp.1.2015.12.23.01.58.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Dec 2015 01:58:05 -0800 (PST) Date: Wed, 23 Dec 2015 01:58:05 -0800 (PST) X-Google-Original-Date: Wed, 23 Dec 2015 09:58:05 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1450864685444.1f2264b8@Nodemailer> In-Reply-To: References: X-Orchestra-Oid: 1EF0E5CD-B63E-47CA-8191-A94682D009E1 X-Orchestra-Sig: ef18e1b2f0aa9faad5c4425c6da13fd97090157d X-Orchestra-Thrid: TF6799EDC-33A1-4EA4-9687-CF1647E8820B_1519989804826721265 X-Orchestra-Thrid-Sig: 24d55955220a94df7f297b7a5199191d4e1efeaf X-Orchestra-Account: b9d2ec835f5c6b3d1dd8401e68c2c8b0d3a853fe From: maxpassion@gmail.com To: "Hui Deng" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1450864685704" Archived-At: Cc: mif@ietf.org, Margaret Subject: Re: [mif] WGLC for MIF happy eyeballs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 09:58:10 -0000 ------Nodemailer-0.5.0-?=_1-1450864685704 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all=EF=BC=8C I have read the latest version. Since mif PVD architecture has been = finalized and mif happy eyeball will not affect the architecture I think = this document is ready for moving forward. One editorial comment=EF=BC=9AWe'd better use Wi-Fi instead of WiFi in the = document. Dapeng Liu =E2=80=94
=E9=80=9A=E8=BF=87 Mailbox =E5=8F=91=E9=80=81 2015 =E5=B9=B4 12=E6=9C=88 8 =E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C 7:47 = PM=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A Hello all We have two weeks WG last call for below document: https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.= txt Please send your comments to this thread. This WGLC will end on Dec. 22nd. Best regards, Cochairs. ------Nodemailer-0.5.0-?=_1-1450864685704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all，

I have read the latest version. = Since mif PVD architecture has been finalized and mif happy eyeball will = not affect the architecture I think this document is ready for moving = forward.

One editorial comment：We'd better use Wi-Fi instead = of WiFi in the document.

Dapeng Liu

—<br>通= 过 <a href=3D=22https://www.dropbox.com/mailbox=22>Mailbox = </a>发送

2015 年 12月 8 日 = 星期二 7:47 PM，Hui Deng <denghui02@hotmail.= com> 写道：

Hello all

We have two weeks WG last call for below document:
https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension= -04.txt

Please send your comments to this thread.
This WGLC will end on Dec. 22nd.

Best regards,

Cochairs.

------Nodemailer-0.5.0-?=_1-1450864685704-- From nobody Wed Dec 23 07:24:19 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242391A02F1 for ; Wed, 23 Dec 2015 07:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rr_ui9yW1GD for ; Wed, 23 Dec 2015 07:24:15 -0800 (PST) Received: from COL004-OMC2S2.hotmail.com (col004-omc2s2.hotmail.com [65.55.34.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC0B1A024C for ; Wed, 23 Dec 2015 07:24:15 -0800 (PST) Received: from COL125-W40 ([65.55.34.71]) by COL004-OMC2S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 23 Dec 2015 07:24:15 -0800 X-TMN: [n4Xoaw4NFCXmvbEqs+xndK3Xg0djDNhxTLCVsCFYxRc=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_1df3c954-963b-40ab-af2e-6984b76ea2de_" From: Hui Deng To: "mif@ietf.org" , Margaret Date: Wed, 23 Dec 2015 23:24:14 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Dec 2015 15:24:15.0260 (UTC) FILETIME=[FBB1A5C0:01D13D95] Archived-At: Subject: [mif] Conclusion of MIF Happy Eyeball WGLC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 15:24:18 -0000 --_1df3c954-963b-40ab-af2e-6984b76ea2de_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQpXZSBoYXZlIGNvbXBsZXRlZCBXR0xDIGZvciBNSUYgSGFwcHkgRXllYmFsbCBk cmFmdCwgYXV0aG9ycyBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IGFzIHRoZSBiZWxvdyBsaW5rOmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1pZi1oYXBweS1leWViYWxscy1l eHRlbnNpb24tMDgNCkkgaGVhcmQgb25lIGNvbmNlcm4gYWJvdXQgdGhlIHdhaXRpbmcgdW50aWwg TVBWRCBpc3N1ZSByZXNvbHZlZCBBcyBhdXRob3IgZXhwbGFpbmVkIHRoYXQgdGhpcyBkcmFmdCBp cyBub3QgYmluZGluZyB3aXRoIE1QVkQgY2x1c3RlciBkcmFmdHMsIGFuZCBiYXNlZCBvbiB0aGUg ZW5vdWdoIHN1cHBvcnRpbmcgZnJvbSBvdGhlcnMsIGNoYWlycyBhcmUgY29udmluY2VkIHRoYXQg dGhpcyBkcmFmdCBjb3VsZCBtb3ZlIGZvcndhcmQsIGNoYWlycyB3aWxsIHByZXBhcmUgdGhlIHdy aXRldXAgYW5kIHN1Ym1pdCB0byBvdXIgQUQuDQpUaGFua3MgZm9yIGtpbmQgcmV2aWV3IGFuZCBj b21tZW50cy4NCkJlc3QgcmVnYXJkcywNCkNvY2hhaXJzLg0KIAkJIAkgICAJCSAg --_1df3c954-963b-40ab-af2e-6984b76ea2de_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPGRpdj48YnI+PC9kaXY+PGRpdj5XZSBo YXZlIGNvbXBsZXRlZCBXR0xDIGZvciBNSUYgSGFwcHkgRXllYmFsbCBkcmFmdCwgYXV0aG9ycyBo YXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IGFzIHRoZSBiZWxvdyBsaW5rOjwvZGl2PjxkaXY+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWlmLWhhcHB5LWV5ZWJh bGxzLWV4dGVuc2lvbi0wOCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1pZi1oYXBweS1leWViYWxscy1leHRlbnNpb24tMDg8L2E+PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5JIGhlYXJkIG9uZSBjb25jZXJuIGFib3V0IHRoZSB3YWl0aW5n IHVudGlsIE1QVkQgaXNzdWUgcmVzb2x2ZWQgQXMgYXV0aG9yIGV4cGxhaW5lZCB0aGF0IHRoaXMg ZHJhZnQmbmJzcDs8L2Rpdj48ZGl2PmlzIG5vdCBiaW5kaW5nIHdpdGggTVBWRCBjbHVzdGVyIGRy YWZ0cywgYW5kIGJhc2VkIG9uIHRoZSBlbm91Z2ggc3VwcG9ydGluZyBmcm9tIG90aGVycywgY2hh aXJzIGFyZSBjb252aW5jZWQgdGhhdCZuYnNwOzwvZGl2PjxkaXY+dGhpcyBkcmFmdCBjb3VsZCBt b3ZlIGZvcndhcmQsIGNoYWlycyB3aWxsIHByZXBhcmUgdGhlIHdyaXRldXAgYW5kIHN1Ym1pdCB0 byBvdXIgQUQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFua3MgZm9yIGtpbmQgcmV2aWV3 IGFuZCBjb21tZW50cy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJlc3QgcmVnYXJkcyw8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNvY2hhaXJzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PiAJCSAJ ICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_1df3c954-963b-40ab-af2e-6984b76ea2de_--