From nobody Wed Jul 2 22:05:27 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F1F1A0ACA for ; Wed, 2 Jul 2014 22:05:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_DOUBLE_IP_LOOSE=1.012, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipE5UO6Hu_1R for ; Wed, 2 Jul 2014 22:05:25 -0700 (PDT) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with SMTP id 298B61A0ACB for ; Wed, 2 Jul 2014 22:05:23 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EMDG-ORIGINAL-FROM: X-EMDG-ORIGINAL-TO: X-EMDG-ORIGINAL-IP: 211.71.74.136 X-EMDG-VER: 4.1.0 Received: (eyou anti_spam gateway 4.1.0); Thu, 03 Jul 2014 12:58:37 +0800 Message-ID: <604363517.17831@bjtu.edu.cn> X-EMDG-SMTPAUTH: fsong@bjtu.edu.cn Received: from 211.71.74.136 by 218.249.29.198 with SMTP; Thu, 03 Jul 2014 12:58:37 +0800 Date: Thu, 3 Jul 2014 13:05:23 +0800 From: "Fei Song" To: mif References: <604109602.03243@bjtu.edu.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201407031305232862278@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/AcXHAeILUgqNMxXU0I4YZsH9dyQ Cc: mrw , denghui02 Subject: [mif] New draft about MIF API extension for combining IEEE 802.21 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 05:05:26 -0000 RGVhciBhbGyjug0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhYm91dCBNSUYgQVBJ IGV4dGVuc2lvbiBmb3IgY29tYmluaW5nIElFRUUgODAyLjIxLg0KaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC16aGFuZy1taWYtYXBpLWV4dGVuc2lvbi04MDItMjEtMDAudHh0DQpDb21tZW50 cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lLg0KVGhhbmsgeW91IHZlcnkg bXVjaKOhDQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KDQo+ From nobody Thu Jul 3 00:04:56 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4731A0AC8 for ; Wed, 2 Jul 2014 22:01:41 -0700 (PDT) X-Quarantine-ID: <9ZhkGTce61b0> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_DOUBLE_IP_LOOSE=1.012, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZhkGTce61b0 for ; Wed, 2 Jul 2014 22:01:39 -0700 (PDT) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with SMTP id 45C4B1A0AC5 for ; Wed, 2 Jul 2014 22:01:39 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EMDG-ORIGINAL-FROM: X-EMDG-ORIGINAL-TO: X-EMDG-ORIGINAL-IP: 211.71.74.136 X-EMDG-VER: 4.1.0 Received: (eyou anti_spam gateway 4.1.0); Thu, 03 Jul 2014 12:54:51 +0800 Message-ID: <604363291.17829@bjtu.edu.cn> X-EMDG-SMTPAUTH: fsong@bjtu.edu.cn Received: from 211.71.74.136 by 218.249.29.198 with SMTP; Thu, 03 Jul 2014 12:54:51 +0800 Date: Thu, 3 Jul 2014 13:01:37 +0800 From: "Fei Song" To: mif References: <604109602.03243@bjtu.edu.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201407031301374749007@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/lCBI3hu_6cxetDgby8aCT98k2kc X-Mailman-Approved-At: Thu, 03 Jul 2014 00:04:54 -0700 Cc: mrw , denghui02 Subject: [mif] New draft about MIF API extension for combining IEEE 802.21 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 05:01:41 -0000 RGVhciBhbGyjug0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhYm91dCBNSUYgQVBJ IGV4dGVuc2lvbiBmb3IgY29tYmluaW5nIElFRUUgODAyLjIxLg0KaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC16aGFuZy1taWYtYXBpLWV4dGVuc2lvbi04MDItMjEtMDAudHh0DQpDb21tZW50 cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lLg0KVGhhbmsgeW91IHZlcnkg bXVjaKOhDQoNCi0tLS0tLS0tLS0tLS0tDQpGZWkgU29uZw0KDQo+ From nobody Thu Jul 3 06:24:44 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC701B29A5 for ; Thu, 3 Jul 2014 06:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5woDvdt8wMJh for ; Thu, 3 Jul 2014 06:24:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE06E1B29AD for ; Thu, 3 Jul 2014 06:24:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C5306A2; Thu, 3 Jul 2014 15:24:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404393877; bh=wsq8cH5zckoR4Zm2E5/aH30r3r0w+kEcuwhJ9LlVWCg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CAqhQs/crD36JZ8hUY4aht60nxa6peYoSO/FJndeBLDuMJiNUV8OGDHmob6qpWRG0 3X3IXXoAIef2dAj3yeYejMhzaaOzaTNslp/TORflydNeK0YtjSGcpAPfyt+2L9OaDV NjVxRrCQY7Iq0oW8OgvmInj5sjOH8oT8PWvIZrgc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 77576A1; Thu, 3 Jul 2014 15:24:37 +0200 (CEST) Date: Thu, 3 Jul 2014 15:24:37 +0200 (CEST) From: Mikael Abrahamsson To: Fei Song In-Reply-To: <604363291.17829@bjtu.edu.cn> Message-ID: References: <604109602.03243@bjtu.edu.cn> <604363291.17829@bjtu.edu.cn> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1291639190-1404393856=:7929" Archived-At: http://mailarchive.ietf.org/arch/msg/mif/o-i9pkBNXLjSwA1mkAd41AV2mVE Cc: mrw , denghui02 , mif Subject: Re: [mif] New draft about MIF API extension for combining IEEE 802.21 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:24:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1291639190-1404393856=:7929 Content-Type: TEXT/PLAIN; CHARSET=ISO-2022-JP; FORMAT=flowed On Thu, 3 Jul 2014, Fei Song wrote: > Dear all： > > We have submitted a new draft about MIF API extension for combining IEEE 802.21. > http://www.ietf.org/id/draft-zhang-mif-api-extension-802-21-00.txt > Comments and suggestions are more than welcome. > Thank you very much！ I intended to read up on 802.21, but you need to be an IEEE member to access the linked document in the draft. I see the same private document referenced from http://tools.ietf.org/html/draft-zuniga-mif-802-21-overview-00#ref-IEEE802.21 Is there anything we can do about this? Referencing non-public documents is kind of meaningless to the general public. I at least can't say if your document makes sense because I have no way to get information to understand 802.21. http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-2/122_ieee.html seems to give some background, but it's not a complete document and not something that could be referred to in an RFC either. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1291639190-1404393856=:7929-- From nobody Thu Jul 3 17:55:02 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39531B2B94; Thu, 3 Jul 2014 17:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4vF64bYwjZR; Thu, 3 Jul 2014 17:54:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 891BC1B2B4F; Thu, 3 Jul 2014 17:54:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 17:54:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/3PPFfvPzYCbq3Q-1Af2sAhIh-ZE Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 00:54:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple Interfaces Working Group of the IETF. Title : Multiple Provisioning Domain Architecture Author : Dmitry Anipko Filename : draft-ietf-mif-mpvd-arch-02.txt Pages : 21 Date : 2014-07-03 Abstract: This document is a product of the work of MIF architecture design team. It outlines a solution framework for some of the issues, experienced by nodes that can be attached to multiple networks. The framework defines the notion of a Provisioning Domain (PVD) - a consistent set of network configuration information, and PVD-aware nodes - nodes which learn PVDs from the attached network(s) and/or other sources and manage and use multiple PVDs for connectivity separately and consistently. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 17:59:29 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B5B1B2BBC for ; Thu, 3 Jul 2014 17:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkfzS7exBemA for ; Thu, 3 Jul 2014 17:59:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CC91B2B8A for ; Thu, 3 Jul 2014 17:59:25 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.974.11; Fri, 4 Jul 2014 00:59:24 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.142]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.142]) with mapi id 15.00.0974.002; Fri, 4 Jul 2014 00:59:24 +0000 From: Dmitry Anipko To: "mif@ietf.org" Thread-Topic: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt Thread-Index: AQHPlyKst3VEhrSGHUmaLroMBGoy0JuPF1Pw Date: Fri, 4 Jul 2014 00:59:23 +0000 Message-ID: <1404435563313.15510@microsoft.com> References: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> In-Reply-To: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.132.138] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(377424004)(377454003)(189002)(87936001)(2656002)(83072002)(85852003)(36756003)(19580395003)(83322001)(19580405001)(15975445006)(92726001)(77096002)(76482001)(15202345003)(85306003)(106356001)(92566001)(86612001)(95666004)(80022001)(66066001)(64706001)(20776003)(99286002)(86362001)(79102001)(106116001)(74502001)(77982001)(31966008)(74662001)(105586002)(107886001)(107046002)(2351001)(54356999)(101416001)(50986999)(76176999)(99396002)(46102001)(81542001)(81342001)(21056001)(22906005); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/ekeDtP5_DHI6sfhQuFX5iDIHgVM Subject: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 00:59:28 -0000 The new revision addresses the comments made on the list, and has added exa= mples in the section 4. Thanks Zhen Cao, Ian Farrer and Dapeng Liu for thei= r contributions to the section 4.=0A= =0A= ________________________________________=0A= From: mif on behalf of internet-drafts@ietf.org =0A= Sent: Thursday, July 03, 2014 5:54 PM=0A= To: i-d-announce@ietf.org=0A= Cc: mif@ietf.org=0A= Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the Multiple Interfaces Working Group of the = IETF.=0A= =0A= Title : Multiple Provisioning Domain Architecture=0A= Author : Dmitry Anipko=0A= Filename : draft-ietf-mif-mpvd-arch-02.txt=0A= Pages : 21=0A= Date : 2014-07-03=0A= =0A= Abstract:=0A= This document is a product of the work of MIF architecture design=0A= team. It outlines a solution framework for some of the issues,=0A= experienced by nodes that can be attached to multiple networks. The=0A= framework defines the notion of a Provisioning Domain (PVD) - a=0A= consistent set of network configuration information, and PVD-aware=0A= nodes - nodes which learn PVDs from the attached network(s) and/or=0A= other sources and manage and use multiple PVDs for connectivity=0A= separately and consistently.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/=0A= =0A= There's also a htmlized version available at:=0A= http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02=0A= =0A= A diff from the previous version is available at:=0A= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-mpvd-arch-02=0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= _______________________________________________=0A= mif mailing list=0A= mif@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mif=0A= From nobody Thu Jul 3 19:01:06 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8471A045D for ; Thu, 3 Jul 2014 19:01:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_DOUBLE_IP_LOOSE=1.012, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4slqlI95vUZ for ; Thu, 3 Jul 2014 19:00:58 -0700 (PDT) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with SMTP id 453B01A0240 for ; Thu, 3 Jul 2014 19:00:58 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EMDG-ORIGINAL-FROM: X-EMDG-ORIGINAL-TO: X-EMDG-ORIGINAL-IP: 211.71.74.136 X-EMDG-VER: 4.1.0 Received: (eyou anti_spam gateway 4.1.0); Fri, 04 Jul 2014 09:54:09 +0800 Message-ID: <604438849.27963@bjtu.edu.cn> X-EMDG-SMTPAUTH: fsong@bjtu.edu.cn Received: from 211.71.74.136 by 218.249.29.198 with SMTP; Fri, 04 Jul 2014 09:54:09 +0800 Date: Fri, 4 Jul 2014 10:00:55 +0800 From: "Fei Song" To: "Mikael Abrahamsson" References: <604109602.03243@bjtu.edu.cn> <604363291.17829@bjtu.edu.cn>, <604393476.05609@bjtu.edu.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201407041000553868544@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/0BJldUKpv-lLI2z4Fci8iFAGE-Q Cc: mrw , denghui02 , mif Subject: Re: [mif] New draft about MIF API extension for combining IEEE 802.21 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 02:01:01 -0000 RGVhciBNaWthZWw6DQoNClRoYW5rcyBmb3IgeW91ciByZXBseS4NCklmIHlvdSBzZWFyY2ggIjgw Mi4yMSBwYXJ0IDIxIiBpbiBnb29nbGUuY29tIG9yIGJhaWR1LmNvbSwgeW91IHdvdWxkIGZpbmQg bWFueSBsaW5rcyBmb3Igdmlld2luZyB0aGUgcHJvdG9jb2xzIChjYW5ub3QgZG93bmxvYWQpLiBU aGUgSUVFRSBpcyBub3QgdGhlIG9ubHkgc291cmNlLg0KDQotLS0tLS0tLS0tLS0tLQ0KRmVpIFNv bmcNCj5PbiBUaHUsIDMgSnVsIDIwMTQsIEZlaSBTb25nIHdyb3RlOg0KPg0KPj4gRGVhciBhbGyj ug0KPj4NCj4+IFdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IE1JRiBBUEkgZXh0 ZW5zaW9uIGZvciBjb21iaW5pbmcgSUVFRSA4MDIuMjEuDQo+PiBodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LXpoYW5nLW1pZi1hcGktZXh0ZW5zaW9uLTgwMi0yMS0wMC50eHQNCj4+IENvbW1l bnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuDQo+PiBUaGFuayB5b3Ug dmVyeSBtdWNoo6ENCj4NCj5JIGludGVuZGVkIHRvIHJlYWQgdXAgb24gODAyLjIxLCBidXQgeW91 IG5lZWQgdG8gYmUgYW4gSUVFRSBtZW1iZXIgdG8gDQo+YWNjZXNzIHRoZSBsaW5rZWQgZG9jdW1l bnQgaW4gdGhlIGRyYWZ0LiBJIHNlZSB0aGUgc2FtZSBwcml2YXRlIGRvY3VtZW50IA0KPnJlZmVy ZW5jZWQgZnJvbSANCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16dW5pZ2EtbWlm LTgwMi0yMS1vdmVydmlldy0wMCNyZWYtSUVFRTgwMi4yMQ0KPg0KPklzIHRoZXJlIGFueXRoaW5n IHdlIGNhbiBkbyBhYm91dCB0aGlzPyBSZWZlcmVuY2luZyBub24tcHVibGljIGRvY3VtZW50cyAN Cj5pcyBraW5kIG9mIG1lYW5pbmdsZXNzIHRvIHRoZSBnZW5lcmFsIHB1YmxpYy4NCj4NCj5JIGF0 IGxlYXN0IGNhbid0IHNheSBpZiB5b3VyIGRvY3VtZW50IG1ha2VzIHNlbnNlIGJlY2F1c2UgSSBo YXZlIG5vIHdheSB0byANCj5nZXQgaW5mb3JtYXRpb24gdG8gdW5kZXJzdGFuZCA4MDIuMjEuIA0K Pmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9hYzEyMy9hYzE0Ny9hcmNoaXZlZF9pc3N1 ZXMvaXBqXzEyLTIvMTIyX2llZWUuaHRtbCANCj5zZWVtcyB0byBnaXZlIHNvbWUgYmFja2dyb3Vu ZCwgYnV0IGl0J3Mgbm90IGEgY29tcGxldGUgZG9jdW1lbnQgYW5kIG5vdCANCj5zb21ldGhpbmcg dGhhdCBjb3VsZCBiZSByZWZlcnJlZCB0byBpbiBhbiBSRkMgZWl0aGVyLg0KPg0KPi0tIA0KPk1p a2FlbCBBYnJhaGFtc3NvbiAgICBlbWFpbDogc3dtaWtlQHN3bS5wcC5zZQ== From nobody Thu Jul 3 21:45:07 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934C81B2BCB for ; Thu, 3 Jul 2014 21:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kODa7fRzjBku for ; Thu, 3 Jul 2014 21:45:03 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51671A04C8 for ; Thu, 3 Jul 2014 21:44:59 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s644ilFD025160; Fri, 4 Jul 2014 13:44:47 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s644il2M012210; Fri, 4 Jul 2014 13:44:47 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id PAA12209; Fri, 4 Jul 2014 13:44:47 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s644ilYF002008; Fri, 4 Jul 2014 13:44:47 +0900 (JST) Received: from tgxml050.toshiba.local by toshiba.co.jp id s644ileF018435; Fri, 4 Jul 2014 13:44:47 +0900 (JST) Received: from TGXML210.toshiba.local ([169.254.4.202]) by tgxml050.toshiba.local ([133.199.68.70]) with mapi id 14.03.0181.006; Fri, 4 Jul 2014 13:44:47 +0900 From: To: , Thread-Topic: [mif] New draft about MIF API extension for combining IEEE 802.21 Thread-Index: AQHPlsIqGzKD4JEyD0qE+Fh0JEfiRpuPVKjg Date: Fri, 4 Jul 2014 04:44:46 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B2724FFE3@TGXML210.toshiba.local> References: <604109602.03243@bjtu.edu.cn> <604363291.17829@bjtu.edu.cn> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.226] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/MlmhvzIjS76l4geG5zYXB7eJCrY Cc: mrw@lilacglade.org, mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] New draft about MIF API extension for combining IEEE 802.21 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 04:45:05 -0000 Anyone can get IEEE 802 specifications with no cost or membership after 6 m= onths passing from publication date from: http://standards.ieee.org/about/g= et/. Yoshihiro Ohba -----Original Message----- From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Thursday, July 3, 2014 10:25 PM To: Fei Song Cc: mrw; denghui02; mif Subject: Re: [mif] New draft about MIF API extension for combining IEEE 802= .21 On Thu, 3 Jul 2014, Fei Song wrote: > Dear all=1B$B!'=1B(B > > We have submitted a new draft about MIF API extension for combining IEEE = 802.21. > http://www.ietf.org/id/draft-zhang-mif-api-extension-802-21-00.txt > Comments and suggestions are more than welcome. > Thank you very much=1B$B!*=1B(B I intended to read up on 802.21, but you need to be an IEEE member to acces= s the linked document in the draft. I see the same private document referen= ced from http://tools.ietf.org/html/draft-zuniga-mif-802-21-overview-00#ref-IEEE802.= 21 Is there anything we can do about this? Referencing non-public documents is= kind of meaningless to the general public. I at least can't say if your document makes sense because I have no way to = get information to understand 802.21.=20 http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-2/122_iee= e.html seems to give some background, but it's not a complete document and not som= ething that could be referred to in an RFC either. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 3 23:13:56 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F681A033D for ; Thu, 3 Jul 2014 23:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSeO6MdQ86Wy for ; Thu, 3 Jul 2014 23:13:54 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E651A031C for ; Thu, 3 Jul 2014 23:13:54 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id i13so1237023veh.15 for ; Thu, 03 Jul 2014 23:13:53 -0700 (PDT) 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=k8CWumj4HoEO1pWSdlg0C6vKybr3pyuriLBexZ/EmRw=; b=sedPeNhTU+lOcj3oemSQz0BK/oS9yNs0lw+KJFQ61FLNdpDiLdehwtCFMgQ3KkJB+s ox3XM0sz3bsMdwL7Wwx9GinP8V8GpLfBRBACYD2VJe7rMoDOTP6d8gaMj0Ly+iWd0Gie VNwdwa6VQXGBASgljzMOJ5chqFmcKvIOSYKMI5M6qMg64s1DDuGVLfQxW9Ii6ry4zTdQ CYYqmVfnhV7TxL8KziuOIoHypz5GrS4hulijto/9OxBt2/I4v/GWonLu888tkBCVN4Qe i0CKGQmffC1V5+hN1MggQeyZ2grRgJSYI19R4WeJXU72rSimzspZQ7rbkUyJlmcIbtoN RPUw== MIME-Version: 1.0 X-Received: by 10.58.76.225 with SMTP id n1mr177368vew.32.1404454433273; Thu, 03 Jul 2014 23:13:53 -0700 (PDT) Received: by 10.220.252.132 with HTTP; Thu, 3 Jul 2014 23:13:53 -0700 (PDT) Date: Fri, 4 Jul 2014 14:13:53 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , Margaret Wasserman , Hui Deng Content-Type: multipart/alternative; boundary=047d7b3a7e6c993cd404fd58071b Archived-At: http://mailarchive.ietf.org/arch/msg/mif/WXchxUxdBpGM9H-XgQpcOv8YA00 Subject: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:13:55 -0000 --047d7b3a7e6c993cd404fd58071b Content-Type: text/plain; charset=UTF-8 Hello all We issue 2 weeks WGLC for the Architecture document, please kindly help to review and comment on the document. http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02 Best regards, -Co-chairs. --047d7b3a7e6c993cd404fd58071b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all

We issue 2 weeks WGLC for the= Architecture document, please kindly help to review and comment on the doc= ument.
http://tools.ietf.org/html/d= raft-ietf-mif-mpvd-arch-02

Best regards,

-Co-chairs.


<= /div> --047d7b3a7e6c993cd404fd58071b-- From nobody Thu Jul 3 23:27:45 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6620D1B2BF7 for ; Thu, 3 Jul 2014 23:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcVGTVNCQHZe for ; Thu, 3 Jul 2014 23:27:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616351B2BF4 for ; Thu, 3 Jul 2014 23:27:41 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F07C0A1; Fri, 4 Jul 2014 08:27:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404455258; bh=98dKR80i5vCYgFFbSz2Iq4YgcbuZgEF3+jZSs+Pjo9E=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eBWMKv6s6DkkvxprI6n7dFofF8Mz4TYtA6ni6aZ/jwxd1zjbawAILGvm85qWlUIxW vs1QSbycwmrErN8FD1siSOFUwCALuJEz4sA9wGqwK4Yc18oJML9aWxawCsafdyIvEj MYhsNMkF1Xt8DOpsij+nvR3f8ChOwHpn2xF/kx1U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E8C639F; Fri, 4 Jul 2014 08:27:38 +0200 (CEST) Date: Fri, 4 Jul 2014 08:27:38 +0200 (CEST) From: Mikael Abrahamsson To: yoshihiro.ohba@toshiba.co.jp In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B2724FFE3@TGXML210.toshiba.local> Message-ID: References: <604109602.03243@bjtu.edu.cn> <604363291.17829@bjtu.edu.cn> <674F70E5F2BE564CB06B6901FD3DD78B2724FFE3@TGXML210.toshiba.local> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/mif/5jsEpG2DKKZdTO46hn_EYf9ifj0 Cc: mrw@lilacglade.org, mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] New draft about MIF API extension for combining IEEE 802.21 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:27:43 -0000 On Fri, 4 Jul 2014, yoshihiro.ohba@toshiba.co.jp wrote: > Anyone can get IEEE 802 specifications with no cost or membership after 6 months passing from publication date from: http://standards.ieee.org/about/get/. Great, thanks, I have now downloaded it. Could we perhaps link to this page instead of to a username/password protected one, in the RFCs? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Jul 4 00:07:44 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009661B2C27 for ; Fri, 4 Jul 2014 00:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erbJsFpDAMZT for ; Fri, 4 Jul 2014 00:07:36 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035651B2C21 for ; Fri, 4 Jul 2014 00:07:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 69B08A1; Fri, 4 Jul 2014 09:07:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1404457654; bh=cOXAgpUVtIvVHR/tavka3rUbYyzUx5Qj20JSh0MlHOQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3SzWlukoSntIAavCHxBM0avPMG0GkNGyEe9+vQgp1Q93mQR/NMjnUOu2MK+l5bf5H ZYFs5tViUcauGYPBhPsx5vCgKkP7WcMkG+gGF6I/8P4iAbhQJysJ6a1Un5HgFwkae7 DOG59kr+pSGvs0bQR6UORVJgxy4+nVLCUkvmoYLM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6222E9F; Fri, 4 Jul 2014 09:07:34 +0200 (CEST) Date: Fri, 4 Jul 2014 09:07:34 +0200 (CEST) From: Mikael Abrahamsson To: Dmitry Anipko In-Reply-To: <1404435563313.15510@microsoft.com> Message-ID: References: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> <1404435563313.15510@microsoft.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/mif/5T4rR88FWCR9lwOHE5LnDBvAC9Y Cc: "mif@ietf.org" Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 07:07:38 -0000 On Fri, 4 Jul 2014, Dmitry Anipko wrote: > The new revision addresses the comments made on the list, and has added examples in the section 4. Thanks Zhen Cao, Ian Farrer and Dapeng Liu for their contributions to the section 4. Hi, I'm re-reading the document in its entirety, writing comments as I go along: 2.3. Does the current writing prohibit that multiple implicit PVDs are formed on a single interface, for instance if RAs are seen from two or more routers on the same link, each announcing non-overlapping address space and DNS resolvers? I would like to see a PVD being formed for each of these to also allow for source based routing to send packets / use each resolver depending on what source address based on these RAs are being used. 2.4. Nit: I would like to see some commas in the second sentence for easier understanding, for instance: "For implicit PVDs, the node assigns a locally generated, with a high probability of being globally unique, ID to each implicit PVD." 2.5 Nit grammar question (unsure): " For implicit PVDs, by default PVD-aware nodes shall including multiple IP families into single implicit PVD created for an interface." Shouldn't that be "shall include"? 3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unless the font/rendering combination in my browser is fooling my eyes). This is also in 3.4 and others. The entire document needs to be checked for this? 5.2.2 If an application chooses an explicit source address first, I would like to see the traffic sourced from that IP go out through the logical/physical interface that IP is associcated with. Example: You have a PVD that is associcated with your physical ethernet connection and a VPN tunnel that goes over your WiFi Internet connection. So the host has two PVDs, one "Internet", and one "Corporate", where the Corporate one has two interfaces, one physical and one logical. If packets are sourced using the VPN based IP address, I would like to see packets src/dst based routed to go out the VPN connection and not go directly to the Corporate physical connection. So this is *after* source address selection has been done. As far as I can tell, there is no text about this. 5.2.3 Nit: "Internet" is a name, thus capital I. It's "Internet" in 5.3. 5.2.4. Nit: "Togetheer" 5.4. I feel 5.4 needs more text, at minimum stating that even though it's a known non-perfect solution with connection managers, this problem is out of scope for this document. The current text seems to say there is a problem, and then... nothing. 10. Nit: there is a " , " (space before comma" in the middle of "tampering" section. Both of the last two sections seems to be lacking a ":" or a "." after the initial section identifier. "Rogue configuration source A compromised" for example. Apart from this I feel the document is in good shape and I support its publication. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Jul 4 03:37:41 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3A21B2CF0 for ; Fri, 4 Jul 2014 03:37:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_DOUBLE_IP_LOOSE=1.012, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKrNwnm_75Sh for ; Fri, 4 Jul 2014 03:37:35 -0700 (PDT) Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with SMTP id DA3011B2CE6 for ; Fri, 4 Jul 2014 03:37:32 -0700 (PDT) X-EYOU-SPAMVALUE: 0 X-EMDG-ORIGINAL-FROM: X-EMDG-ORIGINAL-TO: X-EMDG-ORIGINAL-IP: 211.71.74.136 X-EMDG-VER: 4.1.0 Received: (eyou anti_spam gateway 4.1.0); Fri, 04 Jul 2014 18:30:45 +0800 Message-ID: <604469845.24453@bjtu.edu.cn> X-EMDG-SMTPAUTH: fsong@bjtu.edu.cn Received: from 211.71.74.136 by 218.249.29.198 with SMTP; Fri, 04 Jul 2014 18:30:45 +0800 Date: Fri, 4 Jul 2014 18:37:31 +0800 From: "Fei Song" To: "Mikael Abrahamsson" , yoshihiro.ohba References: <604109602.03243@bjtu.edu.cn> <604363291.17829@bjtu.edu.cn> <674F70E5F2BE564CB06B6901FD3DD78B2724FFE3@TGXML210.toshiba.local>, <604454856.09192@bjtu.edu.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2014070418373158960514@bjtu.edu.cn> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/w6NXPJHg6pD3V8HX19s3-20kRyM Cc: mrw , mif , denghui02 Subject: Re: [mif] New draft about MIF API extension for combining IEEE 802.21 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fsong List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 10:37:36 -0000 SGkgYWxsOg0KDQoNCj5PbiBGcmksIDQgSnVsIDIwMTQsIHlvc2hpaGlyby5vaGJhQHRvc2hpYmEu Y28uanAgd3JvdGU6DQo+DQo+PiBBbnlvbmUgY2FuIGdldCBJRUVFIDgwMiBzcGVjaWZpY2F0aW9u cyB3aXRoIG5vIGNvc3Qgb3IgbWVtYmVyc2hpcCBhZnRlciA2IG1vbnRocyBwYXNzaW5nIGZyb20g cHVibGljYXRpb24gZGF0ZSBmcm9tOiBodHRwOi8vc3RhbmRhcmRzLmllZWUub3JnL2Fib3V0L2dl dC8uDQo+DQo+R3JlYXQsIHRoYW5rcywgSSBoYXZlIG5vdyBkb3dubG9hZGVkIGl0LiBDb3VsZCB3 ZSBwZXJoYXBzIGxpbmsgdG8gdGhpcyANCj5wYWdlIGluc3RlYWQgb2YgdG8gYSB1c2VybmFtZS9w YXNzd29yZCBwcm90ZWN0ZWQgb25lLCBpbiB0aGUgUkZDcz8NCg0KSSB0aGluayBpdCdzIHJlYWxs eSBhIGdvb2Qgc3VnZ2VzdGlvbi4gV2Ugd2lsbCBkbyB0aGF0IGluIG5leHQgdmVyc2lvbi4gVGhh bmtzIQ0KDQo+DQo+LS0gDQo+TWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dt LnBwLnNlDQoNCkZlaSBTb25n From nobody Mon Jul 7 15:34:53 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6221B28BC for ; Mon, 7 Jul 2014 15:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHE6DXXZar-c for ; Mon, 7 Jul 2014 15:34:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142FC1A0AAD for ; Mon, 7 Jul 2014 15:34:49 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 7 Jul 2014 22:34:47 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.142]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.142]) with mapi id 15.00.0974.002; Mon, 7 Jul 2014 22:34:47 +0000 From: Dmitry Anipko To: Mikael Abrahamsson Thread-Topic: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt Thread-Index: AQHPl1akiL51pqotJEiOWx+mtw+rSpuVJsqQ Date: Mon, 7 Jul 2014 22:34:46 +0000 Message-ID: <3ea0c51c57224263a806916c9821f9d8@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> <1404435563313.15510@microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(252514010)(13464003)(377454003)(24454002)(199002)(189002)(99396002)(19580405001)(105586002)(85306003)(19580395003)(106356001)(110136001)(76176999)(107046002)(4396001)(99286002)(33646001)(74662001)(95666004)(50986999)(83322001)(31966008)(54356999)(106116001)(79102001)(86612001)(76576001)(92566001)(86362001)(74316001)(101416001)(87936001)(77096002)(74502001)(80022001)(2656002)(81342001)(76482001)(64706001)(21056001)(85852003)(46102001)(83072002)(81542001)(20776003)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/W_sWrHbPQq4JsvF-T8JoPTtMpkw Cc: "mif@ietf.org" Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:34:52 -0000 Hello Mikael, Thank you for reading the draft and providing feedback. >>2.3. Does the current writing prohibit that multiple implicit PVDs are fo= rmed on a single interface, for instance if RAs are seen from two or more r= outers on the same link, each announcing non-overlapping address space and = DNS resolvers? I would like to see a PVD being formed for each of these to = also allow for source based routing to send packets / use each resolver dep= ending on what source address based on these RAs are being used. IIRC the WG discussed this question on a couple of occasions, and my unders= tanding of consensus is: while there is no intent to prohibit multiple impl= icit PvDs on an interface, there is no clear way how to enable the implicit= PvDs with finer granularity either. The text was supposed to reflect such = position by saying "By default, implicit PVDs are limited... If additional = information is available to the host through mechanisms out of scope of thi= s document, the host may form implicit PVDs with different granularity". D= o you think this needs more elaboration in the text? (such as e.g. includin= g your example into that section; this may open questions though such as e.= g., how to make sure that IPv6 & IPv4 from the same router do not end up in= different PvDs) >>2.4. Nit: I would like to see some commas in the second sentence for easi= er understanding, for instance: >>"For implicit PVDs, the node assigns a locally generated, with a high pro= bability of being globally unique, ID to each implicit PVD." Will do. >>2.5 Nit grammar question (unsure): >>" For implicit PVDs, by default PVD-aware nodes shall including multiple= IP families into single implicit PVD created for an interface." >> Shouldn't that be "shall include"? You're correct, will change. >>3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unles= s the font/rendering combination in my browser is fooling my eyes). This is= also in 3.4 and others. The entire document needs to be checked for this? Will change to PvD across the doc (since V doesn't map to a separate word). >>5.2.2 If an application chooses an explicit source address first, I would= like to see the traffic sourced from that IP go out through the logical/ph= ysical interface that IP is associcated with. Example: >>You have a PVD that is associcated with your physical ethernet connection= and a VPN tunnel that goes over your WiFi Internet connection. So the host= has two PVDs, one "Internet", and one "Corporate", where the Corporate one= has two interfaces, one >>physical and one logical. If packets are sourced= using the VPN based IP address, I would like to see packets src/dst based = routed to go out the VPN connection and not go directly to the Corporate ph= ysical connection. So this is *after* source address >>selection has been d= one. As far as I can tell, there is no text about this. I'll add text, that if the application has explicitly specified a source ad= dress, then for the subsequent operations on the specified API object, a ma= tching PvD should be used, provided that use of that PvD by that applicatio= n is allowed by the host configuration. >>5.2.3 Nit: "Internet" is a name, thus capital I. It's "Internet" in 5.3. >>5.2.4. Nit: "Togetheer" Will change. >>5.4. I feel 5.4 needs more text, at minimum stating that even though it's= a known non-perfect solution with connection managers, this problem is out= of scope for this document. The current text seems to say there is a probl= em, and then... nothing. My understanding is that the text starting with "Although connection manage= rs solve some connectivity problems, they rarely address the network selec= tion problems.." was a reflection on that, with implication that the presen= t draft shall improve the situation by providing to the hosts tools and gui= dance to make better network selection decisions. Will it address your comm= ent if I add such sentence explicitly?=20 >>10. Nit: there is a " , " (space before comma" in the middle of "tamperin= g" section. Both of the last two sections seems to be lacking a ":" or a ".= " after the initial section identifier. "Rogue configuration source A compr= omised" for example. Will add ":"s and fix the other thing. -Dmitry -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Friday, July 4, 2014 12:08 AM To: Dmitry Anipko Cc: mif@ietf.org Subject: Re: [mif] FW: I-D Action: draft-ietf-mif-mpvd-arch-02.txt On Fri, 4 Jul 2014, Dmitry Anipko wrote: > The new revision addresses the comments made on the list, and has added e= xamples in the section 4. Thanks Zhen Cao, Ian Farrer and Dapeng Liu for th= eir contributions to the section 4. Hi, I'm re-reading the document in its entirety, writing comments as I go along: 2.3. Does the current writing prohibit that multiple implicit PVDs are form= ed on a single interface, for instance if RAs are seen from two or more rou= ters on the same link, each announcing non-overlapping address space and DN= S resolvers? I would like to see a PVD being formed for each of these to al= so allow for source based routing to send packets / use each resolver depen= ding on what source address based on these RAs are being used. 2.4. Nit: I would like to see some commas in the second sentence for easier= understanding, for instance: "For implicit PVDs, the node assigns a locally generated, with a high proba= bility of being globally unique, ID to each implicit PVD." 2.5 Nit grammar question (unsure): " For implicit PVDs, by default PVD-aware nodes shall including multiple I= P families into single implicit PVD created for an interface." Shouldn't that be "shall include"? 3.3 Nit: Up to this, PVDs have been all caps, now there is a "PvD" (unless = the font/rendering combination in my browser is fooling my eyes). This is a= lso in 3.4 and others. The entire document needs to be checked for this? 5.2.2 If an application chooses an explicit source address first, I would l= ike to see the traffic sourced from that IP go out through the logical/phys= ical interface that IP is associcated with. Example: You have a PVD that is associcated with your physical ethernet connection a= nd a VPN tunnel that goes over your WiFi Internet connection. So the host h= as two PVDs, one "Internet", and one "Corporate", where the Corporate one h= as two interfaces, one physical and one logical. If packets are sourced usi= ng the VPN based IP address, I would like to see packets src/dst based rout= ed to go out the VPN connection and not go directly to the Corporate physic= al connection. So this is *after* source address selection has been done. A= s far as I can tell, there is no text about this. 5.2.3 Nit: "Internet" is a name, thus capital I. It's "Internet" in 5.3. 5.2.4. Nit: "Togetheer" 5.4. I feel 5.4 needs more text, at minimum stating that even though it's a= known non-perfect solution with connection managers, this problem is out o= f scope for this document. The current text seems to say there is a problem= , and then... nothing. 10. Nit: there is a " , " (space before comma" in the middle of "tampering"= section. Both of the last two sections seems to be lacking a ":" or a "." = after the initial section identifier. "Rogue configuration source A comprom= ised" for example. Apart from this I feel the document is in good shape and I support its publ= ication. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Jul 15 02:42:36 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7114D1A0379 for ; Tue, 15 Jul 2014 02:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e91HdemfsGGA for ; Tue, 15 Jul 2014 02:42:30 -0700 (PDT) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFBF1A0880 for ; Tue, 15 Jul 2014 02:42:27 -0700 (PDT) Received: from poro.lan (84.248.80.109) by jenni1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 53A17E3E020CBB73; Tue, 15 Jul 2014 12:42:23 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 ¥(1878.6¥)) From: Markus Stenberg In-Reply-To: <3ea0c51c57224263a806916c9821f9d8@SN2PR03MB077.namprd03.prod.outlook.com> Date: Tue, 15 Jul 2014 12:42:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81AEBE4D-7C62-4D87-879D-36662459FC9C@iki.fi> References: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> <1404435563313.15510@microsoft.com> <3ea0c51c57224263a806916c9821f9d8@SN2PR03MB077.namprd03.prod.outlook.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mif/zhUL4vQeqKcaEri5eJeqWx-PYUU Cc: Markus Stenberg , "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 09:42:32 -0000 .. back from my vacation, also rereading from scratch. On 8.7.2014, at 1.34, Dmitry Anipko wrote: >>> 2.3. Does the current writing prohibit that multiple implicit PVDs = are formed on a single interface, for instance if RAs are seen from two = or more routers on the same link, each announcing non-overlapping = address space and DNS resolvers? I would like to see a PVD being formed = for each of these to also allow for source based routing to send packets = / use each resolver depending on what source address based on these RAs = are being used. > IIRC the WG discussed this question on a couple of occasions, and my = understanding of consensus is: while there is no intent to prohibit = multiple implicit PvDs on an interface, there is no clear way how to = enable the implicit PvDs with finer granularity either. The text was = supposed to reflect such position by saying "By default, implicit PVDs = are limited... If additional information is available to the host = through mechanisms out of scope of this document, the host may form = implicit PVDs with different granularity". Do you think this needs more = elaboration in the text? (such as e.g. including your example into that = section; this may open questions though such as e.g., how to make sure = that IPv6 & IPv4 from the same router do not end up in different PvDs) Comments: 2.1/=85/5.2.3.1:=20 Is this meant to be IPv6-only? Because most typical hosts allow only one = IPv4 address per interface, and that leads to NATs and all sorts of fun = stuff. 2.5 refers to dual stack, and there=92s references to IPv4, but = e.g. 5.2.3.1 example using the address as determinant of PvD sounds bit = stretched unless you really can provision multiple IP addresses for v4 = too. How is this supposed to work with IPv4, and say, 2 ISPs and one VPN = connection? (I can guess, but document doesn=92t really say.) Diagram: Host=20 | Router - ISP1 | ISP2 2.2/2.3: I=92m still not happy with mixed mode definition in 2.2 - it explicitly = _does_ limit to one implicit PvD per link. What=92s wrong with IPv4/IPv6 = PvDs being distinct in any case? Given good multi-PvD support, what=92s = the problem? Same thing with 2.3 too - why not have implicits be next = hop based by default? (Similarly in 2.5 - it seems to confuse interface and next hop :-p) 2.4: Does the explicit PvD ID have to be really globally unique or just low = chance of collision (like ULA or the implicit PvD)? Constructing one = that is globally unique _and_ human readable may be tricky. Is there = some construction here that (for average human) is human readable and = guaranteed to be globally unique? FQDN or AS# or something derived from = prefix do not really count here I think. And some combination of = $MEGACORP and $SERVICE is not guaranteed to be unique either. The point I=92m trying to make is that e.g. =92LameISP SlowSpeed=92 is = human readable, but has just =92some=92 global uniqueness guarantee. = slowspeed.lamepsi.example.com can be made globally unique, but at = expense of readability. 7.1:=20 Not really serious comment as such, but I think there=92s some = heartwarming trust here towards ISP that actually uses =92trust=92 = mechanism with a customer not to do evil things ;-) My nits: 2.3: s/one interfaces/one interface/ 3.3: [refs to X and Y] 4: the section title is bit misleading I think - I=92d just remove =91and = number of PVDs=92 4.1/4.2: =91- one=92 - I=92d just remove the -, or better yet, rework = out the parentheses too.. Cheers, -Markus From nobody Thu Jul 17 06:59:06 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B41A0659 for ; Thu, 17 Jul 2014 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXEhVUNO1j8u for ; Thu, 17 Jul 2014 06:59:03 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317A41A0649 for ; Thu, 17 Jul 2014 06:59:03 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so1909645qga.8 for ; Thu, 17 Jul 2014 06:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EUdOTUdNTxG691lcY+PjgtCdFOT/1oLFequ4vFqwS8M=; b=EL3uXkLEuHSFDpQKHIvOT/x9re+ryHEOggCgExoG1BRHNf0PRPDC3eBBrtYZDjv+vx 6OLGRZi/4dVrb/CeRrLJN/wkjAndU//oSu5+YALL0p3ZDtFz+DoplThEVjnFHtZEs0Rc sSUDCye5vX8Bftbw6Y1m3VIeacnf2meC8JipSt6c6RNxAt0ZLXafMdGd0SOYwqHGTgtl 3j6lXzXwQZvmzsCe2SIWskTmSYun/bmiEMyvxv0wmVzzuFiI8MkHyYSa9emp9Qp4pztH wd6c3yGKVNYKmWttO+Qe3aClhR4+Bw0lJXMYRFVq9f3BT5Bt10LGvA20F5guir19BERN dBWA== MIME-Version: 1.0 X-Received: by 10.224.166.138 with SMTP id m10mr58323447qay.69.1405605542431; Thu, 17 Jul 2014 06:59:02 -0700 (PDT) Received: by 10.96.66.232 with HTTP; Thu, 17 Jul 2014 06:59:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Jul 2014 21:59:02 +0800 Message-ID: From: Zhen Cao To: Hui Deng Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/0K0UC7LodfKi37HjiEFv1HfKoNY Cc: Margaret Wasserman , MIF Mailing List , Hui Deng Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 13:59:05 -0000 Hi Everyone, Supportive of moving forward the document, and this is an important architecture work. Two more cents for consideration: - Do we or Does the working group need any next step /gap analysis in this document? Although the document is theoretically abundant, I do not see much engineering implications though. - @Co-chairs, This is a design team work, do we need to list the all contributors as well? Many thanks, zhen Chinamobile On Fri, Jul 4, 2014 at 2:13 PM, Hui Deng wrote: > Hello all > > We issue 2 weeks WGLC for the Architecture document, please kindly help to > review and comment on the document. > http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02 > > Best regards, > > -Co-chairs. > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Thu Jul 17 07:57:48 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7624F1A015D for ; Thu, 17 Jul 2014 07:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwIq-GUNvtj3 for ; Thu, 17 Jul 2014 07:57:43 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1011B278D for ; Thu, 17 Jul 2014 07:57:41 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so3513581pab.15 for ; Thu, 17 Jul 2014 07:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=ba+8vRPtMLOQ6jsQu263ksReW6hz0Qnx70lNkZu9QF4=; b=hub50lf0PF+bI5PFidQLKkP5Qf/pBFzx4J+jB3dFeajYGtpoFxUrMN+K5ZOetpWzPA PqxcnWxfyGjuK8Anh9fy4WZH4z5AVmXJnZC0souNWKDopZbLCenYaO3F+Jkmr+vsvyUD iT65FfC922nRr53jCZkw4X4SITGL9my148TYFNKPFllJ7YBTZQD/Oobmw+VbA14Ai6FJ GB9tPExVsVTwjyaMp0w586qC/g2jGw/W9vyi+gCEF1AnE+52lGa7a+do3jD9c+FG3O9Q CtiTta6ZYHwoLo1VOBXfCf7lKlEabuY4i12Or8MPlujGsWnr+rUI47SZt6moNa4ioX4X jZtQ== X-Received: by 10.66.230.163 with SMTP id sz3mr3367183pac.136.1405609060474; Thu, 17 Jul 2014 07:57:40 -0700 (PDT) Received: from [192.168.199.198] ([117.79.232.216]) by mx.google.com with ESMTPSA id fb7sm3656771pdb.68.2014.07.17.07.57.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 17 Jul 2014 07:57:39 -0700 (PDT) Date: Thu, 17 Jul 2014 22:57:37 +0800 From: Dapeng Liu To: Hui Deng Message-ID: In-Reply-To: References: X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="53c7e461_2a487cb0_632" Archived-At: http://mailarchive.ietf.org/arch/msg/mif/bp8NXE_Q2VSR60LyHQMcvjSVIsM Cc: Margaret Wasserman , MIF Mailing List , Hui Deng Subject: [mif] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 14:57:45 -0000 --53c7e461_2a487cb0_632 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, =20 I support moving forward of this document. One comment: In Section 6 (http://tools.ietf.org/html/draft-ietf-mif-mpvd= -arch-02=23section-6). PVD support in APIs: Should we add MI=46 API document as reference=3F =20 -- =20 Dapeng Liu =E5=9C=A8 2014=E5=B9=B47=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94=EF= =BC=8C14:13=EF=BC=8CHui Deng =E5=86=99=E9=81=93=EF=BC=9A > Hello all > =20 > We issue 2 weeks WGLC for the Architecture document, please kindly help= to review and comment on the document. > http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02 =20 > =20 > Best regards, > =20 > -Co-chairs. > =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > mif mailing list > mif=40ietf.org (mailto:mif=40ietf.org) > https://www.ietf.org/mailman/listinfo/mif > =20 > =20 --53c7e461_2a487cb0_632 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello all,

I support moving forward of thi= s document.

One comment: In Section 6. PVD support in APIs:

<= span style=3D=22font-size: 1em; line-height: 0pt; white-space: pre;=22>
Should we add MI=46 API document as reference=3F

-- 
Dapeng Liu

=20

=E5=9C=A8 2014=E5=B9=B4= 7=E6=9C=884=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94=EF=BC=8C14:13=EF=BC=8CHu= i Deng =E5=86=99=E9=81=93=EF=BC=9A

Hello all
We issue 2 weeks WGLC for the Architecture document, please = kindly help to review and comment on the document.

Best regards,

-Co-chairs.


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
mif mailing list
=20 =20 =20 =20
=20

--53c7e461_2a487cb0_632-- From nobody Thu Jul 17 08:08:19 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19C1B278D for ; Thu, 17 Jul 2014 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlhmYPLJWCZb for ; Thu, 17 Jul 2014 08:08:16 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5271B27C1 for ; Thu, 17 Jul 2014 08:08:00 -0700 (PDT) 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 EAC4B1B84A0 for ; Thu, 17 Jul 2014 08:07:58 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5EADC190068; Thu, 17 Jul 2014 08:07:58 -0700 (PDT) Received: from vpna-196.vpn.nominum.com (64.89.227.196) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Jul 2014 08:07:58 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 ¥(1878.6¥)) From: Ted Lemon In-Reply-To: Date: Thu, 17 Jul 2014 11:07:17 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Dapeng Liu X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.227.196] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/2u47vPyVVr2PTD_MoAzzArBDgRs Cc: MIF Mailing List , Margaret Wasserman , Hui Deng Subject: Re: [mif] =?utf-8?b?5Zue5aSN77yaICBXR0xDIGZvciBkcmFmdC1pZXRmLW1pZi1t?= =?utf-8?q?pvd-arch-02?= X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:08:17 -0000 On Jul 17, 2014, at 10:57 AM, Dapeng Liu wrote: > Should we add MIF API document as reference? That would mean that the MPVD doc would be blocked until the API doc was = done, or else that we'd have an informative reference to a draft. From nobody Sun Jul 20 03:28:34 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD871B2B93 for ; Sun, 20 Jul 2014 03:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3-7JBxTTOCQ for ; Sun, 20 Jul 2014 03:28:30 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FA91A03BE for ; Sun, 20 Jul 2014 03:28:30 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hu12so10490576vcb.28 for ; Sun, 20 Jul 2014 03:28:29 -0700 (PDT) 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=HBbZrUydwPdZVxq323Ye+Lo1ZPcemr9hNIUyGn72vik=; b=OtLelq+Z2kTgjysgrRBYNgnR4xoo7KPlM7PeQ9uTV9G7nk5HNyJaGBGucNYMG6I6uj aws7hlEArVA63DuGKpgbTZMqb7B8hGjdve1va7WSuvGxBdcWEAOqZRqK0s28J9KkOrd6 PhTEdrpi2a2Yh+xPZ6bia0tjQl4oacSPBxK/BS9dEWqk0bbOJThz+FBRGYHQ15VUOX3o AlCAexCzrYdOJ1s4SGR2DBeEwFaVx0ZOpi0yZYvVSu0WEThK6E/9PsajBseQW3x4pE6r vfFK80L9NGN1qJb/pm7Je/mXhGnmlrFU7lSHJe84/UN+DjwLknvDT5aydfWskDSjeJLa Ernw== MIME-Version: 1.0 X-Received: by 10.53.1.231 with SMTP id bj7mr16620760vdd.49.1405852109763; Sun, 20 Jul 2014 03:28:29 -0700 (PDT) Received: by 10.220.252.132 with HTTP; Sun, 20 Jul 2014 03:28:29 -0700 (PDT) Date: Sun, 20 Jul 2014 18:28:29 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=001a1133ed3a9bfc8b04fe9d7369 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/J8Om10_MDSEt6ajdUowfYuqmcgs Subject: [mif] Agenda request X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 10:28:31 -0000 --001a1133ed3a9bfc8b04fe9d7369 Content-Type: text/plain; charset=UTF-8 Hello all If you would like to request a time slot, please send email to chairs asap. Best regards, -Hui --001a1133ed3a9bfc8b04fe9d7369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all
=C2=A0
If you would lik= e to request a time slot, please send email to chairs asap.
=C2= =A0
Best regards,
=C2=A0
-Hui
--001a1133ed3a9bfc8b04fe9d7369-- From nobody Mon Jul 21 18:35:36 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1F41A028A for ; Mon, 21 Jul 2014 18:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90giatToiAiJ for ; Mon, 21 Jul 2014 18:35:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325C81A0154 for ; Mon, 21 Jul 2014 18:35:30 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) with Microsoft SMTP Server (TLS) id 15.0.995.11; Tue, 22 Jul 2014 01:35:27 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.92]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.92]) with mapi id 15.00.0995.011; Tue, 22 Jul 2014 01:35:27 +0000 From: Dmitry Anipko To: Markus Stenberg Thread-Topic: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt Thread-Index: AQHPoBEWIOtJ4GGw3EiNv/wLZv79mZurSf3A Date: Tue, 22 Jul 2014 01:35:26 +0000 Message-ID: <4b4ace2e01184131bd355c46ecc7b56f@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> <1404435563313.15510@microsoft.com> <3ea0c51c57224263a806916c9821f9d8@SN2PR03MB077.namprd03.prod.outlook.com> <81AEBE4D-7C62-4D87-879D-36662459FC9C@iki.fi> In-Reply-To: <81AEBE4D-7C62-4D87-879D-36662459FC9C@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.23] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(377454003)(52044002)(199002)(13464003)(189002)(83322001)(110136001)(81542001)(74662001)(87936001)(4396001)(95666004)(19580395003)(54356999)(64706001)(81342001)(99286002)(92566001)(105586002)(86612001)(21056001)(50986999)(19580405001)(74502001)(83072002)(85852003)(76176999)(86362001)(2656002)(85306003)(107046002)(33646002)(561944003)(66066001)(20776003)(106356001)(74316001)(77096002)(101416001)(80022001)(79102001)(93886003)(76482001)(106116001)(76576001)(77982001)(99396002)(31966008)(46102001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB077; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/flvdcbfta2U71dzUkcilu1VnNGs Cc: "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 01:35:34 -0000 Hello Markus, Thank you for the comments. >> Is this meant to be IPv6-only? Because most typical hosts allow only one= IPv4 address per interface, and that leads to NATs and all sorts of fun st= uff. 2.5 refers to dual stack, and there's references to IPv4, but e.g. 5.2= .3.1 example using the address as determinant of PvD sounds bit stretched u= nless you really can provision multiple IP addresses for v4 too. Host=20 | Router - ISP1 | ISP2 >> How is this supposed to work with IPv4, and say, 2 ISPs and one VPN conn= ection? (I can guess, but document doesn't really say.) [danipko] I think the text was written with the assumption in mind that dif= ferent PvDs can provide different addresses, which should be the case in IP= v6, and in some topologies with IPv4. If you have a proposal that works fo= r the topology you described, where presumably the Router performs address = assignment (and does NATing?), please feel free to describe it.=20 >> I'm still not happy with mixed mode definition in 2.2 - it explicitly _d= oes_ limit to one implicit PvD per link. [danipko] I will change the text to further clarify that multiple implicit = are allowed. >> What's wrong with IPv4/IPv6 PvDs being distinct in any case? Given good = multi-PvD support, what's the problem? [danipko] My understanding is that in order for things like DHCPv6 prefix p= olicy option to work, the respective IPv4 and IPv6 connectivity need to be = considered within a context of the single PvD. Having IPv4 and IPv6 from th= e same administrator to be in different PvDs seems to increase complexity, = and e.g. break the scenario with the prefix policy, while the benefits of p= utting in different PvDs are unclear. Can you elaborate on why you think th= e default of putting IPv4 and IPv6 into separate implicit ones makes more s= ense than into single implicit one? >> Does the explicit PvD ID have to be really globally unique or just low c= hance of collision (like ULA or the implicit PvD)? [danipko] IIRC there was a discussion in London on this question, but I do= n't believe there was any better proposal for the arch doc compared to the = current wording. My 2 cents is that I would not object to change the curren= t wording to something like "or otherwise, an ID with high probability of b= eing unique", if that has consensus. For those types of PvD IDs (to be defi= ned in a separate design doc), where the ID is tied to e.g. DNS suffix and = a cert, global uniqueness would be assured through those means (an attacker= can try to fake the ID, but it won't be trusted, and hence the PvD may be = ignored by the host). >> 2.3: s/one interfaces/one interface/ 3.3: [refs to X and Y] 4: the section title is bit misleading I think - I'd just remove 'and numbe= r of PVDs' 4.1/4.2: '- one' - I'd just remove the -, or better yet, rework out the par= entheses too.. [danipko] OK. -Dmitry -----Original Message----- From: Markus Stenberg [mailto:markus.stenberg@iki.fi]=20 Sent: Tuesday, July 15, 2014 2:42 AM To: Dmitry Anipko Cc: Markus Stenberg; Mikael Abrahamsson; mif@ietf.org Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt .. back from my vacation, also rereading from scratch. On 8.7.2014, at 1.34, Dmitry Anipko wrote: >>> 2.3. Does the current writing prohibit that multiple implicit PVDs are = formed on a single interface, for instance if RAs are seen from two or more= routers on the same link, each announcing non-overlapping address space an= d DNS resolvers? I would like to see a PVD being formed for each of these t= o also allow for source based routing to send packets / use each resolver d= epending on what source address based on these RAs are being used. > IIRC the WG discussed this question on a couple of occasions, and my unde= rstanding of consensus is: while there is no intent to prohibit multiple im= plicit PvDs on an interface, there is no clear way how to enable the implic= it PvDs with finer granularity either. The text was supposed to reflect suc= h position by saying "By default, implicit PVDs are limited... If additiona= l information is available to the host through mechanisms out of scope of t= his document, the host may form implicit PVDs with different granularity". = Do you think this needs more elaboration in the text? (such as e.g. includ= ing your example into that section; this may open questions though such as = e.g., how to make sure that IPv6 & IPv4 from the same router do not end up = in different PvDs) Comments: 2.1/.../5.2.3.1:=20 Is this meant to be IPv6-only? Because most typical hosts allow only one IP= v4 address per interface, and that leads to NATs and all sorts of fun stuff= . 2.5 refers to dual stack, and there's references to IPv4, but e.g. 5.2.3.= 1 example using the address as determinant of PvD sounds bit stretched unle= ss you really can provision multiple IP addresses for v4 too. How is this supposed to work with IPv4, and say, 2 ISPs and one VPN connect= ion? (I can guess, but document doesn't really say.) Diagram: Host=20 | Router - ISP1 | ISP2 2.2/2.3: I'm still not happy with mixed mode definition in 2.2 - it explicitly _does= _ limit to one implicit PvD per link. What's wrong with IPv4/IPv6 PvDs bein= g distinct in any case? Given good multi-PvD support, what's the problem? S= ame thing with 2.3 too - why not have implicits be next hop based by defaul= t? (Similarly in 2.5 - it seems to confuse interface and next hop :-p) 2.4: Does the explicit PvD ID have to be really globally unique or just low chan= ce of collision (like ULA or the implicit PvD)? Constructing one that is gl= obally unique _and_ human readable may be tricky. Is there some constructio= n here that (for average human) is human readable and guaranteed to be glob= ally unique? FQDN or AS# or something derived from prefix do not really cou= nt here I think. And some combination of $MEGACORP and $SERVICE is not guar= anteed to be unique either. The point I'm trying to make is that e.g. 'LameISP SlowSpeed' is human read= able, but has just 'some' global uniqueness guarantee. slowspeed.lamepsi.ex= ample.com can be made globally unique, but at expense of readability. 7.1:=20 Not really serious comment as such, but I think there's some heartwarming t= rust here towards ISP that actually uses 'trust' mechanism with a customer = not to do evil things ;-) My nits: 2.3: s/one interfaces/one interface/ 3.3: [refs to X and Y] 4: the section title is bit misleading I think - I'd just remove 'and numbe= r of PVDs' 4.1/4.2: '- one' - I'd just remove the -, or better yet, rework out the par= entheses too.. Cheers, -Markus From nobody Wed Jul 23 08:17:35 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18D1B28A3; Wed, 23 Jul 2014 08:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnzZFSnc68Np; Wed, 23 Jul 2014 08:17:31 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4EE1B2837; Wed, 23 Jul 2014 08:17:31 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so1372998qaq.38 for ; Wed, 23 Jul 2014 08:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XL0yXaYthgFQ7Gh4WLUDhLfxlq1jnPJLQHL2bOIvOCY=; b=xn6+rUoA0tlpXY1nFx7Gky32wHYMOI/Ie9vzbiMcXBVjPwwsxp3ST4bomAD8CHddnJ WlfdazHQcHd7c3VFfHyRefL6WiM4X+nHk9Fj6ncNmF4smKQ2amLtklQQWwFSGzyC7WGW /QWFYZKcgFZGHfxLceh5KkmdkOBkT1Ju+GWEo6yq/FVtQEb2CV1B/CTM6DUJ1l+sK2CT 1QpJ2LuulfJmWvIsLSinf5qH2t9XfQ5IPQQDthpD7x2dT2r6Mv/lc1VgkhXkWiq6n085 1dV9lC4HAerJC6PdxQAGGz5H2wefsq1tLwtY2JMow3sm++uo0cp1OEQjuhCPlH19/U8M t10g== MIME-Version: 1.0 X-Received: by 10.224.123.8 with SMTP id n8mr3396561qar.40.1406128650686; Wed, 23 Jul 2014 08:17:30 -0700 (PDT) Received: by 10.224.57.2 with HTTP; Wed, 23 Jul 2014 08:17:30 -0700 (PDT) In-Reply-To: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> References: <20140704005457.5925.30656.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 23:17:30 +0800 Message-ID: From: GangChen To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/F-RAwEX78_rCU2KaKYpgOivg3Vg Cc: mif@ietf.org, i-d-announce@ietf.org Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 15:17:33 -0000 Hi Dmitry, As we presented in MIF-HE, it's suggested to consider the relation of MPVD and RFC6731, RFC4191. I posted the message before on the list as the below for your information. Is there any conclusion if PVD rules conflict with RFC6731 and RFC4191? Two particular cases are: 1) Name resolution Let's say, host A receives RDNSS Selection DHCPv6 Option with domain name of example.com on interface 1. It also receives PVD-ID of example.com on interface 2. If the host A makes query for a.example.com, which interface should be selected 2) next hop draft-ietf-mif-mpvd-arch-01 states: For each obtained destination address, the node shall perform a next-hop lookup among routers, associated with that PVD. BRs Gang 2014-07-04 8:54 GMT+08:00, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Multiple Provisioning Domain Architecture > Author : Dmitry Anipko > Filename : draft-ietf-mif-mpvd-arch-02.txt > Pages : 21 > Date : 2014-07-03 > > Abstract: > This document is a product of the work of MIF architecture design > team. It outlines a solution framework for some of the issues, > experienced by nodes that can be attached to multiple networks. The > framework defines the notion of a Provisioning Domain (PVD) - a > consistent set of network configuration information, and PVD-aware > nodes - nodes which learn PVDs from the attached network(s) and/or > other sources and manage and use multiple PVDs for connectivity > separately and consistently. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Jul 23 12:47:30 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F711B2BBE; Wed, 23 Jul 2014 12:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7Edax6jUsn7; Wed, 23 Jul 2014 12:47:18 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6ADF1A014F; Wed, 23 Jul 2014 12:47:17 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so2850464wiw.6 for ; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) 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=emLoHB1W4BTVs4WGiZAfJD7uu4UL2yUe7z0ATQUehv8=; b=xDsoJ1U+ESXe8za6DhGB0ED/Cbzeza3ZkH8vPQhT+2vz2R44DTr+ExXjAiV0N6SrGo D4O/PRQN6GnMDMxoE5T2P/Szz0X6iIYZbYvT0LpLE3toFpM8kCOghA/GjnROJdJ93W6I JIKlBxSBEhzwVXvTFPVaIa3p7B7IP/IYCZu0TEF0Tf13bWifJJDR2H+e+lfLqSeh23Pa ye59lsh5Knx+NdStqAD2AkwwGf62ZCl+QH4Kme9PLvZ97xXTQvgStbiPOFVT0Wv21YMZ I39CkEcR81L7OtwTgZqoTn0PC3Sd91h+sY5Cag9lFW/CB/tBQ6dDph5z0dLDtFqA+fmn 98Lw== MIME-Version: 1.0 X-Received: by 10.194.60.240 with SMTP id k16mr5330244wjr.0.1406144836484; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) Date: Wed, 23 Jul 2014 21:47:16 +0200 Message-ID: From: Daniel Migault To: "ipsec@ietf.org" , "mif@ietf.org" , "multipathtcp@ietf.org Mailing List" Content-Type: multipart/alternative; boundary=047d7bacc1e47b490c04fee19b90 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/xewP5CtIkj-FoeDyCryqczhbW8M Subject: [mif] IP Security for multiple interfaces X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:47:20 -0000 --047d7bacc1e47b490c04fee19b90 Content-Type: text/plain; charset=UTF-8 Hi, We believe our document for multiple interfaces security using IPsec is closed to its final version. To go further we collect interests of various WG concerned by multiple interfaces. So please let us know: - 1) if you think this topic is of interests and should be addressed - 2) if you would like to review the documents Comments on the draft are also welcome! BR, Daniel [1] http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-02 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bacc1e47b490c04fee19b90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We believe our document for mul= tiple interfaces security using IPsec is closed to its final version. <= br>
To go further we collect interests of various WG concerned by multiple = interfaces. So please let us know:

=C2=A0 =C2=A0 - 1) if you t= hink this topic is of interests and should be addressed=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 - 2) if you would like to review the documents
--047d7bacc1e47b490c04fee19b90-- From nobody Fri Jul 25 07:03:14 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A791B2923 for ; Fri, 25 Jul 2014 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NICkrdHLCva for ; Fri, 25 Jul 2014 07:03:09 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A43D1B292B for ; Fri, 25 Jul 2014 07:02:18 -0700 (PDT) Received: from dhcp-b86f.meeting.ietf.org ([31.133.184.111]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0MbP98-1Wu7801xUS-00IoOI; Fri, 25 Jul 2014 16:02:16 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_C53CB8C7-0803-402A-8128-E6EA212F1F1D" Mime-Version: 1.0 (Mac OS X Mail 7.3 ¥(1878.6¥)) From: Ian Farrer In-Reply-To: Date: Fri, 25 Jul 2014 10:02:14 -0400 Message-Id: References: To: Hui Deng X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:uABaE4bj/FPs8UgqUdxLV9ywR8dXdsHTz63JupTlTHWs6Pq1d7G WjwKJlbrI6RbOnmTrEjvXNIEQksBhqPPpSSiEdlKwZ70t+ckpxfTatUWfT23czmzL4o6j1Q Rs85tYq+vzPjXLDFPFfi+78HIT99urVZTq9ri4f1qFGAIkNGkPeldRISzzKbe/wkVfsM2AA PtZHCJf38LaAwlZdW9PhA== Archived-At: http://mailarchive.ietf.org/arch/msg/mif/JVx8GxjP2BESXVQH3yRZ8sFBarg Cc: Margaret Wasserman , MIF Mailing List Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:03:13 -0000 --Apple-Mail=_C53CB8C7-0803-402A-8128-E6EA212F1F1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Sorry for my late review. Overall, I think this update has made a lot of = improvements on the last version. Some comments below (most of them also = raised in the MIF WG session): Overall: The document needs a language review. I'll volunteer for this, if you = like. 2.1 "It shall be possible for sources of PVD information to communicate that = some of their configuration elements could be used within a context of = other networks/PVDs. PVD-aware nodes, based on such declaration and = their policies, may choose to inject such elements into some or all = other PVDs they connect to." I'm concerned about this for a couple of reasons. It brings up a = requirement for a very complex mechanism between the PvDs so that = individual PvD configuration paramaters can indictate their = applicability to other PvDs and also for a PvD to accept parameters from = other PvDs. Then, there's the security implications of this. I think that this really blurs the overall architecture of containing = PvD configuration and think that it should be removed. 2.4=20 "PVD-aware node may use these IDs to choose a PVD with matching ID for = special-purpose connection requests, in accordance with node policy or = choice by advanced applications, and/or to present human-readable = representation of the IDs to the end-user for selection of = Internet-connected PVDs." This may be too prescriptive about the format which is used for the PvD. = Of the 6 formats proposed in kkbg-mpvd-id, only three of them are = potentially meaningfully human-readable (UTF-8, FQDN, NAI). What would = be good here is to place no expectation on the PvD ID itself being = readable, but allow for additional PvD ID specific meta-data to be added = which is human readable. Additional meta-data types can the be defined = as required for other PvD selection mechanisms. This avoids 'overloading' the function PvD ID itself, which should just = be a unique id. 3.3 I would like to see some advice in here saying that 'configuration = without any PvD information should continue to be advertised for non = PvD-aware hosts unless it is the explicit intention to exclude such = hosts from obtaining configuration', or something similar. 5.1 Again, I think this has the same problems as my comment for 2.1 = above. How does an administrator indicate that a particular config = parameter is globally applicable, or restricted to a specific subset of = available PvDs? Although duplicating configuration between PvDs may be less efficient = than import/export policies between PvD parameters, it's going to be a = lot easier to implement and manage. Cheers, Ian On 4 Jul 2014, at 02:13, Hui Deng wrote: > Hello all >=20 > We issue 2 weeks WGLC for the Architecture document, please kindly = help to review and comment on the document. > http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02 >=20 > Best regards, >=20 > -Co-chairs. >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_C53CB8C7-0803-402A-8128-E6EA212F1F1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

Sorry for my late = review. Overall, I think this update has made a lot of improvements on = the last version. Some comments below (most of them also raised in the = MIF WG  session):

Overall:
The = document needs a language review. I'll volunteer for this, if you = like.

2.1
"It shall be possible for = sources of PVD information to communicate that some of their = configuration elements could be used within a context of other = networks/PVDs.  PVD-aware nodes, based on such declaration and = their policies, may choose to inject such elements into some or all = other PVDs they connect to."

I'm concerned = about this for a couple of reasons. It brings up a requirement for a = very complex mechanism between the PvDs so that individual PvD = configuration paramaters can indictate their applicability to other PvDs = and also for a PvD to accept parameters from other PvDs. Then, there's = the security implications of this.
I think that this really = blurs the overall architecture of containing PvD configuration and think = that it should be = removed.

2.4 
"PVD-aware node = may use these IDs to choose a PVD with matching ID for special-purpose = connection requests, in accordance with node policy or choice by = advanced applications, and/or to present human-readable representation = of the IDs to the end-user for selection of Internet-connected = PVDs."

This may be too prescriptive about the = format which is used for the PvD. Of the 6 formats proposed in = kkbg-mpvd-id, only three of them are potentially meaningfully = human-readable (UTF-8, FQDN, NAI). What would be good here is to place = no expectation on the PvD ID itself being readable, but allow for = additional PvD ID specific meta-data to be added which is human = readable. Additional meta-data types can the be defined as required for = other PvD selection mechanisms.
This avoids 'overloading' the = function PvD ID itself, which should just be a unique = id.

3.3
I would like to see some = advice in here saying that 'configuration without any PvD information = should continue to be advertised for non PvD-aware hosts unless it is = the explicit intention to exclude such hosts from obtaining = configuration', or something similar.

5.1 = Again, I think this has the same problems as my comment for 2.1 above. = How does an administrator indicate that a particular config parameter is = globally applicable, or restricted to a specific subset of available = PvDs?
Although duplicating configuration between PvDs may be = less efficient than import/export policies between PvD parameters, it's = going to be a lot easier to implement and = manage.

Cheers,
Ian




Hello all

We issue 2 = weeks WGLC for the Architecture document, please kindly help to review = and comment on the document.
http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02

Best = regards,

-Co-chairs.


_______________________________________________
mif mailing = list
mif@ietf.org
https://www.ietf.org/mail= man/listinfo/mif

= --Apple-Mail=_C53CB8C7-0803-402A-8128-E6EA212F1F1D-- From nobody Fri Jul 25 07:12:17 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278181A0352 for ; Fri, 25 Jul 2014 07:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVABzjWusGbm for ; Fri, 25 Jul 2014 07:12:08 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D25C1A0316 for ; Fri, 25 Jul 2014 07:12:08 -0700 (PDT) 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 D42041B8908 for ; Fri, 25 Jul 2014 07:12:07 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A592A190052; Fri, 25 Jul 2014 07:12:07 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.53) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Jul 2014 07:12:07 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 ¥(1878.6¥)) From: Ted Lemon In-Reply-To: Date: Fri, 25 Jul 2014 10:12:04 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9DFCB6BC-5565-4B98-8BA4-3BBBD49B1CAD@nominum.com> References: To: Ian Farrer X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.53] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/KhnOTQjIknIaxJJku2anN_JGJgE Cc: MIF Mailing List , Margaret Wasserman Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:12:10 -0000 On Jul 25, 2014, at 10:02 AM, Ian Farrer wrote: > I'm concerned about this for a couple of reasons. It brings up a = requirement for a very complex mechanism between the PvDs so that = individual PvD configuration paramaters can indictate their = applicability to other PvDs and also for a PvD to accept parameters from = other PvDs. Then, there's the security implications of this. > I think that this really blurs the overall architecture of containing = PvD configuration and think that it should be removed. +1 > This may be too prescriptive about the format which is used for the = PvD. Of the 6 formats proposed in kkbg-mpvd-id, only three of them are = potentially meaningfully human-readable (UTF-8, FQDN, NAI). What would = be good here is to place no expectation on the PvD ID itself being = readable, but allow for additional PvD ID specific meta-data to be added = which is human readable. Additional meta-data types can the be defined = as required for other PvD selection mechanisms. > This avoids 'overloading' the function PvD ID itself, which should = just be a unique id. This can be used as a sort of social engineering attack. Not clear that = it's a good idea. From nobody Fri Jul 25 07:20:40 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BF51A0336 for ; Fri, 25 Jul 2014 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiigFcQOJkl5 for ; Fri, 25 Jul 2014 07:20:36 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEF81A0316 for ; Fri, 25 Jul 2014 07:20:23 -0700 (PDT) Received: from dhcp-b86f.meeting.ietf.org ([31.133.184.111]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0M6ArU-1WHEC03ImA-00yDAQ; Fri, 25 Jul 2014 16:20:18 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 ¥(1878.6¥)) From: Ian Farrer In-Reply-To: <9DFCB6BC-5565-4B98-8BA4-3BBBD49B1CAD@nominum.com> Date: Fri, 25 Jul 2014 10:20:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D87DD83-EAB3-43AB-A895-C04C3C0AD081@gmx.com> References: <9DFCB6BC-5565-4B98-8BA4-3BBBD49B1CAD@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:2lb8Tqb/ePcRfhsqdshb+nDWkaIr/j4Tq/+dBTY3tjd9N1KBHZ+ NhcT+aQHKzFeIs7cm9AcLrsvQb4Tt7XoIXGj0RN8K7cX6aPzyTLSppcuGHy3VNwsh1KK1Sr R2AC70IKwUUctyK2x8cR6pCauIEQK5HzbPJwXwcS/Cdk4VgISlUvx1T4lEEo0myce2HV0Rm ZoZCbR/47ibLIsmb3KiqQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mif/pzEbZw2CtBFboD8v3yQyHZ2gjH4 Cc: MIF Mailing List , Margaret Wasserman Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:20:39 -0000 >=20 >> This may be too prescriptive about the format which is used for the = PvD. Of the 6 formats proposed in kkbg-mpvd-id, only three of them are = potentially meaningfully human-readable (UTF-8, FQDN, NAI). What would = be good here is to place no expectation on the PvD ID itself being = readable, but allow for additional PvD ID specific meta-data to be added = which is human readable. Additional meta-data types can the be defined = as required for other PvD selection mechanisms. >> This avoids 'overloading' the function PvD ID itself, which should = just be a unique id. >=20 > This can be used as a sort of social engineering attack. Not clear = that it's a good idea. >=20 [ian] I think the format / contents of the meta-data is a separate = discussion. What I mean is that the PVD ID shouldn=92t be trying to = convey anything apart from a unique identifier for the PVD. Using a = human readable format as the unique PvD ID also provides the potential = for a social engineering attack. Cheers, Ian= From nobody Fri Jul 25 07:24:07 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB31C1B2945 for ; Fri, 25 Jul 2014 07:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU2RmunYpNdb for ; Fri, 25 Jul 2014 07:23:58 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3D81B2955 for ; Fri, 25 Jul 2014 07:23:45 -0700 (PDT) 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 105081B8917 for ; Fri, 25 Jul 2014 07:23:45 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 037E5190052; Fri, 25 Jul 2014 07:23:45 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.53) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Jul 2014 07:23:45 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 ¥(1878.6¥)) From: Ted Lemon In-Reply-To: <8D87DD83-EAB3-43AB-A895-C04C3C0AD081@gmx.com> Date: Fri, 25 Jul 2014 10:23:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7DEE433F-9F69-4FF0-AA35-52138F91DE2B@nominum.com> References: <9DFCB6BC-5565-4B98-8BA4-3BBBD49B1CAD@nominum.com> <8D87DD83-EAB3-43AB-A895-C04C3C0AD081@gmx.com> To: Ian Farrer X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.53] Archived-At: http://mailarchive.ietf.org/arch/msg/mif/BXBAf2QKpR9RJ6_82aBzPKqw0_c Cc: MIF Mailing List , Margaret Wasserman Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:24:03 -0000 On Jul 25, 2014, at 10:20 AM, Ian Farrer wrote: > [ian] I think the format / contents of the meta-data is a separate = discussion. What I mean is that the PVD ID shouldn=92t be trying to = convey anything apart from a unique identifier for the PVD. Using a = human readable format as the unique PvD ID also provides the potential = for a social engineering attack. Yup. I think this is a problem that needs to be addressed. From nobody Fri Jul 25 07:29:25 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BBA1B2939 for ; Fri, 25 Jul 2014 07:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-7OE6IZf4lt for ; Fri, 25 Jul 2014 07:29:16 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD4C1A0147 for ; Fri, 25 Jul 2014 07:29:15 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so4278525wgh.8 for ; Fri, 25 Jul 2014 07:29:14 -0700 (PDT) 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=7k0/wz/imxjXP9TJu6GqYVnIs+zhwJCxE0qqj8NFTIE=; b=klJETx3gFjBbhW2VySAx1LmMMiE8TI4KJ8d7KQrHQ+vgs/VZPKZWt0TDUxR2EFtnNz TEBw8qmL+T1afxkKYAmXAj7a1G0FDJZvv01r28d7LwCwruSQb1OY/tyG50EemA0cFF0T LyFhsp74SDnIRl37cMUUcS+YtbHEmatzrk99I/ZCS9zLqsW4hAKP8avB6G+aWrgGgveE KOYbSTxnkXbFw9qXZUdBfFR+bEmyMHRm5WKChPy/BYQf1kCba82KyG/qIIc5ajXV7Y+W z+Qc466eWtkWiFmzxY2cY8DqweF/uYz5y0Y44zwBPDw7WMayzNAnwZNcSm4GN2ciA45h uYNg== MIME-Version: 1.0 X-Received: by 10.194.158.101 with SMTP id wt5mr4337879wjb.136.1406298553204; Fri, 25 Jul 2014 07:29:13 -0700 (PDT) Received: by 10.194.236.42 with HTTP; Fri, 25 Jul 2014 07:29:13 -0700 (PDT) Date: Fri, 25 Jul 2014 10:29:13 -0400 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=089e0122f2aab648bf04ff056580 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/o03gbnhc6wzVsf0N3lyC2XYrzvo Subject: [mif] MIF 90th minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:29:17 -0000 --089e0122f2aab648bf04ff056580 Content-Type: text/plain; charset=UTF-8 Hello all Thank Juan Carlos's kind help to take the minutes, feel free to comment on it http://www.ietf.org/proceedings/90/minutes/minutes-90-mif Best regards, -Hui --089e0122f2aab648bf04ff056580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all

Thank Juan Carlos's kind = help to take the minutes, feel free to comment on it

Best regards,

-Hui
=
--089e0122f2aab648bf04ff056580-- From nobody Wed Jul 30 10:42:49 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0E21A01AC for ; Wed, 30 Jul 2014 10:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0rvOtSJeolj for ; Wed, 30 Jul 2014 10:42:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43D21A029C for ; Wed, 30 Jul 2014 10:42:30 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.995.11; Wed, 30 Jul 2014 17:42:28 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.177]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.2.120]) with mapi id 15.00.0995.011; Wed, 30 Jul 2014 17:42:28 +0000 From: Dmitry Anipko To: Ian Farrer , Hui Deng Thread-Topic: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 Thread-Index: AQHPl08maJzPtwkc10SNYfISMt8hwJuw83QAgAgX0zA= Date: Wed, 30 Jul 2014 17:42:27 +0000 Message-ID: <5fdda636e9db4d1597f250534ae6feab@SN2PR03MB077.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(53754006)(377454003)(24454002)(19580405001)(79102001)(46102001)(33646002)(76482001)(77096002)(50986999)(85306003)(19609705001)(83322001)(54356999)(74316001)(19617315012)(99396002)(76576001)(95666004)(19580395003)(16236675004)(74502001)(21056001)(81542001)(77982001)(99286002)(74662001)(15202345003)(105586002)(106116001)(92566001)(19300405004)(83072002)(80022001)(2656002)(87936001)(19625215002)(20776003)(86612001)(85852003)(86362001)(15975445006)(31966008)(76176999)(4396001)(64706001)(101416001)(106356001)(81342001)(107046002)(3826002)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_5fdda636e9db4d1597f250534ae6feabSN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/qMu60g3sxgaP-ims_yR_4_Z2Q_M Cc: MIF Mailing List , Margaret Wasserman Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:42:45 -0000 --_000_5fdda636e9db4d1597f250534ae6feabSN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ian, Thank you for the comments. >> The document needs a language review. I'll volunteer for this, if you li= ke. [danipko] Thank you for the offer and that would be great. I'll send you th= e text after addressing the WGLC comments. >> I think that this really blurs the overall architecture of containing Pv= D configuration and think that it should be removed. [danipko] Will do. >> What would be good here is to place no expectation on the PvD ID itself = being readable, but allow for additional PvD ID specific meta-data to be ad= ded which is human readable. [danipko] I'll change the text so that it would allow this approach. >> I would like to see some advice in here saying that 'configuration witho= ut any PvD information should continue to be advertised for non PvD-aware h= osts unless it is the explicit intention to exclude such hosts from obtaini= ng configuration', or something similar. [danipko] OK. Thank you, Dmitry From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Ian Farrer Sent: Friday, July 25, 2014 7:02 AM To: Hui Deng Cc: Margaret Wasserman; MIF Mailing List Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02 Hi, Sorry for my late review. Overall, I think this update has made a lot of im= provements on the last version. Some comments below (most of them also rais= ed in the MIF WG session): Overall: The document needs a language review. I'll volunteer for this, if you like. 2.1 "It shall be possible for sources of PVD information to communicate that so= me of their configuration elements could be used within a context of other = networks/PVDs. PVD-aware nodes, based on such declaration and their polici= es, may choose to inject such elements into some or all other PVDs they con= nect to." I'm concerned about this for a couple of reasons. It brings up a requiremen= t for a very complex mechanism between the PvDs so that individual PvD conf= iguration paramaters can indictate their applicability to other PvDs and al= so for a PvD to accept parameters from other PvDs. Then, there's the securi= ty implications of this. I think that this really blurs the overall architecture of containing PvD c= onfiguration and think that it should be removed. 2.4 "PVD-aware node may use these IDs to choose a PVD with matching ID for spec= ial-purpose connection requests, in accordance with node policy or choice b= y advanced applications, and/or to present human-readable representation of= the IDs to the end-user for selection of Internet-connected PVDs." This may be too prescriptive about the format which is used for the PvD. Of= the 6 formats proposed in kkbg-mpvd-id, only three of them are potentially= meaningfully human-readable (UTF-8, FQDN, NAI). What would be good here is= to place no expectation on the PvD ID itself being readable, but allow for= additional PvD ID specific meta-data to be added which is human readable. = Additional meta-data types can the be defined as required for other PvD sel= ection mechanisms. This avoids 'overloading' the function PvD ID itself, which should just be = a unique id. 3.3 I would like to see some advice in here saying that 'configuration without = any PvD information should continue to be advertised for non PvD-aware host= s unless it is the explicit intention to exclude such hosts from obtaining = configuration', or something similar. 5.1 Again, I think this has the same problems as my comment for 2.1 above. = How does an administrator indicate that a particular config parameter is gl= obally applicable, or restricted to a specific subset of available PvDs? Although duplicating configuration between PvDs may be less efficient than = import/export policies between PvD parameters, it's going to be a lot easie= r to implement and manage. Cheers, Ian On 4 Jul 2014, at 02:13, Hui Deng > wrote: Hello all We issue 2 weeks WGLC for the Architecture document, please kindly help to = review and comment on the document. http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02 Best regards, -Co-chairs. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --_000_5fdda636e9db4d1597f250534ae6feabSN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ian,=

 <= /p>

Thank you for the comment= s.

 <= /p>

>> The docum= ent needs a language review. I'll volunteer for this, if you like.

 <= /p>

[danipko] Thank you for t= he offer and that would be great. I’ll send you the text after addres= sing the WGLC comments.

 <= /p>

>> I think t= hat this really blurs the overall architecture of containing PvD configurat= ion and think that it should be removed.

 <= /p>

[danipko] Will do.

 <= /p>

>> What woul= d be good here is to place no expectation on the PvD ID itself being readab= le, but allow for additional PvD ID specific meta-data to be added which is human readable.

 

[danipko] I’ll change the text so that it would allow this approach.

 

>> I would like to see some advice in here say= ing that 'configuration without any PvD information should continue to be a= dvertised for non PvD-aware hosts unless it is the explicit intention to ex= clude such hosts from obtaining configuration', or something similar.

 <= /p>

[danipko] OK.<= /span>

 <= /p>

Thank you,

Dmitry<= /p>

 

From: mif [m= ailto:mif-bounces@ietf.org] On Behalf Of Ian Farrer
Sent: Friday, July 25, 2014 7:02 AM
To: Hui Deng
Cc: Margaret Wasserman; MIF Mailing List
Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02

 

Hi,

 

Sorry for my late review. Overall, I think this upda= te has made a lot of improvements on the last version. Some comments below = (most of them also raised in the MIF WG  session):

 

Overall:

The document needs a language review. I'll volunteer= for this, if you like.

 

2.1

"It shall be possible for sources of PVD inform= ation to communicate that some of their configuration elements could be use= d within a context of other networks/PVDs.  PVD-aware nodes, based on = such declaration and their policies, may choose to inject such elements into some or all other PVDs they connect to."=

 

I'm concerned about this for a couple of reasons. It= brings up a requirement for a very complex mechanism between the PvDs so t= hat individual PvD configuration paramaters can indictate their applicabili= ty to other PvDs and also for a PvD to accept parameters from other PvDs. Then, there's the security implicati= ons of this.

I think that this really blurs the overall architect= ure of containing PvD configuration and think that it should be removed.

 

2.4 

"PVD-aware node may use these IDs to choose a P= VD with matching ID for special-purpose connection requests, in accordance = with node policy or choice by advanced applications, and/or to present huma= n-readable representation of the IDs to the end-user for selection of Internet-connected PVDs."

 

This may be too prescriptive about the format which = is used for the PvD. Of the 6 formats proposed in kkbg-mpvd-id, only three = of them are potentially meaningfully human-readable (UTF-8, FQDN, NAI). Wha= t would be good here is to place no expectation on the PvD ID itself being readable, but allow for additional = PvD ID specific meta-data to be added which is human readable. Additional m= eta-data types can the be defined as required for other PvD selection mecha= nisms.

This avoids 'overloading' the function PvD ID itself= , which should just be a unique id.

 

3.3

I would like to see some advice in here saying that = 'configuration without any PvD information should continue to be advertised= for non PvD-aware hosts unless it is the explicit intention to exclude suc= h hosts from obtaining configuration', or something similar.

 

5.1 Again, I think this has the same problems as my = comment for 2.1 above. How does an administrator indicate that a particular= config parameter is globally applicable, or restricted to a specific subse= t of available PvDs?

Although duplicating configuration between PvDs may = be less efficient than import/export policies between PvD parameters, it's = going to be a lot easier to implement and manage.

 

Cheers,

Ian

 

 

 

On 4 Jul 2014, at 02:13, Hui Deng <denghui02@gmail.com> wrote:



Hello all

 

We issue 2 weeks WGLC for the Architecture document,= please kindly help to review and comment on the document.


Best regards,

-Co-chairs.

 

 

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

 

--_000_5fdda636e9db4d1597f250534ae6feabSN2PR03MB077namprd03pro_--