From trac+mif@trac.tools.ietf.org Thu Nov 1 00:03:01 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACE921F8549 for ; Thu, 1 Nov 2012 00:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-psNauLChar for ; Thu, 1 Nov 2012 00:03:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7392D21F8203 for ; Thu, 1 Nov 2012 00:03:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:54082 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTonm-0005je-2z; Thu, 01 Nov 2012 08:02:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 07:02:54 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/12 Message-ID: <051.0d3be817b23faf791968227bf57c2f12@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101070300.7392D21F8203@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 00:03:00 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #12: walled garden use case #7 is invalid as motivation X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 07:03:01 -0000 #12: walled garden use case #7 is invalid as motivation Quoting from IAB document http://tools.ietf.org/html/rfc3002 section 4.2.1 : "It was strongly recommended that independent of the ubiquity of the 'walled garden' deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an 'open model'." As such, I believe that the IETF should not permit walled garden scenarios to be presented as valid motivations. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Thu Nov 1 00:20:39 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9360221F8506 for ; Thu, 1 Nov 2012 00:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKAP5zLva-o3 for ; Thu, 1 Nov 2012 00:20:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F210421F84E9 for ; Thu, 1 Nov 2012 00:20:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:55605 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTp4c-0004AE-Ck; Thu, 01 Nov 2012 08:20:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 07:20:18 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/13 Message-ID: <051.525a75f2c885ce863052f43abb54e3a4@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101072038.F210421F84E9@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 00:20:38 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #13: motivation use case #10 is self-referential X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 07:20:39 -0000 #13: motivation use case #10 is self-referential This argument of the form "if X, which creates a conflict, then X breaks the conflict, therefore justifying X in the first place". That seems extremely weak as a motivation, and should be removed from this section. Further on, the document appears to be somewhat in conflict with itself. The -05 version of section 7.1 says "Information received via Route Options over DHCPv6 MUST be treated equally to routing information obtained via other sources." For "tie-breaking" behaviour, would the DHCPv6-learned routes not need to take precedence? Summary recommendation: remove the motivation, clarify conflict resolution. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: minor | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Thu Nov 1 01:22:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3D21F8514 for ; Thu, 1 Nov 2012 01:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnLiNYj5CYkx for ; Thu, 1 Nov 2012 01:22:35 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 255AA21F8513 for ; Thu, 1 Nov 2012 01:22:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:60818 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTq2K-0007xs-Sz; Thu, 01 Nov 2012 09:22:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 08:22:00 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/14 Message-ID: <051.5204940b3cd3028f5262fab79fae85b8@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101082235.255AA21F8513@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 01:22:35 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #14: use case #6 is insufficient and should be removed X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 08:22:36 -0000 #14: use case #6 is insufficient and should be removed Use case #6 speculates "we cannot assume all the VPN network only use RA". This statement lacks evidence. Why can we not expect them to support RAs? Why can we expect that they would support this DHCPv6 option? There's no convincing technical reason in this use case why it should be preferred nor why the IETF should prefer it. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Thu Nov 1 01:47:01 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4221F8511 for ; Thu, 1 Nov 2012 01:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwDPHSsK8s1I for ; Thu, 1 Nov 2012 01:47:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9144221F852C for ; Thu, 1 Nov 2012 01:47:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:34796 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTqQ5-0005WT-MJ; Thu, 01 Nov 2012 09:46:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 08:46:33 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/15 Message-ID: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101084700.9144221F852C@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 01:47:00 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 08:47:01 -0000 #15: use case #1 does not justify standardization of this option Use case #1 should remove the reference to walled gardens as a motivation (see RFC 3002, section 4.2.1 and other tickets on this theme). This option does not obviate the need for customer edge routers (CPEs) to route ("to avoid routing on the CPE"). Why should we not expect a router to route? Furthermore, this use case does not justify why customer edge routers would need this. Instead, this use case documents a need for a protocol to provision network provider edge routers, which is something different. Recommendation: remove this use case. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Thu Nov 1 01:49:19 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AB221F8513 for ; Thu, 1 Nov 2012 01:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3-1EPgEcesZ for ; Thu, 1 Nov 2012 01:49:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B8EEE21F8511 for ; Thu, 1 Nov 2012 01:49:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:34941 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TTqSc-00041t-8q; Thu, 01 Nov 2012 09:49:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 01 Nov 2012 08:49:10 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/15#comment:1 Message-ID: <066.fc9f9edf86a8f3e292885484226b05fa@trac.tools.ietf.org> References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121101084918.B8EEE21F8511@ietfa.amsl.com> Resent-Date: Thu, 1 Nov 2012 01:49:18 -0700 (PDT) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 08:49:19 -0000 #15: use case #1 does not justify standardization of this option Comment (by ek@…): Furthermore, the reference to the BBF document should be remove. http://www.broadband-forum.org/technical/download/TR-124_Issue-3.pdf does not seem to cite the draft as a "work in progress", which may simply have been an oversight. However, since the text at the top of the document clearly says "[i]t is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress'" it does not seem valid to construct what is essentially a self-referential motivating use case. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: mif From denghui02@hotmail.com Thu Nov 1 21:16:37 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B5B21F9902 for ; Thu, 1 Nov 2012 21:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaJcmmrt3OND for ; Thu, 1 Nov 2012 21:16:36 -0700 (PDT) Received: from col0-omc2-s2.col0.hotmail.com (col0-omc2-s2.col0.hotmail.com [65.55.34.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFEE21F98F5 for ; Thu, 1 Nov 2012 21:16:36 -0700 (PDT) Received: from COL125-W25 ([65.55.34.73]) by col0-omc2-s2.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Nov 2012 21:16:34 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c80c7939-604a-4c81-836d-ec8c16b9b030_" X-Originating-IP: [107.17.121.49] From: Hui Deng To: Date: Fri, 2 Nov 2012 12:16:34 +0800 Importance: Normal In-Reply-To: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> References: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2012 04:16:34.0923 (UTC) FILETIME=[D879D3B0:01CDB8B0] Subject: [mif] FW: Help the NomCom: Community Feedback X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 04:16:37 -0000 --_c80c7939-604a-4c81-836d-ec8c16b9b030_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Please help nomcom -Hui> From: nomcom-chair@ietf.org > To: wgchairs@ietf.org > Subject: Help the NomCom: Community Feedback > Date: Wed, 31 Oct 2012 20:13:18 -0700 > > The IETF Nominations Committee (NomCom) continues to seek input from > the IETF Community. The NomCom would greatly appreciate any help you > could provide in making members of your working group aware of ways in > which they can provide valuable feedback to the NomCom. > > In order to ensure that your input is received in time to be useful, the > NomCom needs to receive community feedback on or before Sunday, November 4. > > The final list of candidates (as per RFC 5680) that the NomCom is > considering for open positions can be found at: > https://www.ietf.org/group/nomcom/2012/input/ > > The NomCom will be holding office hours during IETF 85, Monday- > Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes > comments on specific individuals, as well as general feedback related to > any of the positions that NomCom is considering. > > Note: A list of leadership positions that the NomCom is considering can be > found at: https://www.ietf.org/group/nomcom/2012/ > > If the NomCom office hours are inconvenient for you or if you cannot > attend IETF 85, the NomCom is happy to take community input via email > to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a > meeting outside of office hours, just send us email and we can set > something up. > > Comments on specific candidates can also be provided to the NomCom > via the web feedback tool: > https://www.ietf.org/group/nomcom/2012/input/ > > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org --_c80c7939-604a-4c81-836d-ec8c16b9b030_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

 Please help nomcom
 
-Hui
> From: nomcom-chair@ietf.org
> To: wgchairs@ietf.org
> Subject: Help the NomCom: Community Feedback
> Date: Wed, 31 Oct 2012 20:13:18 -0700
>
> The IETF Nominations Committee (NomCom) continues to seek input from
> the IETF Community. The NomCom would greatly appreciate any help you
> could provide in making members of your working group aware of ways in
> which they can provide valuable feedback to the NomCom.
>
> In order to ensure that your input is received in time to be useful, the
> NomCom needs to receive community feedback on or before Sunday, November 4.
>
> The final list of candidates (as per RFC 5680) that the NomCom is
> considering for open positions can be found at:
> https://www.ietf.org/group/nomcom/2012/input/
>
> The NomCom will be holding office hours duri ng IETF 85, Monday-
> Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes
> comments on specific individuals, as well as general feedback related to
> any of the positions that NomCom is considering.
>
> Note: A list of leadership positions that the NomCom is considering can be
> found at: https://www.ietf.org/group/nomcom/2012/
>
> If the NomCom office hours are inconvenient for you or if you cannot
> attend IETF 85, the NomCom is happy to take community input via email
> to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a
> meeting outside of office hours, just send us email and we can set
> something up.
>
> Comments on specific candidates can also be provided to the NomCom
> via the web feedback tool:
> https://www.ietf.org/group/nomcom/2012/input/
>
> Thank you for your help,
> - Matt Lepinski
> nomcom-chair@ ietf.org
--_c80c7939-604a-4c81-836d-ec8c16b9b030_-- From denghui02@hotmail.com Thu Nov 1 21:17:44 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636621F9930 for ; Thu, 1 Nov 2012 21:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-AQIwYXDczE for ; Thu, 1 Nov 2012 21:17:44 -0700 (PDT) Received: from col0-omc2-s4.col0.hotmail.com (col0-omc2-s4.col0.hotmail.com [65.55.34.78]) by ietfa.amsl.com (Postfix) with ESMTP id EDC8C21F990F for ; Thu, 1 Nov 2012 21:17:43 -0700 (PDT) Received: from COL125-W33 ([65.55.34.72]) by col0-omc2-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Nov 2012 21:17:43 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_624e6278-e1da-4d6f-8b7c-ed0bb7cb3c13_" X-Originating-IP: [107.17.121.49] From: Hui Deng To: Date: Fri, 2 Nov 2012 12:17:43 +0800 Importance: Normal In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2012 04:17:43.0647 (UTC) FILETIME=[017046F0:01CDB8B1] Subject: [mif] FW: CORRECTION: Help the NomCom X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 04:17:44 -0000 --_624e6278-e1da-4d6f-8b7c-ed0bb7cb3c13_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit excuse me, this is the correct version -Hui > From: nomcom-chair@ietf.org > To: wgchairs@ietf.org > Subject: CORRECTION: Help the NomCom > Date: Thu, 1 Nov 2012 05:17:22 -0700 > > I sent a message several hours ago requesting that you help and make > your working group aware that the NomCom is looking for input from the > community. This message had a minor error. The NomCom needs to > receive community input by November 11, 2012. > > The full text of the corrected message is below > --------------------------------------------------- > > The IETF Nominations Committee (NomCom) continues to seek input from > the IETF Community. The NomCom would greatly appreciate any help you > could provide in making members of your working group aware of ways in > which they can provide valuable feedback to the NomCom. > > In order to ensure that your input is received in time to be useful, the > NomCom needs to receive community feedback on or before Sunday, November 11. > > The final list of candidates (as per RFC 5680) that the NomCom is > considering for open positions can be found at: > https://www.ietf.org/group/nomcom/2012/input/ > > The NomCom will be holding office hours during IETF 85, Monday- > Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes > comments on specific individuals, as well as general feedback related to > any of the positions that NomCom is considering. > > Note: A list of leadership positions that the NomCom is considering can be > found at: https://www.ietf.org/group/nomcom/2012/ > > If the NomCom office hours are inconvenient for you or if you cannot > attend IETF 85, the NomCom is happy to take community input via email > to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a > meeting outside of office hours, just send us email and we can set > something up. > > Comments on specific candidates can also be provided to the NomCom > via the web feedback tool: > https://www.ietf.org/group/nomcom/2012/input/ > > Thank you for your help, > - Matt Lepinski > nomcom-chair at ietf.org --_624e6278-e1da-4d6f-8b7c-ed0bb7cb3c13_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

excuse me, this is the correct version
 
-Hui 
> From: nomcom-chair@ietf.org
> To: wgchairs@ietf.org
> Subject: CORRECTION: Help the NomCom
> Date: Thu, 1 Nov 2012 05:17:22 -0700
>
> I sent a message several hours ago requesting that you help and make
> your working group aware that the NomCom is looking for input from the
> community. This message had a minor error. The NomCom needs to
> receive community input by November 11, 2012.
>
> The full text of the corrected message is below
> ---------------------------------------------------
>
> The IETF Nominations Committee (NomCom) continues to seek input from
> the IETF Community. The NomCom would greatly appreciate any help you
> could provide in making members of your working group aware of ways in
> which they can provide valuable feedback to the NomCom.>
> In order to ensure that your input is received in time to be useful, the
> NomCom needs to receive community feedback on or before Sunday, November 11.
>
> The final list of candidates (as per RFC 5680) that the NomCom is
> considering for open positions can be found at:
> https://www.ietf.org/group/nomcom/2012/input/
>
> The NomCom will be holding office hours during IETF 85, Monday-
> Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes
> comments on specific individuals, as well as general feedback related to
> any of the positions that NomCom is considering.
>
> Note: A list of leadership positions that the NomCom is considering can be
> found at: https://www.ietf.org/group/nomcom/2012/
>
> If the NomCom office hours are inconvenient for you or if you cannot
> attend IETF 85, the NomCom is happy to take community input via email
> t o nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a
> meeting outside of office hours, just send us email and we can set
> something up.
>
> Comments on specific candidates can also be provided to the NomCom
> via the web feedback tool:
> https://www.ietf.org/group/nomcom/2012/input/
>
> Thank you for your help,
> - Matt Lepinski
> nomcom-chair at ietf.org
--_624e6278-e1da-4d6f-8b7c-ed0bb7cb3c13_-- From alexandru.petrescu@gmail.com Fri Nov 2 08:39:18 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7610221F8B90 for ; Fri, 2 Nov 2012 08:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+XhKTD4Befu for ; Fri, 2 Nov 2012 08:39:17 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 94DE321F8B38 for ; Fri, 2 Nov 2012 08:39:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qA2FdFUY004392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Nov 2012 16:39:15 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qA2FdFEt015361 for ; Fri, 2 Nov 2012 16:39:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-21.intra.cea.fr [132.166.201.21]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qA2FdB0S015378 for ; Fri, 2 Nov 2012 16:39:15 +0100 Message-ID: <5093E91F.2090506@gmail.com> Date: Fri, 02 Nov 2012 16:39:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> In-Reply-To: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 15:39:18 -0000 Hello, Le 01/11/2012 09:46, mif issue tracker a écrit : > #15: use case #1 does not justify standardization of this option > > Use case #1 should remove the reference to walled gardens as a > motivation (see RFC 3002, section 4.2.1 and other tickets on this > theme). > > This option does not obviate the need for customer edge routers > (CPEs) to route ("to avoid routing on the CPE"). Why should we not > expect a router to route? > > Furthermore, this use case does not justify why customer edge > routers would need this. Instead, this use case documents a need for > a protocol to provision network provider edge routers, which is > something different. > > Recommendation: remove this use case. I am not in a position to comment on the relevance of this use-case 1 "In Broadband network environment where the CPE is multi-homed to two upstream edge routers and each router provides connectivity for different..." I think authors of this use-case have a reason for having suggested it. On another hand, there are a number of other use cases that may need this DHCP route-option behaviour. Some specific to the default route aspect of a general route are described in draft-mouton-mif-dhcpv6-drlo-02.txt ("Large Mobile Network Use Case", "Mi-Fi Coverage Extension Use Case", "M2M Constrained Device Use Case"). Alex From denghui02@gmail.com Sun Nov 4 07:10:57 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196EA21F86F1 for ; Sun, 4 Nov 2012 07:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnGHShW-CTib for ; Sun, 4 Nov 2012 07:10:56 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8647B21F8749 for ; Sun, 4 Nov 2012 07:10:56 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id 25so1704760qao.10 for ; Sun, 04 Nov 2012 07:10:56 -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=uBgFFDguQ92oduHUzgV1KTSBjnbAEMRoHMSBCh9bcPc=; b=YlAqEwyYoX/hkgQUR+R28tpjUZYQsmUQL3cdOj8lJEwIp+RScE/V4e6Cm3PmQdudrv fD53JO2KiaaX/iZwF4O8tTjIDqkfVOvOFbjBqrDaD3Fu2QCw64jofeFALt1zn/nAP6OU aekNpWlFcSK3ORgSHsi7li+IZFs0vh6u6TRQvDb9BxyzTvkuyqTbG3sMwqUCgXijLpAB wcTJFUCdtVfzZLbl0C3WY3XKGdJrvOJfsSy9MDulV9vtCQo+vV80nBVT2wpvIfycO8R+ Sk4VyJbLsEOMh8DkkVYEJMTcSjj0iGx9iD8uqeyEOn7EhlYxzmDBtWQNqCgjKnY0yIvE aTGg== MIME-Version: 1.0 Received: by 10.224.59.197 with SMTP id m5mr1100429qah.4.1352041856043; Sun, 04 Nov 2012 07:10:56 -0800 (PST) Received: by 10.49.97.4 with HTTP; Sun, 4 Nov 2012 07:10:56 -0800 (PST) Date: Sun, 4 Nov 2012 10:10:56 -0500 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=20cf3074d8a48d09cb04cdacc614 Subject: [mif] Agenda Update X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:10:57 -0000 --20cf3074d8a48d09cb04cdacc614 Content-Type: text/plain; charset=ISO-8859-1 Hello all Cochairs have updated the agenda, Thanks for your checking -Hui --20cf3074d8a48d09cb04cdacc614 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Cochairs=A0have updated the agenda,<= /div>
Thanks for your checking
=A0
-Hui
--20cf3074d8a48d09cb04cdacc614-- From mglt.ietf@gmail.com Mon Nov 5 04:48:42 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1B21F85FE; Mon, 5 Nov 2012 04:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScQhj6qxKXEb; Mon, 5 Nov 2012 04:48:42 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A03B821F8599; Mon, 5 Nov 2012 04:48:41 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6521040vbb.31 for ; Mon, 05 Nov 2012 04:48:41 -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 :content-type; bh=NDhxxm30H7c5sb/3SltOEGaiDTsZGWI9m90/8EqdN+c=; b=xyQetWM+gqi2bqOl2WtVFZwklEAuP1XuiLbl4jG8Ji7tnw1J9Jk9kIBcMdNu7ysraZ 7MyUvuT6hcgR4s4Nckz+omv8+p7soTX1+ZNtN6w1Q3j1U+IiDMcwvhq6nC+X7FCnihpF 8b1Fy8xHZd6/+AtUAJoZEDm02gr7hoXp/oAfHMHdlaj6NiMmbx7xhtpClkGELlBEJbS0 +2udqKpFITXNVI22afwio7rYjOXicApKoGsm263VSZLQH0WENnleR0edNrmzACLuQ8VQ OLubkm0oNwINojDKKIqvBy6VqBF6umd2FAyNfHi4KTchPnD7tDX3F7E8fOyPKD/ckaLU B8gA== MIME-Version: 1.0 Received: by 10.52.34.42 with SMTP id w10mr8281383vdi.10.1352119721103; Mon, 05 Nov 2012 04:48:41 -0800 (PST) Received: by 10.58.155.69 with HTTP; Mon, 5 Nov 2012 04:48:41 -0800 (PST) In-Reply-To: <20121105124656.1185.88759.idtracker@ietfa.amsl.com> References: <20121105124656.1185.88759.idtracker@ietfa.amsl.com> Date: Mon, 5 Nov 2012 07:48:41 -0500 Message-ID: From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary=20cf3079bb98ab8f2804cdbee72d Subject: [mif] Fwd: New Version Notification for draft-mglt-mif-security-requirements-03.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:48:43 -0000 --20cf3079bb98ab8f2804cdbee72d Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is the new version of our draft on IPsec and multiple Interfaces. Best Regards, Daniel ---------- Forwarded message ---------- From: Date: Mon, Nov 5, 2012 at 7:46 AM Subject: New Version Notification for draft-mglt-mif-security-requirements-03.txt To: mglt.ietf@gmail.com Cc: carlw@mcsr-labs.org A new version of I-D, draft-mglt-mif-security-requirements-03.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-mif-security-requirements Revision: 03 Title: IPsec Multiple Interfaces Problem Statement Creation date: 2012-11-03 WG ID: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-mglt-mif-security-requirements-03.txt Status: http://datatracker.ietf.org/doc/draft-mglt-mif-security-requirements Htmlized: http://tools.ietf.org/html/draft-mglt-mif-security-requirements-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-mif-security-requirements-03 Abstract: IKEv2 is the protocol used to set up and negotiate Security Associations between nodes. IKEv2 has not been designed for nodes with multiple interfaces. This document is focused on IKEv2 ability to set up IPsec protected communications between nodes with multiple interfaces. This document states the problems and provides requirements for IKEv2 to ease IPsec for multiple interface communication. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --20cf3079bb98ab8f2804cdbee72d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=A0

Here is the new version of our draft on IPsec and= multiple Interfaces.

Best Regards,=A0
D= aniel

---------- Forwarded message ------= ----
From: <internet-drafts@ietf.org>
= Date: Mon, Nov 5, 2012 at 7:46 AM
Subject: New Version Notification for = draft-mglt-mif-security-requirements-03.txt
To: mglt.ietf@gmail.com
Cc: <= a href=3D"mailto:carlw@mcsr-labs.org">carlw@mcsr-labs.org


A new version of I-D, draft-mglt-mif-security-requirements-03.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-mif-security-requirements
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 IPsec Multiple Interfaces Problem Statement
Creation date: =A0 2012-11-03
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 27
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-mglt-mif-security-requirements-03.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-mglt-mif-security-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-mglt-mif-security-requirements-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.= org/rfcdiff?url2=3Ddraft-mglt-mif-security-requirements-03

Abstract:
=A0 =A0IKEv2 is the protocol used to set up and negotiate Security
=A0 =A0Associations between nodes. =A0IKEv2 has not been designed for nodes=
=A0 =A0with multiple interfaces.

=A0 =A0This document is focused on IKEv2 ability to set up IPsec protected<= br> =A0 =A0communications between nodes with multiple interfaces. =A0This docum= ent
=A0 =A0states the problems and provides requirements for IKEv2 to ease IPse= c
=A0 =A0for multiple interface communication.




The IETF Secretariat




--
Daniel Migault
Orange = Labs -- Security
+33 6 70 72 69 58
--20cf3079bb98ab8f2804cdbee72d-- From n@arifumi.net Mon Nov 5 05:05:26 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054B721F86F9 for ; Mon, 5 Nov 2012 05:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvKEjPWn3qeS for ; Mon, 5 Nov 2012 05:05:25 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6967E21F86B5 for ; Mon, 5 Nov 2012 05:05:25 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so6480204vcb.31 for ; Mon, 05 Nov 2012 05:05:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=PA6g8w5L6QWubppZ46aI/KTEB6SRTUVTSPLZ6K4lrKk=; b=Di0YmqhcKDeCtRaHANgQvDbo4RIi3HqWGipTiOQtnH4t63Lrw+gUY0AKse9aSW+eww fEtnLEFhkxDc2c4KAHEpiKYFuj6VF7wyVNnU10Q5TcrbIx0Rkr7M1uVdFd1Z2a2IMFq5 D2CKjOGuI1ol4wN2wjT0HY2E6Rtz/Z6RVAl8DqU+5XItn/pFVB0B4S6FwEFoJqSuVP7X j14J+vuHalvUv9Lz8sHkDyiTEQC71VZm2UcDsoSyxmpRfifmP0yqlx+2AKRuAR3QFPjW t0A9RlOK0/BZHQRQlJcCZl2WIIuH7Iuz7JJ9bWFqoSDDphjB5Ler/rmEiDxifK/WGL/K hI6g== MIME-Version: 1.0 Received: by 10.220.8.73 with SMTP id g9mr9303833vcg.28.1352120724854; Mon, 05 Nov 2012 05:05:24 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Mon, 5 Nov 2012 05:05:24 -0800 (PST) X-Originating-IP: [65.111.75.199] Date: Mon, 5 Nov 2012 22:05:24 +0900 X-Google-Sender-Auth: Ki4HQr4k83ftunOMtfA5by1ERRY Message-ID: From: Arifumi Matsumoto To: "" Content-Type: multipart/alternative; boundary=bcaec54b49247f987f04cdbf23bc X-Gm-Message-State: ALoCoQnUeb2s3Ygn5ti1XyOp+26iR1uIue+9Ar3/D3j1513g8U0ggOSsob6brZx6xqU1ypQAggN4 Subject: [mif] dhcp route option issues on tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:05:26 -0000 --bcaec54b49247f987f04cdbf23bc Content-Type: text/plain; charset=ISO-8859-1 Hi, # should I comment to the list, or to the tracker ? Anyway. Thank you for filing issues on tracker site. After browsing through the filed issues, I found that the only blocker issue of this item is #9. http://trac.tools.ietf.org/wg/mif/trac/ticket/9 Other issues just suggest small changes to the draft, or deletion of specific use cases in the draft. The issue #9 argues about the "fate sharing" characteristics of RA. I admit it is surely an advantage of RA base mechanism. But, as you know it, RA and DHCP has its own benefits. So, IMHO, the single benefit of RA does not block the DHCP based mechanism. I don't know why this issue if the blocker of this draft. Thanks. --bcaec54b49247f987f04cdbf23bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

# should I comment to the list, or to the tracker ?= =A0Anyway.

Thank you for filing issues on tracker site.<= /div>
After browsing through the filed issues, I found that the only bl= ocker issue of this item is #9.

Other is= sues just suggest small changes to the draft, or deletion of specific use c= ases in the draft.

The issue #9 argues about the "fate sharing" = characteristics of RA.
I admit it is surely an advantage of= RA base mechanism. But, as you know it, RA and DHCP has its own benefits. = So, IMHO, the single benefit of RA does not block the DHCP based mechanism.=
I don't know why this issue if the blocker of this draft.

Thanks.
--bcaec54b49247f987f04cdbf23bc-- From brian.e.carpenter@gmail.com Mon Nov 5 05:59:43 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C9321F8496 for ; Mon, 5 Nov 2012 05:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR2Qtp8XoDdY for ; Mon, 5 Nov 2012 05:59:42 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98ECF21F84C5 for ; Mon, 5 Nov 2012 05:59:42 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3937796pbb.31 for ; Mon, 05 Nov 2012 05:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EA8cf/rJnljT2yChebVNupK6DI7FukyktPycP/c3ieE=; b=vjBRUavZFNivi00CV9wmilxxnOyeH2orxCFaD//lN8H+oXWqeY1WAkWdHXmq3UCxL1 QkWKc4XQmHJDkg/+15is8cKCORw3BHWDO2z43yPkYIXC1lQCMSaar+mZ33+rteDO7PdO EKlmzevLCXNlHv5ddE6+jKNPxe/1xn4IPf4TW1fVMps65PaTf8DZ0wV74oyPTd++comp SB53D30Umukqot6xXajArSjEf0kbIYGVyaFFeVtlDYHBRJbJhK/D2TOqGP2GofxuAle2 oUJWKlMkGR/nYuRh8GpXw7J9YFHfGKN1lEh/2PxITkreTByhYSPljBDjQ2P0ZgwiZ18M qRbg== Received: by 10.68.243.70 with SMTP id ww6mr27866668pbc.108.1352123981370; Mon, 05 Nov 2012 05:59:41 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id x8sm10696189paw.16.2012.11.05.05.59.40 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 05:59:40 -0800 (PST) Message-ID: <5097C64D.1060307@gmail.com> Date: Mon, 05 Nov 2012 13:59:41 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arifumi Matsumoto References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] dhcp route option issues on tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:59:43 -0000 On 05/11/2012 13:05, Arifumi Matsumoto wrote: > Hi, > > # should I comment to the list, or to the tracker ? Anyway. > > Thank you for filing issues on tracker site. > After browsing through the filed issues, I found that the only blocker > issue of this item is #9. > http://trac.tools.ietf.org/wg/mif/trac/ticket/9 > > Other issues just suggest small changes to the draft, or deletion of > specific use cases in the draft. > > The issue #9 argues about the "fate sharing" characteristics of RA. > I admit it is surely an advantage of RA base mechanism. But, as you know > it, RA and DHCP has its own benefits. So, IMHO, the single benefit of RA > does not block the DHCP based mechanism. > I don't know why this issue if the blocker of this draft. It seems to me to be a weak argument anyway. Fate sharing is valuable in the context of the end to end argument, but that is not in question here. Yes, the DHCP server is a different point of failure from the router, but both of them are single points of failure for the network as a whole. If you are running DHCP at all, it must never fail. I don't think this is a blocking issue, either. Regards Brian Carpenter Cell phone during IETF85: +1 847 219 0880 From Ted.Lemon@nominum.com Mon Nov 5 06:09:07 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6791721F8681 for ; Mon, 5 Nov 2012 06:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu2vAHMeZ2gM for ; Mon, 5 Nov 2012 06:09:06 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9FE21F8674 for ; Mon, 5 Nov 2012 06:09:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUJfIgtMyvfQITIJCCeXaxuF8p0cLfKCY@postini.com; Mon, 05 Nov 2012 06:09:06 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A26751B82CF for ; Mon, 5 Nov 2012 06:09:05 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9771D19005C; Mon, 5 Nov 2012 06:09:05 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 06:09:05 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] dhcp route option issues on tracker Thread-Index: AQHNu1Y6xVWbpjVinkCl+wk+5N9rMZfbywmAgAACogA= Date: Mon, 5 Nov 2012 14:09:05 +0000 Message-ID: <4B68BF2C-3D07-4111-8418-6E2272C82046@nominum.com> References: <5097C64D.1060307@gmail.com> In-Reply-To: <5097C64D.1060307@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] dhcp route option issues on tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 14:09:07 -0000 On Nov 5, 2012, at 8:59 AM, Brian E Carpenter = wrote: > I don't think this is a blocking issue, either. +1 From tomasz.mrugalski@gmail.com Mon Nov 5 07:08:34 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A62E21F84E6 for ; Mon, 5 Nov 2012 07:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITU0fQVuFwPJ for ; Mon, 5 Nov 2012 07:08:34 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21B4221F84DB for ; Mon, 5 Nov 2012 07:08:34 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so3987115pad.31 for ; Mon, 05 Nov 2012 07:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=yy4xBVgt/5+Z/rIDboApj9r6aA4TmqGBg2S4YMCpVsM=; b=ctD75m7gk7F+QaAvNgepXfGPyHSJLzO7E1B2s1ZKWegGrUo4ckxu6rPyI6T//QiMYI Dn3/rImEN3vD5PjL+WE1JcgUugtkqk1tXf/HhMn1nQdf23LWMbaRO758VplRhb76X7D3 kbwaS0VYQUKGJRynyLCWBLf0jU1BLxzfK5QfIkUND7WcJtAJZbnfV+ZZlHdhekYYEaCW gMijuZb4fgvW9jMIB2wUhjBa9ReRwS7Vcu3K0NKjJnN2v4KW9IJU5Sz5PQmGoG8kjqCu ktGPHtewwq9vcuxw+qTWKhNx7nH7L8NZ/6jdJtAwlQT0Ve6x0IPKsiQ0K1oz0G5XyN1c calA== Received: by 10.66.86.101 with SMTP id o5mr29281962paz.15.1352128113857; Mon, 05 Nov 2012 07:08:33 -0800 (PST) Received: from dhcp-1213.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id nd6sm10684461pbc.68.2012.11.05.07.08.32 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 07:08:33 -0800 (PST) Message-ID: <5097D66E.9060305@gmail.com> Date: Mon, 05 Nov 2012 10:08:30 -0500 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <5097C64D.1060307@gmail.com> In-Reply-To: <5097C64D.1060307@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] dhcp route option issues on tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:08:34 -0000 On 12-11-05 08:59, Brian E Carpenter wrote: > I don't think this is a blocking issue, either. +1 A question to people who think that lack of fate sharing is a deal breaker: There are currently 78 DHCPv6 options defined. Is DHCPv6 server supposed to share faith with all those services? Tomek From ek@google.com Mon Nov 5 07:15:15 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0494121F84E3 for ; Mon, 5 Nov 2012 07:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y75WHOU7GvBP for ; Mon, 5 Nov 2012 07:15:14 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDE021F8694 for ; Mon, 5 Nov 2012 07:15:14 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so260233qca.31 for ; Mon, 05 Nov 2012 07:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=CbqFJ7hHwb/3hOzdcEhu02KqfLfEmM/Ly/rsKMmwgKY=; b=Bx/Bugay4LAPBgRSbSKnSfLrL1Jg9Es5ABpvzW1m5OaNezoBUtcMZHdV7+Pb00n03c 0PN6AyeT/kL5nYaAJEBBI9/KBz/7OZYfKUupyXQak0c+SXuXB2VOirPs2r8MK0xrCxNE losev4ETP6S76SsWS4CkLu/btk4Un0d6P7h/iGCR8xYOoOfSA6MnaSTfeiY9RFV882jl NB3IdsPpdEuAeCF7HTlL7fVd74RqMzsh3IGpHJO7oQziGSg3X5t4BkI7G/zQguI5nIAj AcbqOtkPCZ/G9QhqJipxzTHstT4M3+zHc2GYMkbmDUG5AIt8qNC4iMbleKR3X+oDqRik 36NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=CbqFJ7hHwb/3hOzdcEhu02KqfLfEmM/Ly/rsKMmwgKY=; b=MoKCZKVltRBIZMF4pLjBspFpKMkt0CZodwnOsnyy4qeRdGOJNGPh1RmGYe86H/e+4C sAe5Fdw0vV1iGgPZZjf6G6xEzmXTOR1Jdl5Tcx7UD4xN2RAngtfCMrxn5ngBMdYJLXwv sunAh0UgFyQ+XZSEcqmrbvEGYApvIYuXZzOxDE2qeWVGdxVXbzfR4sBO63cgCe+epBNK TezqfKzk14jPyV8WRa1C/1SLCdL8wfsehScmQCJ63bvCpIPi2Iccc78r8xGGNadP6Zom 4lycpmmw+xG/tkUJC/TW7lmdBt2bvRYOl93a/qxiOaH72tI7mF3/bSIMYTjIJ953ubPd e/qg== Received: by 10.224.27.3 with SMTP id g3mr15069230qac.44.1352128513829; Mon, 05 Nov 2012 07:15:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.192.76 with HTTP; Mon, 5 Nov 2012 07:14:53 -0800 (PST) In-Reply-To: <5097D66E.9060305@gmail.com> References: <5097C64D.1060307@gmail.com> <5097D66E.9060305@gmail.com> From: Erik Kline Date: Tue, 6 Nov 2012 00:14:53 +0900 Message-ID: To: Tomek Mrugalski Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkjZLFXD0eqIF0TYApy/l9X73a5z1srnKZe3JIZ4KxkMqfVxJDV/s6jDldLRnSqqlnIbQ8GAm2z6ACrxzow8EqqPdPl76UANt6W83bhUizaAODISLK8grJLA+DW8MSBfhhL3qqmR52R2a6zxZIZOI5NYKHghOqLzpdoTtnDiI+/qijOgcQLpsyZDSkUlkZaLv0lRa5H Cc: "mif@ietf.org" Subject: Re: [mif] dhcp route option issues on tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:15:15 -0000 > breaker: There are currently 78 DHCPv6 options defined. Is DHCPv6 server > supposed to share faith with all those services? Of course not, but that's no reason to gratuitously discard it where it's available. From trac+mif@trac.tools.ietf.org Mon Nov 5 07:17:32 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E77621F868E for ; Mon, 5 Nov 2012 07:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFKRrl4001mw for ; Mon, 5 Nov 2012 07:17:28 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7C221F867A for ; Mon, 5 Nov 2012 07:17:28 -0800 (PST) Received: from localhost ([127.0.0.1]:48118 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVOQC-0003wv-Rt; Mon, 05 Nov 2012 16:17:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, lorenzo@google.com X-Trac-Project: mif Date: Mon, 05 Nov 2012 15:17:04 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/16 Message-ID: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, lorenzo@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121105151728.2F7C221F867A@ietfa.amsl.com> Resent-Date: Mon, 5 Nov 2012 07:17:28 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:17:33 -0000 #16: DHCPv6 route option does not belong in MIF working group The DHCPv6 route option does not belong in the MIF working group. Rationale: 1. Virtually all the use cases provided (as of draft-05, at least #1, #2, #3, #4, #5, #7, #8, #9, #10) are not specific to hosts with multiple interfaces, and apply equally well to hosts with one interface. 2. The DHCPv6 route option duplicates, in a different way, functionality which is part of the core protocol specification. Specifically, it duplicates functionality of RFC 4862 (stateless address autoconfiguration, routing, on-link prefixes). Duplicating core IPv6 protocol functionality in a different working group is a bad idea. Work on this option should be moved to 6man, which is authoritative for configuration of routing on IPv6 nodes. -- -------------------------+------------------------------------------------- Reporter: lorenzo@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: blocker | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From Ted.Lemon@nominum.com Mon Nov 5 07:23:21 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B34521F8746 for ; Mon, 5 Nov 2012 07:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhVPtkj0ZHy6 for ; Mon, 5 Nov 2012 07:23:20 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0B221F8743 for ; Mon, 5 Nov 2012 07:23:15 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUJfZ4nmKHND/632kv7/qYN05IkBE5tQU@postini.com; Mon, 05 Nov 2012 07:23:20 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0CCB1F8006 for ; Mon, 5 Nov 2012 07:23:14 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0027619005C; Mon, 5 Nov 2012 07:23:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 07:23:13 -0800 From: Ted Lemon To: Erik Kline Thread-Topic: [mif] dhcp route option issues on tracker Thread-Index: AQHNu1Y6xVWbpjVinkCl+wk+5N9rMZfbywmAgAATOwCAAAHIgIAAAlUA Date: Mon, 5 Nov 2012 15:23:13 +0000 Message-ID: References: <5097C64D.1060307@gmail.com> <5097D66E.9060305@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <648B48F1A600F54C8DD46436959CA485@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] dhcp route option issues on tracker X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:23:21 -0000 On Nov 5, 2012, at 10:14 AM, Erik Kline wrote: > Of course not, but that's no reason to gratuitously discard it where > it's available. In order to "gratuitously discard" fate sharing, this document would have t= o explicitly deprecate neighbor discovery. As Arifumi-san said earlier, th= is document does not do that=97it just provides an alternative in environme= nts where the benefits of fate-sharing are outweighed by the benefits of be= ing able to distribute routes to specific clients using DHCP. I think it's important to be clear on this distinction=97like you, I would = oppose this document's advancement if, as you claim, it gratuitously discar= ded fate sharing. From Ted.Lemon@nominum.com Mon Nov 5 07:28:20 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989B221F8661 for ; Mon, 5 Nov 2012 07:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuoaKqGduaSv for ; Mon, 5 Nov 2012 07:28:17 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8092221F8736 for ; Mon, 5 Nov 2012 07:28:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUJfbEOwU+7xEyvPd5mzDpYxtbPBqu1+r@postini.com; Mon, 05 Nov 2012 07:28:17 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2BBCC1B82D1 for ; Mon, 5 Nov 2012 07:28:15 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 22D9919005C; Mon, 5 Nov 2012 07:28:15 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 07:28:15 -0800 From: Ted Lemon To: mif issue tracker Thread-Topic: [mif] #16: DHCPv6 route option does not belong in MIF working group Thread-Index: AQHNu2ixOttDke3GfUuxFwnOOL4JsJfb46OA Date: Mon, 5 Nov 2012 15:28:14 +0000 Message-ID: References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> In-Reply-To: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:28:20 -0000 On Nov 5, 2012, at 10:17 AM, mif issue tracker wrote: > Duplicating core IPv6 protocol functionality in a different working group > is a bad idea. Work on this option should be moved to 6man, which is > authoritative for configuration of routing on IPv6 nodes. The MIF working group has in its charter an action item to do a DHCPv6 rout= e option. You've admitted that there are use cases that are motivated by = the multiple interface use case. The existence of use cases without that = motivation therefore doesn't seem to be a valid argument for your assertion= that this should be done in a different working group. From trac+mif@trac.tools.ietf.org Mon Nov 5 07:38:12 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7596421F849F for ; Mon, 5 Nov 2012 07:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpDltn+MVmqO for ; Mon, 5 Nov 2012 07:38:12 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 96AB521F84B9 for ; Mon, 5 Nov 2012 07:38:08 -0800 (PST) Received: from localhost ([127.0.0.1]:49807 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVOkG-00057a-99; Mon, 05 Nov 2012 16:37:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, lorenzo@google.com X-Trac-Project: mif Date: Mon, 05 Nov 2012 15:37:48 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/17 Message-ID: <056.176f241113903d0b2237969c6d6ac1c1@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, lorenzo@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121105153808.96AB521F84B9@ietfa.amsl.com> Resent-Date: Mon, 5 Nov 2012 07:38:08 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #17: Status of DHCPv6 route option should be clarified X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:38:12 -0000 #17: Status of DHCPv6 route option should be clarified The DHCPv6 route option went through WG last call in November 2011. Since then significant new discussion occurred, and specifically, at IETF 84 there was no consensus that the draft should go forward. The WG should clarify that the draft will need to go through WGLC again before being approved. -- -------------------------+------------------------------------------------- Reporter: lorenzo@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: blocker | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From brian.e.carpenter@gmail.com Mon Nov 5 07:43:08 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF64321F880E for ; Mon, 5 Nov 2012 07:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YODvdw+sCWR for ; Mon, 5 Nov 2012 07:43:08 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52C5D21F8694 for ; Mon, 5 Nov 2012 07:43:08 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so4008978pad.31 for ; Mon, 05 Nov 2012 07:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+IFMHK4xkJ+/Uh3fkWboWsOinutvrGrBQ9Q+QsVi86o=; b=tHgpY4uSS5TdlxW9+lMER2lTS4c2dxlJE1B+aP4qb9Ma9L/WCW9/F+5urEeuRLqfgd y3FmpDI1trYurXnyo0ne0rYukbfPigifZRdFSnXhWVu8Ihq3xTVUhhCpGW0ulQA+eBsS 8ATezljroOeiPYkPpxkw83MLlVHAeAXJ1wpTKNPCBq7rBnVRNbmXlHIkG2uux2t1xd8C 0IWy4RK8NOrHGo5XNJsVqOMMwA9YC4rfptR7RHs0ZkLZKveSSZk5FsiIs3YjIclqFo8/ DN00Fh1x1qW4DcL5WsyorXbWcTrqfHmNC0pNpOVXU2BlayGo9WKlxaqxSlNEr9X97PSq ZZAQ== Received: by 10.68.235.68 with SMTP id uk4mr31294517pbc.52.1352130188122; Mon, 05 Nov 2012 07:43:08 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id c1sm10816595pav.23.2012.11.05.07.43.06 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 07:43:06 -0800 (PST) Message-ID: <5097DE8B.90800@gmail.com> Date: Mon, 05 Nov 2012 15:43:07 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:43:08 -0000 On 05/11/2012 15:28, Ted Lemon wrote: > On Nov 5, 2012, at 10:17 AM, mif issue tracker > wrote: >> Duplicating core IPv6 protocol functionality in a different working group >> is a bad idea. Work on this option should be moved to 6man, which is >> authoritative for configuration of routing on IPv6 nodes. > > The MIF working group has in its charter an action item to do a DHCPv6 route option. Charters can be changed. > You've admitted that there are use cases that are motivated by the multiple interface use case. The existence of use cases without that motivation therefore doesn't seem to be a valid argument for your assertion that this should be done in a different working group. I think it is, given that the option would (if defined) obviously be used widely. At the very minimum, 6man would have to say "no objection" to this. Regards Brian Carpenter Cell phone during IETF85: +1 847 219 0880 From lorenzo@google.com Mon Nov 5 07:54:12 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FE421F8843 for ; Mon, 5 Nov 2012 07:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf0YSkPRSt7M for ; Mon, 5 Nov 2012 07:54:07 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21E6C21F8595 for ; Mon, 5 Nov 2012 07:54:06 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so6354497oag.31 for ; Mon, 05 Nov 2012 07:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=rQMZFSIOQxhGg8hZXsdRdfLTFJQae9FdqlnBRs300dw=; b=c2JnbSYnbBsEqELBPDoFvJ2hjbrFgpdlI6OBLhwi5lxT7FMkWjlBt3qhG6cCLfeAEp DgVhqKjsFKN1J4CRoqvVI68quVP+jJHkbz5q90akgSwi9yYCz+oL8vwVoWdayEYDPsov mlDrEamBAkMYbzC2bCM1DPEgvSSmX0zcLBZFwvY2ncHB+eHiqTMdbQQbG8e7usnj5Rhf Muh5H9++nuzI/wbDe7sTE7zLgGrJRlNSTG3RwHbiM3o52aLBpSiGCBmHtLUafRKFUq4b up+ch0qs//ZqoTSSP+Jp+fulpH8lPcbIjg81AmwSkMBaK2yQTJWPqrv0KV3Oyr6sxF/G zRlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=rQMZFSIOQxhGg8hZXsdRdfLTFJQae9FdqlnBRs300dw=; b=aTJWYY+3MIkbSrBzqOUL1z6znzVOAtGmnhexibd/VmI/eDJW+Z9GKltsTxg2DUcrRy jD5lDERpj/NpXYSzOXigVyW2KKwCfZWS+Rr4dldbwS05rcouh9dj+fdsCgrq2vjR7g32 eikhBDeRlc1iiMjzsflEktHL8Kgw1YHcLUsXZ9+NJflepjr+jBxvDF9OF8318waCbVap LVKe9zXXyKc+EDvfim+NHSPW63MYJGg8lGjUhavP7XMzzP7TZl7yLgQsaorzQSQhqeQa uOHcKAoKniFaa7K2mCYtvgzk6KtwUh5JjSTTwayt5EZ5lXak88zjJDmL4/M5S5Y1V7r6 bFzA== Received: by 10.182.52.105 with SMTP id s9mr8185664obo.25.1352130846527; Mon, 05 Nov 2012 07:54:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 07:53:46 -0800 (PST) In-Reply-To: References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> From: Lorenzo Colitti Date: Tue, 6 Nov 2012 00:53:46 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae9399429cc10c404cdc17e7a X-System-Of-Record: true X-Gm-Message-State: ALoCoQmoyRoXKlQ1Tyr+IjbhUGvPbBrDHj6C4X43TS/F7BU4yGbME3sRh+9dLp7DSmGYjfqKXN+nVsz+VXmnG2Uocv3Bah1EOfzVijQBclFuMmr0au1dNS3EOGLKQ8lFkehPS3VcwOWBuOhu3PBPgDEfG1SF7a3O1noBkhuDLFHhDF4GLTyjnMkT0Ibtil9qSwcuVDaYlEcp Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:54:12 -0000 --14dae9399429cc10c404cdc17e7a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 6, 2012 at 12:28 AM, Ted Lemon wrote: > On Nov 5, 2012, at 10:17 AM, mif issue tracker < > trac+mif@trac.tools.ietf.org> > wrote: > > Duplicating core IPv6 protocol functionality in a different working group > > is a bad idea. Work on this option should be moved to 6man, which is > > authoritative for configuration of routing on IPv6 nodes. > > The MIF working group has in its charter an action item to do a DHCPv6 > route option. The fact that the group was chartered to do this years ago does not mean it is still the best place to have this discussion, or even that this is a good idea at all. And I would argue the charter is not the right place to specify solutions, anyway. Much better to specify problem statements and areas to work on, not solutions. The solution space should be left to the WG - because you don't know, before you actually explore the solution space, whether a specific solution is a good idea. You've admitted that there are use cases that are motivated by the > multiple interface use case. The only use cases I see where multiple interfaces are relevant *at all* are #6 and #8 (though these use cases can be relevant on single interfaces as well). All the others apply identically to hosts with only one interface. I don't think saying "2 out of 11 use cases are partially relevant to hosts with multiple interfaces" is a justification for having this draft be in MIF instead of in 6man, especially since it duplicates core protocol work standardized by 6man. --14dae9399429cc10c404cdc17e7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue= , Nov 6, 2012 at 12:28 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Nov 5, 2012, a= t 10:17 AM, mif issue tracker <trac+mif@trac.tools.ietf.org>
=A0wrote:
> Duplicating core IPv6 protocol functionality in a different working gr= oup
> is a bad idea. Work on this option should be moved to 6man, which is > authoritative for configuration of routing on IPv6 nodes.

The MIF working group has in its charter an action item to do a DHCPv= 6 route option.

The fact that the group was= chartered to do this years ago does not mean it is still the best place to= have this discussion, or even that this is a good idea at all.=A0And I wou= ld argue the charter is not the right place to specify solutions, anyway. M= uch better to specify problem statements and areas to work on, not solution= s. The solution space should be left to the WG - because you don't know= , before you actually explore the solution space, whether a specific soluti= on is a good idea.

=A0 You've admitted that= there are use cases that are motivated by the multiple interface use case.=

The only use cases I see where multiple interfaces are = relevant *at all* are #6 and #8 (though these use cases can be relevant on = single interfaces as well). All the others apply identically to hosts with = only one interface. I don't think saying "2 out of 11 use cases ar= e partially relevant to hosts with multiple interfaces" is a justifica= tion for having this draft be in MIF instead of in 6man, especially since i= t duplicates core protocol work standardized by 6man.
--14dae9399429cc10c404cdc17e7a-- From Ted.Lemon@nominum.com Mon Nov 5 07:56:14 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8391621F84FC for ; Mon, 5 Nov 2012 07:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1fpHw3LQYds for ; Mon, 5 Nov 2012 07:56:14 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id C281221F8847 for ; Mon, 5 Nov 2012 07:56:12 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUJfhnEmAYx5xPkE1yN7c9Ujf8avXYvVv@postini.com; Mon, 05 Nov 2012 07:56:12 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7ADA21B82D8 for ; Mon, 5 Nov 2012 07:56:09 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 64B8219005C; Mon, 5 Nov 2012 07:56:09 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 07:56:04 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] #16: DHCPv6 route option does not belong in MIF working group Thread-Index: AQHNu2ixOttDke3GfUuxFwnOOL4JsJfb46OAgAAEKICAAAOfgA== Date: Mon, 5 Nov 2012 15:56:04 +0000 Message-ID: References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> <5097DE8B.90800@gmail.com> In-Reply-To: <5097DE8B.90800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:56:14 -0000 On Nov 5, 2012, at 10:43 AM, Brian E Carpenter wrote: > I think it is, given that the option would (if defined) obviously be used > widely. At the very minimum, 6man would have to say "no objection" to thi= s. Currently many (perhaps most!) IPv6-capable devices don't even _implement_ = DHCPv6 for IP address allocation. So this claim is not a statement of fac= t=97it is clearly not true. As speculation as to what might happen in the future, it is of questionable= value=97we simply don't know what the future holds. As a user of IPv6 on= my home network, I don't see much use for this option, so it seems like a = special case option to me. When we met in Paris, at least one operator sa= id that he didn't want to use this option because it would make managing hi= s network harder (ironically, he was against the option out of a fear that = he would somehow be forced to use it despite his strong preference not to d= o so). I realize that you have a different opinion, but my point is that both your= opinion and mine are pure speculation=97there is no way to know what will = actually happen if this option becomes a standard. Consequently, the work= ing group should take neither your speculation nor mine into account=97what= we should talk about is whether there are motivating use cases for this dr= aft, and whether there are serious technical problems or known drawbacks wi= th the draft such that, if it were to advance, something bad would definite= ly happen. Of course, chances are we won't have that sort of discussion, because there= are some religious folks who have strong beliefs here, but I feel obliged = to mention it as an aspirational goal. From Ted.Lemon@nominum.com Mon Nov 5 08:06:15 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420C21F87F1 for ; Mon, 5 Nov 2012 08:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lIx+E5HwsEC for ; Mon, 5 Nov 2012 08:06:15 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5C721F881C for ; Mon, 5 Nov 2012 08:06:14 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUJfj9G1aGk2v8Dzs/odjjNy7W5jdYW3Q@postini.com; Mon, 05 Nov 2012 08:06:14 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 81E5A1B82CF for ; Mon, 5 Nov 2012 08:06:12 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7756519005C; Mon, 5 Nov 2012 08:06:12 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 08:06:12 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] #16: DHCPv6 route option does not belong in MIF working group Thread-Index: AQHNu2ixOttDke3GfUuxFwnOOL4JsJfb46OAgAAHIQCAAAN7gA== Date: Mon, 5 Nov 2012 16:06:12 +0000 Message-ID: <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:06:15 -0000 On Nov 5, 2012, at 10:53 AM, Lorenzo Colitti wrote: > I don't think saying "2 out of 11 use cases are partially relevant to ho= sts with multiple interfaces" is a justification for having this draft be i= n MIF instead of in 6man, especially since it duplicates core protocol work= standardized by 6man. This is a situation where someone was asked to come up with a list of actua= l use cases, and misunderstood the meaning of this request, and instead spe= culated as to how the option could in theory be used, and came up with a lo= ng list of such speculative use cases. As far as I know, the motivating use case for this document is in fact use = case 8. We've since heard from BBF that they have another use case, which= is something like use case 7, but slightly different, in the sense that it= has to do with QoS rather than IP address space segregation. The other u= se cases are not actual use cases that anyone has in the real world; a numb= er of them are contrived, and it's difficult to imagine them actually happe= ning in the real world. So as a criticism of the document, I think the point you are making is vali= d=97all of the use cases that don't have actual customers should be removed= from the document. If that were to happen, then we would have one use ca= se that's clearly a MIF-specific use case, and a second use case that's sor= t of relevant to MIF, but not really MIF-specific. This would be a useful exercise, and after doing so it might be worth recon= sidering the point you've made. However, at this point I don't think your= point can be realistically considered, because there is so much noise and = so little signal in the section of the document on use cases. From lorenzo@google.com Mon Nov 5 08:16:46 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7521F8671 for ; Mon, 5 Nov 2012 08:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imY8aIp+KJKb for ; Mon, 5 Nov 2012 08:16:45 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECAA21F84E3 for ; Mon, 5 Nov 2012 08:16:45 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so6320412obq.31 for ; Mon, 05 Nov 2012 08:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Gf8mCqZTHGhT7FxzyaKGXAOt7gtsPJx6ph3Ojy9fXlM=; b=J5JTQ2+PP0l6KJziHLw1naTVQL+AH6p44yUTrglVRWn/cBjZueT8Tj8DFCoMM85XU/ DM976kr/YhlJ6eL2VtgdgoaqsVF2JF9JEEncooJCx66pBf77nJ3KUu2ujfQvL3gmoO8y oV+roplP9v4Bmq6KV2r2TJzYrhDatRRu0dDxbtdhk/l1HFia2GU0vMAOYQUlrpHp94DD Grtti4cFEJdXPa71OLIFtgPDTGIpF40dKFcPxSR3rATg3blmKpc2NpwW+LKGYEH6aYXB n0VZkwJFaDuVw59R7a3er6eU8Ezsb1mJmFJRDfgJFSGxOaTaId+xihVsTKK2aTCGif1y qIuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Gf8mCqZTHGhT7FxzyaKGXAOt7gtsPJx6ph3Ojy9fXlM=; b=Pqs0Sn3DQ9oDCBnaxUx6mJtO8GfjL5XpwO9hp2izAJ9TedwfJOI4Ry4vmbLXp1DlDj m3rsZSTaSiBsRXceaYjtRzimeLNRMdkKTMnwcroEeMDdKJtP1R4pbR6OiMZnW6H66wur 8oox+AvpIZX3OehjLdwMpLfG0+LGIbqyVxpin/nPrS1Egit1REXMclCvQ/ucudkg+fGV GIOtjv43U9wfmFbJmWr9ibzQuv0BRgBo+7pc+ZZ3RP80HdeCnvypgMat1u6m/xPkLgL9 5fnWwKYBF99uHeq/CUXAUixoO9QIfLmGOV0s2frDqwlTtfkwlD3jh9bCGL4dJO1a9rU2 Gf8Q== Received: by 10.60.5.138 with SMTP id s10mr8058578oes.80.1352132204846; Mon, 05 Nov 2012 08:16:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 08:16:24 -0800 (PST) In-Reply-To: <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> From: Lorenzo Colitti Date: Tue, 6 Nov 2012 01:16:24 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8ff252cec25ff204cdc1cfb3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmUXyg0jgCMBRvQ/nZLGLtF7LlSDFkBY1b4EJOk4j5NAfy215fbZcS637Jh7SVgn5GdeMKLUPpQ8V3p2TRuYvJQkTt1KKIU82xdwbMLWECrERiHO1XRUPHQYMvzp192WTZbo26cqhFu/NLYFP+p91jYOXdZsBAorRv0peuvI0+VzLlUoT4QNAVDsZyHNGRY2RsyFzbA Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:16:46 -0000 --e89a8ff252cec25ff204cdc1cfb3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2012 at 1:06 AM, Ted Lemon wrote: > So as a criticism of the document, I think the point you are making is > valid=97all of the use cases that don't have actual customers should be > removed from the document. If that were to happen, then we would have o= ne > use case that's clearly a MIF-specific use case, and a second use case > that's sort of relevant to MIF, but not really MIF-specific. > > This would be a useful exercise, and after doing so it might be worth > reconsidering the point you've made. However, at this point I don't thi= nk > your point can be realistically considered, because there is so much nois= e > and so little signal in the section of the document on use cases. > Ok, so I read your paragraph as "the problem statement for this draft is vague and unparseable". But isn't that a serious problem with the document that needs to be addressed? --e89a8ff252cec25ff204cdc1cfb3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue= , Nov 6, 2012 at 1:06 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
So as a criticism of the document, I think the point you are making is val= id=97all of the use cases that don't have actual customers should be re= moved from the document. =A0 If that were to happen, then we would have one= use case that's clearly a MIF-specific use case, and a second use case= that's sort of relevant to MIF, but not really MIF-specific.

This would be a useful exercise, and after doing so it might be worth recon= sidering the point you've made. =A0 However, at this point I don't = think your point can be realistically considered, because there is so much = noise and so little signal in the section of the document on use cases.

Ok, so I read your paragraph as "the probl= em statement for this draft is vague and unparseable". But=A0isn't= that a serious problem with the document that needs to be addressed?
--e89a8ff252cec25ff204cdc1cfb3-- From Ted.Lemon@nominum.com Mon Nov 5 08:23:39 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BBB21F8514 for ; Mon, 5 Nov 2012 08:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDGCvmUf7izO for ; Mon, 5 Nov 2012 08:23:38 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6321F8487 for ; Mon, 5 Nov 2012 08:23:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUJfoCZx1ayRpxL1MLpW3AX1tyoTGVcH+@postini.com; Mon, 05 Nov 2012 08:23:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EF1A81B82D1 for ; Mon, 5 Nov 2012 08:23:36 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E312319005C; Mon, 5 Nov 2012 08:23:36 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 08:23:36 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] #16: DHCPv6 route option does not belong in MIF working group Thread-Index: AQHNu2ixOttDke3GfUuxFwnOOL4JsJfb46OAgAAHIQCAAAN7gIAAAtgAgAACAoA= Date: Mon, 5 Nov 2012 16:23:36 +0000 Message-ID: <037B3B56-4CE0-438E-8ECD-B9334D006340@nominum.com> References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:23:39 -0000 On Nov 5, 2012, at 11:16 AM, Lorenzo Colitti wrote: > Ok, so I read your paragraph as "the problem statement for this draft is = vague and unparseable". But isn't that a serious problem with the document = that needs to be addressed? Yes, absolutely, and I communicated this to the authors when they issued th= e current version of the draft. I am disappointed that this has not yet b= een fixed. However, it is _not_ the problem that issue #16 talks about. := ) From n@arifumi.net Mon Nov 5 11:16:48 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9D521F8540 for ; Mon, 5 Nov 2012 11:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfi8iWVDm5Zs for ; Mon, 5 Nov 2012 11:16:47 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8266521F8511 for ; Mon, 5 Nov 2012 11:16:47 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so6931599vcb.31 for ; Mon, 05 Nov 2012 11:16:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=PJDSXq1Us5jpXwQG+9zUhQPEoInDA0gsgY2+JSBZyiU=; b=Cv5qrIgyHYgZcck2KhjC5yExIhaAjahbclgZYWtGX9z7i4r/cL6c6dbclprFZu/eDX KADpjrpU857QZ8HwBu25VNOJPYuPy95hWUw9fWzVkDZqwbNurdlz6Gam2jnCTjeKsXez j+wGhUBqx3cWYsd/aPaFTx9YWoT6PWbghNcprNJVD1vem7XhvTGXhN6fZofCg0qfSenE JmRhLKwKLkblPa2zSdFm7iD7oZcB7pKwRi1wyVMwuLU4zNUgm7iJS4YKwNevKKpNuyxm jWoxubaApPCRwkZB2vZ4t/0THdcYXSsuYQzFECVRo3Fj8DuvdWpKFm/1g9HZ49ruciO7 P31g== MIME-Version: 1.0 Received: by 10.52.68.226 with SMTP id z2mr9020125vdt.76.1352143006998; Mon, 05 Nov 2012 11:16:46 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Mon, 5 Nov 2012 11:16:46 -0800 (PST) X-Originating-IP: [130.129.21.185] In-Reply-To: <037B3B56-4CE0-438E-8ECD-B9334D006340@nominum.com> References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> <037B3B56-4CE0-438E-8ECD-B9334D006340@nominum.com> Date: Tue, 6 Nov 2012 04:16:46 +0900 X-Google-Sender-Auth: EPH_FRD0WYAZTlTAz4KdbhZh64c Message-ID: From: Arifumi Matsumoto To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3079c0949e205104cdc4534d X-Gm-Message-State: ALoCoQljqKxVC9r7IL+NcbeX49rnweGDWivgBIczwp4RcY+AE06dqW9jD5nYI+P84srwBk7iYsJr Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:16:48 -0000 --20cf3079c0949e205104cdc4534d Content-Type: text/plain; charset=ISO-8859-1 In my understanding, we are now using issue tracker to fix such vagueness and errors in problem statements. Regarding the issue of a real problem and a contrived problem, I think the criteria should not be "it is really happening somewhere", but be "enough people agree to solve the problem". --20cf3079c0949e205104cdc4534d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In my understanding, we are now using issue tracker to fix such vagueness a= nd errors in problem statements.

Regarding the issue of = a real problem and a contrived problem, I think the criteria should not be = "it is really happening somewhere", but be "enough people ag= ree to solve the problem".

--20cf3079c0949e205104cdc4534d-- From Ted.Lemon@nominum.com Mon Nov 5 11:21:41 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A18121F879E for ; Mon, 5 Nov 2012 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrTDI1HTo1aR for ; Mon, 5 Nov 2012 11:21:40 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3900921F8799 for ; Mon, 5 Nov 2012 11:21:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUJgRwJ4wQ+IFNXi+JzCsrC4mt8pXWfVs@postini.com; Mon, 05 Nov 2012 11:21:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 35A181B82D8 for ; Mon, 5 Nov 2012 11:21:36 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2D17619005C; Mon, 5 Nov 2012 11:21:36 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 11:21:36 -0800 From: Ted Lemon To: Arifumi Matsumoto Thread-Topic: [mif] #16: DHCPv6 route option does not belong in MIF working group Thread-Index: AQHNu2ixOttDke3GfUuxFwnOOL4JsJfb46OAgAAHIQCAAAN7gIAAAtgAgAACAoCAADBjAIAAAVcA Date: Mon, 5 Nov 2012 19:21:35 +0000 Message-ID: References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> <037B3B56-4CE0-438E-8ECD-B9334D006340@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <577E747B880E8C4691743F8CD47FA21C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:21:41 -0000 On Nov 5, 2012, at 2:16 PM, Arifumi Matsumoto wrote: > Regarding the issue of a real problem and a contrived problem, I think th= e criteria should not be "it is really happening somewhere", but be "enough= people agree to solve the problem". That's not a great metric, because the IETF seems to work on a lot of probl= ems with no customers. This document actually has several customers, so there's no reason to contr= ive use cases for which no customers exist. From n@arifumi.net Mon Nov 5 11:32:39 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E2821F85CB for ; Mon, 5 Nov 2012 11:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efx9VjHElkiV for ; Mon, 5 Nov 2012 11:32:29 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB021F8884 for ; Mon, 5 Nov 2012 11:32:28 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7003277vbb.31 for ; Mon, 05 Nov 2012 11:32:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=ILWi7UHys4ro5P5qUBPUbyu0JKaYqW/fmzxoCQ4uvN0=; b=h4OsaWal9S5h7WoSLB8cg5VoERPLpVKy7Z8NeFfsZ8NVqPYTsxv8qZjw6LeBTryGVS lmuYer33mDmNuJLcXn3BAbqpaYpU/QrVdgfqjilsnc0K3VeRnarObQaXdtXeKaggNUzo tYYcQow9QmaufBdAT12oOsor+okHwr4lV2pJJE7S3oCjIyPbD11ynLnA40I2qJP1Qxom VbO742nf3uHz+gjalBCRw4aBKb8XPJkau3zYdo1Wl3fIShQs8aLJdxs6IBuS06oRqCAe +Y45Xr0B5ykN4EII7/XOoLi39mN/odM3A6M2gteNBEWPXVC7A1viuhcdzTST0IBSEC/s xiHw== MIME-Version: 1.0 Received: by 10.52.180.5 with SMTP id dk5mr9126216vdc.45.1352143948118; Mon, 05 Nov 2012 11:32:28 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Mon, 5 Nov 2012 11:32:28 -0800 (PST) X-Originating-IP: [130.129.21.185] In-Reply-To: References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> <037B3B56-4CE0-438E-8ECD-B9334D006340@nominum.com> Date: Tue, 6 Nov 2012 04:32:28 +0900 X-Google-Sender-Auth: 9D6_5AnoOr-g4NeyKMrtCf1o334 Message-ID: From: Arifumi Matsumoto To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec5196789b67cc604cdc48b22 X-Gm-Message-State: ALoCoQn6ykdw5o/OMflMm1cA4H7JgY5fXPFMtzNguXR7RBIviGV+Dzakwo9uKwjd0Iq948b5og43 Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:32:39 -0000 --bcaec5196789b67cc604cdc48b22 Content-Type: text/plain; charset=ISO-8859-1 If one customer is enough for each use case, then each of the use case in the draft has it. It is a different question, whether he is really facing the problem, or he thinks he will be. But, I think it is not the only criteria whether the WG should work on the use case. 2012/11/6 Ted Lemon > On Nov 5, 2012, at 2:16 PM, Arifumi Matsumoto > wrote: > > Regarding the issue of a real problem and a contrived problem, I think > the criteria should not be "it is really happening somewhere", but be > "enough people agree to solve the problem". > > That's not a great metric, because the IETF seems to work on a lot of > problems with no customers. > > This document actually has several customers, so there's no reason to > contrive use cases for which no customers exist. > > > --bcaec5196789b67cc604cdc48b22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If one customer is enough for each use case, then each of the use case in t= he draft has it.
It is a different question, whether he is really facin= g the problem, or he thinks he will be.

But, I think it = is not the only criteria whether the WG should work on the use case.


2012/11= /6 Ted Lemon <Ted.Lemon@nominum.com>
On Nov 5, 2012, at 2:16 PM, Arifumi Matsumoto <arifumi@nttv6.net>
=A0wrote:
> Regarding the issue of a real problem and a contrived problem, I think= the criteria should not be "it is really happening somewhere", b= ut be "enough people agree to solve the problem".

That's not a great metric, because the IETF seems to work on a lo= t of problems with no customers.

This document actually has several customers, so there's no reason to c= ontrive use cases for which no customers exist.



--bcaec5196789b67cc604cdc48b22-- From n@arifumi.net Mon Nov 5 11:38:26 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103B821F850B for ; Mon, 5 Nov 2012 11:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMtFUYs1lCyq for ; Mon, 5 Nov 2012 11:38:25 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D65C21F843C for ; Mon, 5 Nov 2012 11:38:25 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7010037vbb.31 for ; Mon, 05 Nov 2012 11:38:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=KMGscVYdCjtc+2Q1WAZ9UpaKyGCOmCKNNhl3c5UVooU=; b=EicJKo1l6BF5sLXBTUeiu2fyne1yjeFuo7qBy7s0s3ErCavBoI/aduB5Vdf/9LLF/b s5iztf6eVJ7vNhT6mUR54o7w0RlcbAHiIg11dnQI8Efc0Zi3QKuE6vLxNDxflWurqXvv kluOFdL3Y2Y5zwvfqe2H9X/gvEU7QTS0toyu3i1UBIUUn8wJOcRVV5TD7aJyXOjoNPac 6bBl8LToaAdKDcvmN8ha0ZDPSS/nxgeqwqo6EOqj3b0VkJe10FlYPvZEPI9u2GjGgMGg lVx9YdzC1C1OMfEoyLdk5kHano5K9sFbQs5EKc/V4VWGhcrAIAYVLh/aDLTNj2u17JTJ jrZw== MIME-Version: 1.0 Received: by 10.220.107.146 with SMTP id b18mr10320327vcp.48.1352144304633; Mon, 05 Nov 2012 11:38:24 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Mon, 5 Nov 2012 11:38:24 -0800 (PST) X-Originating-IP: [130.129.21.185] In-Reply-To: <5093E91F.2090506@gmail.com> References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> Date: Tue, 6 Nov 2012 04:38:24 +0900 X-Google-Sender-Auth: xlXMzfuTntpxNeUOrNsFOGxo-LQ Message-ID: From: Arifumi Matsumoto To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=f46d0438ecfff6756704cdc4a06f X-Gm-Message-State: ALoCoQlEwMJWYi3C5gPGh6B9xUBjN4cPxa0BaXsWZSJEUJLjPKQv0qxChSZPB+dtNXp851NHPlzP Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:38:26 -0000 --f46d0438ecfff6756704cdc4a06f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agree with Alex. The BBF document might have made a mistake on how to cite an I-D, but it does not change the fact that BBF wants it. 2012/11/3 Alexandru Petrescu > Hello, > > Le 01/11/2012 09:46, mif issue tracker a =E9crit : > > #15: use case #1 does not justify standardization of this option >> >> Use case #1 should remove the reference to walled gardens as a >> motivation (see RFC 3002, section 4.2.1 and other tickets on this >> theme). >> >> This option does not obviate the need for customer edge routers >> (CPEs) to route ("to avoid routing on the CPE"). Why should we not >> expect a router to route? >> >> Furthermore, this use case does not justify why customer edge >> routers would need this. Instead, this use case documents a need for >> a protocol to provision network provider edge routers, which is >> something different. >> >> Recommendation: remove this use case. >> > > I am not in a position to comment on the relevance of this use-case 1 > "In Broadband network environment where the CPE is multi-homed to two > upstream edge routers and each router provides connectivity for > different..." > > I think authors of this use-case have a reason for having suggested it. > > On another hand, there are a number of other use cases that may need > this DHCP route-option behaviour. Some specific to the default route > aspect of a general route are described in > draft-mouton-mif-dhcpv6-drlo-**02.txt ("Large Mobile Network Use Case", > "Mi-Fi Coverage Extension Use Case", "M2M Constrained Device Use Case"). > > Alex > > ______________________________**_________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/**listinfo/mif > --f46d0438ecfff6756704cdc4a06f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree with Alex.

The BBF document might have made = a mistake on how to cite an I-D,
but it does not=A0change the fact that= BBF wants it.


2012/11/3 Alexandru Petrescu <alexandru.petrescu@gmail.com&= gt;
Hello,

Le 01/11/2012 09:46, mif issue tracker a =E9crit :

#15: use case #1 does not justify standardization of this option

Use case #1 should remove the reference to walled gardens as a
motivation (see RFC 3002, section 4.2.1 and other tickets on this
theme).

This option does not obviate the need for customer edge routers
(CPEs) to route ("to avoid routing on the CPE"). =A0Why should we= not
expect a router to route?

Furthermore, this use case does not justify why customer edge
routers would need this. =A0Instead, this use case documents a need for
a protocol to provision network provider edge routers, which is
something different.

Recommendation: remove this use case.

I am not in a position to comment on the relevance of this use-case 1
"In Broadband network environment where the CPE is multi-homed to two<= br> upstream edge routers and each router provides connectivity for
different..."

I think authors of this use-case have a reason for having suggested it.

On another hand, there are a number of other use cases that may need
this DHCP route-option behaviour. =A0Some specific to the default route
aspect of a general route are described in
draft-mouton-mif-dhcpv6-drlo-02.txt ("Large Mobile Network Use = Case",
"Mi-Fi Coverage Extension Use Case", "M2M Constrained Device= Use Case").

Alex

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--f46d0438ecfff6756704cdc4a06f-- From lorenzo@google.com Mon Nov 5 13:50:03 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6540A21F882E for ; Mon, 5 Nov 2012 13:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moIYkYgEuJ7B for ; Mon, 5 Nov 2012 13:50:02 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5EF21F882A for ; Mon, 5 Nov 2012 13:50:02 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so6773113oag.31 for ; Mon, 05 Nov 2012 13:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=gyD9D9UFcmbBdTaGz3gKJufQHTow62TNglfuYBLiSzo=; b=TNHYERJD93sI4arRsUH61rHn3oxTFMp8Oizu5krvC3m5W0qi2qES26RHTuCAIijGzH lJcHisSss8EVJDEIb5oeqhBjNtSH9dpYBqpbWzLAOiwQglRVARI1g5gMdFP5c+6/AvbE CIsirCPEV7aGbszfpK63D2K5MaeanhatHsuKQY9qWdIO18zlTEwqyPKw1yjdn00xrlzw bU9Zwd+w9wk/zKz9PM8BNwnvJR2n17owCODm8zgjy6L9gELo0W5YQFMRVYazzzRE16XD PEKDjbpgLwn4XaexNp5TLk/CMxrU6JUywzyWrG+xhsYjUBalLN14u8jT8VuIZXNTmljI 4AzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=gyD9D9UFcmbBdTaGz3gKJufQHTow62TNglfuYBLiSzo=; b=F6fA0oBigTun/AjPRTjKtw+3eG5EARtLbuC4sIpG7ykLjGE/TNAFS0kAXqXbOrDoA0 lrx9QhslJ6lyMLCCaidpYeok0Jxmh4xmOAM+/VSSNPC7oB523fylYHNFdGwoH7L2qNj2 2tj9eqZfcga/E6MQill1S9u144CxndQpigtvvvVAd5Lqptwgsu+6jqNFgS2RN5QJHXj4 qjyQRvsgZM2k3hOtly9XZtG5bi9e8ukPiBCB0m7BZKszFAVc5QQvTJs4HMsqzBLEnsDw vXO0Vq6JiX1BIEv6dWa8XsCatjH7EQc5lMQKTyP2vCK98T3S/J3irv6g8qBVt7rKbE92 WyCA== Received: by 10.60.27.161 with SMTP id u1mr3910786oeg.27.1352152202035; Mon, 05 Nov 2012 13:50:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 13:49:41 -0800 (PST) In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> From: Lorenzo Colitti Date: Tue, 6 Nov 2012 06:49:41 +0900 Message-ID: To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=e89a8fb20302af438404cdc677d4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk8AModPvbY7XDcmyFfmvOzGeWzbeZR/Xn5vDhn6kcoZcxpQ++ICUPTQYwTSrWLWPbpbE4gB6IXNJAGjDBEuu7++EOoEzJAT4jf+WCmq9WWxStJlqdbB6RLaXQeEpVWUr9IPxvxReYXcp+VDjxv5NjaRdSSPXrHC9keTrYnsSt5/DhL3+bAwqkMe0L+7NC7V30vhET4 Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:50:03 -0000 --e89a8fb20302af438404cdc677d4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm sorry, but you can't draft an option and then claim that the option needs to be standardized because the BBF needs it. The BBF cannot assume that an option will be standardized until it becomes an RFC, and referring to any particular IETF solution, including this one, before it is standardized is premature. That is the meaning of the text at the top of the draft, which says: It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Just because the BBF didn't read that text, or chose to ignore it, doesn't mean we have to standardize this option. If the BBF has a problem statement or a use case for this option, then that's fair game to include in the draft. Saying "we have to standardize it because they cite it already" or "we have to standardize it because they want it" is not. On Tue, Nov 6, 2012 at 4:38 AM, Arifumi Matsumoto wrote= : > Agree with Alex. > > The BBF document might have made a mistake on how to cite an I-D, > but it does not change the fact that BBF wants it. > > > 2012/11/3 Alexandru Petrescu > >> Hello, >> >> Le 01/11/2012 09:46, mif issue tracker a =E9crit : >> >> #15: use case #1 does not justify standardization of this option >>> >>> Use case #1 should remove the reference to walled gardens as a >>> motivation (see RFC 3002, section 4.2.1 and other tickets on this >>> theme). >>> >>> This option does not obviate the need for customer edge routers >>> (CPEs) to route ("to avoid routing on the CPE"). Why should we not >>> expect a router to route? >>> >>> Furthermore, this use case does not justify why customer edge >>> routers would need this. Instead, this use case documents a need for >>> a protocol to provision network provider edge routers, which is >>> something different. >>> >>> Recommendation: remove this use case. >>> >> >> I am not in a position to comment on the relevance of this use-case 1 >> "In Broadband network environment where the CPE is multi-homed to two >> upstream edge routers and each router provides connectivity for >> different..." >> >> I think authors of this use-case have a reason for having suggested it. >> >> On another hand, there are a number of other use cases that may need >> this DHCP route-option behaviour. Some specific to the default route >> aspect of a general route are described in >> draft-mouton-mif-dhcpv6-drlo-**02.txt ("Large Mobile Network Use Case", >> "Mi-Fi Coverage Extension Use Case", "M2M Constrained Device Use Case"). >> >> Alex >> >> ______________________________**_________________ >> 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 > > --e89a8fb20302af438404cdc677d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'= m sorry, but you can't draft an option and then claim that the option n= eeds to be standardized because the BBF needs it.

The BBF cannot assume that an option will be standardized until it becomes = an RFC, and referring to any particular IETF solution, including this one, = before it is standardized is premature. That is the meaning of the text at = the top of the draft, which says:

It is inappropriate to use Internet-Drafts as reference= =A0material or to cite them other than as "work in progress."

Just because the BBF didn't read that text, = or chose to ignore it, doesn't mean we have to standardize this option.=

If the BBF has a problem statement or a use case for th= is option, then that's fair game to include in the draft. Saying "= we have to standardize it because they cite it already" or "we ha= ve to standardize it because they want it" is not.

On Tue, Nov 6, 2012 at 4:38 AM, Arifumi Matsumoto <ari= fumi@nttv6.net> wrote:
Agree with Alex.

The BBF document might have made = a mistake on how to cite an I-D,
but it does not=A0change the fact that= BBF wants it.


2012/11/3 Alexandru Petrescu <alexandru.petrescu@gmail.com&= gt;
Hello,

Le 01/11/2012 09:46, mif issue tracker a =E9crit :

#15: use case #1 does not justify standardization of this option

Use case #1 should remove the reference to walled gardens as a
motivation (see RFC 3002, section 4.2.1 and other tickets on this
theme).

This option does not obviate the need for customer edge routers
(CPEs) to route ("to avoid routing on the CPE"). =A0Why should we= not
expect a router to route?

Furthermore, this use case does not justify why customer edge
routers would need this. =A0Instead, this use case documents a need for
a protocol to provision network provider edge routers, which is
something different.

Recommendation: remove this use case.

I am not in a position to comment on the relevance of this use-case 1
"In Broadband network environment where the CPE is multi-homed to two<= br> upstream edge routers and each router provides connectivity for
different..."

I think authors of this use-case have a reason for having suggested it.

On another hand, there are a number of other use cases that may need
this DHCP route-option behaviour. =A0Some specific to the default route
aspect of a general route are described in
draft-mouton-mif-dhcpv6-drlo-02.txt ("Large Mobile Network Use = Case",
"Mi-Fi Coverage Extension Use Case", "M2M Constrained Device= Use Case").

Alex

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif


_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif


--e89a8fb20302af438404cdc677d4-- From lorenzo@google.com Mon Nov 5 13:51:17 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D274121F8883 for ; Mon, 5 Nov 2012 13:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0RvN3-X+zpE for ; Mon, 5 Nov 2012 13:51:17 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1B521F881E for ; Mon, 5 Nov 2012 13:51:17 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so6699155obq.31 for ; Mon, 05 Nov 2012 13:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=/l6V4SM4NwW6V2J0ZCm4JKXFuc39U4nLxqM+Md8GB14=; b=QwDtQN//INk5uAqEU654vcIguRE3GbyGUUaawKLdm0+qe4NvwpBGuoHlxEtqGomCHv cwqxOLr6zEIqiW59a/8RYcFqGYZt7iLuRgm/A4oPoWT+3b5IkBIS9rQj2hKTOTX0PZI5 YLClkCpdTCDEMDSTcmFpAdgeifbRmA9d8LKDeYnlSxMSH6p/E9OwM/urm7oPfH88O6Nl r7fGdMgtCFInCmk9a3ZAISs8LMfM6Dv3Lla/eWsjtqrTr2A88+LL9vzDTsfs9E0r6A0o q1R+jNpYIOurSeq9yYCKTNlFBIt+TNdb4uj49cXd4pKIvsZE3GAiwp6WgrU+xcKGr1km Ez6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=/l6V4SM4NwW6V2J0ZCm4JKXFuc39U4nLxqM+Md8GB14=; b=SXBvbdVSVMgSGXAPvTesgf2qVn7gweXf4M6HvYIsb3a8rF58QcrshFNmepWMwff23z j862qxafnl/YiknpszmKUzMJWsiJIzRi9rk2sBGltXYKv4jOjxpQP1htRo7gJAQVG4K9 6oBHyA7V7otSFWHXcGDCLY5rzcIDH6iw6Tudcc1kayOgsOVWa3xsl/QliQyef/d8b3aG 5cdecpdWAPn3vb5Mv8MpwTvo0unXQuuNRoLKAfmHiun/90EVvmj6jckdloAL3B4yAgyY JyBRaqN3uGXGo3A3DVWDLIr8olKJ+KHyqYfC1J88xRfR70FNwkGm/+4WXMscNCBb8ydd Fscw== Received: by 10.60.8.65 with SMTP id p1mr8940532oea.92.1352152276859; Mon, 05 Nov 2012 13:51:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 13:50:56 -0800 (PST) In-Reply-To: <037B3B56-4CE0-438E-8ECD-B9334D006340@nominum.com> References: <056.2fabef163443fc4fd98f1ac75403af22@trac.tools.ietf.org> <79E97868-2D02-4DD1-80D8-45920AED654A@nominum.com> <037B3B56-4CE0-438E-8ECD-B9334D006340@nominum.com> From: Lorenzo Colitti Date: Tue, 6 Nov 2012 06:50:56 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8ff1c56a24fbbe04cdc67cd4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl7q2xFSBGE7xvGPdzIW5t3n8BlgLZmwV8ZU3M6h3Q5EZNd8FrhQGYKmbSLnmBmyBSwGy4SrZwUjm5OGR5idEQV7RIH1btHbv+mu39lGszSUKmC5v8GyiQjw2qr7cgvHk6eNoFV6KYlsqBHwb7R2lPp1oO+f3Met5c/RAc4UKR2zZY0c3wx0HXMprILPkuBrWeexzyh Cc: mif issue tracker , "" , "" Subject: Re: [mif] #16: DHCPv6 route option does not belong in MIF working group X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:51:17 -0000 --e89a8ff1c56a24fbbe04cdc67cd4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 6, 2012 at 1:23 AM, Ted Lemon wrote: > On Nov 5, 2012, at 11:16 AM, Lorenzo Colitti wrote: > > Ok, so I read your paragraph as "the problem statement for this draft is > vague and unparseable". But isn't that a serious problem with the document > that needs to be addressed? > > Yes, absolutely, and I communicated this to the authors when they issued > the current version of the draft. I am disappointed that this has not yet > been fixed. However, it is _not_ the problem that issue #16 talks about. > :) > You're right. I will file another issue then. --e89a8ff1c56a24fbbe04cdc67cd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 6, 2= 012 at 1:23 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:=
On Nov 5, 20= 12, at 11:16 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> Ok, so I read your paragraph as "the problem statement for this d= raft is vague and unparseable". But isn't that a serious problem w= ith the document that needs to be addressed?

Yes, absolutely, and I communicated this to the authors when they iss= ued the current version of the draft. =A0 I am disappointed that this has n= ot yet been fixed. =A0 However, it is _not_ the problem that issue #16 talk= s about. :)

You're right. I will file another issue then.
--e89a8ff1c56a24fbbe04cdc67cd4-- From Ted.Lemon@nominum.com Mon Nov 5 14:05:44 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CC121F8510 for ; Mon, 5 Nov 2012 14:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10vVGNhps5Vc for ; Mon, 5 Nov 2012 14:05:44 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2E821F8533 for ; Mon, 5 Nov 2012 14:05:43 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUJg4NTXLK24l3QISyQOs9JF2psU1X793@postini.com; Mon, 05 Nov 2012 14:05:44 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EFA8A1B82DC for ; Mon, 5 Nov 2012 14:05:40 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E516A19005C; Mon, 5 Nov 2012 14:05:40 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 14:05:41 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] #15: use case #1 does not justify standardization of this option Thread-Index: AQHNu40i2ewIM/ll2UKEJmbwQeKD2JfcTe2AgAAEdoA= Date: Mon, 5 Nov 2012 22:05:39 +0000 Message-ID: <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:05:45 -0000 On Nov 5, 2012, at 4:49 PM, Lorenzo Colitti wrote: > I'm sorry, but you can't draft an option and then claim that the option n= eeds to be standardized because the BBF needs it. This is a misrepresentation of the point to which you are responding. Ari= fumi's point is that BBF has a use case for this option. The point of adv= ancing the option is not because OMG they've already adopted it. It's beca= use they need it. We discussed this back in Prague, and you were there. = Why are we discussing it again? From lorenzo@google.com Mon Nov 5 14:36:40 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C356521F86CB for ; Mon, 5 Nov 2012 14:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwflFxkgJpM4 for ; Mon, 5 Nov 2012 14:36:40 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAF221F85C6 for ; Mon, 5 Nov 2012 14:36:40 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so9955546iec.31 for ; Mon, 05 Nov 2012 14:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=AKL/qTXPxzQt+7r6UcSpucOWp3lBdk1+MjmVdFWlMfA=; b=AR27Mbf5F75+07gzPJ96fHCnDhyJ7jeNNV87FVVYTKDcuGicgkTqNlEFj/k9s5onLz yzHhJvSKfSuQHVAsvVXtTSF9h8Jl0qNOmYud12WIyyLXeeq4rf0O8lA9GHnwEyiayDdw RueWjXhNOjvFmmSVy+0puotayqu023fCpH0txWGZCKdVFm3nwXPROOVwC/cpqoxClCiV CbSX9U7uqONPV+7xwpsBxTkZv8hhQoXNhBm6hIkW7m9vxqvXVnUrhSvr+yxN1tHxhJC0 Shx748Ox4YDp1STBm51qXq6Di8U+PSpKPrQxfvf/iLwznRxMrMCtpFCzFEKu7DNqpPzW +mMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=AKL/qTXPxzQt+7r6UcSpucOWp3lBdk1+MjmVdFWlMfA=; b=Fg395hjZTFPM3MFO+/DtiKihI7fOcnR78g3+u1nNxzgcrrwEZb77maHwwDR88GKgv7 5aRLmT6Rs9JtE6Bmvn6SinDe+eYKWq3DrsZr5cbqmmY+PxMnI5TE+HIHXWKo9jT5KumS t08Miac+cV0OkA1ZQw2LqBpP2/Sa5MK88dx8cmPg0S4lnss2KUbU+4olGalA2Zzni9Uc bffXkVgCAQalj3KLyLCVmoH0c6C4WfqFSXSMXbFKqHnvwkFFM7Y8r5Q8Qs+3MESK/Anv dFXFVTXQhxgZ3KJDz03iBPN8oIbR4ApeCsCAi3OVkcuoCR2XvZKYS2GUbgsrkK849ZLH tPqw== Received: by 10.42.157.202 with SMTP id e10mr9645077icx.41.1352154999557; Mon, 05 Nov 2012 14:36:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.23.137 with HTTP; Mon, 5 Nov 2012 14:36:18 -0800 (PST) In-Reply-To: <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> From: Lorenzo Colitti Date: Tue, 6 Nov 2012 07:36:18 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=90e6ba6138d06e0eab04cdc71e52 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkJ474PXIDFkKjcv74n7SoCI7TPho4puh4C5haoliF9lT+u9ku8to5J6npqUV4Ub4iypiPB0hR5rjppdVzSMydtkRDaFMSndi4p75GjTkRhrzZhHubivCctZXp3ayBRg2LjSq7Q7sbqJbS+Nv657RMg6OuIC71m5Si6Q+jLuQe4DOiE9FeGImDRyJ1YBZVVn8GZyCry Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 22:36:40 -0000 --90e6ba6138d06e0eab04cdc71e52 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 6, 2012 at 7:05 AM, Ted Lemon wrote: > On Nov 5, 2012, at 4:49 PM, Lorenzo Colitti > wrote: > > I'm sorry, but you can't draft an option and then claim that the option > needs to be standardized because the BBF needs it. > > This is a misrepresentation of the point to which you are responding. > Arifumi's point is that BBF has a use case for this option. The point of > advancing the option is not because OMG they've already adopted it. It's > because they need it. We discussed this back in Prague, and you were > there. Why are we discussing it again? > But do they? I can't read WT-124 issue 4 because I'm not a BBF member, but if WT-124 issue 3 is simply the working title for TR-124 issue 3 (since published), then there is no use case. TR-124 issue 3 only says that the gateway should be able to request this option and, if it has multiple WAN interfaces, use it. It doesn't say why. Since their document doesn't say why they want it, we can't know if the reason they want it is a reason that we would consider an acceptable reason to standardize it. --90e6ba6138d06e0eab04cdc71e52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue= , Nov 6, 2012 at 7:05 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Nov 5, 2012, a= t 4:49 PM, Lorenzo Colitti <lorenz= o@google.com>
=A0wrote:
> I'm sorry, but you can't draft an option and then claim that t= he option needs to be standardized because the BBF needs it.

This is a misrepresentation of the point to which you are responding.= =A0 Arifumi's point is that BBF has a use case for this option. =A0 Th= e point of advancing the option is not because OMG they've already adop= ted it. =A0It's because they need it. =A0 We discussed this back in Pra= gue, and you were there. =A0Why are we discussing it again?

But do they?=A0I can't read WT-124 iss= ue 4 because I'm not a BBF member, but if WT-124 issue 3 is simply the = working title for TR-124 issue 3 (since published), then there is no use ca= se. TR-124 issue 3 only says that the gateway should be able to request thi= s option and, if it has multiple WAN interfaces, use it. It doesn't say= why.

Since their document doesn't say why they want it, = we can't know if the reason they want it is a reason that we would cons= ider an acceptable reason to standardize it.
--90e6ba6138d06e0eab04cdc71e52-- From Ted.Lemon@nominum.com Mon Nov 5 15:18:48 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712E121F86CB for ; Mon, 5 Nov 2012 15:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coX4iezz5I-R for ; Mon, 5 Nov 2012 15:18:47 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9AC21F84BF for ; Mon, 5 Nov 2012 15:18:46 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUJhJVTcXnn2AbmY6Mf74gH0PhoCw6MwF@postini.com; Mon, 05 Nov 2012 15:18:46 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6643B1B82E3 for ; Mon, 5 Nov 2012 15:18:45 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5C90519005C; Mon, 5 Nov 2012 15:18:45 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 15:18:45 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] #15: use case #1 does not justify standardization of this option Thread-Index: AQHNu6YH4Qhf6U7YHUamoQAJS2RRLJfcZpcA Date: Mon, 5 Nov 2012 23:18:45 +0000 Message-ID: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:18:48 -0000 On Nov 5, 2012, at 5:36 PM, Lorenzo Colitti wrote: > Since their document doesn't say why they want it, we can't know if the r= eason they want it is a reason that we would consider an acceptable reason = to standardize it. Roberta Maglione was present at the meeting I spoke of, and has been presen= t in each working group meeting since then where this has been discussed, a= nd has explicitly stated what the BBF's needs are and why. There's probab= ly even a liason statement lying around somewhere. If you genuinely feel that this has not been sufficiently documented, I gue= ss we can track it down, but this is the first time I've heard you dispute = the point that the BBF has a need for this functionality. Previously when= we've talked about it you've said that it doesn't matter that they have th= is need, not that they don't in fact have this need. From lorenzo@google.com Mon Nov 5 16:04:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9B211E80D2 for ; Mon, 5 Nov 2012 16:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.91 X-Spam-Level: X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS+IF09kIR09 for ; Mon, 5 Nov 2012 16:04:34 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C42F811E80BF for ; Mon, 5 Nov 2012 16:04:34 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so6883684oag.31 for ; Mon, 05 Nov 2012 16:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=dS0Un6BRDqLXWRe/eXsEsIxeXClSinxiNJN7ppUoQL4=; b=NYtz+Pb+EFsO1nLwDItLwLYAIMj2DcqFW0KVI0MoP23gKWO6kBsNAx6NOguQt5AIst oqhldiAoFRuHs3tOczKGNeP0IxgIZC7YFBrMOfauChPxz1GbrnckLfaYAjROpCT88oBo pZUXyaqsxzF927o8926yB+jhPHCOUgU+f81VwFRfXkHwqv8EH+iU/xrirFLf5cAy0a8H WvMOFSrdSSw/KfiFjkxo3C7AIzlK9nh83TEcJKJfVNbZrHz5Cg/eLOxLoU2MbIbU100k I9Hb9UB+kmhlEqYgllo5HIXGFOu/OmypdCWtRAnOsGk5ToFN419ekg++dIJ4nwLYW9go TmrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=dS0Un6BRDqLXWRe/eXsEsIxeXClSinxiNJN7ppUoQL4=; b=WWMCEGcbNUrSFtPBHCStG/8tQb6ctZySuutzlouDDaKP0Gwp3pUv68Myxzf+4PiVBU 5X0VgAdGqmZm6+8t9Jd1ztxqiMFAWwCkpVzaYNQIddCbMa6PWgzsJSbGN4sDvVHhqYYX b4lTk9/b0slrjQ5RSaQzMrO9zzQeBWdoQpciQEzO/RMqzCuWZpKhSi3btAcWC6bpqwRf CLKIRJz3ABpBn9vio81j5vbuG2g7Qy9ZCItAnYteb6iMXk0KLFHSxoM7t5zneKPo+4uZ 2bMygqMMtG72G0UvbMiSboPf2AKQueNiWRYKdCL+HmN/f0xmF5TdgU60FeVVsRTID4Iu R7jg== Received: by 10.182.150.37 with SMTP id uf5mr9319849obb.10.1352160274137; Mon, 05 Nov 2012 16:04:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 16:04:14 -0800 (PST) In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> From: Lorenzo Colitti Date: Tue, 6 Nov 2012 09:04:14 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec51f9555d1c20904cdc85833 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmFsV89FYuqkkrVTR/Rp6WPy59Xq17oGYKPZfTBer0Gcqxy7h0V5mB4FYR8kz59mnTaD3gzi/9Wis1jPdGEN1U2Uxz6IKvKgRfyVHSR+KZwo/tMH+u/+/ej3FDpfdGKuPhKbWmYfeV0QTjbfL0s3SiLYmg3mkjyw/lvwdT1Ln5t6ZKHDCTCmXyPI7TDppG/PlqYaIsB Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:04:35 -0000 --bcaec51f9555d1c20904cdc85833 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 6, 2012 at 8:18 AM, Ted Lemon wrote: > On Nov 5, 2012, at 5:36 PM, Lorenzo Colitti wrote: > > Since their document doesn't say why they want it, we can't know if the > reason they want it is a reason that we would consider an acceptable reason > to standardize it. > > Roberta Maglione was present at the meeting I spoke of, and has been > present in each working group meeting since then where this has been > discussed, and has explicitly stated what the BBF's needs are and why. > There's probably even a liason statement lying around somewhere. > > If you genuinely feel that this has not been sufficiently documented, I > guess we can track it down, but this is the first time I've heard you > dispute the point that the BBF has a need for this functionality. > Previously when we've talked about it you've said that it doesn't matter > that they have this need, not that they don't in fact have this need. > Can we stop talking about me and take it back to the use case and the issue specified in the tracker? I think it's fair to say that the use case: 1. Is poorly documented ("in order to avoid routing on the CPE, we're specifying a protocol to configure routing on it" - seriously?) 2. Is poorly justified (why do we need a protocol to configure routing beyond the one we already have? is this case common enough that a vendor option is not enough? if the problem is provisioning the edge router, why can't we solve that problem instead?) 3. Has an incorrect statement about the BBF (TR-124 does not call for this draft or say why it's needed). 4. Violates the strong IAB recommendations made in RFC 3002 that the IETF not design for walled gardens. The "it doesn't matter that they have this need" is mostly captured in #4. --bcaec51f9555d1c20904cdc85833 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue= , Nov 6, 2012 at 8:18 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Nov 5, 2012, at 5:36 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
> Since their document doesn't say why they want it, we can't kn= ow if the reason they want it is a reason that we would consider an accepta= ble reason to standardize it.

Roberta Maglione was present at the meeting I spoke of, and has been = present in each working group meeting since then where this has been discus= sed, and has explicitly stated what the BBF's needs are and why. =A0 Th= ere's probably even a liason statement lying around somewhere.

If you genuinely feel that this has not been sufficiently documented, I gue= ss we can track it down, but this is the first time I've heard you disp= ute the point that the BBF has a need for this functionality. =A0 Previousl= y when we've talked about it you've said that it doesn't matter= that they have this need, not that they don't in fact have this need.<= br>

Can we stop talking about me and take it b= ack to the use case and the issue specified in the tracker? I think it'= s fair to say that=A0the use case:
  1. Is poorly documented (= "in order to avoid routing on the CPE, we're specifying a protocol= to configure routing on it" - seriously?)
  2. Is poorly justified (why do we need a protocol to configure routing bey= ond the one we already have? is this case common enough that a vendor optio= n is not enough? if the problem is provisioning the edge router, why can= 9;t we solve that problem instead?)
  3. Has an incorrect statement about the BBF (TR-124 does not call for this= draft or say why it's needed).
  4. Violates the strong IAB recomme= ndations made in RFC 3002 that the IETF not design for walled gardens.
The "it doesn't matter that they have this need" is= mostly captured in #4.
--bcaec51f9555d1c20904cdc85833-- From Ted.Lemon@nominum.com Mon Nov 5 16:30:03 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4011F0C54 for ; Mon, 5 Nov 2012 16:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHIOqqe0jZ3W for ; Mon, 5 Nov 2012 16:30:02 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6B921F8480 for ; Mon, 5 Nov 2012 16:30:02 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUJhaCph6qUuYs6iEW6hFhAVZkpj3HBBl@postini.com; Mon, 05 Nov 2012 16:30:02 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5DE131B82D1 for ; Mon, 5 Nov 2012 16:30:01 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5569019005C; Mon, 5 Nov 2012 16:30:01 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 16:30:01 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] #15: use case #1 does not justify standardization of this option Thread-Index: AQHNu6YH4Qhf6U7YHUamoQAJS2RRLJfcZpcAgAAMvACAAAcxgA== Date: Tue, 6 Nov 2012 00:30:00 +0000 Message-ID: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:30:03 -0000 If you are advocating for a clean-up of the requirements, I am 100% in agre= ement, but it seems to me that you are advancing a complete misrepresentati= on of the BBF requirement. Since we already agree that the requirements n= eed clean-up, talking about how one requirement indicates a problem with an= other is moot=97let's just advocate a careful review and cleanup, and see i= f the authors will do that. If not, there is no way to make forward progr= ess, and in that case it would make the most sense to just discontinue the = work. But assuming the authors are willing to clean up the requirements, it would= be better to postpone discussion of the problems with the requirements sec= tion until that work has been done. From trac+mif@trac.tools.ietf.org Mon Nov 5 16:44:55 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95911E80BA for ; Mon, 5 Nov 2012 16:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usjzTEFBzjgU for ; Mon, 5 Nov 2012 16:44:54 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9479111E80AE for ; Mon, 5 Nov 2012 16:44:54 -0800 (PST) Received: from localhost ([127.0.0.1]:45382 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVXHI-0001pa-Gv; Tue, 06 Nov 2012 01:44:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, lorenzo@google.com X-Trac-Project: mif Date: Tue, 06 Nov 2012 00:44:28 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/18 Message-ID: <056.bf4be9973967ba3360fd76cdc2cc3950@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, lorenzo@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121106004454.9479111E80AE@ietfa.amsl.com> Resent-Date: Mon, 5 Nov 2012 16:44:54 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #18: Vague problem statement and poorly-documented use cases X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:44:55 -0000 #18: Vague problem statement and poorly-documented use cases As documented in other tickets, many of the use cases listed in the draft are spurious, self-referential, poorly documented, or in contrast with IAB guidance. The use cases need to be better documented and justified before the work can proceed. -- -------------------------+------------------------------------------------- Reporter: lorenzo@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: blocker | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From lorenzo@google.com Mon Nov 5 16:50:06 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAFE21F85E0 for ; Mon, 5 Nov 2012 16:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thJcb5EPfVSK for ; Mon, 5 Nov 2012 16:50:06 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2528821F85A8 for ; Mon, 5 Nov 2012 16:50:05 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so6836957obq.31 for ; Mon, 05 Nov 2012 16:50:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2c4SRZUTSD+A8t6HjRxBxPVnCPqq0T/4AaDyXYWhu/8=; b=AQ1oZuUkYsU35GgLrgyy69Y4vC2WKJw3Bm1mkKFcxiidZX9N9/yQIe4ElzDB9juifX JIct5BSE1HT4NzOs8h+Djd6zE0kaJdpO2i6SNvrAZEF1JYkdefwo73GiEMaoTIBGLvwW C80i6nmp4eg+RfZW6BzXeL+oA8cJWaLIvzpqwZp+OL9lfoSi1nqlV6qK0meV4YlWmktY WOPZcKQ12qgHD6ub1wz+NqvsAi/IlbE+6CdoTwd0JHeq0VT5rciTSr6wuaqOnTwSwfeg E2QaFVXOddnf4DI6aYTVuv2/+gbRFM+MXRKekl12Xk8O7ZFm5CsNX5ObwyxpykyCDwOo vpVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=2c4SRZUTSD+A8t6HjRxBxPVnCPqq0T/4AaDyXYWhu/8=; b=L84qyXMunemAE/9YQLIhcHObFO09StgvR/m1CIAi41Yol7b7g9mbWr8k7L1gJABWLP r6LfBuawoF6IpEkC7Bvmzqiq5Eawfz3DTm82cY97JibS4DNGPhly7RGJITULbhMLCSqZ QuhWdCMDvqGdcY1zxhxDgdMLI4SbuUAvOvvPv68AcwxoDRDp6ba+uZTu3k3bmrJItWib TIQyFzf7T0XhsMa8v8rih4wLVeNCywcGbpIsBbgSNtlxLue0BHvG6ceo12MLjjPJkvVZ F+t+wjYfTLgoKkcVkNuNVJu5++7wYIr3Qmjty2LG8C2pHkzdOI/ERrIg0L51u1NkixpX f27Q== Received: by 10.60.14.165 with SMTP id q5mr9661206oec.28.1352163005467; Mon, 05 Nov 2012 16:50:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 16:49:45 -0800 (PST) In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> From: Lorenzo Colitti Date: Tue, 6 Nov 2012 09:49:45 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8fb1f4689e8c4704cdc8fb99 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm5IPLDm6oW/CGVKgsLLYmeiEbAstwUXGZQ0oIvPIuH33RSsk1EUZLXgcqoPxdcGVRmA5KLKunr1DIcJ6aIDD32gl90V8DcP94hkx/pIpoJYh7NMT3nL58DGQS0VMdqEYYiJUnuBsLr3p4o7poFInSrkPbJ2LMKDZB/MhOtHErQBWGE9krHiL3PsBg4LvYvU+uMqU4C Cc: "" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:50:07 -0000 --e89a8fb1f4689e8c4704cdc8fb99 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2012 at 9:30 AM, Ted Lemon wrote: > If you are advocating for a clean-up of the requirements, I am 100% in > agreement, but it seems to me that you are advancing a complete > misrepresentation of the BBF requirement. It's not just a clean-up. Points 2, 3, and 4 in the email (especially 4) are issues that need to be dealt with in in order for this requirement to be valid at all. The IAB guidance on walled gardens is quite substantive to many of the use cases for this draft, and is therefore a serious concern. > Since we already agree that the requirements need clean-up, talking > about how one requirement indicates a problem with another is moot=97let'= s > just advocate a careful review and cleanup, and see if the authors will d= o > that. If not, there is no way to make forward progress, and in that cas= e > it would make the most sense to just discontinue the work. > > But assuming the authors are willing to clean up the requirements, it > would be better to postpone discussion of the problems with the > requirements section until that work has been done. > Ack. http://trac.tools.ietf.org/wg/mif/trac/ticket/18 --e89a8fb1f4689e8c4704cdc8fb99 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue= , Nov 6, 2012 at 9:30 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
If you are advoca= ting for a clean-up of the requirements, I am 100% in agreement, but it see= ms to me that you are advancing a complete misrepresentation of the BBF req= uirement.

It's not just a clean-up. Points 2, 3, and 4 in the= email (especially 4) are issues that need to be dealt with in in order for= this requirement to be valid at all. The IAB guidance on walled gardens is= quite substantive to many of the use cases for this draft, and is therefor= e a serious concern.
=A0
=A0 Since we already agree th= at the requirements need clean-up, talking about how one requirement indica= tes a problem with another is moot=97let's just advocate a careful revi= ew and cleanup, and see if the authors will do that. =A0 If not, there is n= o way to make forward progress, and in that case it would make the most sen= se to just discontinue the work.

But assuming the authors are willing to clean up the requirements, it would= be better to postpone discussion of the problems with the requirements sec= tion until that work has been done.

--e89a8fb1f4689e8c4704cdc8fb99-- From n@arifumi.net Mon Nov 5 16:59:42 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D223711E80AE for ; Mon, 5 Nov 2012 16:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e74JBDSByLeP for ; Mon, 5 Nov 2012 16:59:42 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48D6F11E80A5 for ; Mon, 5 Nov 2012 16:59:42 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so7299608vbb.31 for ; Mon, 05 Nov 2012 16:59:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=OUGQ50RtPkP8PQc1NIstXegT45hlyKol9H4vYao7+Ck=; b=WRPRJc5Dw4fJSeKw+d6hlp82eErZGldaaYvarcjSN5SMKyv4lqrGWcya1lcRO42rNr Yg79UMTFYsukkStQs3s8gYyM4+CE6CiKI7T00SOINllCfiNSaZaH9zZ0gih5Z/7I0aLl 5f+3RngHy+8N5PAxj2l8DFv2gH9Lfiw8F7DEvLU1bXf0AVGzTJdLsaKITNtq5WOQ2zxt cRcKKUNfmdS7WBtZBzPz4gMZFILQ9SMMKZx6qo4Q/6sK0svtAXmC1L9EJjqRBCynevz4 m7XIzDjPLvZScG7lVoTsOGYxqr3Cd5J0bN9HuEOCMC1DEHWjlBkgvs6UGEYBFEmcGCfn +noQ== MIME-Version: 1.0 Received: by 10.52.72.132 with SMTP id d4mr9831193vdv.91.1352163581631; Mon, 05 Nov 2012 16:59:41 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Mon, 5 Nov 2012 16:59:41 -0800 (PST) X-Originating-IP: [65.111.75.199] In-Reply-To: <056.bf4be9973967ba3360fd76cdc2cc3950@trac.tools.ietf.org> References: <056.bf4be9973967ba3360fd76cdc2cc3950@trac.tools.ietf.org> Date: Tue, 6 Nov 2012 09:59:41 +0900 X-Google-Sender-Auth: IU5Xq4g7-GK1sNwonDZ7WV38RLk Message-ID: From: Arifumi Matsumoto To: mif issue tracker Content-Type: multipart/alternative; boundary=bcaec5016557f61c0504cdc91d2e X-Gm-Message-State: ALoCoQlgW5Q8C0e37Hz86PsXzbCWAva3fRZMRE+Mhp5l55zcdmX8cpS1CBIRgZSiZNRSlM9/FS5E Cc: "" , "" Subject: Re: [mif] #18: Vague problem statement and poorly-documented use cases X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:59:42 -0000 --bcaec5016557f61c0504cdc91d2e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If other tickets documented concrete issues, do we need this new ticket ? 2012/11/6 mif issue tracker > #18: Vague problem statement and poorly-documented use cases > > As documented in other tickets, many of the use cases listed in the draf= t > are spurious, self-referential, poorly documented, or in contrast with I= AB > guidance. > > The use cases need to be better documented and justified before the work > can proceed. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: lorenzo@=85 | Owner: draft-ietf-mif-dhcpv6-route- > Type: defect | option@=85 > Priority: blocker | Status: new > Component: dhcpv6 | Milestone: > -route-option | Version: > Severity: - | Keywords: > -------------------------+-----------------------------------------------= -- > > Ticket URL: > mif > > --bcaec5016557f61c0504cdc91d2e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If other tickets documented concrete issues, do we need this new ticket ?

2012/11/6 mif i= ssue tracker <trac+mif@grenache.tools.ietf.org>
#18: Vague problem statement and poorly-docu= mented use cases

=A0As documented in other tickets, many of the use cases listed in the draf= t
=A0are spurious, self-referential, poorly documented, or in contrast with I= AB
=A0guidance.

=A0The use cases need to be better documented and justified before the work=
=A0can proceed.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0lorenzo@=85 =A0 =A0| =A0 =A0 =A0Owner: =A0draft-ietf-mif-dh= cpv6-route-
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0option@=85
=A0Priority: =A0blocker =A0 =A0 =A0| =A0 =A0 Status: =A0new
Component: =A0dhcpv6 =A0 =A0 =A0 | =A0Milestone:
=A0 -route-option =A0 =A0 =A0 =A0 =A0| =A0 =A0Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/18>= ;
mif <http://too= ls.ietf.org/mif/>


--bcaec5016557f61c0504cdc91d2e-- From Ted.Lemon@nominum.com Mon Nov 5 17:09:28 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2455011E80AE for ; Mon, 5 Nov 2012 17:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT-D-CANeIvm for ; Mon, 5 Nov 2012 17:09:26 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 71DB121F8799 for ; Mon, 5 Nov 2012 17:09:26 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUJhjQc7zR1v8TzHDBypnQt5hZ02mmVF9@postini.com; Mon, 05 Nov 2012 17:09:26 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 945E1F8002 for ; Mon, 5 Nov 2012 17:09:20 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7867E19005C; Mon, 5 Nov 2012 17:09:20 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 17:09:13 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] #15: use case #1 does not justify standardization of this option Thread-Index: AQHNu6YH4Qhf6U7YHUamoQAJS2RRLJfcZpcAgAAMvACAAAcxgIAABYaAgAAFbwA= Date: Tue, 6 Nov 2012 01:09:12 +0000 Message-ID: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <97F8F8407CCBF1499685B77DBA90266A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 01:09:28 -0000 On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti wrote: > It's not just a clean-up. Points 2, 3, and 4 in the email (especially 4) = are issues that need to be dealt with in in order for this requirement to b= e valid at all. The IAB guidance on walled gardens is quite substantive to = many of the use cases for this draft, and is therefore a serious concern. It's an interesting point, but what we're talking about here is dedicated r= outing for streaming services like VoIP and video, not a walled garden in t= he old sk00l AOL/Compuserve sense. You could get to the service over the = best-effort routing as well, but you will do better getting to that service= over the custom route. This is an application which seems to be quite po= pular among various ISPs=97the Wifi Alliance is working on it, I know of at= least one customer of my own employer who wants to do something like this,= and apparently BBF considers it useful. Is this what the IAB meant when they said that we shouldn't support walled = gardens? This is a serious question=97it is not my impression that this i= s what they meant, but I honestly don't know. Of course, that opens up the question of why not use existing QoS mechanism= s, and I honestly don't know the answer to that=97I'm not an expert on exis= ting solutions to that problem. I suspect the goal is to avoid expensive, = specialized switching gear near the provider edge, but that's just a guess. From brian.e.carpenter@gmail.com Mon Nov 5 18:38:19 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CF721F8507 for ; Mon, 5 Nov 2012 18:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3JDD6Fo3h0g for ; Mon, 5 Nov 2012 18:38:18 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7411E80D5 for ; Mon, 5 Nov 2012 18:38:18 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so30182pbb.31 for ; Mon, 05 Nov 2012 18:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=amMhdYGqHRaTbpaNmC8UtM0E1Z1DdCypbWM7WpYl5Cs=; b=IZq9k/0+hMOtcpGhCK4McDwI1ExLGhu0RFQEy4Ikfw4Ej8veTgS798iJzubD9W5Qwe ChJ88/Sp5VF1Q4FNh9WBbs6Ogmlutzc7FGTC5VvIM9Ay92TtwOLBFxSyutswyeKyRGnq 2v+k0SqipFkFt7TFQp0AtCwb//nUxi+aDh4+j+AIJRucLZjGlbEWlitW9gXVGX10G0m6 GqvGISZocjm46d+g76TlzB/hl9dw1P5hbzkuR71mW2O91EOLOx8UYTAL1wpn1f7CjZWZ Bb5pUhP4/yWkzavxNXsdMlmLEFKhO9aUoFpLyktBkbeduYW8Sk+EwyavgwKsQqAqGkM+ BH7A== Received: by 10.68.231.41 with SMTP id td9mr35804031pbc.128.1352169496212; Mon, 05 Nov 2012 18:38:16 -0800 (PST) Received: from [130.129.66.184] (dhcp-42b8.meeting.ietf.org. [130.129.66.184]) by mx.google.com with ESMTPS id c8sm11602472pav.4.2012.11.05.18.38.14 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 18:38:15 -0800 (PST) Message-ID: <50987819.407@gmail.com> Date: Tue, 06 Nov 2012 02:38:17 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 02:38:19 -0000 On 06/11/2012 01:09, Ted Lemon wrote: > On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti > wrote: >> It's not just a clean-up. Points 2, 3, and 4 in the email >> (especially 4) are issues that need to be dealt with in in >> order for this requirement to be valid at all. The IAB >> guidance on walled gardens is quite substantive to many of >> the use cases for this draft, and is therefore a serious >> concern. >=20 > It's an interesting point, but what we're talking about here > is dedicated routing for streaming services like VoIP and > video, not a walled garden in the old sk00l AOL/Compuserve > sense. You could get to the service over the best-effort > routing as well, but you will do better getting to that > service over the custom route. This is an application which > seems to be quite popular among various ISPs=E2=80=94the Wifi > Alliance is working on it, I know of at least one customer of > my own employer who wants to do something like this, and > apparently BBF considers it useful. >=20 > Is this what the IAB meant when they said that we shouldn't > support walled gardens? This is a serious question=E2=80=94it is > not my impression that this is what they meant, but I > honestly don't know. Speaking as a participant at the IAB workshop that led to RFC 3002 (and with no authority beyond that of a participant): Firstly, please read section 3.1 of that RFC. Perhaps the key quote is this: 'The term "walled garden" was coined to describe the resulting captive customer economic and service model. That is, the user is constrained within the limits of the service provided by the carrier with limited ability to extend features or access services outside the provider.' and a bit later: 'Some discussion focused on whether cellular carriers could be persuaded to transition toward the Internet "open" service model. Responses indicated that there was little hope of this as carriers will always fight being reduced to a "bit pipe", fearing they cannot sustain sufficient revenues without the value added services.' It's also worth reading section 4.2 'Recommendations for Dealing with "Walled Garden" Model.' This is written constructively on the assumption that there will be walled gardens, so the IETF should live with it despite not liking it. The dislike is very explicit: 'It was strongly recommended that independent of the ubiquity of the "walled garden" deployment scenario that protocols and architectural decisions should not target this model.' I think it's a bit of a stretch to say that draft-ietf-mif-dhcpv6-route-option explicitly targets this model; it's actually a generic mechanism, even if some of the use cases do fit the walled garden model. > Of course, that opens up the question of why not use existing > QoS mechanisms, and I honestly don't know the answer to > that=E2=80=94I'm not an expert on existing solutions to that problem. > I suspect the goal is to avoid expensive, specialized > switching gear near the provider edge, but that's just a > guess. The main existing QoS mechanism is known as "throw bandwidth at the problem", and providing a dedicated route on a path known to have adequate bandwidth is exactly that. But there are people considering other approaches including diffserv or the flow label. There is yet another approach about which draft-sun-semantic-usecase and draft-jiang-semantic-prefix will enlighten you. Brian From Ted.Lemon@nominum.com Mon Nov 5 18:55:22 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8715821F89AD for ; Mon, 5 Nov 2012 18:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtiEK62EBm27 for ; Mon, 5 Nov 2012 18:55:22 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2A52221F8525 for ; Mon, 5 Nov 2012 18:55:18 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUJh8ESrO3QBfqqlNlKWC+t96NOzuxpLr@postini.com; Mon, 05 Nov 2012 18:55:19 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 81BBEF8005 for ; Mon, 5 Nov 2012 18:55:13 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 759CC19005C; Mon, 5 Nov 2012 18:55:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 5 Nov 2012 18:55:13 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] #15: use case #1 does not justify standardization of this option Thread-Index: AQHNu6YH4Qhf6U7YHUamoQAJS2RRLJfcZpcAgAAMvACAAAcxgIAABYaAgAAFbwCAABjkgIAABLoA Date: Tue, 6 Nov 2012 02:55:12 +0000 Message-ID: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> In-Reply-To: <50987819.407@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <66BEE76EA875BF41881927EDC36123F2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 02:55:22 -0000 On Nov 5, 2012, at 9:38 PM, Brian E Carpenter = wrote: > There is yet another approach about which > draft-sun-semantic-usecase and draft-jiang-semantic-prefix will > enlighten you. Yes, I'm familiar with this work. Thanks for the detailed explanation=97t= hat was very helpful. From lorenzo@google.com Mon Nov 5 20:27:01 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AD921F85C6 for ; Mon, 5 Nov 2012 20:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.918 X-Spam-Level: X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsG8XT9nDXGX for ; Mon, 5 Nov 2012 20:27:01 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27F7121F85BA for ; Mon, 5 Nov 2012 20:27:01 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so22742oag.31 for ; Mon, 05 Nov 2012 20:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J9Edfe5s0EeN54doRVIfxbFiD/3VtgNf9JD4e1WFQrg=; b=lI5oMyQ1Ru8KchFTcTFtZuyHIb/zpaGxd7LrXKiBHeZv1qFbRh3QLuDp8QPgIA/2/l DR5q9qeqC14wxlBBPiTUZcuZ8laFsi3Gm5kuNFMPcrRuauFU0RTni131jzD/KCRnqmwY EqQzgmLeMtZn5e6WcXs4lKKAkwWfSIpquWU3+5DnV1A7Lz7QaguTATvEhmGpZtKpvvHv kGR2JA49+/XFaCg0os8v51vlISg4SmYHjLL46RM+rSgpG3PVIJ+4PHhREYZarIAzlglQ 7zOYkifpJsKo0fn6qSGlvPu/PVxUpsuOZjZ/znFc3lc3AsH4at659ghg/3/NM6ePd25y N+MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=J9Edfe5s0EeN54doRVIfxbFiD/3VtgNf9JD4e1WFQrg=; b=MYBtHETMg3adqlbhxY0GZySKSNmU4zORaJ3dRGTEP44igz/SFjq6Vpl8y/xNGhptjO rbkODyZg7JO5Cx4Q42L61HiXX+hd4Sv+fzwWnjBhQ55Qeo6ZS4gZwfUwyW13GLAaYjOq 2f7I0FKKsb/3TiaJSbQ0NZyxYl8o2/wmtxCTBN8ksMdAqOHIxvnuY+QVQMFZ03gjHjzN MXHbrx49Oh9f9b6waZrshGEZPx0FGnx0TDLaKiNocEjOzT7eNaWD77ljyepzRhVieuFe mSSX2O/pWzZLtzH6AxKvxA58o6i+mC1vx+RvOr+e0HqfNdw2iJsqT+zPT6TCStRbWk+S OnFg== MIME-Version: 1.0 Received: by 10.60.26.72 with SMTP id j8mr9832539oeg.68.1352176020533; Mon, 05 Nov 2012 20:27:00 -0800 (PST) Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 20:27:00 -0800 (PST) Received: by 10.182.176.106 with HTTP; Mon, 5 Nov 2012 20:27:00 -0800 (PST) In-Reply-To: References: <056.bf4be9973967ba3360fd76cdc2cc3950@trac.tools.ietf.org> Date: Tue, 6 Nov 2012 13:27:00 +0900 Message-ID: From: Lorenzo Colitti To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=e89a8fb1f8d260b3ba04cdcc03ca X-Gm-Message-State: ALoCoQmmYyTz3MQ7zTXdT3lompu82m6YuANYCadiCBteajc5ixmQRCy7BwFPl7yBZf5Q7xYlDQlu0hVqWGJHiR0mtns6nrJsEL5BYgOjumsBsIqWBz++nUys7jXloApAEcWe/tGPOp3LOxmUgIr+8ycr7tPlXfzC1r/Fcr5ezE1aaeuJXgKmczZPoT/lrizp+Cq2mOSd5FoT Cc: mif issue tracker , mif@ietf.org, "" Subject: Re: [mif] #18: Vague problem statement and poorly-documented use cases X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 04:27:01 -0000 --e89a8fb1f8d260b3ba04cdcc03ca Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I filed this ticket mostly in response to Ted's assertion that "we agree that the requirements section needs a cleanup [...] if not, there is no way to make forward progress." This ticket was intended to track that cleanup effort. On Nov 5, 2012 7:59 PM, "Arifumi Matsumoto" wrote: > If other tickets documented concrete issues, do we need this new ticket ? > > > 2012/11/6 mif issue tracker > >> #18: Vague problem statement and poorly-documented use cases >> >> As documented in other tickets, many of the use cases listed in the dra= ft >> are spurious, self-referential, poorly documented, or in contrast with >> IAB >> guidance. >> >> The use cases need to be better documented and justified before the wor= k >> can proceed. >> >> -- >> >> -------------------------+----------------------------------------------= --- >> Reporter: lorenzo@=85 | Owner: draft-ietf-mif-dhcpv6-route- >> Type: defect | option@=85 >> Priority: blocker | Status: new >> Component: dhcpv6 | Milestone: >> -route-option | Version: >> Severity: - | Keywords: >> >> -------------------------+----------------------------------------------= --- >> >> Ticket URL: >> mif >> >> > --e89a8fb1f8d260b3ba04cdcc03ca Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I filed this ticket mostly in response to Ted's assertio= n that "we agree that the requirements section needs a cleanup [...] i= f not, there is no way to make forward progress."

This ticket was intended to track that cleanup effort.

On Nov 5, 2012 7:59 PM, "Arifumi Matsumoto&= quot; <arifumi@nttv6.net> wr= ote:
If other tickets documented concrete issues, do we need this new ticket ?

2012/11/6 mif i= ssue tracker <trac+mif@grenache.tools.ietf.org>
#18: Vague problem statement and poorly-docu= mented use cases

=A0As documented in other tickets, many of the use cases listed in the draf= t
=A0are spurious, self-referential, poorly documented, or in contrast with I= AB
=A0guidance.

=A0The use cases need to be better documented and justified before the work=
=A0can proceed.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0lorenzo@=85 =A0 =A0| =A0 =A0 =A0Owner: =A0draft-ietf-mif-dh= cpv6-route-
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0option@=85
=A0Priority: =A0blocker =A0 =A0 =A0| =A0 =A0 Status: =A0new
Component: =A0dhcpv6 =A0 =A0 =A0 | =A0Milestone:
=A0 -route-option =A0 =A0 =A0 =A0 =A0| =A0 =A0Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/mif/trac/ticket/18>= ;
mif <http://too= ls.ietf.org/mif/>


--e89a8fb1f8d260b3ba04cdcc03ca-- From n@arifumi.net Tue Nov 6 07:41:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3C21F89E5 for ; Tue, 6 Nov 2012 07:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lje2qny-RvEO for ; Tue, 6 Nov 2012 07:41:34 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5721F89F6 for ; Tue, 6 Nov 2012 07:41:33 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so573699vbb.31 for ; Tue, 06 Nov 2012 07:41:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=h0NIolnwuSkvlEL6x4aSCkENlcX09cyfkneUOmy+Ll4=; b=FTOEl+liVuC8XuDivLylyZYTjFQM0nqtrVjhCY5BtWFSkEX2/4832YduERPSaTn8o6 UZHzuPDCL5LsdG75UlCuRmxpy4pfDFgP5Z/Oqvoj0jwIuIjFaNo3DIubHIr/7lqaP3YC QM291d2EJXJtdA577wTx4IUAo9JjImhl4mlhJ+axKSYwWNc6TwhoSmBnw2p3Vhf6Jw2t deWscwbaZFVedoqtZMwp7caqDFaxrCw4TLO7IOpTADZsx5qLVvtJ87FITwgdu/fVvM8z sIOxuA90mZRYU19cz+fXHsNr5Wggqzd8JMKY0cYYVZjqyDS/xPmpI162DQ981JUxvG3P 27vw== MIME-Version: 1.0 Received: by 10.220.8.73 with SMTP id g9mr1245205vcg.28.1352216493343; Tue, 06 Nov 2012 07:41:33 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Tue, 6 Nov 2012 07:41:33 -0800 (PST) X-Originating-IP: [65.111.75.199] In-Reply-To: <50987819.407@gmail.com> References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> Date: Tue, 6 Nov 2012 10:41:33 -0500 X-Google-Sender-Auth: givpCbRaPG7y1bPJa7gAKJC_1pc Message-ID: From: Arifumi Matsumoto To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec54b4924bec24404cdd56f1a X-Gm-Message-State: ALoCoQkDchJvSI/BaRhqu/SYrNOJzM1yyS7H7Wz9NFMMF/FAPv2dMPjY32wuaEEtwSjs8bAb7ppg Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 15:41:35 -0000 --bcaec54b4924bec24404cdd56f1a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, rereading RFC 3002 walled garden treatment in IETF, it also describes like follows, "Recognition that the "walled garden" model has some perceived benefits led to recommendations to better integrate it into the Internet architecture. These focused on service location and escape from the "walled garden"." " It was recommended to investigate standard protocols for service and proxy discovery within the "walled garden" domain." "It was recommended to investigate standard methods to transport through the garden wall (e.g., escape to the Internet)." So, it does not recommend targeting this model of walled garden, but it looks recommending to standardize better co-existence method of open model and closed model. The model that the current dhcp route option draft describes seems me to fall into the matter of co-existence. Thanks. 2012/11/5 Brian E Carpenter > On 06/11/2012 01:09, Ted Lemon wrote: > > On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti > > wrote: > >> It's not just a clean-up. Points 2, 3, and 4 in the email > >> (especially 4) are issues that need to be dealt with in in > >> order for this requirement to be valid at all. The IAB > >> guidance on walled gardens is quite substantive to many of > >> the use cases for this draft, and is therefore a serious > >> concern. > > > > It's an interesting point, but what we're talking about here > > is dedicated routing for streaming services like VoIP and > > video, not a walled garden in the old sk00l AOL/Compuserve > > sense. You could get to the service over the best-effort > > routing as well, but you will do better getting to that > > service over the custom route. This is an application which > > seems to be quite popular among various ISPs=97the Wifi > > Alliance is working on it, I know of at least one customer of > > my own employer who wants to do something like this, and > > apparently BBF considers it useful. > > > > Is this what the IAB meant when they said that we shouldn't > > support walled gardens? This is a serious question=97it is > > not my impression that this is what they meant, but I > > honestly don't know. > > Speaking as a participant at the IAB workshop that led to RFC > 3002 (and with no authority beyond that of a participant): > > Firstly, please read section 3.1 of that RFC. Perhaps the key > quote is this: > > 'The term "walled garden" was coined to describe the resulting > captive customer economic and service model. That is, the user > is constrained within the limits of the service provided by the > carrier with limited ability to extend features or access > services outside the provider.' > > and a bit later: > > 'Some discussion focused on whether cellular carriers could be > persuaded to transition toward the Internet "open" service > model. Responses indicated that there was little hope of this as > carriers will always fight being reduced to a "bit pipe", > fearing they cannot sustain sufficient revenues without the > value added services.' > > It's also worth reading section 4.2 'Recommendations for Dealing > with "Walled Garden" Model.' This is written constructively on > the assumption that there will be walled gardens, so the IETF > should live with it despite not liking it. The dislike is very > explicit: 'It was strongly recommended that independent of the > ubiquity of the "walled garden" deployment scenario that > protocols and architectural decisions should not target this model.' > > I think it's a bit of a stretch to say that > draft-ietf-mif-dhcpv6-route-option explicitly targets this > model; it's actually a generic mechanism, even if some of the > use cases do fit the walled garden model. > > > Of course, that opens up the question of why not use existing > > QoS mechanisms, and I honestly don't know the answer to > > that=97I'm not an expert on existing solutions to that problem. > > I suspect the goal is to avoid expensive, specialized > > switching gear near the provider edge, but that's just a > > guess. > > The main existing QoS mechanism is known as "throw bandwidth at > the problem", and providing a dedicated route on a path known to > have adequate bandwidth is exactly that. But there are people > considering other approaches including diffserv or the flow > label. There is yet another approach about which > draft-sun-semantic-usecase and draft-jiang-semantic-prefix will > enlighten you. > > Brian > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --bcaec54b4924bec24404cdd56f1a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

rereading RFC 3002 walled garden treatment in IETF,<= /div>
it also describes like follows,

"Recognition that the "wal= led garden" model has some perceived
   benefits led to recommendations to better integrate it in=
to the
   Internet architecture.  These focused on service location and escape
   from the "walled garden"."

=
" It was recommend= ed to investigate standard protocols for service and
=A0 =A0proxy discovery = within the "walled garden" domain."

"It was recommended to investigate= standard methods to transport
   through the garden wall (e.g., escape to the Internet).&q=
uot;

So, it does not recommend targeting this model of =
walled garden,
but it looks recommending to standardize better co-existence method of
open model and closed model.

The model that the current dhcp route option draft=
 describes seems me
to fall into the matter of co-existence.

Thanks.


=
2012/11/5 Brian E Carpenter <brian.e.carpenter@gmail.com>=



On 06/11/2012 01:09, Ted L=
emon wrote:

> On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti

> <lorenzo@google.com> w=
rote:

>> It's not just a clean-up. Points 2, 3, and 4 in the email

>> (especially 4) are issues that need to be dealt with in in

>> order for this requirement to be valid at all. The IAB

>> guidance on walled gardens is quite substantive to many of

>> the use cases for this draft, and is therefore a serious

>> concern.

>

> It's an interesting point, but what we're talking about here
> is dedicated routing for streaming services like VoIP and

> video, not a walled garden in the old sk00l AOL/Compuserve

> sense. =A0 You could get to the service over the best-effort

> routing as well, but you will do better getting to that

> service over the custom route. =A0 This is an application which

> seems to be quite popular among various ISPs=97the Wifi

> Alliance is working on it, I know of at least one customer of

> my own employer who wants to do something like this, and

> apparently BBF considers it useful.

>

> Is this what the IAB meant when they said that we shouldn't

> support walled gardens? =A0 This is a serious question=97it is

> not my impression that this is what they meant, but I

> honestly don't know.




Speaking as a participant at the IAB workshop that led to RFC

3002 (and with no authority beyond that of a participant):



Firstly, please read section 3.1 of that RFC. Perhaps the key

quote is this:



'The term "walled garden" was coined to describe the resultin=
g

captive customer economic and service model. That is, the user

is constrained within the limits of the service provided by the

carrier with limited ability to extend features or access

services outside the provider.'



and a bit later:



'Some discussion focused on whether cellular carriers could be

persuaded to transition toward the Internet "open" service

model. Responses indicated that there was little hope of this as

carriers will always fight being reduced to a "bit pipe",

fearing they cannot sustain sufficient revenues without the

value added services.'



It's also worth reading section 4.2 'Recommendations for Dealing
with "Walled Garden" Model.' This is written constructively o=
n

the assumption that there will be walled gardens, so the IETF

should live with it despite not liking it. The dislike is very

explicit: 'It was strongly recommended that independent of the

ubiquity of the "walled garden" deployment scenario that

protocols and architectural decisions should not target this model.'


I think it's a bit of a stretch to say that

draft-ietf-mif-dhcpv6-route-option explicitly targets this

model; it's actually a generic mechanism, even if some of the

use cases do fit the walled garden model.




> Of course, that opens up the question of why not use existing

> QoS mechanisms, and I honestly don't know the answer to

> that=97I'm not an expert on existing solutions to that problem.
> I suspect the goal is to avoid expensive, specialized

> switching gear near the provider edge, but that's just a

> guess.




The main existing QoS mechanism is known as "throw bandwidth at<=
br>
the problem", and providing a dedicated route on a path known to

have adequate bandwidth is exactly that. But there are people

considering other approaches including diffserv or the flow

label. There is yet another approach about which

draft-sun-semantic-usecase and draft-jiang-semantic-prefix will

enlighten you.



=A0 =A0Brian




_______________________________________________

mif mailing list

mif@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/mif





--bcaec54b4924bec24404cdd56f1a--

From lorenzo@google.com  Tue Nov  6 07:55:50 2012
Return-Path: 
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004B221F8A11 for ; Tue,  6 Nov 2012 07:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.921
X-Spam-Level: 
X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfbSn2k2Tl2Z for ; Tue,  6 Nov 2012 07:55:49 -0800 (PST)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52C7521F89EB for ; Tue,  6 Nov 2012 07:55:49 -0800 (PST)
Received: by mail-oa0-f44.google.com with SMTP id n5so640186oag.31 for ; Tue, 06 Nov 2012 07:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oRGJGgJJL+ZWkZyWpHpHhLdBPxaTQr0ewv28CJAZ/F8=; b=peUw2gLjFIkbbbmxwlnqRrdZ4481ole+9fS4pNSytO3khUhc4brBmpzMZhEzQv9ZFe oafQ+tmW89MGXb7iuV330UxYin+JFkC4U5CitkU7wv3o7rHJm/cdnSYHD27S2GhHo4uf +JLY25SHNVIEiJ3OG1Ra20Hx6RE60rr4KeE//3yVQr+xSB9BoQXlmT4h8QS4Xp6XkcoR 28aTfd9UpGMer+4VYJPdqymqLRb73gvQGiaHrRGOVntPWclbg1INwHZx+lUaBPyvJUCk yui5ZA9BViiQW90jK5ZgNAOimcew75TylHm+ikCCCYGO0X45vyfmSlpcYMhEl0dwtrkY u53Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=oRGJGgJJL+ZWkZyWpHpHhLdBPxaTQr0ewv28CJAZ/F8=; b=TZMtYZFDyDzPlLwVyMpuvvMCXukWIlSWDDQxE/7DajSwPUxocit3GhymWriXDN4ayh 9uEDpXHyQI/vngIdy6YvLP0BF3ZCGYkqZ6tEmTOJVxuLKCN3z6cx64MPA+scbPSwQH/U g72k59JF4vYmuQPrIGaSf7S3bBW7cxVnaOAtZWHTZexuBCqwn1mCeCt1uIbKsQ2hPQhY Zr8lAbsqTyP1VGe63TPTjOAVp0dkUeYZSmKQn9/969TDfnmpDkMLfr6vJgEQxVjnqLfY BrFiLomcK5cE7PQyx45UAt3f3++qwdxLCy8qDuK01yx07SbRiGjvUCkzp3kTlCuMkcrg wjBg==
Received: by 10.60.26.72 with SMTP id j8mr1186940oeg.68.1352217348829; Tue, 06 Nov 2012 07:55:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.176.106 with HTTP; Tue, 6 Nov 2012 07:55:28 -0800 (PST)
In-Reply-To: 
References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com>   <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com>       <50987819.407@gmail.com> 
From: Lorenzo Colitti 
Date: Wed, 7 Nov 2012 00:55:28 +0900
Message-ID: 
To: Arifumi Matsumoto 
Content-Type: multipart/alternative; boundary=e89a8fb1f8d2bc713304cdd5a2c8
X-Gm-Message-State: ALoCoQloLKbifhXwycPDJ6dod4Hqk418wu8NcEdwrHgEeJHm07Rpj8uAbNAu8Kj2Da2hN2xyMbKW1JozwjGpGwEKOYrlNSGKZqVbsz9tn5I80gvbetW6mBQqZ/eSysS1fnO8ZNuvOHpUTymAAs7eUqxAvihKX+alZGcjpIK91jjIzREAB8MBdRptRGHoxqHs/fSKeQqnFcWR
Cc: "mif@ietf.org" 
Subject: Re: [mif] #15: use case #1 does not justify standardization of this option
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2012 15:55:50 -0000

--e89a8fb1f8d2bc713304cdd5a2c8
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 7, 2012 at 12:41 AM, Arifumi Matsumoto wrote:

> So, it does not recommend targeting this model of walled garden,
>
> but it looks recommending to standardize better co-existence method of
>
> open model and closed model.
>
>
> The model that the current dhcp route option draft describes seems me
>
>
> to fall into the matter of co-existence.
>
>
I think you're reading the text wrong. I don't see the word coexistence
anywhere in the text; the sentences you quote are all about "escaping" the
walled garden. In fact, the text says: These focused on service location
and escape from the "walled garden" - i.e., when you are in a walled
garden, figure out how to access the Internet instead.

So it seems to me that the IAB is saying:

1. Don't target the walled garden model with protocols and architectural
decisions.
2. Investigate standard ways that make it easier to escape from the walled
garden.

--e89a8fb1f8d2bc713304cdd5a2c8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed=
, Nov 7, 2012 at 12:41 AM, Arifumi Matsumoto <arifumi@nttv6.net> wrote:



So, it does not recommend targeting this model of walled=
 garden,



but it looks =
recommending to standardize better co-existence method of
open model and closed m=
odel.




The model that t=
he current dhcp route option draft describes seems me

to fall into the matter of co-existence.

I think you're reading the tex= t wrong.=A0I don't see the word coexistence anywhere in the text; the s= entences you quote are all about "escaping" the walled garden. In= fact, the text says:=A0These focused on service location and escape=A0from= the "walled garden" - i.e., when you are in a walled garden, fig= ure out how to access the Internet instead.

So it seems to me that the IAB is saying:
1. Don't target the walled garden model with protocols and = architectural decisions.
2. Investigate standard ways that make i= t easier to escape from the walled garden.
--e89a8fb1f8d2bc713304cdd5a2c8-- From lorenzo@google.com Tue Nov 6 08:02:43 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA01721F8A17 for ; Tue, 6 Nov 2012 08:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPhhuQp-1JDR for ; Tue, 6 Nov 2012 08:02:43 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1214621F8A14 for ; Tue, 6 Nov 2012 08:02:42 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so643981obq.31 for ; Tue, 06 Nov 2012 08:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eeozRUB/vOxWD1OVE5D7AjxmkQOlj8g/vBJSNzrVm0c=; b=WA0Ax4vaOUzoIEtZkSZYmAvOMW0VgYmx6TN0aADhjtEtKcLunfAzVHTaJ7Um2t9sBc Ztp7V47Rz4mMKGgQO1MTvqpxiqUm6qXz0u7TKtvEO9jPd3iOYkV8KjDHPlMyVlvjhY95 4BTqwPVp/5EwGGuz5W+7aGGY7y2CqMAfeanYYABD0VE0YL5GZhjCh70g7SGrp04KN8xs NP1tH8eJSM9IO5CtVbIpkhwGvgTB9eKwJ8UyKF4l6z8uXyib7ykODJmdUEcP6tgIPx3U l8hGyFfvkq4JjBINQVsn+r8gtbVsQz3OabDuuYjSrIer82BucvzMLOsEwvobaIW/J48o HozQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=eeozRUB/vOxWD1OVE5D7AjxmkQOlj8g/vBJSNzrVm0c=; b=bsneD+zLecj84Tq08SCmnoR3oqubQfds6QdPlM4C3COL7o1Q6SfnwpuRSmfmndOPVs bgYdC82Yv4EL0Xg8GOIufiNQQK0zhjEmrCKwjBti++8AO5kIhllJK/gL/cgV3M3fGAvj xoXsU4lzfSaT5hiEtzMCpNa7nVO7bE1hN4FpDcDbgao5romOyrHrESrSLLLUuDfnxFkG gG+iBm8XXiw17WwkSFwhXQFcPNi8pNleODYoK62vVvK9QzIY9kWGUlVGhdOsVf7niPOn 8jKI2ejYMGXXfMtUG5xc1eUpU5HryzyMMu74yPjrxUZsORCadVu4ccNXKqTMPgmj2iYY 7b9w== Received: by 10.182.31.13 with SMTP id w13mr1216219obh.29.1352217759625; Tue, 06 Nov 2012 08:02:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 6 Nov 2012 08:02:18 -0800 (PST) In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> From: Lorenzo Colitti Date: Wed, 7 Nov 2012 01:02:18 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae93a148d38b0ae04cdd5bb63 X-Gm-Message-State: ALoCoQnvrbV+HC/OcleymFkLzze7A5F4l6gcGz39FW29ke1AZkUnF48ONa8wuEYEA3onc+dBKeoVhXC8u/f/ULI1dt7S1Rt0RFymadsAQdgEarAZjoXY/5m6WZR9RAZToeYMe2PNteNQ6KBZE25qhC0cDMFxE3QoT5+S9PkaTfSjTIim7a2IE1MoWDnNbRO3g4qTSaofq/8T Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:02:43 -0000 --14dae93a148d38b0ae04cdd5bb63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 6, 2012 at 10:09 AM, Ted Lemon wrote: > On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti > It's an interesting point, but what we're talking about here is dedicated > routing for streaming services like VoIP and video, not a walled garden i= n > the old sk00l AOL/Compuserve sense. You could get to the service over t= he > best-effort routing as well, but you will do better getting to that servi= ce > over the custom route. This is an application which seems to be quite > popular among various ISPs=97the Wifi Alliance is working on it, I know o= f at > least one customer of my own employer who wants to do something like this= , > and apparently BBF considers it useful. > I don't see where you read that it should be possible to get to the service via best-effort routing as well. All the walled gardens I've seen (and I have one at home, as Arifumi well knows) don't allow this. The use case is undocumented, so we can't say for sure, but I suspect that in this use case, the provisioning of a separate router to specific customers serves *precisely* to ensure that only paying customers will get the specific routing option via DHCPv6 that allows them to connect to the router that provides access to the walled garden. This seems to be exactly what Brian means by "captive customer economic and service model". Of course, that opens up the question of why not use existing QoS > mechanisms, and I honestly don't know the answer to that=97I'm not an exp= ert > on existing solutions to that problem. I suspect the goal is to avoid > expensive, specialized switching gear near the provider edge, but that's > just a guess. > Yes, the motivation here is not particularly clear. --14dae93a148d38b0ae04cdd5bb63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue= , Nov 6, 2012 at 10:09 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Nov 5, 2012, a= t 7:49 PM, Lorenzo Colitti <lorenz= o@google.com>
It's an interesting point, but what we're talking= about here is dedicated routing for streaming services like VoIP and video= , not a walled garden in the old sk00l AOL/Compuserve sense. =A0 You could = get to the service over the best-effort routing as well, but you will do be= tter getting to that service over the custom route. =A0 This is an applicat= ion which seems to be quite popular among various ISPs=97the Wifi Alliance = is working on it, I know of at least one customer of my own employer who wa= nts to do something like this, and apparently BBF considers it useful.

I don't see where you read that it sho= uld be possible to get to the service via best-effort routing =A0as well. A= ll the walled gardens I've seen (and I have one at home, as Arifumi wel= l knows) don't allow this.

The use case is undocumented, so we can't say for s= ure, but I suspect that in this use case, the provisioning of a separate ro= uter to specific customers serves *precisely* to ensure that only paying cu= stomers will get the specific routing option via DHCPv6 that allows them to= connect to the router that provides access to the walled garden.

This seems to be exactly what Brian means by "capt= ive customer economic and service model".

Of course, that opens up the question of why not use existing QoS mechanism= s, and I honestly don't know the answer to that=97I'm not an expert= on existing solutions to that problem. =A0I suspect the goal is to avoid e= xpensive, specialized switching gear near the provider edge, but that's= just a guess.
=A0
Yes, the motivation here is not particularl= y clear.
--14dae93a148d38b0ae04cdd5bb63-- From lorenzo@google.com Tue Nov 6 08:08:28 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7092F21F8688 for ; Tue, 6 Nov 2012 08:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuvwdFz+pJMU for ; Tue, 6 Nov 2012 08:08:28 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E15A621F8685 for ; Tue, 6 Nov 2012 08:08:27 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so658291oag.31 for ; Tue, 06 Nov 2012 08:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V8c6hOXNplcBWRdpRQHpxIpxLkl8qfIVehAJj3B6AC4=; b=gFTtVnMlEKbsh2gf7f1g7xLdisrAkcBSzeReC6hu3Wp0Df1sRu/3pYgg8FSXs/XIsU ZgNl0hOoy2afKIMWg5gbthyP7GM0zRFynmcuABXGzCv7kMO9NObUXBhkLT2AQTu4iU1e 00W6S3cAV+8BDNwzkcg6dWPyta5gP/08AJEE38fExoXPC6YKsbMeIIO2huecDV1XX7jD pLLPb94S4tRFiTgt9ApGZxy1/PSrNDCewnP/ECYjwstvYXiHl482XZB15s+V62W+lZzf bsIe3dP/8Kz4VZljzWQ5fbdoSCNd10c6MQTixjPS/8KvLtUaCtb3Zu7HKpG5AfIt/JI/ OZ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=V8c6hOXNplcBWRdpRQHpxIpxLkl8qfIVehAJj3B6AC4=; b=Zu3Gfj0DML3pdwEeNpECNyVMbFcEkA//dIoZss/k+EUehIxX3MxEc2pUeHIfzM1f1B SKdm+deYUMUfxOgxqU90J0JFDpfFUWndNHbeUk16QgDV//cx4Nn5NKaLjfqJD0sOeeRt 7c36pg6mFhLMRzdNDXqcWfZkXsFrZ6DpyfOvtUc/5SFyjkigb4zvgQy2A8Mq45VsQlgg oGsdoOSPk13D6sArh48YzTQOMaUwztiob1U75FiTGbLyB64ua456WlqplYgVgtPIMDZc r/hCUpt+YBNnDiPMUmToBn2sXaCjcc8jLPAQ0+z+/iREVItN6J3oU7+whYMn9LZIRyL1 Xjww== Received: by 10.60.154.231 with SMTP id vr7mr1161857oeb.119.1352218107529; Tue, 06 Nov 2012 08:08:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 6 Nov 2012 08:08:06 -0800 (PST) In-Reply-To: <50987819.407@gmail.com> References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> From: Lorenzo Colitti Date: Wed, 7 Nov 2012 01:08:06 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec550b6f6f54b2704cdd5cfb6 X-Gm-Message-State: ALoCoQlDHqxESzrb7ZURmEbeGON8FNA+k+WUOXAUOWIesy2s6AQXTuKjrAm6tWUSCZ40CmpUTm9FptJJbkYBDT6/WwWHIdA/89rsRTiknteTtlDIrmUnfBEtNTkj9d2Ifufd/tCPDhMufekU2AlS+UNoOsP2pcnBf3+vJ1bLIgAFa5wbDMMhY9CTIICA3H+B5x1inuZGoovt Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:08:28 -0000 --bcaec550b6f6f54b2704cdd5cfb6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 6, 2012 at 11:38 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I think it's a bit of a stretch to say that > draft-ietf-mif-dhcpv6-route-option explicitly targets this > model; it's actually a generic mechanism, even if some of the > use cases do fit the walled garden model. > That was not the assertion made in this ticket. I believe that (part of) the assertion was that use cases that target walled gardens should be removed as justification, because IAB guidance is that protocol and architecture development should not target walled gardens. If there are other use cases, then we should decide on the merits of those, but the use cases that are targeting walled gardens should be removed. Does that make sense? Do you agree? --bcaec550b6f6f54b2704cdd5cfb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue= , Nov 6, 2012 at 11:38 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
I think it's a bit of a stretch to say that
draft-ietf-mif-dhcpv6-route-option explicitly targets this
model; it's actually a generic mechanism, even if some of the
use cases do fit the walled garden model.

That was not the assertion made in this ticket. I believe that (part of)= the assertion was that use cases that target walled gardens should be remo= ved as justification, because IAB guidance is that protocol and architectur= e development should not target walled gardens.

If there are other use cases, then we should decide on = the merits of those, but the use cases that are targeting walled gardens sh= ould be removed.

Does that make sense? Do you agre= e?
--bcaec550b6f6f54b2704cdd5cfb6-- From n@arifumi.net Tue Nov 6 08:11:53 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4907D21F8A53 for ; Tue, 6 Nov 2012 08:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsoZzc0U55HS for ; Tue, 6 Nov 2012 08:11:51 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5A3B21F8A51 for ; Tue, 6 Nov 2012 08:11:50 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so609074vbb.31 for ; Tue, 06 Nov 2012 08:11:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=vfCx864tfjopEHXCF/R18oyQE0/e9uYNFc4BmLMewuA=; b=iPMCEAN3pi7t31Fpmweebe/x2XzwxcC+EkUlJmyUO9xJIVlUVkiRyaRdx4W11MZuc2 rYk+oMXp7DKmLAXuQqqpVdtREwXvvwbz4KVp/0jobLMvzeFGcK/wf0aFCgR5bFhAn8kk sQgVXWxZfDqIo06KojxAYXnPw7hWKkD0JtNL70Yx1jdrwM/CTInekHabdEGOGFAo6oXf OT+6F4u4M2vPewaSlr6ed20S0w0c2t61stwqm5nefl4AfM3sIN5VrtfaEdlUnGTdEtpS 1MghIOk3dEjz65wnK4OZBAX/r8eqF/Y9yjmQDezOgzTJfzL9vcm1kFj/TG+1e7QmyKza 7oog== MIME-Version: 1.0 Received: by 10.52.180.5 with SMTP id dk5mr1176820vdc.45.1352218310295; Tue, 06 Nov 2012 08:11:50 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Tue, 6 Nov 2012 08:11:50 -0800 (PST) X-Originating-IP: [130.129.21.185] In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> Date: Tue, 6 Nov 2012 11:11:50 -0500 X-Google-Sender-Auth: uhZimUQAIw6m9iwGpSuJgQzUTMQ Message-ID: From: Arifumi Matsumoto To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=bcaec51967890b3fa704cdd5dc24 X-Gm-Message-State: ALoCoQmOdbBAZOLdfC2rIAeo8m0hI66CBUmXBSeNtDUaA4zU5KmlZxah0q3YqMyRw7hA9VjMeXRg Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:11:53 -0000 --bcaec51967890b3fa704cdd5dc24 Content-Type: text/plain; charset=ISO-8859-1 The RFC says "integrate". So I understand the co-existence is recommended. Service location and escape is focused in that RFC. I think delivering correct routing information for both internet connecting service, and walled garden service should be service location and escape mechanism. 2012/11/6 Lorenzo Colitti > On Wed, Nov 7, 2012 at 12:41 AM, Arifumi Matsumoto wrote: > >> So, it does not recommend targeting this model of walled garden, >> >> but it looks recommending to standardize better co-existence method of >> >> open model and closed model. >> >> >> The model that the current dhcp route option draft describes seems me >> >> >> to fall into the matter of co-existence. >> >> > I think you're reading the text wrong. I don't see the word coexistence > anywhere in the text; the sentences you quote are all about "escaping" the > walled garden. In fact, the text says: These focused on service location > and escape from the "walled garden" - i.e., when you are in a walled > garden, figure out how to access the Internet instead. > > So it seems to me that the IAB is saying: > > 1. Don't target the walled garden model with protocols and architectural > decisions. > 2. Investigate standard ways that make it easier to escape from the walled > garden. > --bcaec51967890b3fa704cdd5dc24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The RFC says "integrate". So I understand the co-existence is rec= ommended.

Service location and escape is focused in that= RFC. I think delivering
correct routing information for both int= ernet connecting service, and walled garden
service should be service location and escape mechanism.


2012/11/6 Lorenzo Col= itti <lorenzo@google.com>
On Wed, Nov 7, 2012 at 12:41 AM,= Arifumi Matsumoto <arifumi@nttv6.net> wrote:
So, it does not recommend targeti= ng this model of walled garden,
but it looks =
recommending to standardize better co-existence method of
open model and closed m=
odel.

The model that t= he current dhcp route option draft describes seems me

to fall into the matter of co-existence.

I think you're reading t= he text wrong.=A0I don't see the word coexistence anywhere in the text;= the sentences you quote are all about "escaping" the walled gard= en. In fact, the text says:=A0These focused on service location and escape= =A0from the "walled garden" - i.e., when you are in a walled gard= en, figure out how to access the Internet instead.

So it seems to me that the IAB is saying:
1. Don't target the walled garden model with protocols and = architectural decisions.
2. Investigate standard ways that make i= t easier to escape from the walled garden.

--bcaec51967890b3fa704cdd5dc24-- From lorenzo@google.com Tue Nov 6 08:14:43 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A9E21F8A33 for ; Tue, 6 Nov 2012 08:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.929 X-Spam-Level: X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbpnuWePvkIe for ; Tue, 6 Nov 2012 08:14:42 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC89321F89CF for ; Tue, 6 Nov 2012 08:14:42 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so668496oag.31 for ; Tue, 06 Nov 2012 08:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=djIq/qetEpfkK1gQAA91c9RQwPR6q+qAL70Xv44hqSU=; b=OHIno5XsUUk5zyItstqxic58kJFXiASKfS9Q43SoG2p1H1oPVrK1FWLp56xg+1Eu2t BkaxOnn0KEzKKBu2ogrRr6BWaJIa3aE9qFpU37LMywuFv2y5E781x4PLRk7yaM7qWKpV THtLiTt5OINZCQ3AeSXI48kE2NRSj6r4I09jpI77K3bhayblV4q0hmsNjpzioATm4q7B P/z+y7cRYhpizNN07UOXC5LfUiZVVEaUd86yjRIbnXJQcRmc1R2Lvx0V9P6agt6urrL7 V49QOVwOIZjU4nFrf+e87+UDGY0NVBVvaGQjPSdI59uXGiiCEMnciptAK4bp6gE9qie2 O+Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=djIq/qetEpfkK1gQAA91c9RQwPR6q+qAL70Xv44hqSU=; b=AqQ2oFM1OI0p26xRJJ301vUGAS1/G/w3y5WFAob1xMARCm4c7KRdjh8cGOoIFMEdWk PbRSvCRybEXWKz0xiu+yoygbadZHuYPqMEcSp9WQvzbB5lOJHbVnW4UPwSlhq+9HFSBi ZDuJDliNFcltDm8gT/x8WIdhugIAhQK0Z99ZOhMsLM1f1mI6neKGAnh7Jim5Tj4webqe gmb8BcKniR5r4mYs1p0g1bi4KYZgNdSiKOrqM/zROWVkQM2oqK80/umukbSXwZnKAKVA wUt7MjUgFHG/d+8kMzfseuHDpCKJy7CE9O+zojreVl+mzdG8+tVwuhouWgqK3ExYoRgk 8uPQ== Received: by 10.182.31.13 with SMTP id w13mr1252365obh.29.1352218481992; Tue, 06 Nov 2012 08:14:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 6 Nov 2012 08:14:21 -0800 (PST) In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> From: Lorenzo Colitti Date: Wed, 7 Nov 2012 01:14:21 +0900 Message-ID: To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=14dae93a148d47240104cdd5e64e X-Gm-Message-State: ALoCoQkiiJhdKXqXWJ9s4cMmP99fcLPu68sZxNMRAxSUcoJTdH9jIUoXi/zpCmqmWSFvJGFcgx+O2HV0BewyoVyPY5QyKWz7ISN1uSF7Xi1me9G8oAT8oKOdrcm8T3I96aEKo4S+PMRgHfZChF7B4YpfYplNB77mEWc8QRbZ4w8/yTvMvbneJGh7BE8ueARSvdvfmPBTjs6w Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:14:43 -0000 --14dae93a148d47240104cdd5e64e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 7, 2012 at 1:11 AM, Arifumi Matsumoto wrote: > The RFC says "integrate". So I understand the co-existence is recommended. Yes, but as in "integrate the walled garden into the Internet", not the other way around :) > Service location and escape is focused in that RFC. I think delivering > correct routing information for both internet connecting service, and > walled garden > service should be service location and escape mechanism. > >From the text I think their intention was to make it easy for users in walled gardens to access the Internet properly, not to make it easy to allow Internet users to access walled gardens properly. --14dae93a148d47240104cdd5e64e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed= , Nov 7, 2012 at 1:11 AM, Arifumi Matsumoto <arifumi@nttv6.net> wrote:
The RFC says &quo= t;integrate". So I understand the co-existence is recommended.

Yes, but as in "integrate the walled garden into the In= ternet", not the other way around :)
=A0
Service location and escape is focused in that RFC. I think delivering=
correct routing information for both internet connecting service= , and walled garden
service should be service location and escape mechanism.

From the text I think their intention was to make = it easy for users in walled gardens to access the Internet properly, not to= make it easy to allow Internet users to access walled gardens properly.
--14dae93a148d47240104cdd5e64e-- From brian.e.carpenter@gmail.com Tue Nov 6 08:16:51 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FE221F8860 for ; Tue, 6 Nov 2012 08:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY6NebN1QFJ7 for ; Tue, 6 Nov 2012 08:16:50 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5268221F8772 for ; Tue, 6 Nov 2012 08:16:49 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so526381pbb.31 for ; Tue, 06 Nov 2012 08:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HUroYI9vUXU8PVPm0EKAvrvg4EdHwWP9snaw84SKBzQ=; b=nm7RPe1Jb3c091EnFooiEzNUmIaV+Nrozdb4PFEwzPv3xuBb2t9aC/VU8d9gn2xbFI 1VmvTPKPiemsFFaHuDWkTtkR3S94v3xoj8DpcqYUf4RYRcN8uLVYuUcZ9MGDXziUu60E di8vsC9S5xGZdaE6J7Bx8+TOdgwxTi3okunxGz4X6v8bWg+SRfrX8nNyjbb7VBnI4L0u Cti7AjO1Z6j3Me4rg5QySSwQS6XLRgdWw6g5luHIvFa2Q9y2oDeo/CHxZLSnpvqAroEx m7sh8Gxq2NIncREkPOSap/c4Ebyywi8yLBc/8Jtbr9VXa9MuAwFGaBEGIEtv+PAQ/DDE 1XGA== Received: by 10.68.235.71 with SMTP id uk7mr4879102pbc.10.1352218608733; Tue, 06 Nov 2012 08:16:48 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id qi2sm12557582pbc.22.2012.11.06.08.16.47 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 08:16:48 -0800 (PST) Message-ID: <509937F1.9070808@gmail.com> Date: Tue, 06 Nov 2012 16:16:49 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:16:51 -0000 On 06/11/2012 15:55, Lorenzo Colitti wrote: > On Wed, Nov 7, 2012 at 12:41 AM, Arifumi Matsumoto wrote: > >> So, it does not recommend targeting this model of walled garden, >> but it looks recommending to standardize better co-existence method of >> open model and closed model. >> >> The model that the current dhcp route option draft describes seems me >> to fall into the matter of co-existence. >> > I think you're reading the text wrong. I don't see the word coexistence > anywhere in the text; the sentences you quote are all about "escaping" the > walled garden. In fact, the text says: These focused on service location > and escape from the "walled garden" - i.e., when you are in a walled > garden, figure out how to access the Internet instead. > > So it seems to me that the IAB is saying: > > 1. Don't target the walled garden model with protocols and architectural > decisions. > 2. Investigate standard ways that make it easier to escape from the walled > garden. I assume we want the MIF client system to be able to take control of its routing choices, for example to ignore a more specific route from one provider because the client would prefer its traffic to go via another provider. But that's a more general question than how the specific route reaches the client in the first place. One way or another, the specific route will arrive, won't it? Brian From n@arifumi.net Tue Nov 6 08:17:09 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED31C21F89CF for ; Tue, 6 Nov 2012 08:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8xoBAI6i-3V for ; Tue, 6 Nov 2012 08:17:09 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3573021F8894 for ; Tue, 6 Nov 2012 08:17:09 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so607836vcb.31 for ; Tue, 06 Nov 2012 08:17:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=z1UkbdFLOo17wpll1K++847hteNHv7sSnLarPgTa1mY=; b=AtQcBeTjYuwQ4YedgzY8PV97SAo57Tdh31lIgmlBHbBJcQ4PxiBGQaDj2F3nVmdOuH GW6ETjcJS6SfmzzYPumevEkVjTc5usjRhZeX0Y6rjqhQEQsw1rXCmj0XEI4ew+Q7IiIY uQiHh/RdfK1l/+gJK85GjlTb/8cuYVcJiu0g1LayhfTWBXHP65OdJMmUcPv7KFnOmVs4 fjREUPTm5bV8OSngPoFMclr09ZW5g7ruETkiUI4xyogCSZrjqJPxDZ5FAFDdw5UN6xgk Yt9AMbzl8ZUxaHHekJdgIuIw3hyi4D87/AOWUOYQXOz5B58G7kg/z4WaOlINZGu9Zi1O oh5Q== MIME-Version: 1.0 Received: by 10.52.68.226 with SMTP id z2mr1166733vdt.76.1352218628656; Tue, 06 Nov 2012 08:17:08 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Tue, 6 Nov 2012 08:17:08 -0800 (PST) X-Originating-IP: [130.129.21.185] In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> Date: Tue, 6 Nov 2012 11:17:08 -0500 X-Google-Sender-Auth: YZVkmlEaG63in98n_q9SYM8fhUc Message-ID: From: Arifumi Matsumoto To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3079c094050fed04cdd5ef8e X-Gm-Message-State: ALoCoQl3qeK6QDT4eUQv5eJXIdn95VK0VKIMN96mGj74f82F+E3JHgmD+UxIMUHAbLHAkp4Urr1w Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:17:10 -0000 --20cf3079c094050fed04cdd5ef8e Content-Type: text/plain; charset=ISO-8859-1 > From the text I think their intention was to make it easy for users in walled gardens to access the Internet properly, not to make it easy to allow Internet users to access walled gardens properly. I don't see the difference. 2012/11/6 Lorenzo Colitti > On Wed, Nov 7, 2012 at 1:11 AM, Arifumi Matsumoto wrote: > >> The RFC says "integrate". So I understand the co-existence is recommended. > > > Yes, but as in "integrate the walled garden into the Internet", not the > other way around :) > > >> Service location and escape is focused in that RFC. I think delivering >> correct routing information for both internet connecting service, and >> walled garden >> service should be service location and escape mechanism. >> > > From the text I think their intention was to make it easy for users in > walled gardens to access the Internet properly, not to make it easy to > allow Internet users to access walled gardens properly. > --20cf3079c094050fed04cdd5ef8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=A0From the text I think their intention was to make it easy for users in wa= lled gardens to access the Internet properly, not to make it easy to allow = Internet users to access walled gardens properly.

<= /span>
I don't see the difference.


2012/11/6 Lorenzo Colitti <lorenzo@goo= gle.com>
On Wed, Nov 7, 2012 at 1:11 AM, Arifumi Matsumoto <arifumi@ntt= v6.net> wrote:
The RFC says "integrate". So I understand the co-existence= is recommended.

Yes, but as in "integrate the walled garden into = the Internet", not the other way around :)
=A0
Service location and escape is focused in that RFC. I think delivering=
correct routing information for both internet connecting service= , and walled garden
service should be service location and escape mechanism.

From the text I think their intention was to= make it easy for users in walled gardens to access the Internet properly, = not to make it easy to allow Internet users to access walled gardens proper= ly.

--20cf3079c094050fed04cdd5ef8e-- From brian.e.carpenter@gmail.com Tue Nov 6 08:18:51 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2697621F8681 for ; Tue, 6 Nov 2012 08:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpBl1pLvnHEV for ; Tue, 6 Nov 2012 08:18:50 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1B8A21F8434 for ; Tue, 6 Nov 2012 08:18:50 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so465748pad.31 for ; Tue, 06 Nov 2012 08:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0nVuoBa/zU4Ybo4DjD1/YhvOHvLTUaWb/TBZswB3rs0=; b=fTM0m2ML1IkFwrz9VMtsGvLx3mLK9n67iyK39yvRPtzUwbKH4yLDUh0XR3asly3W0D QgtSCJqXC57gHHT1oD5+GjIIhYTA5nfc4uFyTMRElC0w6uIZOZg+LfEGptK4vUNHMpuj kvlxTIV2TNERx1xiyi29Zsym/nxoCz5Nl2YXp5KTlgg43XUIF1EFCgmrwbPyAyk6XM3k lD+5V0oW79D6oYWxSA1QPEm7+WTtnozGHc6HseP3FOUMIB4/ApUVZYFqB+qgVyXiaBdX nX1pAw8iFUdS/0Gsu1MfqHQVAAxjerU7SnaCFjFT1NjQHGwCtdtcFPhkgPE2EhG/R5f/ bE4A== Received: by 10.66.76.98 with SMTP id j2mr3851702paw.65.1352218730568; Tue, 06 Nov 2012 08:18:50 -0800 (PST) Received: from [130.129.19.51] (dhcp-1333.meeting.ietf.org. [130.129.19.51]) by mx.google.com with ESMTPS id rk17sm1165700pbb.3.2012.11.06.08.18.48 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 08:18:48 -0800 (PST) Message-ID: <5099386D.6070208@gmail.com> Date: Tue, 06 Nov 2012 16:18:53 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:18:51 -0000 On 06/11/2012 16:08, Lorenzo Colitti wrote: > On Tue, Nov 6, 2012 at 11:38 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> I think it's a bit of a stretch to say that >> draft-ietf-mif-dhcpv6-route-option explicitly targets this >> model; it's actually a generic mechanism, even if some of the >> use cases do fit the walled garden model. >> > > That was not the assertion made in this ticket. I believe that (part of) > the assertion was that use cases that target walled gardens should be > removed as justification, because IAB guidance is that protocol and > architecture development should not target walled gardens. > > If there are other use cases, then we should decide on the merits of those, > but the use cases that are targeting walled gardens should be removed. > > Does that make sense? Do you agree? I agree, but I'm prejudiced because I was in the IAB at the relevant time ;-). Brian > From lorenzo@google.com Tue Nov 6 09:51:41 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E382D21F8A26 for ; Tue, 6 Nov 2012 09:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKvn2cSgs8sp for ; Tue, 6 Nov 2012 09:51:39 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69DB921F8BDD for ; Tue, 6 Nov 2012 09:51:30 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so777598obq.31 for ; Tue, 06 Nov 2012 09:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HU/oWE7C6B7VKtIwC5j2JwgRel1N2kKw4hmtponPz0A=; b=lKvNLVFwe0+lOhlmauSucfiTq9OkLcixlnQ8koRndbYfZnMaQ97eVgJVJR+4M1TvAl SrbfzMfTMTOG8RUUPAF3Z/knXsYo83G3i2GhYFL42a3+tuIf5BrIJ7bD8ch2qWRosyjF csXxoEyS6Di/IhUdv+jKInR4rVWfL3iE3KPzt4rqKwbOmz9pELIClVXu88HOhVXnbHBj uqcHVWpNlb56bYdizP42Qhijd88p8EOq+KFJz1JDlUXgm/DJVRpaGEyS9fsVrYc/75HO A5qxgkSq7S6jVN2ZnHQfiDaZ/52Dzh4cguFZcJujSrYQXx6lZFMN/boqnbwmoqLuIuWQ 1LFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=HU/oWE7C6B7VKtIwC5j2JwgRel1N2kKw4hmtponPz0A=; b=nNhXywgxdh/RYq0H24Na4EJvQmIbrOmbfd3BnlYbEM6TGdKUhmZp/rzHVIVP++6Vow FGkWey2PJoaIPZaHC3qtli920tof0aQN3MgFB/JGVcTf7Dd+6MXjgfx2T/P8DgSghLfk MZf91ZO6RTY16oHnezDLyatYbP08dN8vAlNO25uLZ5oGtbSdFjrbUlFNOk7Q74+d/xDw A/r/zJQC6viMKWrkHkHLfM5g3YSr+4iWTN7g4ISEVy3eoN9QGDVV+r6g5aNUORuw7APO /W9ASZDNMrOVPnBOau8l/3F26XFWGgTGzmW7rKDP32VuDNYX7gSzesxZidVx4nU1qT0w ZzhA== Received: by 10.182.150.37 with SMTP id uf5mr1518040obb.10.1352224288142; Tue, 06 Nov 2012 09:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 6 Nov 2012 09:51:06 -0800 (PST) In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> From: Lorenzo Colitti Date: Wed, 7 Nov 2012 02:51:06 +0900 Message-ID: To: Arifumi Matsumoto Content-Type: multipart/alternative; boundary=bcaec51f955559f43404cdd7400e X-Gm-Message-State: ALoCoQkRFeATxrm22rsK2QUAi1sBr/VldFFpKQkZ80byTOCyQ/jvanqhwZzYKxjwsL4mhq/BrZqeDjeQAFUqvnkJ3CUTxYSDr5dsgKXzxp1idEHksPKy3OVq340f4roPPBSY8Ki65raIhHCIBdIRVu6/qDJFBAJ4LIrDsP4/gbIK4yjA15fsQGEIENkYrrePJ5Oo2oq7pe5C Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:51:41 -0000 --bcaec51f955559f43404cdd7400e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 7, 2012 at 1:17 AM, Arifumi Matsumoto wrote: > > From the text I think their intention was to make it easy for users in > walled gardens to access the Internet properly, not to make it easy to > allow Internet users to access walled gardens properly. > > I don't see the difference. > The difference is in which system should be changed to conform to the other. --bcaec51f955559f43404cdd7400e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed= , Nov 7, 2012 at 1:17 AM, Arifumi Matsumoto <arifumi@nttv6.net> wrote:
>=A0From the text I think their intention was to make it easy for users in w= alled gardens to access the Internet properly, not to make it easy to allow= Internet users to access walled gardens properly.

<= /span>
I don't see the difference.

The difference is in which system should be changed to = conform to the other.=A0
--bcaec51f955559f43404cdd7400e-- From Ted.Lemon@nominum.com Tue Nov 6 10:08:00 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE80521F887F for ; Tue, 6 Nov 2012 10:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt5XRAjdkTPT for ; Tue, 6 Nov 2012 10:07:59 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5C21F8879 for ; Tue, 6 Nov 2012 10:07:58 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUJlR/rKN0edmoXm+tT9jKhLC9G09WpMs@postini.com; Tue, 06 Nov 2012 10:07:58 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9B24A1B8301 for ; Tue, 6 Nov 2012 10:07:57 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 90700190043; Tue, 6 Nov 2012 10:07:57 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 6 Nov 2012 10:07:57 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] #15: use case #1 does not justify standardization of this option Thread-Index: AQHNvDczyxWSX1d1q0qOzxuHVdcb/JfdgIgAgAAAtICAAADHAIAAGkEAgAAEtQA= Date: Tue, 6 Nov 2012 18:07:57 +0000 Message-ID: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3BDA51676D23BB4C849EC2221D0229A5@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:08:00 -0000 On Nov 6, 2012, at 12:51 PM, Lorenzo Colitti wrote: > The difference is in which system should be changed to conform to the oth= er.=20 As I mentioned previously, the use of the term "walled garden" here is, as = far as I understand it, inaccurate. I agree that it should be taken from = the document, and if in fact a documented use case _is_ a walled garden, th= at use case should be eliminated. However, it seems pretty clear from the= discussion up to this point that supplying fat pipes to differentiated ser= vices is not what "walled garden" means. To me, "walled garden" means that you can't get out. An advertised route = that gives you a fast path to an otherwise reachable resource can be argued= to be anti-competitive, but it's not a walled garden. And despite the co= mpetitive environment in the U.S., there are competitive environments in Eu= rope where the pipe would be made available to any provider of the same ser= vice, by law. So this is not a reason to consider such a use case to be i= n any sense analogous to a walled garden. From lorenzo@google.com Tue Nov 6 13:55:29 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E642B21F8B7A for ; Tue, 6 Nov 2012 13:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dLKWwexFZZg for ; Tue, 6 Nov 2012 13:55:28 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A920821F8B92 for ; Tue, 6 Nov 2012 13:55:23 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1060377oag.31 for ; Tue, 06 Nov 2012 13:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kHApGpeRnjMgkkoNamTwsz2kkwBrBbS+LZjjrNa/f9E=; b=DwRgVz2KGI/Kb9epXorN7E4ROVCzS9er3Ap9q/PSPsceizbxUWObMoG0f4OEilONSM cgJvkJAaq2RbLCNwpuga8RJSrjiQQQ6TlFWJue53smtfIsk0p2Zc4EXx24rLPYTz9KD1 oan08rMspt4j6vy95m9qwlJ9fbuQSm+EW3H0FHZcuIwTFW73bMCkr4CdaaNaO4Vz7JUR HqA4c5L358FPfc4dXSLZ3/p21xndJO06+VP3v2AjVMSw3rV9D7ID2ihAUNCULpr/vD9Y JD/AVxhXFtkLey1Plfn7sQ42UA1mw4hoq+1plPpISuBdXGT1NgznRbszCE4qmNNXmhWg FUTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=kHApGpeRnjMgkkoNamTwsz2kkwBrBbS+LZjjrNa/f9E=; b=HZCJR3asLHUEy6FNT6k3SqDf2BYfH4SBgkn1d6IHXL8k8KOeBWAKCAkxqAjl2UMwlA sfFXcQZ6uevmMWzt7PpaZh9m/67k62ld1i+R0p1yTc0/YcohtFgDr3Fe+BZIIHnjheUV 33Yr+3mH6F/kB76TRZwL3+IMsrJXlq0Yc1Ze360ouHsp2gfXut5GVvFvRp7X49iIOPLu iOEWOZS7BcseBubwFreZ6qkNhzGykAELw1V/Awae44PJYZGmpLoG3IXpMm6b1fAru7GI JInYryaJi6L26XCkzEdgK/yYjMLE6028vvoIbo8L+ylC+wJGqUQplC2MSXqCMD2Zd0jp 3y9w== Received: by 10.60.8.65 with SMTP id p1mr2103589oea.92.1352238920559; Tue, 06 Nov 2012 13:55:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Tue, 6 Nov 2012 13:55:00 -0800 (PST) In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> From: Lorenzo Colitti Date: Wed, 7 Nov 2012 06:55:00 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8ff1c56a82ecf104cddaa86d X-Gm-Message-State: ALoCoQkbMMNplqg3HP64AttBmsc5xdAXPnVzJB06ohq7Qfk8Xp9vrPD8iIHosD7kGYzubdPKewCOyY9Do6cZtmVlRrduDfQuPROeRkRBlVVZRvZCp309k1R6zpdWZPeHGniC610+6VOCqF8q0Kkoyc0DUcCAbEFgGw2XT0gZrk7GL1dLXJbJThmF4wtmrKAf69Ddl4/UxJjd Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 21:55:30 -0000 --e89a8ff1c56a82ecf104cddaa86d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 7, 2012 at 3:07 AM, Ted Lemon wrote: > > The difference is in which system should be changed to conform to the > other. > > As I mentioned previously, the use of the term "walled garden" here is, as > far as I understand it, inaccurate. I agree that it should be taken from > the document, and if in fact a documented use case _is_ a walled garden, > that use case should be eliminated. However, it seems pretty clear from > the discussion up to this point that supplying fat pipes to differentiated > services is not what "walled garden" means. > AIUI based on our in-person conversations in Taipei it's not about fat pipes, it's about access to premium content. But since the use case is undocumented, there's no way to verify that. To me, "walled garden" means that you can't get out. An advertised route > that gives you a fast path to an otherwise reachable resource can be argued > to be anti-competitive, but it's not a walled garden. And despite the > competitive environment in the U.S., there are competitive environments in > Europe where the pipe would be made available to any provider of the same > service, by law. So this is not a reason to consider such a use case to > be in any sense analogous to a walled garden. > AIUI the use case is: - We want to provide video content to my subscribers - The content is hosted on my our network, not on the Internet, and we want to provide our subscriber with a route to that network - We provide DSL services by purchasing wholesale access on an incumbent's BNG - We can't use RAs because we don't control the BNG --e89a8ff1c56a82ecf104cddaa86d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed= , Nov 7, 2012 at 3:07 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
> The difference is in which system should be changed to conform to the= other.

As I mentioned previously, the use of the term "walled garden&qu= ot; here is, as far as I understand it, inaccurate. =A0 I agree that it sho= uld be taken from the document, and if in fact a documented use case _is_ a= walled garden, that use case should be eliminated. =A0 However, it seems p= retty clear from the discussion up to this point that supplying fat pipes t= o differentiated services is not what "walled garden" means.

AIUI based on our in-person conversations = in Taipei it's not about fat pipes, it's about access to premium co= ntent. But since the use case is undocumented, there's no way to verify= that.

To me, "walled garden&qu= ot; means that you can't get out. =A0 An advertised route that gives yo= u a fast path to an otherwise reachable resource can be argued to be anti-c= ompetitive, but it's not a walled garden. =A0 And despite the competiti= ve environment in the U.S., there are competitive environments in Europe wh= ere the pipe would be made available to any provider of the same service, b= y law. =A0 So this is not a reason to consider such a use case to be in any= sense analogous to a walled garden.

AIUI the use case is:

= - We want to provide video content to my subscribers
- The conten= t is hosted on my our network, not on the Internet, and we want to provide = our subscriber with a route to that network
- We provide DSL services by purchasing wholesale access on an incumbe= nt's BNG
- We can't use RAs because we don't control = the BNG
--e89a8ff1c56a82ecf104cddaa86d-- From n@arifumi.net Tue Nov 6 14:29:18 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F421F8BB8 for ; Tue, 6 Nov 2012 14:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbru1EoBOmOQ for ; Tue, 6 Nov 2012 14:29:17 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3419A21F8BB5 for ; Tue, 6 Nov 2012 14:29:17 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so1017204vbb.31 for ; Tue, 06 Nov 2012 14:29:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=uc/UZRYsIki/6KmcKSQJe1YYLK967E4cRJPEjV7aKXk=; b=Vys15CDJI9UDO+jGE4RSyw5z7ZyfzM1HeIKdgZVmyHzG6xUmjN5/1JyyEbtriU1buJ CccGTXqneHd7NuH5igFA8+/LeM6EfRu5nRgcio2MM5geBXn9PcuECgoAz/VwX9nKqDhH GXDlM8a8OO3RDlcFWKoiQzK+lhrwlEqCX7Ld6z0+n9SKv5Iq4ydzSCE3MrZEslCLdepp OKvccbC0OqXK6BYmt8AzKBWJsT36lkvcIoxbmxUB+u8sEC6IS8v0gkXz7TzY/u3F7jPn vcMn30y+ZpZ5HSEoOfLuiQE66AiYk9oCj+EgxCtw/bjoiu6PJ4z4b9fVjzmwTnbIvo0j Lwyg== MIME-Version: 1.0 Received: by 10.52.76.103 with SMTP id j7mr2065170vdw.22.1352240956633; Tue, 06 Nov 2012 14:29:16 -0800 (PST) Sender: n@arifumi.net Received: by 10.58.228.196 with HTTP; Tue, 6 Nov 2012 14:29:16 -0800 (PST) X-Originating-IP: [2001:df8:0:16:dc1f:bd0e:32de:ccf2] In-Reply-To: References: <051.e7a943a1f47fd6d67aebdaf8251ee3ef@trac.tools.ietf.org> <5093E91F.2090506@gmail.com> <157C4659-7B7D-4962-A647-9E5BDA0694EE@nominum.com> <50987819.407@gmail.com> Date: Tue, 6 Nov 2012 17:29:16 -0500 X-Google-Sender-Auth: HlHerRKmvcuF_CIUyyO4FVgGFhc Message-ID: From: Arifumi Matsumoto To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=bcaec5016233def40b04cddb21ca X-Gm-Message-State: ALoCoQm/lIzXVGBsvuhwsOvVyPgvjdrASBmFaabLks6H4PT+049Pzwi6ii4XKN1nlbbi2hg/cE75 Cc: "mif@ietf.org" Subject: Re: [mif] #15: use case #1 does not justify standardization of this option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:29:18 -0000 --bcaec5016233def40b04cddb21ca Content-Type: text/plain; charset=ISO-8859-1 Then, this route option can serve as both ways. It makes walled garden user/device to access the internet, and vice versa. I think it's just a matter of viewpoint or start point. 2012/11/6 Lorenzo Colitti > On Wed, Nov 7, 2012 at 1:17 AM, Arifumi Matsumoto wrote: > >> > From the text I think their intention was to make it easy for users in >> walled gardens to access the Internet properly, not to make it easy to >> allow Internet users to access walled gardens properly. >> >> I don't see the difference. >> > > The difference is in which system should be changed to conform to the > other. > --bcaec5016233def40b04cddb21ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Then, this route option can serve as both ways. It makes walled garden user= /device to access the internet, and vice versa.

I think = it's just a matter of viewpoint or start point.


2012/11/6 Lorenzo Colitti <lorenzo@goo= gle.com>
On Wed, Nov 7, 2012 at 1:17 AM, Arifumi Matsumoto <arifumi@ntt= v6.net> wrote:
>=A0From the text I think their intention was to make it easy for= users in walled gardens to access the Internet properly, not to make it ea= sy to allow Internet users to access walled gardens properly.

<= /span>
I don't see the difference.

The difference is in which system should be chang= ed to conform to the other.=A0

--bcaec5016233def40b04cddb21ca-- From rdroms.ietf@gmail.com Thu Nov 8 23:15:31 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0870021F8B2D for ; Thu, 8 Nov 2012 23:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztOYmAvfi1Yr for ; Thu, 8 Nov 2012 23:15:30 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28E8121F8B2B for ; Thu, 8 Nov 2012 23:15:30 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so2659509qca.31 for ; Thu, 08 Nov 2012 23:15:26 -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:date:message-id :cc:to:mime-version:x-mailer; bh=rsFT+hQM4TZK+FpHS2bm71yNhDLWg4fPHzHiGTkkc4o=; b=jvmt2iczQjTeMj+AQtGz5Ot+5wS/oeeRWdn5fM2uiCi0Rc5u7E/VOmWgqmUBgyZ65K GZfA8EWF5wcvwW/1ju86KSyTL3YCEeLvb7F3MoAqsFC+K0FZqvXTm3genflKRXb6oiXG evjYr/KsUjpxBG04Tre5Rlgw4h5XA81m7Z+AQ2taXw4iq2KOa4SEMq87tPcDT+h41j0I Rk9OW9NZ4vVEpgg4rmmzzmvUpe4B02EFL8Me5Vcz+XXWHqV3IWaeFn9wYm4B80zJaCvI vvt0fuP4eQlube2X1eAPPBJdVy+M/z+zSp8BpR4nxNeEpQgo1CnVcbSZjZ2Oq2nBpvEt GO8A== Received: by 10.229.69.70 with SMTP id y6mr3691315qci.102.1352445326016; Thu, 08 Nov 2012 23:15:26 -0800 (PST) Received: from [10.86.255.7] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id fl1sm8028927qab.14.2012.11.08.23.15.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 23:15:25 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 02:15:21 -0500 Message-Id: <59A4BE5D-9D46-476F-927B-598E5A95D99E@gmail.com> To: mif mif Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: mif-chairs@tools.ietf.org Subject: [mif] draft-ietf-mif-dhcpv6-route-option in mif WG charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 07:15:31 -0000 I've been following the recent discussion of = draft-ietf-mif-dhcpv6-route-option, including the issue of whether this = work belongs in mif. As item 2 in the list of explicit WG deliverables = defines the problem addressed in draft-ietf-mif-dhcpv6-route-option, and = that document has been accepted as a mif WG work item, it's appropriate = for the mif WG to continue development of the document. - Ralph From margaretw42@gmail.com Fri Nov 9 03:44:46 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED55521F85A9 for ; Fri, 9 Nov 2012 03:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z19QT3JMxDY for ; Fri, 9 Nov 2012 03:44:46 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFDE21F8587 for ; Fri, 9 Nov 2012 03:44:46 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1758394dan.31 for ; Fri, 09 Nov 2012 03:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mLAMnAZ6YoKdKS4HfXQFYVAcOFwBM9mN4Z3M6wAeTIw=; b=bOSN/tL85uSVlKuSLdnkA/s6QdFfiSmpiY0WEw513kgLm3MtlEs9xTbAqyHtYgxbzu r7X2Ue1iJ9Q9NGKB84Bjst+LvSfF0gyYtbEDCItIqYXwBdSacMc34RpYxjXUkX2imfR/ 24lqMDxdEKtzEskSVFnvl1R9TG6r9ZVLWTvGGXubOoFGl6y1GF2w3PSRxzUiHE1V4tzZ WbliMs+5H2+KWeroF4orgSjQ5Zv7QBpFuOMVtJETY6CJziiJ5wUZInJqc8e9frkFch/6 tZH/pbo9UjWZ2f0ix7g3EkH70Y0Okv3bDpg5gw4nT1HsObB5xv7LcbA1sA0+XD775Cye yI1w== Received: by 10.68.143.201 with SMTP id sg9mr33595109pbb.32.1352461486168; Fri, 09 Nov 2012 03:44:46 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id qi2sm17635567pbc.22.2012.11.09.03.44.44 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 03:44:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <59A4BE5D-9D46-476F-927B-598E5A95D99E@gmail.com> Date: Fri, 9 Nov 2012 06:44:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <470747F3-F056-46AF-A6BA-ABC89A99EACB@lilacglade.org> References: <59A4BE5D-9D46-476F-927B-598E5A95D99E@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: mif mif , mif-chairs@tools.ietf.org Subject: [mif] Issue #16: Re: draft-ietf-mif-dhcpv6-route-option in mif WG charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:44:47 -0000 Hi Ralph, Based on this e-mail, I think we should close issue #16: DHCP route = option does not belong in mif WG. It is not in scope for the mif WG to = discuss whether our chartered work items belong in our group. Thoughts? Margaret On Nov 9, 2012, at 2:15 AM, Ralph Droms wrote: > I've been following the recent discussion of = draft-ietf-mif-dhcpv6-route-option, including the issue of whether this = work belongs in mif. As item 2 in the list of explicit WG deliverables = defines the problem addressed in draft-ietf-mif-dhcpv6-route-option, and = that document has been accepted as a mif WG work item, it's appropriate = for the mif WG to continue development of the document. >=20 > - Ralph >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From margaretw42@gmail.com Fri Nov 9 03:54:19 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75C421F8581 for ; Fri, 9 Nov 2012 03:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6woP6e6L3nA for ; Fri, 9 Nov 2012 03:54:19 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 567A921F857E for ; Fri, 9 Nov 2012 03:54:19 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1761619dan.31 for ; Fri, 09 Nov 2012 03:54:19 -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:date:message-id :to:mime-version:x-mailer; bh=BtpVcCNZaJl4SRBSchP3jd1fxhDJQQUbW4LlGwYNZgc=; b=sKOH3ry9kiVGb/IJeguk9LUM6h1ZdTrL3ckpUujaOjeMGWa/heZHG3luSEBDUnNAPu YDVYxtdl0y7PKhprsQ+yL7c4JXdISrYMBMU6OQSOOM+urWIV0LY9RLhuvyDgL2+iay2G 476a+xWvVol6pT7LWPpyiivW2pQcIGDYy23a2JmQ1nUrDkRm9dlPsYHPXNRLOSNNTmbu rm0aKJ07MkSDd7py957gAtudqsOaEN5EVU1hp/ytjORFeVJN2N+MgqJ5YFD2laEKw2FT aa5WdGAGYsNOTNTDizxs9GPVyaCe89fwM5x4jNFNSri8hJoM5vjPHDcCnWR41IMR9QzS oSzw== Received: by 10.68.189.38 with SMTP id gf6mr9955688pbc.145.1352462059035; Fri, 09 Nov 2012 03:54:19 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id f2sm17860611paz.25.2012.11.09.03.54.18 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 03:54:18 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 06:54:16 -0500 Message-Id: <33D070DC-97D8-496F-928B-0F3281BF4AC3@gmail.com> To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #18: Vague problem statement... X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:54:19 -0000 As explicitly stated in the issue text and pointed out on the list, this = issue is a duplicate of other, more specific, open issues. I propose = that it be closed as a duplicate issue. Thoughts? Margaret From margaretw42@gmail.com Fri Nov 9 03:58:31 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76DC21F84AE for ; Fri, 9 Nov 2012 03:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv9rwjkGkK4w for ; Fri, 9 Nov 2012 03:58:31 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8351421F84A9 for ; Fri, 9 Nov 2012 03:58:31 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1763059dan.31 for ; Fri, 09 Nov 2012 03:58:31 -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:date:message-id :to:mime-version:x-mailer; bh=ukzyWmhhIdy7cm5OwdAlpvg5K8UTiGWNUT7KoALJGI4=; b=T/YkUJ9aA+COElwmWNeh0aSqknv9ElLQINXtsKcR6mqf+b8cEphNh9FA2V55zxt+Gs d2ppvOhL1XB9V8JvrZH/oafG2b7t1Vou3++XLRiL460/GFC7AAM9GpHda1T2nJxFuQZs KpoePAOjj3X2mLdAOhDfpFCX7UAr4l7orBSaj5cYu6QvlXEBXP3Z/4tj2K5mTL8JL8Em C3alJ6S0S9rXiolaO+E8fO7TCTaIWQsjpbVjJy75+iwmUG8GbnBeql7QEFwmwivlKygA anX9G0wmg2/wrRXhP2263L3GSwpDy7lx9fjgpp4Dijsh1RqdKQrKA1kJCWQEIR4s5Nkf cDOw== Received: by 10.66.85.233 with SMTP id k9mr24780949paz.73.1352462311359; Fri, 09 Nov 2012 03:58:31 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id ni3sm17655200pbc.2.2012.11.09.03.58.30 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 03:58:30 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 06:58:28 -0500 Message-Id: To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #15: Use case #1 does not justify standardization... X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 11:58:32 -0000 This issue claims that use case #1 could be resolved using a different = type of mechanism. My opinion: Since the WG is chartered, explicitly, to standardize a DHCPv6 Route = Option and is not currently chartered to document other solutions to the = same problem, it is not necessary for us to justify this work item at = this point -- that was done at the time that we were chartered to do the = work. My suggestion would be that we close this issue with no changes to the = document. Thoughts? Margaret From margaretw42@gmail.com Fri Nov 9 04:08:30 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8488121F84BD for ; Fri, 9 Nov 2012 04:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzlomw+6uKHi for ; Fri, 9 Nov 2012 04:08:30 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8D121F84B8 for ; Fri, 9 Nov 2012 04:08:30 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2994562pbb.31 for ; Fri, 09 Nov 2012 04:08:29 -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:date:message-id :to:mime-version:x-mailer; bh=Fp27PlcnAfY17yDgqnodQu1g7+W3DS2PWcNJUNS0BRY=; b=OQ2CH0HTLjwF3i2YGkjI1h6nCKwOz4p3DSQng+dOuK1FRmMGcWpaC2yxuq6yXPfkwK itbW+xPAou9a+f9mko3sSNTfnMXD/U8VR3zPinQifKI4sJtjSuTtNvc9iTHAbVE674gp YbVLXn3qL9SqH8uVNeGnm9rfzO36iIYowlOv36I1+gM5v8juWyv58qV8rflng7zY6H3J iXUHig/7VFflZHItR2DZeXB2CV8vZZjc+21zhYnkBeUA9iIWXyBiZvLkwcwLgziXUuOH H8j05DbWszffBx3chf8+PK2b8jXVsmZ30u828CvEFbLu7a+gPCFBXSEC5Shn1KNxOe1V rGvQ== Received: by 10.68.238.72 with SMTP id vi8mr26266564pbc.55.1352462909887; Fri, 09 Nov 2012 04:08:29 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id tm5sm11518009pbc.64.2012.11.09.04.08.28 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 04:08:29 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 07:08:26 -0500 Message-Id: <26B5D5A1-3767-4A60-9452-F72593F5D7C3@lilacglade.org> To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #17: Status of DHCP Route Option should be clarified X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:08:30 -0000 This issue claims that we should issue another WGLC before sending the = DHCPv6 Route Option draft to the IESG. This is not an issue with the document itself. It is typical for us to = issue another WGLC if there are substantive changes to a document based = on previous WGLC comments, and not to issue another WGLC if there are no = substantive changes. Is there any reason that this case should be = handled differently? I propose that we close this issue with no changes to the document, = because it does not concern contents of the document. =20 Thoughts? Margaret From margaretw42@gmail.com Fri Nov 9 04:14:38 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BF221F853D for ; Fri, 9 Nov 2012 04:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYvHUXkFfI52 for ; Fri, 9 Nov 2012 04:14:33 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id E791821F8528 for ; Fri, 9 Nov 2012 04:14:32 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2962214pad.31 for ; Fri, 09 Nov 2012 04:14:32 -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:date:message-id :to:mime-version:x-mailer; bh=OclXQX1b6N+yL9/F5k+A26+t2Lu/v1XP9griHuuPbO8=; b=LcyuWtBUdjjmWi2WoLJZDJp5uKhu4ItWv0dQ9oOQp0aO4Nnn5QzTQGV+8UCLOPAUbz /Q2pijnDrqpWKThPus+TSbA85wRt98bSDgeP/YJqcQlZMGea0Gc0P9eFfbpoWK7jWSM3 EdzANxu9L1t0Rro5oNZ8pE7zk7HXnqe9NtNvt9/XIyIP4BYSzdxw8rd+n9HorqrakIuS WQlf6h7/TLa+B9hU81FMHLOIiK0WjiTW+m/0SJXDpeHCfsr+kFsBwJP1tPc8lvGG8uVJ uACTXMa/p6tdkF4O34B6keKkK2xzYi4c2dQaMVrFCZru+/wqHa6/Z+oogs4Qa+Do5gAF /eLg== Received: by 10.68.192.66 with SMTP id he2mr32903772pbc.112.1352463272483; Fri, 09 Nov 2012 04:14:32 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id yi9sm17663399pbc.39.2012.11.09.04.14.31 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 04:14:32 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 07:14:29 -0500 Message-Id: <076017A8-0007-447A-8BDC-DF3B9D58F498@lilacglade.org> To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #9: Violates RFC 5505 section 3.2.1 (fate sharing) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:14:38 -0000 This issue claims that we "violate" RFC 5505. However, RFC 5505 is an = informational document that defines some terms and describes some = concepts related to node configuration. RFC 5505 does not contain any = requirements, and is not a proscriptive document at all, and it doesn't = make sense to talk about "violating" it. It is true that the DHCPv6 Route Option (like all DHCP options) lacks = the property of "fate sharing", unless the DHCP server is co-hosted with = the default gateway in certain circumstances. However, there is no = requirement that all of our configuration mechanisms have that property. I propose that we close this issue with no changes to the document. Thoughts? Margaret= From margaretw42@gmail.com Fri Nov 9 04:25:06 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8249221F85DB for ; Fri, 9 Nov 2012 04:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecqBu8Gay0uY for ; Fri, 9 Nov 2012 04:25:06 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1074721F85DD for ; Fri, 9 Nov 2012 04:25:06 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3003095pbb.31 for ; Fri, 09 Nov 2012 04:25:05 -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:date:message-id :to:mime-version:x-mailer; bh=aBsGYvFLeMF8zPzvVyvdLwdE102eTDXeOUtcxBdKDLc=; b=ff/f9Ni3BHlIJHuaXvI2eHUCei8OJcelaHVey40dlZwy8LdCMOHNIfSl+ZR/6O7Az6 P8bxkKH9uZG6cdWPiAm8tx93g5OEfTvj8jaukrZbAvJyglZR5OjqGOgB/YeB3PJhXj2a Mrdkpz5gMZCffQdwm8UcC0zoLcdDayPzCp6ILf6P1Y+s64z5TB+kn6WbX1b1znrMQ4bS safI5nxLfIweh41lAr0IOxnM5HtMt2BKze3kE2Ml+NnpJy7LRkp+4zdIcEkWYq9wOAms JQCO0KV1gCBha4ieX50zG6U9hInQR8dcNt/A94VldoxFDASey1hcYHcrGuXrhi3hyVbO ypuQ== Received: by 10.68.192.66 with SMTP id he2mr32989687pbc.112.1352463905870; Fri, 09 Nov 2012 04:25:05 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id e9sm17893411paz.28.2012.11.09.04.25.04 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 04:25:05 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 07:25:03 -0500 Message-Id: To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issues #10, #11 & #12: "Walled-garden" use cases are invalid X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:25:06 -0000 This issue claims that walled-garden use cases are invalid based on text = from RFC 3002, which is an informational IAB report from an = invitation-only IAB workshop held in 2000. =20 There has been some list discussion explaining that use cases #1, #5 and = #7 are not inherently walled-garden use cases. Also, it is not required that our work comply with the opinions = expressed in IAB workshop reports. Workshop reports are not even IETF = consensus documents, and they do not place requirements on IETF protocol = work. My proposed resolution is to close these issues with no changes to the = document. Thoughts? Margaret From margaretw42@gmail.com Fri Nov 9 04:30:18 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB57B21F862B for ; Fri, 9 Nov 2012 04:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8JI718M7ce8 for ; Fri, 9 Nov 2012 04:30:18 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3CB21F8623 for ; Fri, 9 Nov 2012 04:30:18 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2970890pad.31 for ; Fri, 09 Nov 2012 04:30:17 -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:date:message-id :to:mime-version:x-mailer; bh=dlIvC/kPukmBav+da/PDZGmd4tezPMSgxgBPEQ8l6I4=; b=midSYN/aKh39hljh3qyf78q0YHzew9b6qE2AufxmpexB48Vw+22P5C7JztRWoQBaR0 EjCP1Lu8xLr0FJeebvlgHxmz6bjjt8NRCPO28FVWN4xLt1Q4oICAhvLP3TFkrvHb1YWj P31uAApDeBiRelasg11VK0Ru0R+r+U65bL/kIERbo1m1Y59JJiD9MEaSKnEQ4qDuh/vE 9bDOep54KOkTOwGogWjfFzOkh0hqdhnl8D/vVQ+DlY54pL4sLSQVPHFeBHNS09CWcvBV /GAJfY8E2p6c9LpsZqtnVMLMP2vP0vWzZ5fstgZuDAuKFhTcs0j9Vi0TrERtYqggbG1M EKpg== Received: by 10.69.1.8 with SMTP id bc8mr33889135pbd.9.1352464217119; Fri, 09 Nov 2012 04:30:17 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id kb3sm6265855pbc.27.2012.11.09.04.30.16 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 04:30:16 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 07:30:15 -0500 Message-Id: <38E11A84-02C1-4EC4-AEDD-30123D91A931@lilacglade.org> To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #14: Use case #6 is insufficient X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:30:19 -0000 This issue claims that use case #6 should be removed. Personally, i agree that use case #6 is quite week, and that it should = be removed. My proposed resolution is to remove use case #6 from the document. Thoughts, Margaret From margaretw42@gmail.com Fri Nov 9 04:32:13 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0923221F862B for ; Fri, 9 Nov 2012 04:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azT0P93p2PDd for ; Fri, 9 Nov 2012 04:32:12 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id A363E21F8629 for ; Fri, 9 Nov 2012 04:32:12 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2971901pad.31 for ; Fri, 09 Nov 2012 04:32:12 -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:date:message-id :to:mime-version:x-mailer; bh=HEkjrt59HpUeLdHA+crmgGtyX68ZhTZRTYvv7lmP5mU=; b=B4Y9vr9pMvAl6/K/KGAZOJpljoruDmq0EKKKChLgW146X59PMzSpqEfcmmHIc58Pje 2KSmzy07Jz8SmoOKwYFylTPBz8c9P0+BvHsZSH1A8eskYM8tAhTGmO27bmbJsbhgWzLX ba73q2c9sUyk9i/qYe8SYms+YoksPQYucF3Cm3IdPdoo3QC6WBXrXUFlqdHzerIR2W9P EueoODn54pAI9BWZyF+qb8uLVopcQfs97q/PkxmqFTxGKPQH3+YCx/I6/D5kbwrGu29B 52pw5QgVQy3u0MdlX7reSC461YFlz1qirWkjFDSPHdilBmzfz+m6RiI/X6fQFNu2g7u/ /UqQ== Received: by 10.66.87.132 with SMTP id ay4mr31043870pab.67.1352464332489; Fri, 09 Nov 2012 04:32:12 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id az8sm17902701pab.24.2012.11.09.04.32.11 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 04:32:12 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 07:31:59 -0500 Message-Id: <045AC679-9C57-4A74-AD27-A5DA4EDAAEB9@lilacglade.org> To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #13: Use case #10 is self-referential X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:32:13 -0000 This issue claims that use case #10 is logically invalid. In my opinion, it is true that use case #10 (as written) is = self-referential and non-sensical. =20 My proposed resolution is that use case #10 should be removed, unless = someone can explain what it was meant to say... Thoughts? Margaret= From margaretw42@gmail.com Fri Nov 9 04:58:19 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247B921F8508 for ; Fri, 9 Nov 2012 04:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N5ypvCkQ7V4 for ; Fri, 9 Nov 2012 04:58:18 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3CB921F84CD for ; Fri, 9 Nov 2012 04:58:18 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2985096pad.31 for ; Fri, 09 Nov 2012 04:58:18 -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:date:message-id :to:mime-version:x-mailer; bh=dQg6n8Mk6dt3t2+3jMtzrYVJcYxH2oYyM53Lm/GymMY=; b=kVCIeQTyUsqK4tC9XYifOt7WmdZ+wW+qmDgY1L3BC6u7rYOC2UyJBlOGqL6r7yWD3i kKHrd0W+KgzXHKX/oN9OVcddkoKXiZvmMAtNlE7F1UHoIikhExbhyyatfObZ5XDtMXMH GXS1utBtElo49erCEaIqMrPbfDJ1Gi5wGQXWgAw3/lNm0nyhrjGeNfne/1fh9Ltjmg/7 9xReDNJ2YOzzuKMEYscqk0CPm4+oEcy1sIsHA7n/3jRPfNymkstFq+zbqA/hddLS2xiQ F13XM7ZsWoQONxE4tyDDaJoAA8rFnMXNZTfif8TCjKCmy4hAJLxqIrSA/VbnTMmn7XpG OjdA== Received: by 10.68.233.196 with SMTP id ty4mr33824266pbc.23.1352465898561; Fri, 09 Nov 2012 04:58:18 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id n11sm17702933pby.67.2012.11.09.04.58.17 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 04:58:18 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 07:58:16 -0500 Message-Id: To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #5: Only one default route? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 12:58:19 -0000 Issue #5 indicates that there should be a default router list for each = prefix, not just a single default router. This issue has been discussed = on the mailing list and in the WG without formal resolution, but we seem = to be mostly in agreement that a default router list would be = preferable. I would propose updating the document to include a default router list = per prefix. Thoughts? Margaret From margaretw42@gmail.com Fri Nov 9 05:00:45 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3AB21F85D4 for ; Fri, 9 Nov 2012 05:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKeEwZbAdvz9 for ; Fri, 9 Nov 2012 05:00:45 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05CDB21F85BB for ; Fri, 9 Nov 2012 05:00:44 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2986396pad.31 for ; Fri, 09 Nov 2012 05:00:44 -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:date:message-id :to:mime-version:x-mailer; bh=+jcPSnQapCvIvxCJlKPuJA04zQ2GJTxCm/uQviUkoZk=; b=NWPICfbyoqZM0f8JsGjgH4sX4zR+Ea5Bmb/JbGlJ/9p3LqDqTSojbvU2ZCknJR7bXO I9jNvfH4V37WGsPcauvFL6VZBsWDT8M7dH9Oa51hiHwbMrwfA/CHVW+65V5Bo7YosGAg UORXwclq2Osf1JkJgkG+Z2g/lS+VTF9nS0RrCKHHwUXM6b+HXd1CTZe5ykOOZ6oi23Hl NGzYOC5SF3c9ve38Lv7i/P/v5hjfEgrpMHrPi7OJhqVntTAyyQXLSawBpmlnndlCXJVF qCYgQp9HYscBwhg2RihalNYo8Q3NDRvKgznK2X2EO2U9/vSh1enPxvs6D6rgP6XKmsyd xvWA== Received: by 10.66.75.165 with SMTP id d5mr31597965paw.39.1352466044830; Fri, 09 Nov 2012 05:00:44 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id ox8sm11236466pbc.31.2012.11.09.05.00.43 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 05:00:44 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 08:00:42 -0500 Message-Id: <27E29B59-C139-45B3-847D-01D420E34FBE@lilacglade.org> To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #6: Lifetime field length should be 16 bits for ND compatibility X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:00:45 -0000 This issue claims that the lifetime field in the DHCPv6 Route Option = should be 16 bits for compatibility with ND, instead of 32 bits as is = currently in the draft. There has been some discussion of this issue on the mailing list and in = the WG meetings, but no formal resolution has been reached.=20 Personally, I think that having the lifetime field have the same size = and meaning between ND and the DHCPv6 route option is desirable. So, I = would propose that we change the length of this field to 16 bits in the = document. Thoughts? Margaret From margaretw42@gmail.com Fri Nov 9 05:03:21 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B3621F8467 for ; Fri, 9 Nov 2012 05:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.661 X-Spam-Level: X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsJOieypxNHd for ; Fri, 9 Nov 2012 05:03:21 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29BBE21F8542 for ; Fri, 9 Nov 2012 05:03:21 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1785406dan.31 for ; Fri, 09 Nov 2012 05:03:21 -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:date:message-id :to:mime-version:x-mailer; bh=+zXZor817pCuYeiR29X8++JEWIzi/A7wheKElJWBWd4=; b=yvybmrf+O36xaXCia3STFNGSCnZv2dO4x3RL6YGBbhfmqwANkdaJbOeyncONE5MVW7 zBkVLvQ32ON+nQ4h7sPcFWDrzKaHzhA3+Fmz6PJgC5NnrqMxXeC7ep4j9rjjy3iChy3h nFI/geqPRRUf7JHUg1eYnEkHAgCeZKRUPkx3Q2WABjILhuwyjvB1aEvR9Rce8SX9Mz8j 5I1kNJYHw0pfgP50aYTFp+9RFX0TPGSihP5POUHAJp1iU60XWD2oNsXpCADuRKWzuOHM skz00+zcrgbJUNHSZbld2j5VMX03DrYbg8+hATS22bjd6Yx2vmhT59ydPq1vOSIOrajq Jxdw== Received: by 10.66.78.199 with SMTP id d7mr31415124pax.77.1352466201010; Fri, 09 Nov 2012 05:03:21 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id jw14sm17716237pbb.36.2012.11.09.05.03.20 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 05:03:20 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 08:03:18 -0500 Message-Id: To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #8: Absent MAC Address of Default Route X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:03:21 -0000 It has been proposed that the DHCPv6 Route Option should contain the MAC = address of each default router. There has been some list discussion, and we mostly seem to be in = agreement that MAC addresses do not belong in this option and should be = obtained using ND, as usual. However, there has been no formal = resolution of this issue. My proposed resolution is that we close this issue with no corresponding = document changes. Thoughts? Margaret From margaretw42@gmail.com Fri Nov 9 05:10:19 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B6921F865D for ; Fri, 9 Nov 2012 05:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TgWRGF2vHHw for ; Fri, 9 Nov 2012 05:10:19 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 769C421F862A for ; Fri, 9 Nov 2012 05:10:19 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2991445pad.31 for ; Fri, 09 Nov 2012 05:10:19 -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:date:message-id :to:mime-version:x-mailer; bh=uzPJH1qg+/8w1KuyZdnFIBFQJEjrvEixgJ0PXRHo7q4=; b=do5hHJiWfbFTqUbY54OXhvDEwG7b9MbZOYTUwOqSTz268gc/sJI8eX3Dp7ItYF1i+A F4rEbyJtl6q/3+hqR1cHMWO0QPph1c2ge/ADHY8z7TCIEYo1nbC67rmhIhpeNb9vj4/j 77gLS8ED0D777vmlAJTBMY5MLZAArYNe4fII7oPUmM8A0eQBOFLdLHvlQwOty3KII+jp qLrJS80xFl6y8OqCjlsypqHty5+ztWKuB0UGSDPN/brEfPpT32U9J8iomEJdCGgrc55L ZKlu5mxmRP0PT2obRJypojlXLVxIO+xt+8cYxSxgVIMhU7/pp6SKWNx6AIvh4EWMUj55 FlaQ== Received: by 10.68.217.104 with SMTP id ox8mr26866885pbc.35.1352466619305; Fri, 09 Nov 2012 05:10:19 -0800 (PST) Received: from ?IPv6:2001:df8::64:462a:60ff:fef6:acfc? ([2001:df8:0:64:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id qt3sm15205331pbb.32.2012.11.09.05.10.18 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 05:10:18 -0800 (PST) From: Margaret Wasserman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2012 08:10:16 -0500 Message-Id: <6B618639-B883-43D2-B437-D0212BFE4E95@lilacglade.org> To: mif mif Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [mif] Issue #7: Separate specific routes from default routes? X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:10:20 -0000 This option proposes separate options for specific vs. default routes. There has been some discussion of this proposal in WG meetings, and = there has not been very much support for making this change. =20 I would propose that we close this issue without any changes to the = document. Thoughts? Margaret From internet-drafts@ietf.org Fri Nov 9 05:19:00 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0194E21F85A1; Fri, 9 Nov 2012 05:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84fZ2fEPhyr6; Fri, 9 Nov 2012 05:18:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4821F21F854C; Fri, 9 Nov 2012 05:18:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121109131859.6872.24837.idtracker@ietfa.amsl.com> Date: Fri, 09 Nov 2012 05:18:59 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-api-extension-03.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:19:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of the = IETF. Title : MIF API consideration Author(s) : Dapeng Liu Ted Lemon Zhen Cao Filename : draft-ietf-mif-api-extension-03.txt Pages : 17 Date : 2012-11-09 Abstract: Hosts may connect to the internet using more than one network API at a time, or to a single network on which service is provided by more than one provider. Existing APIs are inadequate to allow applications to successfully use the network in this environment. This document presents a new abstract API that provides the minimal set of messages required to enable an application to communicate successfully in this environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-api-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-api-extension-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-api-extension-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@google.com Fri Nov 9 06:18:57 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217B621F85BC for ; Fri, 9 Nov 2012 06:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRy8RKzw11Ex for ; Fri, 9 Nov 2012 06:18:56 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97E2821F854E for ; Fri, 9 Nov 2012 06:18:56 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so4374601oag.31 for ; Fri, 09 Nov 2012 06:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QRlu6BtCZX3YUlVNzoPFnp0FKyPkOr6JXYrv4kiE2II=; b=aTKa7Qb8RQJl5ovkq01pmidfWbLBPl0m0tC1Fytiided3nzMiC2eJf+MIh/ktzGTs0 3yYDnwFyC3BlGwDFIcSvt0KqzfEn31AVk9kBqD98/MvCPunfOwQMvvFXdE7eSV2U4pzH W2CyBi8SwlmqUWEseMFXhXIH/EEi6OUXBXrkhMKUiT6VyG4TNHgziCEsRMF9JeRV6yBL EfaYHiI3BlU+3pLQLQncvgG4o4SMUZpPo1X+57vgwEtP8fxOIF19Tkt8UVkgfAKQMe+N s/jH0+fUhqHJMxvd+Aq7PGfdLY6dD/D7V9AI1L3UluItrGXhuQ2wW9EfaFkL8vqPXa8T 0tug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=QRlu6BtCZX3YUlVNzoPFnp0FKyPkOr6JXYrv4kiE2II=; b=bZoEGd4Yeq37k2rNSO2STgqNybWCqNPXYZFn8aZ4CJSZJeromNGm/DP2tmBdACBg0R v5kWxbg44pG85NbYad0MsuYOBSc0pQ6FLXkARxQCfJIJBquD9X1zdqCxRppsPcwHbWPx ptee9k1w49yjr0sgV9NqhDXvBwO8RI5nLUavuWTCu7IuXQfdnIrkyoSmQzswpWjWTudI SQtEr3samHB8v2KTzH8+OWyz1F4iA37qm2HDtcGsH5mR/7e7m2ZcI9gfzBHdbTmtCVrH U79CiHp5j4mu7p8INk8FjlkyAEE9MPTWor2x/VUVoqc8uCd6si1kvk001JVC+ZpPOtnq a3dw== Received: by 10.182.38.101 with SMTP id f5mr8720146obk.80.1352470735890; Fri, 09 Nov 2012 06:18:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Fri, 9 Nov 2012 06:18:34 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 9 Nov 2012 09:18:34 -0500 Message-ID: To: Margaret Wasserman Content-Type: multipart/alternative; boundary=f46d04463008c829de04ce10a15a X-Gm-Message-State: ALoCoQmpjZYUQ+i43D3L2Am9GtqJLjv4udskrXDkIB/vILZarBqvraOyi6/BzS+JJ0uHTimvNMrqLl7KbH79RAN87a9QbZWGxaoaIcD2RCTMiBI36U+GUELqYiHxPDpwx/ESMYLVFa+a/mHtJhVsVdfRb3uWziBy33OjEaUegm0J419f7xxhpPpOrzSB2jc++gfb6VPubhKR Cc: mif mif Subject: Re: [mif] Issues #10, #11 & #12: "Walled-garden" use cases are invalid X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:18:57 -0000 --f46d04463008c829de04ce10a15a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 9, 2012 at 7:25 AM, Margaret Wasserman wrote: > There has been some list discussion explaining that use cases #1, #5 and > #7 are not inherently walled-garden use cases. > In that case, the use cases should be reworded so they do not refer to walled gardens. Also, it is not required that our work comply with the opinions expressed > in IAB workshop reports. Workshop reports are not even IETF consensus > documents, and they do not place requirements on IETF protocol work. > The IAB is responsible for "oversight of [...] the architecture for the protocols and procedures used by the Internet". If the IAB issues a strong recommendation not to design for this use case, then it is silly for us to target it. --f46d04463008c829de04ce10a15a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --f46d04463008c829de04ce10a15a-- From lorenzo@google.com Fri Nov 9 06:24:06 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1421F8594 for ; Fri, 9 Nov 2012 06:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gbaJdFwxdNc for ; Fri, 9 Nov 2012 06:24:06 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4321F85BC for ; Fri, 9 Nov 2012 06:24:06 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id wo10so645836obc.31 for ; Fri, 09 Nov 2012 06:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HyurEuCSCTh4uezoGsqKgzqulw9/bWfj3pZWQ6GQnls=; b=Hw3cbO7Ie3/AMoV7AqkMpVnlHMFE/8JXmXVz5omNR8dAS159bz5Zx1t4C/u3ImeBJJ bWiwWPO/38UqfBM4b/Iuy3xVR0dTg1refH5+6AOMf6FICOvKdx7gtVaYGwGLjqJw8QaU k5PmVXs7HWl6Kh+LF1toExOq6Aq/89mDOaDgMZWwSoGHSDjpPHTqtKsrih+sy41vS1ab TVg8HJp97FqsqFLFVTtrZ2wYurrDOpSWuor2Bh0ueQaB6AhEvLBN+g6GcL2LyOmz1Flt GRRZR43QqGJ3c+Mw42E5VbZA3E0rfPSVWlta15N1KO2RpPLoKUHImSL4AMg+Qw0wnQLP B8Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=HyurEuCSCTh4uezoGsqKgzqulw9/bWfj3pZWQ6GQnls=; b=LbADVJPxsZbgmpk2u9pXNouE94F8O2LTNCmnEz2/BdxFlFdrOyu77SorYGT+G/3Oc7 VZEDLAJ7yAWwJG3ctGq24E2RLUqlBPZe4iQBF8fpS9g3keZ68K/ik+ImmPoqq6GXSMqj DXrCFTYB/zIpQsiG26mKy2gBtGgTWG9QVZ0dRRxnGUk4zCITo+82uhrpb2kt/ohsQE/s oXE/JmNhgYqOfOdSLDCsjbI3HPMhXEfp35k65uN7K8zIDFdXcmsvx3khhck61TwbBQJG 0fyJt/wZqRXZTPocPn6rJmicIzv0uxsHjeycwPr6+EikOzT1w4sGlpng9xWfH89oHFk3 kKSQ== Received: by 10.60.30.100 with SMTP id r4mr8105191oeh.121.1352471045776; Fri, 09 Nov 2012 06:24:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.176.106 with HTTP; Fri, 9 Nov 2012 06:23:45 -0800 (PST) In-Reply-To: <33D070DC-97D8-496F-928B-0F3281BF4AC3@gmail.com> References: <33D070DC-97D8-496F-928B-0F3281BF4AC3@gmail.com> From: Lorenzo Colitti Date: Fri, 9 Nov 2012 09:23:45 -0500 Message-ID: To: Margaret Wasserman Content-Type: multipart/alternative; boundary=e89a8fb206d440a6ba04ce10b449 X-Gm-Message-State: ALoCoQnXRHwdccuA9KIWjyleLBn8m5iCLls+LCl3n2IESoXoN96udu15Rv4z0BoYX6/ts4AQ2OnPC8Z0X0UQBdQ0NAVhV0AfR5S3WtBxliAnsP0pi7bTDNOyt9lUL8ByIfnui9jJ15WKRqJ+M9q3lzbbyLvM+ZllIPOtHmo6uvmpfSTXnCBpsksIj7V9w9yqPrbSXH1G9NiV Cc: mif mif Subject: Re: [mif] Issue #18: Vague problem statement... X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:24:06 -0000 --e89a8fb206d440a6ba04ce10b449 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 9, 2012 at 6:54 AM, Margaret Wasserman wrote: > > As explicitly stated in the issue text and pointed out on the list, this > issue is a duplicate of other, more specific, open issues. I propose that > it be closed as a duplicate issue. > This is a more general issue that covers the more specific issues filed, plus other problems with other use cases, general text clarity, and so on. It should not be treated as a duplicate but rather a tracking issue that is blocked by the other, more specific, issues. When all the blocking issues are resolved, this issue can automatically be resolved. --e89a8fb206d440a6ba04ce10b449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --e89a8fb206d440a6ba04ce10b449-- From trac+mif@trac.tools.ietf.org Fri Nov 9 06:46:16 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFD321F86D0 for ; Fri, 9 Nov 2012 06:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF7sNw3kxyob for ; Fri, 9 Nov 2012 06:46:15 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC5821F86DF for ; Fri, 9 Nov 2012 06:46:13 -0800 (PST) Received: from localhost ([127.0.0.1]:49633 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWpq0-0003Dt-7j; Fri, 09 Nov 2012 15:45:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Fri, 09 Nov 2012 14:45:40 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/19 Message-ID: <051.0e236fcc9951ebcf0a88663d79405bc8@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121109144615.9CC5821F86DF@ietfa.amsl.com> Resent-Date: Fri, 9 Nov 2012 06:46:13 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #19: Last paragraph of 7.1 needs clarification X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:46:16 -0000 #19: Last paragraph of 7.1 needs clarification The final paragraph of section 7.1 appears to create another directive for the client in terms of processing the DHCPv6 option format. It's not clear that it belong in a "Conflict resolution" section. Suggestion: (once the intent is clarified) I suspect it belongs in its own little section. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Fri Nov 9 06:49:36 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A512821F86F7 for ; Fri, 9 Nov 2012 06:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVU0RI9IOduD for ; Fri, 9 Nov 2012 06:49:36 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F275921F8553 for ; Fri, 9 Nov 2012 06:49:35 -0800 (PST) Received: from localhost ([127.0.0.1]:50073 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWptW-0005oY-1R; Fri, 09 Nov 2012 15:49:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Fri, 09 Nov 2012 14:49:18 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/20 Message-ID: <051.d1e5167969738b8e96452f0bf41c434f@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121109144935.F275921F8553@ietfa.amsl.com> Resent-Date: Fri, 9 Nov 2012 06:49:35 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #20: Use case #9 suggests changes to IPv6 deployment architecture X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:49:36 -0000 #20: Use case #9 suggests changes to IPv6 deployment architecture The text in use case #9 appears to create a new, different IPv6 deployment architecture, one in which RAs are not required. This suggests that perhaps (if this moves forward) we need to update the IPv6 node requirements document to strongly recommend not just support of DHCPv6 but specifically this option. Guidance to host implementations that this will be required in some environments is probably critical. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: blocker | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From ajs@anvilwalrusden.com Fri Nov 9 06:54:40 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B016A21F86CF for ; Fri, 9 Nov 2012 06:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5h96-mep5WG for ; Fri, 9 Nov 2012 06:54:40 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0C021F86A8 for ; Fri, 9 Nov 2012 06:54:40 -0800 (PST) Received: from mx1.yitter.info (dhcp-2113.meeting.ietf.org [130.129.33.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id AF9FB8A031 for ; Fri, 9 Nov 2012 14:54:38 +0000 (UTC) Date: Fri, 9 Nov 2012 09:54:32 -0500 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20121109145431.GC79908@mx1.yitter.info> References: <59A4BE5D-9D46-476F-927B-598E5A95D99E@gmail.com> <470747F3-F056-46AF-A6BA-ABC89A99EACB@lilacglade.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <470747F3-F056-46AF-A6BA-ABC89A99EACB@lilacglade.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Issue #16: Re: draft-ietf-mif-dhcpv6-route-option in mif WG charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:54:40 -0000 Dear colleagues, On Fri, Nov 09, 2012 at 06:44:42AM -0500, Margaret Wasserman wrote: > Based on this e-mail, I think we should close issue #16: DHCP route option does not belong in mif WG. It is not in scope for the mif WG to discuss whether our chartered work items belong in our group. > I confess that I don't really understand the technical issues about the DHCP route option, but I have three things to say on this topic: 1. I don't really think that it matters where the work gets done, and it seems to me that making a decision on this matter would be useful. Therefore, I would prefer the WG to complete the work. 2. If someone has a strong argument about why the topic ought to be removed from the charter, I don't recall seeing it on this list. 3. That there is a charter item about this does not oblige us actually to deliver a DHCP option, if we conclude that there are technical problems that mean we shouldn't define such an option. The document could say, for instance, "A DHCP route option seems like a good idea, but is not feasible because …." There is nothing wrong with the WG doing that, and I don't believe any responsible IESG would refuse to accept such a decision from a WG. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From trac+mif@trac.tools.ietf.org Fri Nov 9 07:36:37 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09C321F86A8 for ; Fri, 9 Nov 2012 07:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6hkX6Mqn+1g for ; Fri, 9 Nov 2012 07:36:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 521A421F8546 for ; Fri, 9 Nov 2012 07:36:37 -0800 (PST) Received: from localhost ([127.0.0.1]:54800 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWqd0-0006Lo-0t; Fri, 09 Nov 2012 16:36:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-api-extension@tools.ietf.org, nordmark@acm.org X-Trac-Project: mif Date: Fri, 09 Nov 2012 15:36:17 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/21 Message-ID: <054.ca8771963657f0f765853e54616fc8ae@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-api-extension@tools.ietf.org, nordmark@acm.org, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: caozhen@chinamobile.com, liudapeng@chinamobile.com, ted.lemon@nominum.com Resent-Message-Id: <20121109153637.521A421F8546@ietfa.amsl.com> Resent-Date: Fri, 9 Nov 2012 07:36:37 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #21: Some use cases assume IP multicast is not part of the Internet architecture X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:36:38 -0000 #21: Some use cases assume IP multicast is not part of the Internet architecture Many of the current use cases have an underlying motivation that can be characterized as some form of isolation or separation, where different hosts on the same link should use different ISPs. That separation only applies to unicast. Should a host need to send or receive IP multicast packets, it will interact with all routers on the link. (And even in the case of a host with multiple interfaces, a /0 prefix route doesn't have an impact on multicast sending and receiving.) The working group seems intent on rewriting the use case section from scratch, hence I will not go into the details of which of the current use cases makes the assumption that we can ignore the existence of IP multicast. But this ticket should be taken into account when formulating the new use cases to make sure the things are clear with respect to the support for IP multicast. Note that even if IP multicast isn't deployed Internet-wide, there are potentially issues even locally if multicast DNS is used and different gateways needs to expose different mDNS information to the subsets of hosts on the link that they should serve. -- ---------------------------+-------------------------------------------- Reporter: nordmark@… | Owner: draft-ietf-mif-api-extension@… Type: defect | Status: new Priority: major | Milestone: Component: api-extension | Version: Severity: - | Keywords: ---------------------------+-------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Fri Nov 9 07:37:26 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23B221F86A8 for ; Fri, 9 Nov 2012 07:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9csWtP3r9mgn for ; Fri, 9 Nov 2012 07:37:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53021F8546 for ; Fri, 9 Nov 2012 07:37:26 -0800 (PST) Received: from localhost ([127.0.0.1]:54819 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWqdy-000801-NW; Fri, 09 Nov 2012 16:37:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, nordmark@acm.org X-Trac-Project: mif Date: Fri, 09 Nov 2012 15:37:18 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/22 Message-ID: <054.ad9543e3a3ed0990cf0c49bc8359b5df@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, nordmark@acm.org, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121109153726.4C53021F8546@ietfa.amsl.com> Resent-Date: Fri, 9 Nov 2012 07:37:26 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #22: Some use cases assume IP multicast is not part of the Internet architecture X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:37:27 -0000 #22: Some use cases assume IP multicast is not part of the Internet architecture Many of the current use cases have an underlying motivation that can be characterized as some form of isolation or separation, where different hosts on the same link should use different ISPs. That separation only applies to unicast. Should a host need to send or receive IP multicast packets, it will interact with all routers on the link. (And even in the case of a host with multiple interfaces, a /0 prefix route doesn't have an impact on multicast sending and receiving.) The working group seems intent on rewriting the use case section from scratch, hence I will not go into the details of which of the current use cases makes the assumption that we can ignore the existence of IP multicast. But this ticket should be taken into account when formulating the new use cases to make sure the things are clear with respect to the support for IP multicast. Note that even if IP multicast isn't deployed Internet-wide, there are potentially issues even locally if multicast DNS is used and different gateways needs to expose different mDNS information to the subsets of hosts on the link that they should serve. -- -------------------------+------------------------------------------------- Reporter: nordmark@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: major | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Fri Nov 9 07:56:05 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AED21F86F0 for ; Fri, 9 Nov 2012 07:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FdfIy0FjHvC for ; Fri, 9 Nov 2012 07:56:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4791B21F86E3 for ; Fri, 9 Nov 2012 07:56:03 -0800 (PST) Received: from localhost ([127.0.0.1]:56657 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWqvj-0006su-1W; Fri, 09 Nov 2012 16:55:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, alexandru.petrescu@gmail.com X-Trac-Project: mif Date: Fri, 09 Nov 2012 15:55:39 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/23 Message-ID: <066.9d0ab44b64c1395730cf0ab3e0970bb2@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, alexandru.petrescu@gmail.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121109155605.4791B21F86E3@ietfa.amsl.com> Resent-Date: Fri, 9 Nov 2012 07:56:03 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #23: Prefer 'preference' over 'metric' X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:56:06 -0000 #23: Prefer 'preference' over 'metric' At Atlanta WG meeting Behcet reminded an issue was posted on the email list which is not tracked, that he couldnt upload because he's an Author, so here I upload it. Ivo Sedlacek to whom I agree raised this issue, among others, on 24 October 2012 on the mif email list. > Metric: Route Metric. 8-bit signed integer. The Route Metric > indicates whether to prefer the next hop associated with > this prefix over others, when multiple identical prefixes > (for different next hops) have been received. This 'Metric' field is absent from the message encoding of Figure 3 "Route Prefix Option Format". Besides, in the default route case, a 'metric' is almost always equal 1. I suppose I suggest to always assume it 1 for the default route case. A 'metric' is the number of hops between self and the subnet prefix for this next hop. For other than default routes - I dont know what to put in this metric field, which is often necessary whenever inserting a routing table entry (although a 'by default' value is often substituted). On another hand, a 'Preference' field is what RFC4191 uses, and what this draft discusses elswhere, like: > Prf(Route Preference): 2-bit signed integer. The Route > Preference indicates [...] I suggest to use this form of Preference throughout the route-option draft. At the very least, remove that 'Metric' text quoted first in this issue. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mif-dhcpv6-route- alexandru.petrescu@… | option@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: dhcpv6 | Version: -route-option | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: mif From margaretw42@gmail.com Fri Nov 9 10:26:22 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89221F868E for ; Fri, 9 Nov 2012 10:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.655 X-Spam-Level: X-Spam-Status: No, score=-3.655 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3riTC8yEX2H for ; Fri, 9 Nov 2012 10:26:21 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2D4B21F858F for ; Fri, 9 Nov 2012 10:26:21 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so3164242pad.31 for ; Fri, 09 Nov 2012 10:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5mMUKXUPQ+ZYAmrvn37SCc4H79l3LPzSRYc7r5fC8+4=; b=HMFUTKQjFc2WhfF8gV5s8sQo+v+FNeju+YaIqGamiFIrUBQa+Y4ZnoOoUhm+Em1Scc yPSbHywfKDwhfUzx/mQ5PkFiafTpkajUDRan/bCMLPFFnxA/nO1elzQCGD/T7Y9gLNwO UTAODIVYrLYfdCyCrm971P5YVYJ0+nRGEVCj+bI3LxqogQRn7GKAg3ekpiYUcuWEYSsn FcXkSQ+Drf8CBb9bpBG2MxJpvdBJWNPrK3ys8/a+UaNWkIvWtxpYecF44lcFDiNScT/X P2UjdFthg8DR3dKh0lgTFS5rrPjJNn5IZMEbH2QU+W3M5F3N+t8hX23X4dvwXVT+hVpA NKAw== Received: by 10.68.237.106 with SMTP id vb10mr2405543pbc.5.1352485581636; Fri, 09 Nov 2012 10:26:21 -0800 (PST) Received: from ?IPv6:2001:df8::16:462a:60ff:fef6:acfc? ([2001:df8:0:16:462a:60ff:fef6:acfc]) by mx.google.com with ESMTPS id ni8sm18068929pbc.70.2012.11.09.10.26.19 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 10:26:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Margaret Wasserman In-Reply-To: <20121109145431.GC79908@mx1.yitter.info> Date: Fri, 9 Nov 2012 13:26:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59A4BE5D-9D46-476F-927B-598E5A95D99E@gmail.com> <470747F3-F056-46AF-A6BA-ABC89A99EACB@lilacglade.org> <20121109145431.GC79908@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Issue #16: Re: draft-ietf-mif-dhcpv6-route-option in mif WG charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:26:22 -0000 On Nov 9, 2012, at 9:54 AM, Andrew Sullivan wrote: > 3. That there is a charter item about this does not oblige us > actually to deliver a DHCP option, if we conclude that there are > technical problems that mean we shouldn't define such an option. > The document could say, for instance, "A DHCP route option seems > like a good idea, but is not feasible because =85." There is > nothing wrong with the WG doing that, and I don't believe any > responsible IESG would refuse to accept such a decision from a WG. I agree with this statement. The WG has not reached consensus that we _shouldn't_ define this option. = It is possible that we no longer have consensus that we should define = it, but that isn't the same thing... Margaret From mcr@sandelman.ca Fri Nov 9 11:04:33 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6238521F850A for ; Fri, 9 Nov 2012 11:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWNnU5qxHr5H for ; Fri, 9 Nov 2012 11:04:32 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1921321F84C7 for ; Fri, 9 Nov 2012 11:04:31 -0800 (PST) Received: from sandelman.ca (unknown [199.108.69.151]) by relay.sandelman.ca (Postfix) with ESMTPS id 4DAC381AA for ; Fri, 9 Nov 2012 13:56:18 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3AC6ACA0BC for ; Fri, 9 Nov 2012 14:04:23 -0500 (EST) From: Michael Richardson To: mif@ietf.org X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 09 Nov 2012 14:04:23 -0500 Message-ID: <18178.1352487863@sandelman.ca> Sender: mcr@sandelman.ca Subject: [mif] some questions about dns-server-selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:04:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Thank you to the MIF WG for sending out spores to other WG this week to tell us about your work.=20=20 I realize that dns-server-selection-12 is in the RFC editor queue, but I had some questions about it. I found the document to be well written, relatively clear, and I found that the security discussion was informed and appropriate.=20=20 Why does the IPv6 DHCP option have a single DNS recursive server listed, while the IPv4 one has a primary and secondary? What is the preference for a DNS server learnt from a DHCP server that does not send the DNS_SERVER_SELECT option? I guess section 4.6 talks about this, but I felt was a bit buried. I think that this document is very good example of why DNS64 *should* have provided signaling that DNS64 was occuring in DHCP and RA :-) That would have informed a host better as to which interface to use for better service.=20 Also, the document keeps saying "network interface". I understand that to mean a specific device, e.g. "wlan0". I think, however, that really it should be read to understand "wlan0"+"specific ESSID" for the wifi case, and perhaps "specific APN" for the cellular case. It's funny that wired, has no such "sub-interface" naming system... Why are only DHCP methods documented? what about RA options? I found the section:=20 As the DHCP by itself cannot tell whether it is using secure, trusted channel, or whether the client on a node is performing DNSSEC validation, this option cannot be used without being explicitly enabled. The functionality can be enabled for an interface via administrative means, such as by provisioning tools or manual configuration. Furthermore, the functionality can be automatically enabled by a client on a node that knows it is performing DNSSEC validation, or by a node that is configured or hard-coded to trust certain interfaces (see Section 9.2). so, basically, please never use this protocol unless you know what you are doing, in which case, you should just vi /etc/resolv.conf instead? That DNSSEC is required to even think about using this is instructive, because it means that actually, recursive DNS lookups are local already. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQnVO2AAoJEKD0KQ7Gj3P2UXsIALyHDX35foUZQEpcgJQ9ZYut EZHHJTpHk9lM5ucJmqy8rH+bkJkFX8SsvW3judRCsoKhAepHqyTclmrdPL4IwH32 M/7aqZxCxtf8yycWXEZNTaamZsRWU4yRXvfdoqF8eV3HlK2glIO80bjp6+L10Pda hXDGlyxErCNm7hhiWx2xOrMo+g18Iz8Y19/XnUMw4Y8joUNGQjHCcaZa3ifvro7c FGxsyAtGAegoM8STovX8Jk3S0vOwPohZNVqdeK8kYTXL0wzbsd5ibnX0f6zoRhnz i7Dl4ehOBjyDMLscXhc1hBbgh1bC8IYWaGLppJg4RJleMx7oKbp8dfThFMkAk+g= =s6vi -----END PGP SIGNATURE----- --=-=-=-- From Ted.Lemon@nominum.com Fri Nov 9 11:44:04 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21E021F853E for ; Fri, 9 Nov 2012 11:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnshChkrExF3 for ; Fri, 9 Nov 2012 11:44:04 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0C16021F84FF for ; Fri, 9 Nov 2012 11:44:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUJ1dA1IVv1Jy3pZ8eO4QI7sNjbuyI/Zs@postini.com; Fri, 09 Nov 2012 11:44:04 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2DECD1B8220 for ; Fri, 9 Nov 2012 11:44:03 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 225AA190043; Fri, 9 Nov 2012 11:44:03 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 9 Nov 2012 11:44:03 -0800 From: Ted Lemon To: Margaret Wasserman Thread-Topic: [mif] Issue #16: Re: draft-ietf-mif-dhcpv6-route-option in mif WG charter Thread-Index: AQHNvqe6mIC4ROaCCkSwXLarug+RQ5fibesA Date: Fri, 9 Nov 2012 19:44:03 +0000 Message-ID: References: <59A4BE5D-9D46-476F-927B-598E5A95D99E@gmail.com> <470747F3-F056-46AF-A6BA-ABC89A99EACB@lilacglade.org> <20121109145431.GC79908@mx1.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Issue #16: Re: draft-ietf-mif-dhcpv6-route-option in mif WG charter X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:44:05 -0000 On Nov 9, 2012, at 1:26 PM, Margaret Wasserman wrote: > The WG has not reached consensus that we _shouldn't_ define this option. = It is possible that we no longer have consensus that we should define it, = but that isn't the same thing... Speaking from bitter experience in the dnsop working group, these two thing= s actually are the same thing; it's just that the "no longer have consensus= " option wastes a lot more working group time. From teemu.savolainen@nokia.com Mon Nov 12 00:49:55 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1110A21F8539 for ; Mon, 12 Nov 2012 00:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOXU6P3xM6ol for ; Mon, 12 Nov 2012 00:49:54 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2A97021F852C for ; Mon, 12 Nov 2012 00:49:50 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAC8nkkb018874; Mon, 12 Nov 2012 10:49:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.50]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 10:49:46 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.19]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.02.0318.003; Mon, 12 Nov 2012 08:49:47 +0000 From: To: , Thread-Topic: [mif] some questions about dns-server-selection Thread-Index: AQHNvq0R1Oj3O5YtrUWjnLlSMVsQ/Zfl4KQQ Date: Mon, 12 Nov 2012 08:49:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962044D14EC@008-AM1MPN1-053.mgdnok.nokia.com> References: <18178.1352487863@sandelman.ca> In-Reply-To: <18178.1352487863@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Iq6b9s1V91cZrTvSk5BbPj/3C6gJM8EmTWR1+SWkd7We1EVgeLmP4NZoNRSBL0EUezv6DOUfkUxtUfCavQqBXupd0/+aIG4DfR2cpLYXrMC4+UZkj7qXG2iljhgJn0eYDyBaT4IyzJZxnpI+3UFJsFiTHJamrnnqvoyAtPeZkDvOJBfsRXfQNkHmPKCR9VgdBRWd5d7k4WSpelIRoPqzhLD7xuc8oQapPK8PXDb5lkFMVMSA+dmFcIbUcUn4oJBkzg== x-originating-ip: [10.163.169.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 08:49:46.0664 (UTC) FILETIME=[AAD88280:01CDC0B2] X-Nokia-AV: Clean Cc: mif-ads@tools.ietf.org Subject: Re: [mif] some questions about dns-server-selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 08:49:55 -0000 Thank you Michael for these questions. Please see inline: > Why does the IPv6 DHCP option have a single DNS recursive server listed, > while the IPv4 one has a primary and secondary? On this I have to confess I don't recall a particular reason (this draft ha= s been in works for four years, and the early days are getting blurry in my= memory). Do you see this as a serious issue that REALLY should be addresse= d before publication?=20 > What is the preference for a DNS server learnt from a DHCP server that do= es > not send the DNS_SERVER_SELECT option? I guess section 4.6 talks about > this, but I felt was a bit buried. Medium, quote from document: -- The RDNSSes learned via other tools than OPTION_DNS_SERVER_SELECT MUST be handled as default RDNSSes, with medium preference, when building a list of RDNSSes to talk to (see Section 4.1). -- > I think that this document is very good example of why DNS64 *should* hav= e > provided signaling that DNS64 was occuring in DHCP and RA :-) That would > have informed a host better as to which interface to use for better servi= ce. This is sidetrack for MIF and DNS server selection, right? (More for Behave= ). Anyhow, I don't think DHCP/RA should be involved in DNS64/NAT64, but ins= tead it *would* have been nice if DNS64 would have included e.g. EDNS0 opti= ons to indicate (for modified hosts) that synthesis is taking place. It wou= ld've also helped in Pref64::/n discovery, see: http://datatracker.ietf.org= /doc/draft-korhonen-edns0-synthesis-flag/=20 Too late for that, though. > Also, the document keeps saying "network interface". I understand that > to mean a specific device, e.g. "wlan0". I think, however, that really > it should be read to understand "wlan0"+"specific ESSID" for the wifi cas= e, > and perhaps "specific APN" for the cellular case. It's funny that wired,= has no > such "sub-interface" naming system... Terminology... Maybe "point of network attachment" would have been better c= hoice of working? > Why are only DHCP methods documented? what about RA options? That would be a topic for another document, for someone who wants this to R= A (I volunteer to coauthor if someone wants to pursue that, but I don't hav= e time to be the lead author for that piece of work). > I found the section: > As the DHCP by itself cannot tell whether it is using secure, trusted > channel, or whether the client on a node is performing DNSSEC > validation, this option cannot be used without being explicitly > enabled. The functionality can be enabled for an interface via > administrative means, such as by provisioning tools or manual > configuration. Furthermore, the functionality can be automatically > enabled by a client on a node that knows it is performing DNSSEC > validation, or by a node that is configured or hard-coded to trust > certain interfaces (see Section 9.2). >=20 > so, basically, please never use this protocol unless you know what you ar= e > doing, in which case, you should just vi /etc/resolv.conf instead? > That DNSSEC is required to even think about using this is instructive, be= cause > it means that actually, recursive DNS lookups are local already. You should check the zillion emails about security discussions related to t= his draft. If you are not sure about security, use OPTION_DNS_SERVERS. But please read carefully the text you quoted:" using secure, trusted chann= el, ". This means that if a channel from a host to the DHCP server is trust= ed, DNSSEC is not needed. These kinds of environments exist e.g. in 3GPP do= main, where the cellular connection is considered trusted enough for this p= urpose. Best regards, Teemu From mcr@sandelman.ca Mon Nov 12 10:08:23 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5221F84F3 for ; Mon, 12 Nov 2012 10:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Eh6-ZGFQFdf for ; Mon, 12 Nov 2012 10:08:22 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 50CE121F8472 for ; Mon, 12 Nov 2012 10:08:22 -0800 (PST) Received: from sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id 8358381A9; Mon, 12 Nov 2012 13:00:03 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1DE0DCA0BC; Mon, 12 Nov 2012 13:08:20 -0500 (EST) From: Michael Richardson To: teemu.savolainen@nokia.com In-reply-to: <916CE6CF87173740BC8A2CE443096962044D14EC@008-AM1MPN1-053.mgdnok.nokia.com> References: <18178.1352487863@sandelman.ca> <916CE6CF87173740BC8A2CE443096962044D14EC@008-AM1MPN1-053.mgdnok.nokia.com> Comments: In-reply-to message dated "Mon, 12 Nov 2012 08:49:46 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Nov 2012 13:08:19 -0500 Message-ID: <9722.1352743699@sandelman.ca> Sender: mcr@sandelman.ca Cc: mif-ads@tools.ietf.org, mif@ietf.org Subject: Re: [mif] some questions about dns-server-selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:08:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "teemu" =3D=3D teemu savolainen writes: teemu> On this I have to confess I don't recall a particular reason teemu> (this draft has been in works for four years, and the early teemu> days are getting blurry in my memory). Do you see this as a teemu> serious issue that REALLY should be addressed before teemu> publication? No. >> so, basically, please never use this protocol unless you know >> what you are doing, in which case, you should just vi >> /etc/resolv.conf instead? That DNSSEC is required to even think >> about using this is instructive, because it means that actually, >> recursive DNS lookups are local already. teemu> You should check the zillion emails about security teemu> discussions related to this draft. I figured as much. teemu> But please read carefully the text you quoted:" using secure, teemu> trusted channel, ". This means that if a channel from a host teemu> to the DHCP server is trusted, DNSSEC is not needed. These teemu> kinds of environments exist e.g. in 3GPP domain, where the teemu> cellular connection is considered trusted enough for this teemu> purpose. okay, an existence proof of this kind of enough for me. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQoTsTAAoJEKD0KQ7Gj3P2T3YH/19ONl0BW5rFSXHxy347v3Up ihJVinC66gx1TUYOL587PpjyXdF/NBYFkluh5piMJ/Tu2ED5h34UwsMqltvd3x8S JO3S/ZVw/ilYr29WRycwT8NlwrhCyb4WqbTBYQRE3qBLiQCwB7xZkjgofrOWr+Ut 7TLdMbViIHd0yFrYUuJ6MS90kkDXLMIp1f8GxzjKLiYqXhmvO9pChAmkU3MZ3tpf WEyaVyuZCkxhlDFlehs8lExzLA20H3ADoG0l3pikvgyJtGjL7LyGzIzOcwO8oHel LAjGC9I+d6tbXYWPLzmzIDgOgOxyYEhBejzq0EYyUSc9+hj6sEhrgzBKW+WJIuU= =MB/U -----END PGP SIGNATURE----- --=-=-=-- From denghui02@gmail.com Tue Nov 13 09:59:52 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D254D21F85FF for ; Tue, 13 Nov 2012 09:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1af7Y9IyPeT for ; Tue, 13 Nov 2012 09:59:52 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A94E021F85BF for ; Tue, 13 Nov 2012 09:59:51 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so2368117qaa.10 for ; Tue, 13 Nov 2012 09:59:49 -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=Ql9umF0IUx8QKdQRKZbv/QcLSmqlAQgg/S2dWD2JMoY=; b=mblF+SjKcccdQ8v+MsVUhYAthGBEVV6p058R89Jqbxg3RNWVjVVMqjS+aj8t30PCk9 ytjdEXy1uOrXDA5g67PNuOGY+bHv+9n7jeuw1zY6TQXjIGII6LfiLnIGuKja/e35VfoK bGnKHWKMfWNlI5+CWHQZkbAgaSMn5HxrU71nKk5/EETkR9sfBYBp/ZSAMrRtEjUKK94y z+bZzInHOUjvzI533J3HWBZHz4Quj7p78GIDZeUsdnVjRpto2RPM0hLMYC+DPcUfxHII iu7UWE+hTKbU4FL/W44N/5ddH3vK+bHqZ+kRv+jQrepDhOlq2SLyySBGtUf1+za29qId WHAg== MIME-Version: 1.0 Received: by 10.224.201.73 with SMTP id ez9mr23675217qab.92.1352829589772; Tue, 13 Nov 2012 09:59:49 -0800 (PST) Received: by 10.49.97.4 with HTTP; Tue, 13 Nov 2012 09:59:49 -0800 (PST) Date: Tue, 13 Nov 2012 11:59:49 -0600 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=20cf3010edaf23d98004ce642f0a Subject: [mif] IETF 85th MIF Minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 17:59:52 -0000 --20cf3010edaf23d98004ce642f0a Content-Type: text/plain; charset=ISO-8859-1 Hello all Thanks Stuart Cheshire and Peer Azmat Shah for taking the minutes, and also Michael Richardson's help for jabber scribe. Please feel free to let us know if there is any revision needed. http://www.ietf.org/proceedings/85/minutes/minutes-85-mif Best, -Hui --20cf3010edaf23d98004ce642f0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Thanks Stuart Cheshire and Peer Azma= t Shah for taking the minutes, and also Michael Richardson's help for j= abber scribe.
Please feel free to let us know if there is any rev= ision needed.
=A0=
Best,
=A0
-Hui
--20cf3010edaf23d98004ce642f0a-- From k.pentikousis@huawei.com Wed Nov 14 06:31:43 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEAA21F8581 for ; Wed, 14 Nov 2012 06:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ9cGyTMESOJ for ; Wed, 14 Nov 2012 06:31:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 50B4B21F8583 for ; Wed, 14 Nov 2012 06:31:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALN30818; Wed, 14 Nov 2012 14:31:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 14:31:22 +0000 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 14:31:31 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Wed, 14 Nov 2012 22:31:28 +0800 From: Konstantinos Pentikousis To: Hui Deng , MIF Mailing List Thread-Topic: [mif] IETF 85th MIF Minutes Thread-Index: AQHNwdmRc/L9ilQPNU6PTPpPGLvfK5fpZKRA Date: Wed, 14 Nov 2012 14:31:28 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4EE9E3@szxeml545-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: multipart/alternative; boundary="_000_8D38716F0C1A444BA0CD7E96454366C23A4EE9E3szxeml545mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Alexandru Petrescu Subject: Re: [mif] IETF 85th MIF Minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 14:31:43 -0000 --_000_8D38716F0C1A444BA0CD7E96454366C23A4EE9E3szxeml545mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hui, Just a kind reminder that Alex (CCed) and I volunteered to assist the draft= authors with the rewriting of the use cases, should they proceed with an u= pdate of draft-ietf-mif-dhcpv6-route-option-05. This is currently not recor= ded in the minutes. Best Regards, Kostas From: Hui Deng [mailto:denghui02@gmail.com] Sent: Tuesday, November 13, 2012 7:00 PM To: MIF Mailing List Subject: [mif] IETF 85th MIF Minutes Hello all Thanks Stuart Cheshire and Peer Azmat Shah for taking the minutes, and also= Michael Richardson's help for jabber scribe. Please feel free to let us know if there is any revision needed. http://www.ietf.org/proceedings/85/minutes/minutes-85-mif Best, -Hui --_000_8D38716F0C1A444BA0CD7E96454366C23A4EE9E3szxeml545mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hui,=

 <= /p>

Just a kind reminder that= Alex (CCed) and I volunteered to assist the draft authors with the rewriti= ng of the use cases, should they proceed with an update of draft-ietf-mif-dhcpv6-route-option-05. This is currently not recorded i= n the minutes.

 <= /p>

Best Regards,<= /span>

 <= /p>

Kostas<= /p>

 <= /p>

From: Hui Deng= [mailto:denghui02@gmail.com]
Sent: Tuesday, November 13, 2012 7:00 PM
To: MIF Mailing List
Subject: [mif] IETF 85th MIF Minutes

 

Hello all

 

Thanks Stuart Cheshire and Peer Azmat Shah for takin= g the minutes, and also Michael Richardson's help for jabber scribe.

Please feel free to let us know if there is any revi= sion needed.

 

Best,

 

-Hui

--_000_8D38716F0C1A444BA0CD7E96454366C23A4EE9E3szxeml545mbxchi_-- From alexandru.petrescu@gmail.com Wed Nov 14 08:14:00 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E2321F85A5 for ; Wed, 14 Nov 2012 08:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 234OmJf5ftnC for ; Wed, 14 Nov 2012 08:14:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 94D6E21F8558 for ; Wed, 14 Nov 2012 08:13:59 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qAEGDt5M009097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Nov 2012 17:13:55 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qAEGDtvd027747; Wed, 14 Nov 2012 17:13:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qAEGDslF018733; Wed, 14 Nov 2012 17:13:54 +0100 Message-ID: <50A3C342.1090609@gmail.com> Date: Wed, 14 Nov 2012 17:13:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantinos Pentikousis References: <8D38716F0C1A444BA0CD7E96454366C23A4EE9E3@szxeml545-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4EE9E3@szxeml545-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: MIF Mailing List Subject: Re: [mif] IETF 85th MIF Minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:14:00 -0000 I agree. Alex Le 14/11/2012 15:31, Konstantinos Pentikousis a écrit : > Hi Hui, > > Just a kind reminder that Alex (CCed) and I volunteered to assist the > draft authors with the rewriting of the use cases, should they proceed > with an update of draft-ietf-mif-dhcpv6-route-option-05. This is > currently not recorded in the minutes. > > Best Regards, > > Kostas > > *From:*Hui Deng [mailto:denghui02@gmail.com] > *Sent:* Tuesday, November 13, 2012 7:00 PM > *To:* MIF Mailing List > *Subject:* [mif] IETF 85th MIF Minutes > > Hello all > > Thanks Stuart Cheshire and Peer Azmat Shah for taking the minutes, and > also Michael Richardson's help for jabber scribe. > > Please feel free to let us know if there is any revision needed. > > http://www.ietf.org/proceedings/85/minutes/minutes-85-mif > > Best, > > -Hui > From denghui02@gmail.com Wed Nov 14 14:23:35 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0521F882E for ; Wed, 14 Nov 2012 14:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtpVDOQkSK7t for ; Wed, 14 Nov 2012 14:23:34 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 792B921F84D3 for ; Wed, 14 Nov 2012 14:23:34 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id c4so1941141qae.10 for ; Wed, 14 Nov 2012 14:23:33 -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=Rvn1GhwazKtvv+v913hbkMdJYlKdaIn9d7t2tEn30a4=; b=crLbExioxIM3T9FWQfrf32zn2UWS0sm+aZRY8nucELR/CHQCScBEK/DBlpPNAMLubF ccCr3vIjSoTzk1mGbIzh+lpgs/R2s1AO4RI3GikD5SWqHjXoKAYzAHiFrXD6DbP9K4tM AoXAXtwGBKG2V+D4j6DA09NskyMX0iAoNQ1EAWIj92WASPm9Np7A5ywX1o/32U9Pc3Hl tIuny/Q4vqESzyQSXDc7bMKCVFzh1Bfq+G9nNk3k9AoqcWibjTr0Qpvfu9LL0D62LmJz Xi/k/fJ08HGcFW6bpB4yMbyRrty3zU0QtrxPrXLN4f/Tms03dqPGS4XVO/BILrpAu13u imfA== MIME-Version: 1.0 Received: by 10.224.59.197 with SMTP id m5mr27101088qah.4.1352931813885; Wed, 14 Nov 2012 14:23:33 -0800 (PST) Received: by 10.49.97.4 with HTTP; Wed, 14 Nov 2012 14:23:33 -0800 (PST) In-Reply-To: <50A3C342.1090609@gmail.com> References: <8D38716F0C1A444BA0CD7E96454366C23A4EE9E3@szxeml545-mbx.china.huawei.com> <50A3C342.1090609@gmail.com> Date: Wed, 14 Nov 2012 16:23:33 -0600 Message-ID: From: Hui Deng To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=20cf3074d8a42c08a704ce7bfc65 Cc: MIF Mailing List , Konstantinos Pentikousis Subject: Re: [mif] IETF 85th MIF Minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:23:35 -0000 --20cf3074d8a42c08a704ce7bfc65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable thanks, minutes has been updated to ack this. Best, -Hui 2012/11/14 Alexandru Petrescu > I agree. > > Alex > > Le 14/11/2012 15:31, Konstantinos Pentikousis a =E9crit : > >> Hi Hui, >> >> Just a kind reminder that Alex (CCed) and I volunteered to assist the >> draft authors with the rewriting of the use cases, should they proceed >> with an update of draft-ietf-mif-dhcpv6-route-**option-05. This is >> currently not recorded in the minutes. >> >> Best Regards, >> >> Kostas >> >> *From:*Hui Deng [mailto:denghui02@gmail.com] >> *Sent:* Tuesday, November 13, 2012 7:00 PM >> *To:* MIF Mailing List >> *Subject:* [mif] IETF 85th MIF Minutes >> >> >> Hello all >> >> Thanks Stuart Cheshire and Peer Azmat Shah for taking the minutes, and >> also Michael Richardson's help for jabber scribe. >> >> Please feel free to let us know if there is any revision needed. >> >> http://www.ietf.org/**proceedings/85/minutes/**minutes-85-mif >> >> Best, >> >> -Hui >> >> > --20cf3074d8a42c08a704ce7bfc65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
thanks, minutes has been updated to ack this.
=A0
= Best,
=A0
-Hui

= 2012/11/14 Alexandru Petrescu <alexandru.petrescu@gmail.com= >
I agree.

Alex

Le 14/11/2012 15:31, Konstantinos Pentikousis a =E9crit :
Hi Hui,

Just a kind reminder that Alex (CCed) and I volunteered to assist the
draft authors with the rewriting of the use cases, should they proceed
with an update of draft-ietf-mif-dhcpv6-route-option-05. This is
currently not recorded in the minutes.

Best Regards,

Kostas

*From:*Hui Deng [mailto:denghui02@gmail.com]
*Sent:* Tuesday, November 13, 2012 7:00 PM
*To:* MIF Mailing List
*Subject:* [mif] IETF 85th MIF Minutes


Hello all

Thanks Stuart Cheshire and Peer Azmat Shah for taking the minutes, and
also Michael Richardson's help for jabber scribe.

Please feel free to let us know if there is any revision needed.

http://www.ietf.org/proceedings/85/minutes/minut= es-85-mif

Best,

-Hui



--20cf3074d8a42c08a704ce7bfc65-- From trac+mif@trac.tools.ietf.org Wed Nov 14 17:34:38 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6997321F844B for ; Wed, 14 Nov 2012 17:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGSEFCampM76 for ; Wed, 14 Nov 2012 17:34:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id BCE1721F8444 for ; Wed, 14 Nov 2012 17:34:37 -0800 (PST) Received: from localhost ([127.0.0.1]:48013 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYoLO-0006S8-Eq; Thu, 15 Nov 2012 02:34:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "mif issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 15 Nov 2012 01:34:14 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/24 Message-ID: <051.119f6a76a3e53a11b11e8950a667413d@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121115013437.BCE1721F8444@ietfa.amsl.com> Resent-Date: Wed, 14 Nov 2012 17:34:37 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #24: Officially document that this updates RFC 4862 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 01:34:38 -0000 #24: Officially document that this updates RFC 4862 This document obsoletes a chunk of text in section 5.5.2 and should therefore officially note that it updates RFC 4862. The section in question: http://tools.ietf.org/html/rfc4862#section-5.5.2 """ 5.5.2. Absence of Router Advertisements Even if a link has no routers, the DHCPv6 service to obtain addresses may still be available, and hosts may want to use the service. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [RFC4861]. Note that it is possible that there is no router on the link in this sense, but there is a node that has the ability to forward packets. In this case, the forwarding node's address must be manually configured in hosts to be able to send packets off-link, since the only mechanism to configure the default router's address automatically is the one using Router Advertisements. """ This is likely not an onerous edit. -- -------------------------+------------------------------------------------- Reporter: ek@… | Owner: draft-ietf-mif-dhcpv6-route- Type: defect | option@… Priority: blocker | Status: new Component: dhcpv6 | Milestone: -route-option | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: mif From trac+mif@trac.tools.ietf.org Thu Nov 15 15:34:07 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6754521F8856 for ; Thu, 15 Nov 2012 15:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8tJm0qRS5G7 for ; Thu, 15 Nov 2012 15:34:04 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECBF21F8855 for ; Thu, 15 Nov 2012 15:34:02 -0800 (PST) Received: from localhost ([127.0.0.1]:35268 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TZ8w4-0002k9-AW; Fri, 16 Nov 2012 00:33:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "mif issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com X-Trac-Project: mif Date: Thu, 15 Nov 2012 23:33:28 -0000 X-URL: http://tools.ietf.org/mif/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mif/trac/ticket/25 Message-ID: <051.4d985ba8b84efb9439103b8a750e564a@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-mif-dhcpv6-route-option@tools.ietf.org, ek@google.com, mif@ietf.org X-SA-Exim-Mail-From: trac+mif@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: arifumi@nttv6.net, sarikaya@ieee.org, suntao@chinamobile.com, tomasz.mrugalski@gmail.com, wdec@cisco.com Resent-Message-Id: <20121115233404.7ECBF21F8855@ietfa.amsl.com> Resent-Date: Thu, 15 Nov 2012 15:34:02 -0800 (PST) Resent-From: trac+mif@trac.tools.ietf.org Cc: mif@ietf.org Subject: [mif] #25: Should document that it updates RFC 6434 (node requirements) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:34:07 -0000 #25: Should document that it updates RFC 6434 (node requirements) Just found some more text that this document needs to note that it's updating. This time it's in the IPv6 Node Requirements doc: http://tools.ietf.org/html/rfc6434#section-7.2.2 """ 7.2.2. Use of Router Advertisements in Managed Environments Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are expected to determine their default router information and on- link prefix information from received Router Advertisements. """ This should not be an onerous edit either. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-mif-dhcpv6-route- ek@google.com | option@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: dhcpv6 | Version: -route-option | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: mif From brian.e.carpenter@gmail.com Fri Nov 16 01:10:34 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B670521F8466 for ; Fri, 16 Nov 2012 01:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.562 X-Spam-Level: X-Spam-Status: No, score=-101.562 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRsZ4ybYZqXc for ; Fri, 16 Nov 2012 01:10:34 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1480B21F8202 for ; Fri, 16 Nov 2012 01:10:33 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hm14so1424745wib.13 for ; Fri, 16 Nov 2012 01:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a37mVrt9OqTMgcOcml1Iz/sEJ4reZ4vyR7t0pA90am4=; b=UAoWUx9c1bi6RoIzui5VbGsbKZCbQgVQbLfezG0LKXk9eOtUxQ1MshJUPretw9nXuC 69MEm6Y7J0rn8crQfAWCUsFB/zrZy+6S/1dwCSc5vgsL0Ek25BOKutYw41hjym+ZuILF TTdtYeXZxO3oVKxo3/Bjudk0o0akCQ50h2+no3TeqiWa+p+Q2z3wgvp7NUb8amVBz2jZ IbO3QNkb0/qu+USvLqaZt45EypAuyZbQpPqHxQ94WyKZotLOSOIO/acROES1hkC8a0Ep MFTVhLHcT9B3GIYdUZDX8vVmDgGKU0b4xGPWqCPKR3LzrqaRX95gNwm3FCokdrC0h4h5 oxcg== Received: by 10.180.101.3 with SMTP id fc3mr3990161wib.16.1353057033168; Fri, 16 Nov 2012 01:10:33 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-111.as13285.net. [2.102.216.111]) by mx.google.com with ESMTPS id fa9sm1454416wib.5.2012.11.16.01.10.30 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 01:10:31 -0800 (PST) Message-ID: <50A60314.6020307@gmail.com> Date: Fri, 16 Nov 2012 09:10:44 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mif issue tracker References: <051.4d985ba8b84efb9439103b8a750e564a@trac.tools.ietf.org> In-Reply-To: <051.4d985ba8b84efb9439103b8a750e564a@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org, draft-ietf-mif-dhcpv6-route-option@tools.ietf.org Subject: Re: [mif] #25: Should document that it updates RFC 6434 (node requirements) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 09:10:34 -0000 On 15/11/2012 23:33, mif issue tracker wrote: > #25: Should document that it updates RFC 6434 (node requirements) > > Just found some more text that this document needs to note that it's > updating. This time it's in the IPv6 Node Requirements doc: Hmm. 6434 is Informational and is intentionally a snapshot. I'm not sure that formally updating it is appropriate. We didn't systematically update 4294 for each new IPv6 spec prior to 6434. Regards Brian > > http://tools.ietf.org/html/rfc6434#section-7.2.2 > > """ > 7.2.2. Use of Router Advertisements in Managed Environments > > Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > are expected to determine their default router information and on- > link prefix information from received Router Advertisements. > """ > > This should not be an onerous edit either. > From soohongp@gmail.com Fri Nov 16 18:39:34 2012 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531E021F8B06 for ; Fri, 16 Nov 2012 18:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJyutZ91QWcP for ; Fri, 16 Nov 2012 18:39:33 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA8321F8B2A for ; Fri, 16 Nov 2012 18:39:31 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1566041bku.31 for ; Fri, 16 Nov 2012 18:39:31 -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=dUDRwW8OnFY9BET+OGtCQr9nNXgKkAUvzfTk4AS3Trk=; b=Rl4geXBtgyngjRBEMafwqLmKQn/pjJfW+ciE+J6M8DND7HsRv51ByPHABeC4X7DgyU GPy0WLRp4BCc0gEWbhqDSq+IsmnCUSZRqPzCToRifwbcTTTMUutEpto1AXFg+xifSFzU siQ+fl2JT9O3MmdtFSuw9m9MG8YFg9H5wlYVBnVtnVc7n7HIYmauZvjegrk8AkH+U433 gbuDkSfs2skCawFR5sN+RjnPo3Q2C0cMe4sWfXbLWyx3Cc66Q8OSYaJ/hXuNGyLoyj4n 31MXNvttQGKvnu3hQAARRl9ojw1+AfI4kO2G1hb/JflegFfZKwMzNzJEq10S2Jw2qS13 u5GA== MIME-Version: 1.0 Received: by 10.205.120.134 with SMTP id fy6mr2710671bkc.18.1353119970953; Fri, 16 Nov 2012 18:39:30 -0800 (PST) Received: by 10.204.60.81 with HTTP; Fri, 16 Nov 2012 18:39:30 -0800 (PST) Date: Sat, 17 Nov 2012 11:39:30 +0900 Message-ID: From: Daniel Park To: m.ludden@sta.samsung.com, madamic@w3.org, mif@ietf.org, mk95.kim@samsung.com, mkoh@etri.re.kr Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 16 Nov 2012 20:05:38 -0800 Subject: [mif] (no subject) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 02:39:34 -0000 http://www.akpartisinop.com/wp-content/plugins/akismet/google235.html