From nobody Mon Feb 2 00:06:58 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CB31A0032 for ; Mon, 2 Feb 2015 00:06:50 -0800 (PST) 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 jyn3ez-xEC3x; Mon, 2 Feb 2015 00:06:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7D51A002F; Mon, 2 Feb 2015 00:06:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: denghui02@hotmail.com, mif@ietf.org, mif-chairs@tools.ietf.org, draft-ietf-mif-mpvd-arch.all@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150202080632.20207.44768.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 00:06:32 -0800 From: IETF Secretariat Archived-At: Subject: [mif] ID Tracker State Update Notice: X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 08:06:55 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Tue Feb 3 00:45:06 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280F21A1A92; Tue, 3 Feb 2015 00:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 eDK6TJ6-yuXO; Tue, 3 Feb 2015 00:45:01 -0800 (PST) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id 285731A8728; Tue, 3 Feb 2015 00:44:58 -0800 (PST) Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8A39200B014B6; Tue, 3 Feb 2015 10:44:56 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> Date: Tue, 3 Feb 2015 10:44:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Markus Stenberg , mif@ietf.org, IETF-Announce Subject: Re: [mif] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC 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, 03 Feb 2015 08:45:03 -0000 I am not sure if this document has been really thought through in terms = of IPv4, or the dual-stack case.=20 Notably, in section 2: * Source address prefixes for use by connections within the provisioning = domain If we have a home router, which does NAT (and I dare you to find one = that does not), the e.g. potential authentication mentioned in Section = 2.3 becomes invalid in case of IPv4 as the source address prefix = information has to change (or be omitted) for it to be useful. Section = 2.5 further advocates combining both IPv4 and IPv6 PVDs, and as a = result, whole authentication scheme becomes more or less invalid if not = directly connected to the network PVD lives in. (And IPv4 source address = prefix information has to change.) My proposal: - make use of source address specific optional with IPv4? (or note = somewhere that prefix should be 0.0.0.0/0 if any use of NAT is ever = thought reasonable using the PVD) On not so serious note, as PvD has (more or less) binding to the = protocol it was used to acquire the configuration information (e.g. = DHCPv4, DHCPv6, or RA), I would much rather advocate single-AF PvDs so = their lifetime would map to the lifetime of the other network = information received/updated via that particular protocol. My proposal (but I can live without too, this is mostly just = elegance-of-design criteria for me): - unbundle dual-stack case so that IPv4 PVD comes from DHCPv4, and IPv6 = PVD from DHCPv6/RA. Or at least make bundling optional; in case of e.g. = IKEv2, having both from same source makes still sense. Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA have = TLS transport? (X.509 certificate would fit better.) Nit: In section 9, I am Markus, not Marcus ;) Cheers, -Markus= From nobody Tue Feb 3 04:47:17 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8079E1A8A0B; Tue, 3 Feb 2015 04:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e_W2E-zd48I; Tue, 3 Feb 2015 04:47:10 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A5C1A871B; Tue, 3 Feb 2015 04:47:10 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 7F84ADA00D5; Tue, 3 Feb 2015 12:47:10 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4BB9E53E082; Tue, 3 Feb 2015 04:47:10 -0800 (PST) Received: from [172.19.131.133] (12.130.116.26) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 3 Feb 2015 04:47:09 -0800 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: Tue, 3 Feb 2015 07:47:04 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [12.130.116.26] Archived-At: Cc: "mif@ietf.org List" , IETF Discussion Mailing List Subject: Re: [mif] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC 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, 03 Feb 2015 12:47:13 -0000 On Feb 3, 2015, at 3:44 AM, Markus Stenberg = wrote: > If we have a home router, which does NAT (and I dare you to find one = that does not), the e.g. potential authentication mentioned in Section = 2.3 becomes invalid in case of IPv4 as the source address prefix = information has to change (or be omitted) for it to be useful. Section = 2.5 further advocates combining both IPv4 and IPv6 PVDs, and as a = result, whole authentication scheme becomes more or less invalid if not = directly connected to the network PVD lives in. (And IPv4 source address = prefix information has to change.) I think this is future work. The MIF working group did consider = whether to separate IPv4 and IPv6 PVDs; my belief was that we should, = but the consensus was that they should be able to be kept together. I = think it's true that the capability to authenticate an explicit = provisioning domain's container across a home gateway that is doing NAT = for IPv4 is unlikely to work without some care. However, it's not = clear to me that this is even a use case that we care about. If it is, = then it can be addressed by treating the NATted provisioning domain as a = different provisioning domain than the external IPv4 provisioning = domain. It's actually not usual however for HGs to even pass the = external PVD information into the home network on IPv4 NATs. Instead, = it sets up a DNS proxy and advertises that, and passes nothing else = through at all. > - make use of source address specific optional with IPv4? (or note = somewhere that prefix should be 0.0.0.0/0 if any use of NAT is ever = thought reasonable using the PVD) This is another alternative, but it would only be necessary in the case = where you wanted to advertise a translated prefix internally and have = that be treated as the same PVD as the externally advertised prefix. = Since the current architecture document doesn't make specific = recommendations about this, I don't think that we need to add anything, = but if you think it's worthwhile we could add text that just explains = the issue you've raised and talks about your proposed solution and = possibly the one I've suggested. I don't really want to add text about this, because I don't think it's = been thought through carefully, and there are some holes in it that I = can see. For example, there's no way to prove that an advertised NAT = prefix actually reaches the PVD that it is claimed to reach. So you = are pretty much at the mercy of the HG anyway. > On not so serious note, as PvD has (more or less) binding to the = protocol it was used to acquire the configuration information (e.g. = DHCPv4, DHCPv6, or RA), I would much rather advocate single-AF PvDs so = their lifetime would map to the lifetime of the other network = information received/updated via that particular protocol. Me too, but I think that ship has already sailed. And if you think = about it, your point about RA and DHCPv6 is clearly an implementation = issue: the implementation for explicit PVDs has to make it possible to = connect them, because in practice they are related. So there's no = technical reason why this can't also work for DHCPv4 and explicit PVDs. > Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA = have TLS transport? (X.509 certificate would fit better.) How about "PKI" instead of "TLS"? I know PKI generally means X.509, but = it isn't restricted to X.509. > Nit: In section 9, I am Markus, not Marcus ;) Sorry about that. Thanks for the thorough review! From nobody Tue Feb 3 07:10:12 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBA1A040C; Tue, 3 Feb 2015 07:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, 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 jyC06SAhHbXp; Tue, 3 Feb 2015 07:10:05 -0800 (PST) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 6908C1A036E; Tue, 3 Feb 2015 07:10:05 -0800 (PST) Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8A39200BBD8FE; Tue, 3 Feb 2015 17:10:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: Date: Tue, 3 Feb 2015 17:09:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi> References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Markus Stenberg , "mif@ietf.org List" , IETF Discussion Mailing List Subject: Re: [mif] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC 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, 03 Feb 2015 15:10:11 -0000 On 3.2.2015, at 14.47, Ted Lemon wrote: > On Feb 3, 2015, at 3:44 AM, Markus Stenberg = wrote: >> If we have a home router, which does NAT (and I dare you to find one = that does not), the e.g. potential authentication mentioned in Section = 2.3 becomes invalid in case of IPv4 as the source address prefix = information has to change (or be omitted) for it to be useful. Section = 2.5 further advocates combining both IPv4 and IPv6 PVDs, and as a = result, whole authentication scheme becomes more or less invalid if not = directly connected to the network PVD lives in. (And IPv4 source address = prefix information has to change.) > I think this is future work. The MIF working group did consider = whether to separate IPv4 and IPv6 PVDs; my belief was that we should, = but the consensus was that they should be able to be kept together. I = think it's true that the capability to authenticate an explicit = provisioning domain's container across a home gateway that is doing NAT = for IPv4 is unlikely to work without some care. However, it's not = clear to me that this is even a use case that we care about. If it is, = then it can be addressed by treating the NATted provisioning domain as a = different provisioning domain than the external IPv4 provisioning = domain. It's actually not usual however for HGs to even pass the = external PVD information into the home network on IPv4 NATs. Instead, = it sets up a DNS proxy and advertises that, and passes nothing else = through at all. >=20 >> - make use of source address specific optional with IPv4? (or note = somewhere that prefix should be 0.0.0.0/0 if any use of NAT is ever = thought reasonable using the PVD) >=20 > This is another alternative, but it would only be necessary in the = case where you wanted to advertise a translated prefix internally and = have that be treated as the same PVD as the externally advertised = prefix. Since the current architecture document doesn't make specific = recommendations about this, I don't think that we need to add anything, = but if you think it's worthwhile we could add text that just explains = the issue you've raised and talks about your proposed solution and = possibly the one I've suggested. >=20 > I don't really want to add text about this, because I don't think it's = been thought through carefully, and there are some holes in it that I = can see. For example, there's no way to prove that an advertised NAT = prefix actually reaches the PVD that it is claimed to reach. So you = are pretty much at the mercy of the HG anyway. Fair enough; I guess just splitting the dual stack PVDs if encountered = (IPv4+IPv6 -> NATted IPv4 + IPv6 as-is) is sufficient answer to that. As = I personally consider authentication mostly bogus, this is not really a = problem for me :) >> On not so serious note, as PvD has (more or less) binding to the = protocol it was used to acquire the configuration information (e.g. = DHCPv4, DHCPv6, or RA), I would much rather advocate single-AF PvDs so = their lifetime would map to the lifetime of the other network = information received/updated via that particular protocol. > Me too, but I think that ship has already sailed. And if you think = about it, your point about RA and DHCPv6 is clearly an implementation = issue: the implementation for explicit PVDs has to make it possible to = connect them, because in practice they are related. So there=E2=80=99s = no technical reason why this can't also work for DHCPv4 and explicit = PVDs. >> Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA = have TLS transport? (X.509 certificate would fit better.) > How about "PKI" instead of "TLS"? I know PKI generally means X.509, = but it isn=E2=80=99t restricted to X.509. PKI is more generic, yes. I also wondered about doing =E2=80=98authenticat= ion using .. DANE=E2=80=99, as _that_ also just uses X.509 certificates = (and would be covered under PKI certificate using authentication). So final suggestion - get rid of DANE, get rid of TLS, and probably = rework the text in that paragraph a bit to make it simpler. As-is, both = DANE and TLS mention seem superfluous. Cheers, -Markus= From nobody Tue Feb 3 10:31:10 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5162E1A1A32; Tue, 3 Feb 2015 10:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7pdgmPe4hQC; Tue, 3 Feb 2015 10:31:02 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877C91A1B9B; Tue, 3 Feb 2015 10:31:02 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 577AEDA011E; Tue, 3 Feb 2015 18:31:02 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 220C353E08B; Tue, 3 Feb 2015 10:31:02 -0800 (PST) Received: from [172.19.131.154] (12.130.117.24) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 3 Feb 2015 10:26:58 -0800 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: <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi> Date: Tue, 3 Feb 2015 12:26:48 -0600 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [12.130.117.24] Archived-At: Cc: "mif@ietf.org List" , IETF Discussion Mailing List Subject: Re: [mif] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC 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, 03 Feb 2015 18:31:06 -0000 On Feb 3, 2015, at 9:09 AM, Markus Stenberg = wrote: > Fair enough; I guess just splitting the dual stack PVDs if encountered = (IPv4+IPv6 -> NATted IPv4 + IPv6 as-is) is sufficient answer to that. As = I personally consider authentication mostly bogus, this is not really a = problem for me :) To be clear, the authentication we're talking about here, at least = generally, is not intended to assert that the node receiving it can = trust it without question. It merely asserts that the information came = from a particular source, which the node may or may not trust. That's = what the text you were commenting on was for, actually. > So final suggestion - get rid of DANE, get rid of TLS, and probably = rework the text in that paragraph a bit to make it simpler. As-is, both = DANE and TLS mention seem superfluous. I'm skeptical about this--I think it's good to mention DANE. DNSSEC is = in effect a PKI, but it's quite a bit different than the other common = PKI example. How about "a PKI, for example DNSSEC/DANE or X.509?" = That way we don't lose the mention of DNSSEC, but keep it open to other = PKIs. From nobody Wed Feb 4 20:25:37 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FD71A1A09; Wed, 4 Feb 2015 20:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b805_vnfPeH4; Wed, 4 Feb 2015 20:25:27 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4F01A0210; Wed, 4 Feb 2015 20:25:10 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id h11so7926397wiw.1; Wed, 04 Feb 2015 20:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AKPsxCZ72IVyhbd5COOqUIGcxy5313uxg98dvTkjIag=; b=OfUKjxSk36+byySOxDoVHVDfy/iiUedEHKF1atW9Pk6xcZOFV5yQn8GrQ/q4GkZzP3 0WC7b9PAEMIcm+9L286xBQTVeueIJwZKW6SwLo5tRn7UTGc4imIrqQy14V/rR8Q3gW6r AS+GVsz0+Nl48GqwSD0FyHmizOiL+F3Yr7b9nRCusieGNiLVNa4YF03TDrRlNgBRj8X3 pan6ftoBYFE7/EYB/56+UGqx2b8XWkkH/QZ4iaJwpgqH6euBF3WQr+lqOWagnRSPCNsy 0QurlNntNjQdqbKG7Qix6TE9GQxrXbYpZ6lpNlFomUue430GGZx5xiDezMzk3Fu8qVU7 ETsA== MIME-Version: 1.0 X-Received: by 10.180.205.210 with SMTP id li18mr6751453wic.39.1423110309660; Wed, 04 Feb 2015 20:25:09 -0800 (PST) Received: by 10.180.209.38 with HTTP; Wed, 4 Feb 2015 20:25:09 -0800 (PST) In-Reply-To: References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi> Date: Wed, 4 Feb 2015 20:25:09 -0800 Message-ID: From: Dmitry Anipko To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c260ec7bcd32050e4fb0da Archived-At: Cc: Markus Stenberg , "mif@ietf.org List" , IETF Discussion Mailing List Subject: Re: [mif] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC 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, 05 Feb 2015 04:25:31 -0000 --001a11c260ec7bcd32050e4fb0da Content-Type: text/plain; charset=UTF-8 My reading is that there is a consensus to fix the name misspelling :-), but I could not quite read whether the PKI question got resolved. Markus, can you please comment whether the modification Ted worded would address your concern? On Tue, Feb 3, 2015 at 10:26 AM, Ted Lemon wrote: > On Feb 3, 2015, at 9:09 AM, Markus Stenberg > wrote: > > Fair enough; I guess just splitting the dual stack PVDs if encountered > (IPv4+IPv6 -> NATted IPv4 + IPv6 as-is) is sufficient answer to that. As I > personally consider authentication mostly bogus, this is not really a > problem for me :) > > To be clear, the authentication we're talking about here, at least > generally, is not intended to assert that the node receiving it can trust > it without question. It merely asserts that the information came from a > particular source, which the node may or may not trust. That's what the > text you were commenting on was for, actually. > > > So final suggestion - get rid of DANE, get rid of TLS, and probably > rework the text in that paragraph a bit to make it simpler. As-is, both > DANE and TLS mention seem superfluous. > > I'm skeptical about this--I think it's good to mention DANE. DNSSEC is > in effect a PKI, but it's quite a bit different than the other common PKI > example. How about "a PKI, for example DNSSEC/DANE or X.509?" That way > we don't lose the mention of DNSSEC, but keep it open to other PKIs. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --001a11c260ec7bcd32050e4fb0da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My reading is that there is a consensus to fix the name mi= sspelling :-), but I could not quite read whether the PKI question got reso= lved. Markus, can you please comment whether the modification Ted worded wo= uld address your concern?

On Tue, Feb 3, 2015 at 10:26 AM, Ted Lemon = <Ted.Lemon@no= minum.com> wrote:
On Feb 3, 2015, at 9:09 AM, Markus Stenberg <markus.stenberg@iki.fi> wrote:
> Fair enough; I guess just splitting the dual stack PVDs if encountered= (IPv4+IPv6 -> NATted IPv4 + IPv6 as-is) is sufficient answer to that. A= s I personally consider authentication mostly bogus, this is not really a p= roblem for me :)

To be clear, the authentication we're talking about here, at lea= st generally, is not intended to assert that the node receiving it can trus= t it without question.=C2=A0 =C2=A0It merely asserts that the information c= ame from a particular source, which the node may or may not trust.=C2=A0 = =C2=A0That's what the text you were commenting on was for, actually.
> So final suggestion - get rid of DANE, get rid of TLS, and probably re= work the text in that paragraph a bit to make it simpler. As-is, both DANE = and TLS mention seem superfluous.

I'm skeptical about this--I think it's good to mention DANE.= =C2=A0 =C2=A0DNSSEC is in effect a PKI, but it's quite a bit different = than the other common PKI example.=C2=A0 =C2=A0How about "a PKI, for e= xample DNSSEC/DANE or X.509?"=C2=A0 =C2=A0That way we don't lose t= he mention of DNSSEC, but keep it open to other PKIs.

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

--001a11c260ec7bcd32050e4fb0da-- From nobody Thu Feb 5 01:14:18 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3984B1A007F; Thu, 5 Feb 2015 01:13:30 -0800 (PST) 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 zY7xSElnn0yT; Thu, 5 Feb 2015 01:13:27 -0800 (PST) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id 81CAC1A0059; Thu, 5 Feb 2015 01:13:27 -0800 (PST) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54C8F2EA00EA272B; Thu, 5 Feb 2015 11:13:22 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Markus Stenberg In-Reply-To: Date: Thu, 5 Feb 2015 11:13:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66BBE1F3-A36E-4A75-8844-6CCE9469735B@iki.fi> References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi> To: Dmitry Anipko X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Markus Stenberg , "mif@ietf.org List" , IETF Discussion Mailing List Subject: Re: [mif] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC 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, 05 Feb 2015 09:13:30 -0000 On 5.2.2015, at 6.25, Dmitry Anipko wrote: > My reading is that there is a consensus to fix the name misspelling = :-), but I could not quite read whether the PKI question got resolved. = Markus, can you please comment whether the modification Ted worded would = address your concern? Sorry, I got sidetracked to writing security a audit document and never = got back. We all have our guilty pleasures.. Anyway, haha ;) Guess we agree about something at least! > > So final suggestion - get rid of DANE, get rid of TLS, and probably = rework the text in that paragraph a bit to make it simpler. As-is, both = DANE and TLS mention seem superfluous. > I'm skeptical about this--I think it's good to mention DANE. DNSSEC = is in effect a PKI, but it's quite a bit different than the other common = PKI example. How about "a PKI, for example DNSSEC/DANE or X.509?" = That way we don=E2=80=99t lose the mention of DNSSEC, but keep it open = to other PKIs. If simplification is not desired, I guess we can work that in too. DANE is just about binding a (DNS) label + port + protocol using various = selectors to a X.509 certificate (either CA or end node one). Text in question: If authentication is done using a public key mechanism such as a TLS certificate or DANE, authentication by itself is not enough since theoretically any PvD could be authenticated in this way. In addition to authentication, the node would need configuration to =E2=80=A6 I am not sure where this DNS label + port + protocol combination would = be derived from this case, but admittedly (say) using DHCPv6 or = something might make sense in this case. So.. my proposed version: If authentication is done using a public key mechanism such as=20 PKI certificate chain validation or DANE, authentication by itself is = not enough since theoretically any PvD could be authenticated in this way. In addition to authentication, the node would need configuration to As the text talks of public key authentication mechanisms, I think PKI = certificate chain validation and DANE both qualify. The old text=E2=80=99s= =E2=80=99TLS certificate=E2=80=99 is just weird to me, although I = understand the idea is fundamentally the same. Cheers, -Markus= From nobody Thu Feb 5 01:49:54 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4C11ABB1A; Sun, 1 Feb 2015 23:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LylIfiwa7sVc; Sun, 1 Feb 2015 23:52:14 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE421A930A; Sun, 1 Feb 2015 23:52:14 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t127qE3p027798; Mon, 2 Feb 2015 07:52:14 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 47D70C20402; Mon, 2 Feb 2015 07:52:14 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150123153537.10431.77686.idtracker@ietfa.amsl.com> References: <20150123153537.10431.77686.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #805354 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 02 Feb 2015 07:52:14 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 05 Feb 2015 01:49:53 -0800 Cc: iesg@ietf.org, mif@ietf.org, mif-chairs@tools.ietf.org, draft-ietf-mif-mpvd-arch.all@tools.ietf.org Subject: [mif] [IANA #805354] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 07:52:17 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mif-mpvd-arch-09, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Fri Jan 23 15:36:04 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Multiple Interfaces WG (mif) to > consider the following document: > - 'Multiple Provisioning Domain Architecture' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-02-06. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document is a product of the work of the MIF Architecture Design > team. It outlines a solution framework for some of the issues > experienced by nodes that can be attached to multiple networks > simultaneously. The framework defines the concept of a Provisioning > Domain (PvD) which is a a consistent set of network configuration > information. PvD aware nodes learn PvD specific information from the > networks they are attached to and / or other sources. PvDs are used > to enable separation and configuration consistency in presence of > multiple concurrent connections. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Fri Feb 6 00:08:54 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719D91A1A5D; Fri, 6 Feb 2015 00:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 evUFD3oBsmQX; Fri, 6 Feb 2015 00:08:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA451A1A2F; Fri, 6 Feb 2015 00:08:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206080846.12685.7805.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 00:08:46 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [mif] Last Call Expired: 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, 06 Feb 2015 08:08:49 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Fri Feb 6 00:08:59 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DAC511A1A60; Fri, 6 Feb 2015 00:08:49 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719D91A1A5D; Fri, 6 Feb 2015 00:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 evUFD3oBsmQX; Fri, 6 Feb 2015 00:08:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA451A1A2F; Fri, 6 Feb 2015 00:08:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206080846.12685.7805.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 00:08:46 -0800 Archived-At: Cc: iesg-secretary@ietf.org Subject: [mif] Last Call Expired: 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, 06 Feb 2015 08:08:50 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Mon Feb 9 10:57:24 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0461A1BAA for ; Mon, 9 Feb 2015 10:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHsg7UJ-QT5G for ; Mon, 9 Feb 2015 10:35:14 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F481A1B75 for ; Mon, 9 Feb 2015 10:35:14 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4330BDA0293 for ; Mon, 9 Feb 2015 18:35:14 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 197FC53E080; Mon, 9 Feb 2015 10:35:14 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 9 Feb 2015 10:35:14 -0800 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: Mon, 9 Feb 2015 13:35:10 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150123153536.10431.23196.idtracker@ietfa.amsl.com> <853D079F-75B3-4AF6-857F-AE15C2AB32D2@iki.fi> To: Dmitry Anipko X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: Markus Stenberg , "mif@ietf.org List" Subject: Re: [mif] Last Call: (Multiple Provisioning Domain Architecture) to Informational RFC 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, 09 Feb 2015 18:35:16 -0000 On Feb 4, 2015, at 11:25 PM, Dmitry Anipko = wrote: > My reading is that there is a consensus to fix the name misspelling = :-), but I could not quite read whether the PKI question got resolved. = Markus, can you please comment whether the modification Ted worded would = address your concern? It looks like you got an answer from Markus. This document is = currently scheduled for the 2/19 telechat, so it would be great if we = could get an update in the next day or so that incorporates the = agreed-upon changes, or if you don't yet feel that you have what you = need, we should figure out how to address that. The document has to be = finished and ready for IETF review with enough lead time that people can = meaningfully comment on it and discuss it. From nobody Mon Feb 9 22:22:56 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDF51A8FD2; Mon, 9 Feb 2015 22:22:54 -0800 (PST) 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 iAh1DJjAmich; Mon, 9 Feb 2015 22:22:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D92681A0055; Mon, 9 Feb 2015 22:22:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210062252.17348.33500.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 22:22:52 -0800 Archived-At: Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-10.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: Tue, 10 Feb 2015 06:22:54 -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-10.txt Pages : 22 Date : 2015-02-09 Abstract: This document is a product of the work of the MIF Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD) which is a a consistent set of network configuration information. PvD aware nodes learn PvD specific information from the networks they are attached to and / or other sources. PvDs are used to enable separation and configuration consistency in presence of multiple concurrent connections. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-10 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 Mon Feb 9 22:23:07 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBECF1A8FD4; Mon, 9 Feb 2015 22:22:55 -0800 (PST) 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 XxnGthl_xOTE; Mon, 9 Feb 2015 22:22:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 161BE1A8A86; Mon, 9 Feb 2015 22:22:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210062253.17348.71087.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 22:22:53 -0800 Archived-At: Subject: [mif] New Version Notification - draft-ietf-mif-mpvd-arch-10.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: Tue, 10 Feb 2015 06:22:56 -0000 A new version (-10) has been submitted for draft-ietf-mif-mpvd-arch: http://www.ietf.org/internet-drafts/draft-ietf-mif-mpvd-arch-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-10 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. IETF Secretariat. From nobody Mon Feb 9 22:23:09 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1F4D21A8A86; Mon, 9 Feb 2015 22:22:56 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBECF1A8FD4; Mon, 9 Feb 2015 22:22:55 -0800 (PST) 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 XxnGthl_xOTE; Mon, 9 Feb 2015 22:22:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 161BE1A8A86; Mon, 9 Feb 2015 22:22:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210062253.17348.71087.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 22:22:53 -0800 Archived-At: Subject: [mif] New Version Notification - draft-ietf-mif-mpvd-arch-10.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: Tue, 10 Feb 2015 06:22:56 -0000 A new version (-10) has been submitted for draft-ietf-mif-mpvd-arch: http://www.ietf.org/internet-drafts/draft-ietf-mif-mpvd-arch-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-10 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. IETF Secretariat. From nobody Tue Feb 10 15:39:01 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55961A877F; Tue, 10 Feb 2015 15:38:57 -0800 (PST) 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 kCaDSkDWREGl; Tue, 10 Feb 2015 15:38:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E995F1A8786; Tue, 10 Feb 2015 15:37:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210233747.541.31552.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 15:37:47 -0800 From: IETF Secretariat Archived-At: Subject: [mif] ID Tracker State Update Notice: 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: Tue, 10 Feb 2015 23:38:58 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Tue Feb 10 15:39:02 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1C6731A8785; Tue, 10 Feb 2015 15:38:58 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55961A877F; Tue, 10 Feb 2015 15:38:57 -0800 (PST) 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 kCaDSkDWREGl; Tue, 10 Feb 2015 15:38:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E995F1A8786; Tue, 10 Feb 2015 15:37:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150210233747.541.31552.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 15:37:47 -0800 From: IETF Secretariat Archived-At: Subject: [mif] ID Tracker State Update Notice: 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: Tue, 10 Feb 2015 23:38:58 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Tue Feb 10 23:06:34 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8221A8784; Tue, 10 Feb 2015 23:06:28 -0800 (PST) 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 u2_RjZ8OeBWo; Tue, 10 Feb 2015 23:06:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 788061A710D; Tue, 10 Feb 2015 23:06:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070622.27739.7022.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:22 -0800 From: IETF Secretariat Archived-At: Subject: [mif] ID Tracker State Update Notice: 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: Wed, 11 Feb 2015 07:06:29 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Tue Feb 10 23:06:40 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 198B31A8789; Tue, 10 Feb 2015 23:06:29 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8221A8784; Tue, 10 Feb 2015 23:06:28 -0800 (PST) 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 u2_RjZ8OeBWo; Tue, 10 Feb 2015 23:06:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 788061A710D; Tue, 10 Feb 2015 23:06:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150211070622.27739.7022.idtracker@ietfa.amsl.com> Date: Tue, 10 Feb 2015 23:06:22 -0800 From: IETF Secretariat Archived-At: Subject: [mif] ID Tracker State Update Notice: 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: Wed, 11 Feb 2015 07:06:29 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Wed Feb 18 17:09:35 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350851A1F00; Wed, 18 Feb 2015 17:09:33 -0800 (PST) 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 GpYxp0uGZBAC; Wed, 18 Feb 2015 17:09:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9701F1A1BBC; Wed, 18 Feb 2015 17:09:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219010931.8631.12438.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 17:09:31 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Barry Leiba's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 01:09:33 -0000 Barry Leiba has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1.1 -- As far as I can see, there are no 2119 key words in this document (and I'm glad about that). You should remove this section and the reference to RFC 2119. From nobody Wed Feb 18 17:09:36 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5A0E51A1F70; Wed, 18 Feb 2015 17:09:33 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350851A1F00; Wed, 18 Feb 2015 17:09:33 -0800 (PST) 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 GpYxp0uGZBAC; Wed, 18 Feb 2015 17:09:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9701F1A1BBC; Wed, 18 Feb 2015 17:09:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219010931.8631.12438.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 17:09:31 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Barry Leiba's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 01:09:33 -0000 Barry Leiba has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 1.1 -- As far as I can see, there are no 2119 key words in this document (and I'm glad about that). You should remove this section and the reference to RFC 2119. From nobody Wed Feb 18 20:39:58 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9A1A8749; Wed, 18 Feb 2015 20:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 c0qG-ykaPY9f; Wed, 18 Feb 2015 20:39:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 712841A1BAF; Wed, 18 Feb 2015 20:39:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219043955.32234.79308.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 20:39:55 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Spencer Dawkins' No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 04:39:57 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text: 5.2.3.1.2. Connectionless APIs For connectionless APIs, the host should provide an API that PvD- aware applications can use to query the PvD associated with the packet. For outgoing traffic on this transport API object, the OS should use the selected outgoing PvDs, determined as described above. does "above" mean "in section 5.2.2"? Whatever it means, perhaps a cross reference would be helpful. From nobody Wed Feb 18 20:40:00 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0A7371A1BAF; Wed, 18 Feb 2015 20:39:56 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9A1A8749; Wed, 18 Feb 2015 20:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 c0qG-ykaPY9f; Wed, 18 Feb 2015 20:39:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 712841A1BAF; Wed, 18 Feb 2015 20:39:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219043955.32234.79308.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 20:39:55 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Spencer Dawkins' No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 04:39:57 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text: 5.2.3.1.2. Connectionless APIs For connectionless APIs, the host should provide an API that PvD- aware applications can use to query the PvD associated with the packet. For outgoing traffic on this transport API object, the OS should use the selected outgoing PvDs, determined as described above. does "above" mean "in section 5.2.2"? Whatever it means, perhaps a cross reference would be helpful. From nobody Thu Feb 19 02:52:08 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E7E1A8AC9; Thu, 19 Feb 2015 02:52:05 -0800 (PST) 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 CUe4DvL1XJqg; Thu, 19 Feb 2015 02:52:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 950601A8AC6; Thu, 19 Feb 2015 02:52:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219105203.28177.38424.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 02:52:03 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, francis Dupont , denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Jari Arkko's No Record on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 10:52:05 -0000 Jari Arkko has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A number of comments were submitted by Francis Dupont in his Gen-ART review. Hopefully the authors will be able to see if those comments result in some changes to the text. From nobody Thu Feb 19 02:52:09 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 248301A8ACC; Thu, 19 Feb 2015 02:52:05 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E7E1A8AC9; Thu, 19 Feb 2015 02:52:05 -0800 (PST) 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 CUe4DvL1XJqg; Thu, 19 Feb 2015 02:52:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 950601A8AC6; Thu, 19 Feb 2015 02:52:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219105203.28177.38424.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 02:52:03 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, francis Dupont , denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Jari Arkko's No Record on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 10:52:05 -0000 Jari Arkko has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A number of comments were submitted by Francis Dupont in his Gen-ART review. Hopefully the authors will be able to see if those comments result in some changes to the text. From nobody Thu Feb 19 06:19:41 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C801A87AD; Thu, 19 Feb 2015 06:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 Qqq_MXZxP1ks; Thu, 19 Feb 2015 06:19:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F341A8784; Thu, 19 Feb 2015 06:19:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219141936.5149.23302.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:19:36 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Adrian Farrel's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 14:19:39 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have No Objection to the publication of this document. Here are some comments that you can take or leave in discussion with your AD. Some of these Comments and nits come from a "training review" by Alvaro. --- I think you correctly avoid the use of 2119 language. You can delete the boilerplate and reference. --- I think you are talking about dual homed devices rather than dual homed networks. More precisely, the "node" that is dual homed is not a router but is a host. Possibly, you are extending to a dual homed home gateway. But I think (I hope) you are not intnding to cover dual homed ASBRs or ABRs. And you are not (I hope) covering dual-homed CPEs such as might provide access to a substantial enterprise network. I think that this would benefit from more explanation of scope in the document. In practice, you are discussing making connectivity choices rather than routing choices. If I have this wrong, please tell me and I can worry about whether this should have been a Discuss :-) [BTW Section 4 is great, but it addresses my specific concerns by example rather than statement.] --- The document uses "policy" a bit like a unicorn. Of course, there is a fine tradition of saying "the node will apply locally configured policy" but you have an opportunity to be much more specific and so far more helpful for protocol developers and for implementers. Policies are easy to write in pseduorcode, and I think you know the core set of policies you expect to see supported. So you could supply some guidance. --- I also think there is a problem with how policy is expected to be configured. The "nodes" you are talking to are (I think) end-system hosts rather than routers (see my prvious) and many of these will be relatively dumb devices and/or have relatively dumb users. These users will not be capable of making more than very basic policy decisions and their choics will need to be presented in different terms to the choices that the device itself makes. This would benefit from discussion because the policy model will need more work. --- Some references to other parts of the document are missing. 2.1 discusses about the possibility of using DHCP to carry information about the PvD, but there's no reference to the later section that talks about the same topic. 2.3 talks a little about authentication, but no reference to the trust section later. --- Section 2.1 Link-specific and / or vendor-proprietary mechanisms for the discovery of PvD information (differing from IETF-defined mechanisms) can be used by nodes either separate from, or in conjunction with, IETF-defined mechanisms; providing they allow the discovery of the . necessary elements of the PvD(s). In all cases, nodes must by default ensure that the lifetime of all dynamically discovered PvD configuration is appropriately limited by relevant events. For example, if an interface media state change is indicated, previously discovered information relevant to that interface may no longer be valid and so need to be confirmed or re- Discovered. The first paragraph seems to be superfluous to me (of course I can use proprietary mechanisms!), but then the second has (what should be) a normative directive: "must ensure appropriate lifetime". But, I tend to see "appropriate" and "relevant" as red flags! Why are you not able to give firmer directives? --- Section 2.4 PvD ID is a value that is, or has a high probability of being globally unique. If it's capable of not being unique, you have to handle conflict. If you have to handle conflict, it becomes less important that the probability of being unique is high. Maybe... If two PvDs have the same ID, this conflict must be detected and resolved. Using a mechanism that selects values that are more likely to be unique has the benefit of more rapid convergence and no need to execute the conflict resolution mechanism. And please be careful with "globally unique". Is "global" really that or is it constrained? --- Section 3.3 has references to what seems to be possible solutions or just other work. I think that just saying that "any new mechanisms should consider co-existence with deployed mechanisms" is enough. --- Section 5.2.3 introduces "PvD-aware applications". This is not clearly defined. Maybe this is just another example of a policy that is not defined in the document. From nobody Thu Feb 19 06:19:44 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 984AD1A87BA; Thu, 19 Feb 2015 06:19:39 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C801A87AD; Thu, 19 Feb 2015 06:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 Qqq_MXZxP1ks; Thu, 19 Feb 2015 06:19:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F341A8784; Thu, 19 Feb 2015 06:19:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219141936.5149.23302.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:19:36 -0800 Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Adrian Farrel's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 14:19:39 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have No Objection to the publication of this document. Here are some comments that you can take or leave in discussion with your AD. Some of these Comments and nits come from a "training review" by Alvaro. --- I think you correctly avoid the use of 2119 language. You can delete the boilerplate and reference. --- I think you are talking about dual homed devices rather than dual homed networks. More precisely, the "node" that is dual homed is not a router but is a host. Possibly, you are extending to a dual homed home gateway. But I think (I hope) you are not intnding to cover dual homed ASBRs or ABRs. And you are not (I hope) covering dual-homed CPEs such as might provide access to a substantial enterprise network. I think that this would benefit from more explanation of scope in the document. In practice, you are discussing making connectivity choices rather than routing choices. If I have this wrong, please tell me and I can worry about whether this should have been a Discuss :-) [BTW Section 4 is great, but it addresses my specific concerns by example rather than statement.] --- The document uses "policy" a bit like a unicorn. Of course, there is a fine tradition of saying "the node will apply locally configured policy" but you have an opportunity to be much more specific and so far more helpful for protocol developers and for implementers. Policies are easy to write in pseduorcode, and I think you know the core set of policies you expect to see supported. So you could supply some guidance. --- I also think there is a problem with how policy is expected to be configured. The "nodes" you are talking to are (I think) end-system hosts rather than routers (see my prvious) and many of these will be relatively dumb devices and/or have relatively dumb users. These users will not be capable of making more than very basic policy decisions and their choics will need to be presented in different terms to the choices that the device itself makes. This would benefit from discussion because the policy model will need more work. --- Some references to other parts of the document are missing. 2.1 discusses about the possibility of using DHCP to carry information about the PvD, but there's no reference to the later section that talks about the same topic. 2.3 talks a little about authentication, but no reference to the trust section later. --- Section 2.1 Link-specific and / or vendor-proprietary mechanisms for the discovery of PvD information (differing from IETF-defined mechanisms) can be used by nodes either separate from, or in conjunction with, IETF-defined mechanisms; providing they allow the discovery of the . necessary elements of the PvD(s). In all cases, nodes must by default ensure that the lifetime of all dynamically discovered PvD configuration is appropriately limited by relevant events. For example, if an interface media state change is indicated, previously discovered information relevant to that interface may no longer be valid and so need to be confirmed or re- Discovered. The first paragraph seems to be superfluous to me (of course I can use proprietary mechanisms!), but then the second has (what should be) a normative directive: "must ensure appropriate lifetime". But, I tend to see "appropriate" and "relevant" as red flags! Why are you not able to give firmer directives? --- Section 2.4 PvD ID is a value that is, or has a high probability of being globally unique. If it's capable of not being unique, you have to handle conflict. If you have to handle conflict, it becomes less important that the probability of being unique is high. Maybe... If two PvDs have the same ID, this conflict must be detected and resolved. Using a mechanism that selects values that are more likely to be unique has the benefit of more rapid convergence and no need to execute the conflict resolution mechanism. And please be careful with "globally unique". Is "global" really that or is it constrained? --- Section 3.3 has references to what seems to be possible solutions or just other work. I think that just saying that "any new mechanisms should consider co-existence with deployed mechanisms" is enough. --- Section 5.2.3 introduces "PvD-aware applications". This is not clearly defined. Maybe this is just another example of a policy that is not defined in the document. From nobody Thu Feb 19 07:12:15 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06DE1A87BA; Thu, 19 Feb 2015 06:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 Zk5h7jun2Cu8; Thu, 19 Feb 2015 06:58:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF181A001C; Thu, 19 Feb 2015 06:58:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219145818.18512.48550.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:58:18 -0800 Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 07:12:14 -0800 Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Kathleen Moriarty's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 14:58:19 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. I'm fine with it, but have one minor text suggestion resulting from considering the SecDir review. http://www.ietf.org/mail-archive/web/secdir/current/msg05457.html In 5.1, you may need a clause at the end of this sentence to make sure the same PvD is used to prevent such issues (it is implied, but may be better stated explicitly - and is explicitly stated elsewhere). From: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach to. Such creation / augmentation of PvD(s) could be static or dynamic. To: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach via the same PvD. Such creation / augmentation of PvD(s) could be static or dynamic. From nobody Thu Feb 19 07:12:16 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E34AD1A8820; Thu, 19 Feb 2015 06:58:19 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06DE1A87BA; Thu, 19 Feb 2015 06:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 Zk5h7jun2Cu8; Thu, 19 Feb 2015 06:58:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF181A001C; Thu, 19 Feb 2015 06:58:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219145818.18512.48550.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:58:18 -0800 Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 07:12:15 -0800 Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, mif@ietf.org, denghui02@hotmail.com, mif-chairs@ietf.org Subject: [mif] Kathleen Moriarty's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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: Thu, 19 Feb 2015 14:58:20 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-mif-mpvd-arch-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. I'm fine with it, but have one minor text suggestion resulting from considering the SecDir review. http://www.ietf.org/mail-archive/web/secdir/current/msg05457.html In 5.1, you may need a clause at the end of this sentence to make sure the same PvD is used to prevent such issues (it is implied, but may be better stated explicitly - and is explicitly stated elsewhere). From: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach to. Such creation / augmentation of PvD(s) could be static or dynamic. To: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach via the same PvD. Such creation / augmentation of PvD(s) could be static or dynamic. From nobody Thu Feb 19 08:25:43 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FD21A916C; Thu, 19 Feb 2015 08:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az_-T5t8ll_q; Thu, 19 Feb 2015 08:25:39 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5C21A9250; Thu, 19 Feb 2015 08:25:15 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 89315DA01D2; Thu, 19 Feb 2015 16:25:15 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4ED9753E07C; Thu, 19 Feb 2015 08:25:15 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 19 Feb 2015 08:25:15 -0800 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: <20150219141936.5149.23302.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:24:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150219141936.5149.23302.idtracker@ietfa.amsl.com> To: Adrian Farrel X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, denghui02@hotmail.com, mif@ietf.org, The IESG , mif-chairs@ietf.org Subject: Re: [mif] Adrian Farrel's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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, 19 Feb 2015 16:25:41 -0000 Just a high-level response to one of the points you raised: this = document is indeed talking about hosts, generally, not nodes, although = it's possible that a router could be connected to an upstream network, = for instance, that advertises more than one provisioning domain, and the = architecture intends to be able to reflect that to nodes on the = downstream end. This document certainly isn't taking any positions on the operation of = ASBRs. However, it is expected that Homenet will write a document that talks = about how to provide MPVD info to hosts in a dual-homed home network or = a single-homed network with an ISP that provides multiple provisioning = domains. The point of this is that a node connected to a single link = on a homenet that is dual-homed ought in principle to be able to behave = the same as if that node were connected to a single-homed homenet and = also to the other upstream provider (e.g., a mobile data service), or if = it were connected to the single upstream link with multiple provisioning = domains. For instance, one of the upstream networks may provide services not = accessible through the other upstream network. A classic example of = this would be a VPN, but this could also be something like a VoIP = service that is offered by one ISP, where the equivalent service is not = available through the other, or when accessed through the other does not = provide the same QoS guarantees. From nobody Thu Feb 19 08:25:47 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D65AB1A923C; Thu, 19 Feb 2015 08:25:41 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FD21A916C; Thu, 19 Feb 2015 08:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az_-T5t8ll_q; Thu, 19 Feb 2015 08:25:39 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5C21A9250; Thu, 19 Feb 2015 08:25:15 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 89315DA01D2; Thu, 19 Feb 2015 16:25:15 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4ED9753E07C; Thu, 19 Feb 2015 08:25:15 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 19 Feb 2015 08:25:15 -0800 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: <20150219141936.5149.23302.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:24:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150219141936.5149.23302.idtracker@ietfa.amsl.com> To: Adrian Farrel X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: draft-ietf-mif-mpvd-arch.all@ietf.org, denghui02@hotmail.com, mif@ietf.org, The IESG , mif-chairs@ietf.org Subject: Re: [mif] Adrian Farrel's No Objection on draft-ietf-mif-mpvd-arch-10: (with COMMENT) 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, 19 Feb 2015 16:25:42 -0000 Just a high-level response to one of the points you raised: this = document is indeed talking about hosts, generally, not nodes, although = it's possible that a router could be connected to an upstream network, = for instance, that advertises more than one provisioning domain, and the = architecture intends to be able to reflect that to nodes on the = downstream end. This document certainly isn't taking any positions on the operation of = ASBRs. However, it is expected that Homenet will write a document that talks = about how to provide MPVD info to hosts in a dual-homed home network or = a single-homed network with an ISP that provides multiple provisioning = domains. The point of this is that a node connected to a single link = on a homenet that is dual-homed ought in principle to be able to behave = the same as if that node were connected to a single-homed homenet and = also to the other upstream provider (e.g., a mobile data service), or if = it were connected to the single upstream link with multiple provisioning = domains. For instance, one of the upstream networks may provide services not = accessible through the other upstream network. A classic example of = this would be a VPN, but this could also be something like a VoIP = service that is offered by one ISP, where the equivalent service is not = available through the other, or when accessed through the other does not = provide the same QoS guarantees. From nobody Thu Feb 19 11:36:53 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A1F1A1B2F; Thu, 19 Feb 2015 11:36:52 -0800 (PST) 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 13DD6y3xb6vT; Thu, 19 Feb 2015 11:36:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7A1A00F6; Thu, 19 Feb 2015 11:36:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193642.25205.35612.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:36:42 -0800 From: IETF Secretariat Archived-At: Subject: [mif] ID Tracker State Update Notice: 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: Thu, 19 Feb 2015 19:36:52 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Thu Feb 19 11:36:55 2015 Return-Path: X-Original-To: expand-draft-ietf-mif-mpvd-arch.all@virtual.ietf.org Delivered-To: mif@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 835881A7029; Thu, 19 Feb 2015 11:36:52 -0800 (PST) X-Original-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-mif-mpvd-arch.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A1F1A1B2F; Thu, 19 Feb 2015 11:36:52 -0800 (PST) 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 13DD6y3xb6vT; Thu, 19 Feb 2015 11:36:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7A1A00F6; Thu, 19 Feb 2015 11:36:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193642.25205.35612.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:36:42 -0800 From: IETF Secretariat Archived-At: Subject: [mif] ID Tracker State Update Notice: 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: Thu, 19 Feb 2015 19:36:52 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ From nobody Sat Feb 28 17:05:18 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F08E1A0141; Sat, 28 Feb 2015 17:05:15 -0800 (PST) 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 qIJ0iFeJIQ2s; Sat, 28 Feb 2015 17:05:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C95A1A0126; Sat, 28 Feb 2015 17:05:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150301010512.21194.56723.idtracker@ietfa.amsl.com> Date: Sat, 28 Feb 2015 17:05:12 -0800 Archived-At: Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-mpvd-ndp-support-01.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: Sun, 01 Mar 2015 01:05:15 -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 : Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol Authors : Jouni Korhonen Suresh Krishnan Sri Gundavelli Filename : draft-ietf-mif-mpvd-ndp-support-01.txt Pages : 11 Date : 2015-02-28 Abstract: The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. One part of the solution requires associating configuration information with provisioning domains. This document details how configuration information provided through IPv6 Neighbor Discovery Protocol can be associated with provisioning domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-ndp-support/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-mpvd-ndp-support-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-ndp-support-01 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 Sat Feb 28 18:39:48 2015 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC64B1A1B24; Sat, 28 Feb 2015 18:39:46 -0800 (PST) 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 yMdRlBRbu6oe; Sat, 28 Feb 2015 18:39:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBF71A1B0B; Sat, 28 Feb 2015 18:39:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150301023945.23585.83053.idtracker@ietfa.amsl.com> Date: Sat, 28 Feb 2015 18:39:45 -0800 Archived-At: Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-mpvd-id-01.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: Sun, 01 Mar 2015 02:39:47 -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 : Identification of provisioning domains Authors : Suresh Krishnan Jouni Korhonen Shwetha Bhandari Sri Gundavelli Filename : draft-ietf-mif-mpvd-id-01.txt Pages : 6 Date : 2015-02-28 Abstract: The MIF working group is producing a solution to solve the issues that are associated with nodes that can be attached to multiple networks. This document describes several methods of generating identification information for provisioning them and a format for carrying such identification in configuration protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-mpvd-id-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-id-01 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/