From nobody Sat May 3 20:42:23 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF0C1A0147; Sat, 3 May 2014 20:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JQPblDINXFY; Sat, 3 May 2014 20:42:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE511A0116; Sat, 3 May 2014 20:42:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> Date: Sat, 03 May 2014 20:42:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mif/p7BN7uOVM2AKw2Fb4JTxCTSygDE Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-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, 04 May 2014 03:42:20 -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-01.txt Pages : 19 Date : 2014-05-03 Abstract: This document is a product of the work of MIF architecture design team. It outlines a solution framework for some of the issues, experienced by nodes that can be attached to multiple networks. The framework defines the notion of a Provisioning Domain (PVD) - a consistent set of network configuration information, and PVD-aware nodes - nodes which learn PVDs from the attached network(s) and/or other sources and manage and use multiple PVDs for connectivity separately and consistently. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-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 May 3 20:51:11 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9951A0146 for ; Sat, 3 May 2014 20:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqmmSpsqIPpF for ; Sat, 3 May 2014 20:51:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB2F1A0144 for ; Sat, 3 May 2014 20:51:06 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.934.12; Sun, 4 May 2014 03:51:02 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.205]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.205]) with mapi id 15.00.0934.000; Sun, 4 May 2014 03:51:02 +0000 From: Dmitry Anipko To: "mif@ietf.org" Thread-Topic: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt Thread-Index: AQHPZ0rueEqsYx5Jz0inW8N3612uOJsvyYye Date: Sun, 4 May 2014 03:51:01 +0000 Message-ID: <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> References: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> In-Reply-To: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [32.159.20.179] x-forefront-prvs: 02015246A9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(428001)(377424004)(189002)(199002)(377454003)(479174003)(64706001)(80976001)(20776003)(76176999)(21056001)(54356999)(76576001)(19580395003)(19580405001)(83322001)(50986999)(81342001)(81542001)(74502001)(74662001)(80022001)(66066001)(46102001)(31966008)(86362001)(4396001)(77982001)(74316001)(76482001)(101416001)(2656002)(85852003)(33646001)(87936001)(16236675002)(99396002)(83072002)(86612001)(92566001)(15202345003)(99286001)(15975445006)(79102001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dmitry.Anipko@microsoft.com; Content-Type: multipart/alternative; boundary="_000_41ec8ac06a624cc1b89756c3d89626f4SN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/r-yW3eorBOAR_rfYa0uMfVaJyz4 Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 03:51:10 -0000 --_000_41ec8ac06a624cc1b89756c3d89626f4SN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This revision has changes supposed to address most comments made in London = as well as agreed changes from Alper's and Ian's reviews. For reference topologies / propagation of PVD info through intermediate rou= ters from ISP uplinks (e.g. Homenet) more changes are needed, it would be g= reat to see more inputs / discussion on the list around that. -Dmitry ________________________________ From: internet-drafts@ietf.org Sent: 5/3/2014 8:42 PM To: i-d-announce@ietf.org Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of the = IETF. Title : Multiple Provisioning Domain Architecture Author : Dmitry Anipko Filename : draft-ietf-mif-mpvd-arch-01.txt Pages : 19 Date : 2014-05-03 Abstract: This document is a product of the work of MIF architecture design team. It outlines a solution framework for some of the issues, experienced by nodes that can be attached to multiple networks. The framework defines the notion of a Provisioning Domain (PVD) - a consistent set of network configuration information, and PVD-aware nodes - nodes which learn PVDs from the attached network(s) and/or other sources and manage and use multiple PVDs for connectivity separately and consistently. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-mpvd-arch-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --_000_41ec8ac06a624cc1b89756c3d89626f4SN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This revision= has changes supposed to address most comments made in London as well as ag= reed changes from Alper's and Ian's reviews.

For reference topologies / propagation of PVD info through intermediate rou= ters from ISP uplinks (e.g. Homenet) more changes are needed, it would be g= reat to see more inputs / discussion on the list around that.

-Dmitry


From: intern= et-drafts@ietf.org
Sent: 5/3/20= 14 8:42 PM
To: i-d-an= nounce@ietf.org
Cc: mif@ie= tf.org
Subject: [mif] = I-D Action: draft-ietf-mif-mpvd-arch-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Multiple Interfaces Working Group of= the IETF.

        Title    &nb= sp;      : Multiple Provisioning Domain Architectu= re
        Author    &n= bsp;     : Dmitry Anipko
        Filename    =     : draft-ietf-mif-mpvd-arch-01.txt
        Pages    &nb= sp;      : 19
        Date    &nbs= p;       : 2014-05-03

Abstract:
   This document is a product of the work of MIF architecture des= ign
   team.  It outlines a solution framework for some of the i= ssues,
   experienced by nodes that can be attached to multiple networks= .  The
   framework defines the notion of a Provisioning Domain (PVD) - = a
   consistent set of network configuration information, and PVD-a= ware
   nodes - nodes which learn PVDs from the attached network(s) an= d/or
   other sources and manage and use multiple PVDs for connectivit= y
   separately and consistently.


The IETF datatracker status page for this draft is:
http= s://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/

There's also a htmlized version available at:
http://t= ools.ietf.org/html/draft-ietf-mif-mpvd-arch-01

A diff from the previous version is available at:
= http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mif-mpvd-arch-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/= mailman/listinfo/mif
 --_000_41ec8ac06a624cc1b89756c3d89626f4SN2PR03MB077namprd03pro_-- From nobody Sun May 4 23:23:15 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14541A0260 for ; Sun, 4 May 2014 23:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 63-EMEgc9hqJ for ; Sun, 4 May 2014 23:21:18 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id 505521A025D for ; Sun, 4 May 2014 23:21:17 -0700 (PDT) Received: from [192.168.43.129] (80.220.67.193) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D2ABA01714811; Mon, 5 May 2014 09:21:10 +0300 Content-Type: multipart/alternative; boundary="Apple-Mail=_B4FDA502-0155-4491-9A66-A207DCBADAFD" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Markus Stenberg In-Reply-To: <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> Date: Mon, 5 May 2014 08:21:06 +0200 Message-Id: References: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/mif/xFIM4xWHQQmX2m_s3t-V6BTPg7A X-Mailman-Approved-At: Sun, 04 May 2014 23:23:14 -0700 Cc: Markus Stenberg , "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 06:21:21 -0000 --Apple-Mail=_B4FDA502-0155-4491-9A66-A207DCBADAFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 4.5.2014, at 5.51, Dmitry Anipko wrote: > This revision has changes supposed to address most comments made in = London as well as agreed changes from Alper's and Ian's reviews.=20 >=20 > For reference topologies / propagation of PVD info through = intermediate routers from ISP uplinks (e.g. Homenet) more changes are = needed, it would be great to see more inputs / discussion on the list = around that. After some thinking on this topic, I think that implicit PVDs noted on = homenet edge towards ISPs have to be converted to explicit ones to be = offered to clients, if no information is to be lost. At least in IPv6 = case, IPv4 I=92m not sure how it should be even handled, perhaps as = fallback PVD-less potentially broken by two+ different NATs connectivity = :p As a random example, during the weekend we had a discussion on IRC about = some ISPs being sensitive about which source address is used with their = DNS server. This information isn=92t currently propagated in the = information available _from_ the ISPs explicitly (it=92s implicit by = definition), yet for even homenet routers to work correctly if there=92s = multiple upstream ISPs, the information needs to be available within the = homenet (e.g. =91we got this delegated prefix and this DNS address, use = them together=92) for the DNS resolution to work consistently. = Obviously, this can be also fixed by the homenet routers and then = presenting just themselves as DNS servers to the clients. As another random example, even if the ISP at end of 3G dongle isn=92t = providing explicit PVD, implicit PVD information should be bundled into = explicit one with the extra information available (in this case, that it = is not wired connection and has speed roughly of X, perhaps). So I=92m not really sure the text in 2.3 is that reasonable, because it = seems to assume implicit PVDs are generated (only?) on hosts, but in = case of homenet, I don=92t see the point in non-explicit PVDs coming = _to_ hosts except perhaps in case of IPv4 (too much magic related to = possibly more than one NAT needs to happen, and I=92m not sure we really = want to go there). Some other thoughts.. 5.2.3.1: Also, I=92d just rather treat PVD-bind as per-interface or per-address = one; if we can determine packet doesn=92t belong to it (outside the = application), application shouldn=92t know, and remote node shouldn=92t = know application is listening to some other PVD. So connection = refused/equivalent. Cheers, -Markus= --Apple-Mail=_B4FDA502-0155-4491-9A66-A207DCBADAFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On = 4.5.2014, at 5.51, Dmitry Anipko <Dmitry.Anipko@microsoft.com> wrote:
This revision has changes = supposed to address most comments made in London as well as agreed = changes from Alper's and Ian's reviews. 

For reference = topologies / propagation of PVD info through intermediate routers from = ISP uplinks (e.g. Homenet) more changes are needed, it would be great to = see more inputs / discussion on the list around = that.

Af= ter some thinking on this topic, I think that implicit PVDs noted on = homenet edge towards ISPs have to be converted to explicit ones to be = offered to clients, if no information is to be lost. At least in IPv6 = case, IPv4 I=92m not sure how it should be even handled, perhaps as = fallback PVD-less potentially broken by two+ different NATs connectivity = :p

As a random example, during the weekend we = had a discussion on IRC about some ISPs being sensitive about which = source address is used with their DNS server. This information isn=92t = currently propagated in the information available _from_ the ISPs = explicitly (it=92s implicit by definition), yet for even homenet routers = to work correctly if there=92s multiple upstream ISPs, the information = needs to be available within the homenet (e.g. =91we got this delegated = prefix and this DNS address, use them together=92) for the DNS = resolution to work consistently.  Obviously, this can be also fixed = by the homenet routers and then presenting just themselves as DNS = servers to the clients.

As another random = example, even if the ISP at end of 3G dongle isn=92t providing explicit = PVD, implicit PVD information should be bundled into explicit one with = the extra information available (in this case, that it is not wired = connection and has speed roughly of X, = perhaps).

So I=92m not really sure the text in = 2.3 is that reasonable, because it seems to assume implicit PVDs are = generated (only?) on hosts, but in case of homenet, I don=92t see the = point in non-explicit PVDs coming _to_ hosts except perhaps in case of = IPv4 (too much magic related to possibly more than one NAT needs to = happen, and I=92m not sure we really want to go = there).

Some other = thoughts..

5.2.3.1:

Also= , I=92d just rather treat PVD-bind as per-interface or per-address one; = if we can determine packet doesn=92t belong to it (outside the = application), application shouldn=92t know, and remote node shouldn=92t = know application is listening to some other PVD. So connection = refused/equivalent.

Cheers,

-Markus=
= --Apple-Mail=_B4FDA502-0155-4491-9A66-A207DCBADAFD-- From nobody Wed May 7 01:29:07 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E331A0186 for ; Wed, 7 May 2014 01:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIk3IBaysp1A for ; Wed, 7 May 2014 01:29:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C05021A0278 for ; Wed, 7 May 2014 01:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mif@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507082904.2101.49014.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 01:29:04 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mif/wZXDd6Vrcafp5q07IOik8Yc6QWE Subject: [mif] Milestones changed for mif WG 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, 07 May 2014 08:29:07 -0000 Deleted milestone "Initial WG draft on DHCPv6 option for routing configuration". Changed milestone "Analysis draft submitted to the IESG for publication as an Informational RFC", resolved as "Done". Deleted milestone "Submit DHCPv6 routing configuration option to IESG for publication as a Proposed Standard RFC". Deleted milestone "Submit MIF API extension solution to IESG for publication as an Informational RFC". URL: http://datatracker.ietf.org/wg/mif/charter/ From nobody Wed May 7 07:10:57 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC731A031A for ; Wed, 7 May 2014 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ0P3YpacerP for ; Wed, 7 May 2014 07:10:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5921A077A for ; Wed, 7 May 2014 07:10:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mif@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507141051.12364.74780.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 07:10:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mif/xg_FWplQ63kEIFk_1bWvJpTS9Co Subject: [mif] Milestones changed for mif WG 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, 07 May 2014 14:10:54 -0000 Changed milestone "Initial draft on MPvD architecture adopted by the WG", set state to active from review, accepting new milestone. Changed milestone "MPvD Architecture draft submitted to the IESG for publication as an Informational RFC", set state to active from review, accepting new milestone. Changed milestone "Initial draft on the requirements for changes to DHCPv6 and ND adopted by the WG", set state to active from review, accepting new milestone. Changed milestone "Initial draft on the guidance to applications adopted by the WG", set state to active from review, accepting new milestone. Changed milestone "MIF API extension solution to IESG for publication as an Informational RFC", set state to active from review, accepting new milestone. Changed milestone "Initial draft on high level MIF API adopted by the WG", set state to active from review, accepting new milestone. Changed milestone "Initial draft on format and usage of PvD ID adoped by the WG", set state to active from review, accepting new milestone. Changed milestone "Initial draft on DHCPv6 and ND extention adopted by the WG", set state to active from review, accepting new milestone. Changed milestone "Requirements for changes to DHCPv6 and ND submitted to the IESG for publication as an Informational RFC", set state to active from review, accepting new milestone. Changed milestone "Guidance to applications submitted to the IESG for publication as an Informational RFC", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mif/charter/ From nobody Fri May 9 19:52:01 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737221A00FE for ; Fri, 9 May 2014 19:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx0mNVU3_opF for ; Fri, 9 May 2014 19:51:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id EBE721A011D for ; Fri, 9 May 2014 19:51:50 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.939.12; Sat, 10 May 2014 02:51:44 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.84]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.84]) with mapi id 15.00.0939.000; Sat, 10 May 2014 02:51:43 +0000 From: Dmitry Anipko To: Markus Stenberg Thread-Topic: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt Thread-Index: AQHPZ0rueEqsYx5Jz0inW8N3612uOJsvyYyegAG8QgCAB5zvwA== Date: Sat, 10 May 2014 02:51:43 +0000 Message-ID: References: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(377454003)(51444003)(52024003)(45914002)(24454002)(21056001)(76576001)(15975445006)(19609705001)(81342001)(20776003)(99286001)(64706001)(50986999)(54356999)(80022001)(76176999)(15202345003)(74316001)(19625215002)(79102001)(81542001)(4396001)(99396002)(2656002)(76482001)(33646001)(87936001)(19300405004)(92566001)(86362001)(83072002)(85852003)(16236675002)(19580395003)(77982001)(46102001)(74662001)(101416001)(31966008)(19580405001)(74502001)(83322001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dmitry.Anipko@microsoft.com; Content-Type: multipart/alternative; boundary="_000_e423e57ead744358a5ee3361bcb2b15dSN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/KNbXYOEfF7yFWOrWu1fgicf-Qt8 Cc: "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 02:51:59 -0000 --_000_e423e57ead744358a5ee3361bcb2b15dSN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Markus, Thank you for the comments. In the Homenet scenario you described, I agree = on the substance with what you wrote - if the router can do such formation = of explicit PVDs, it should do that to prevent mix-up of configuration. Suc= h text can be added into the section 4, example network configuration and n= umber of PVDs. That said, I don't think it contradicts to 2.3, because Impl= icit PVDs by definition in 2.2. apply only when there the network is non-PV= D aware: It is likely that for a long time there may be networks which do not advertise explicit PVD information, since deployment of any new features in networking protocols is a relatively slow process. When connected to networks, which don't advertise explicit PVD information, PVD-aware node shall automatically create separate PVDs for received configuration. Such PVDs are referred to in this document as "implicit". So from the host perspective, presence of a router, which can/does advertis= e PVDs, makes it a scenario with explicit PVDs, and not implicit ones. >>, I don't see the point in non-explicit PVDs coming _to_ hosts except per= haps in case of IPv4 My understanding, is that the main reason we introduced the notion of impli= cit PVD is to be able to handle configurations received on multiple interfa= ces (which typically are connected to different networks) in the same way a= s in the case of multiple explicit PVDs, basically to unify and simplify co= nceptual host implementation. The acknowledged limitation is that we don't = know well how to form multiple implicit PVDs on one interface (or form impl= icit PVDs, spanning multiple interface). >> Also, I'd just rather treat PVD-bind as per-interface or per-address one= ; if we can determine packet doesn't belong to it (outside the application)= , application shouldn't know, and remote node shouldn't know application is= listening to some other PVD. So connection refused/equivalent. The current text is If the determined receiving PVD of the packet is not in the allowed subset of PVDs for the particular app/transport API object, the packet should be handled in the same way as if there were no listener (alternatives - error message 'administratively prohibited', or just refer to pre-PVD behavior for legacy behavior for interface-scoped binds). It seems the case you described would be where the "allowed subset of PVDs"= contains only one PVD. If you think the current text is not sufficient, ca= n you please suggest the change? -Dmitry From: Markus Stenberg [mailto:markus.stenberg@iki.fi] Sent: Sunday, May 4, 2014 11:21 PM To: Dmitry Anipko Cc: Markus Stenberg; mif@ietf.org Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt On 4.5.2014, at 5.51, Dmitry Anipko > wrote: This revision has changes supposed to address most comments made in London = as well as agreed changes from Alper's and Ian's reviews. For reference topologies / propagation of PVD info through intermediate rou= ters from ISP uplinks (e.g. Homenet) more changes are needed, it would be g= reat to see more inputs / discussion on the list around that. After some thinking on this topic, I think that implicit PVDs noted on home= net edge towards ISPs have to be converted to explicit ones to be offered t= o clients, if no information is to be lost. At least in IPv6 case, IPv4 I'm= not sure how it should be even handled, perhaps as fallback PVD-less poten= tially broken by two+ different NATs connectivity :p As a random example, during the weekend we had a discussion on IRC about so= me ISPs being sensitive about which source address is used with their DNS s= erver. This information isn't currently propagated in the information avail= able _from_ the ISPs explicitly (it's implicit by definition), yet for even= homenet routers to work correctly if there's multiple upstream ISPs, the i= nformation needs to be available within the homenet (e.g. 'we got this dele= gated prefix and this DNS address, use them together') for the DNS resoluti= on to work consistently. Obviously, this can be also fixed by the homenet = routers and then presenting just themselves as DNS servers to the clients. As another random example, even if the ISP at end of 3G dongle isn't provid= ing explicit PVD, implicit PVD information should be bundled into explicit = one with the extra information available (in this case, that it is not wire= d connection and has speed roughly of X, perhaps). So I'm not really sure the text in 2.3 is that reasonable, because it seems= to assume implicit PVDs are generated (only?) on hosts, but in case of hom= enet, I don't see the point in non-explicit PVDs coming _to_ hosts except p= erhaps in case of IPv4 (too much magic related to possibly more than one NA= T needs to happen, and I'm not sure we really want to go there). Some other thoughts.. 5.2.3.1: Also, I'd just rather treat PVD-bind as per-interface or per-address one; i= f we can determine packet doesn't belong to it (outside the application), a= pplication shouldn't know, and remote node shouldn't know application is li= stening to some other PVD. So connection refused/equivalent. Cheers, -Markus --_000_e423e57ead744358a5ee3361bcb2b15dSN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Markus,

 

Thank you for the comments. In the Homenet scenario you = described, I agree on the substance with what you wrote – if the rout= er can do such formation of explicit PVDs, it should do that to prevent mix-up of configuration. Such text can be added into the section 4= , example network configuration and number of PVDs. That said, I don’= t think it contradicts to 2.3, because Implicit PVDs by definition in 2.2. = apply only when there the network is non-PVD aware:

 

<Quote>

   It is li= kely that for a long time there may be networks which do not

   advertis= e explicit PVD information, since deployment of any new

   features= in networking protocols is a relatively slow process.

 

   When con= nected to networks, which don't advertise explicit PVD

   informat= ion, PVD-aware node shall automatically create separate PVDs

   for rece= ived configuration.  Such PVDs are referred to in this

   document= as "implicit".

</quote>

 

So from the host perspective, presence of a router, whic= h can/does advertise PVDs, makes it a scenario with explicit PVDs, and not = implicit ones.

 

>>, I don’t see the point in non-explicit= PVDs coming _to_ hosts except perhaps in case of IPv4

 

My understanding, is that the main reason we introduced = the notion of implicit PVD is to be able to handle configurations received = on multiple interfaces (which typically are connected to different networks) in the same way as in the case of multiple explicit PV= Ds, basically to unify and simplify conceptual host implementation. The ack= nowledged limitation is that we don’t know well how to form multiple = implicit PVDs on one interface (or form implicit PVDs, spanning multiple interface).

 

>> Also, I’d just rather treat PVD-bind a= s per-interface or per-address one; if we can determine packet doesn’= t belong to it (outside the application), application shouldn’t know, and remote node should= n’t know application is listening to some other PVD. So connection re= fused/equivalent.

 

The current text is

<quote>

  If the determin=
ed receiving PVD of the packet is not in the allowed

   subset of=
 PVDs for the particular app/transport API object, the

   packet sh=
ould be handled in the same way as if there were no listener


   (alternat=
ives - error message 'administratively prohibited', or just


   refer to =
pre-PVD behavior for legacy behavior for interface-scoped=



   binds).


</quiote>


 


It seems the case you described would be where the ̶=
0;allowed subset of PVDs” contains only one PVD. If you think the cur=
rent text is not sufficient, can you please suggest the change?<=
/span>


 


-Dmitry


 <=
/p>





From: Markus=
 Stenberg [mailto:markus.stenberg@iki.fi]


Sent: Sunday, May 4, 2014 11:21 PM

To: Dmitry Anipko

Cc: Markus Stenberg; mif@ietf.org

Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt<=
/o:p>






 


On 4.5.2014, at 5.51, Dmitry Anipko <Dmitry.Anipko@microsoft.com> wrot=
e:














This revision has changes supposed to a=
ddress most comments made in London as well as agreed changes from Alper's =
and Ian's reviews. 



For reference topologies / propagation of PVD info through intermediate rou=
ters from ISP uplinks (e.g. Homenet) more changes are needed, it would be g=
reat to see more inputs / discussion on the list around that.
















 






After some thinking on this topic, I think that impl=
icit PVDs noted on homenet edge towards ISPs have to be converted to explic=
it ones to be offered to clients, if no information is to be lost. At least=
 in IPv6 case, IPv4 I’m not sure how
 it should be even handled, perhaps as fallback PVD-less potentially broken=
 by two+ different NATs connectivity :p






 






As a random example, during the weekend we had a dis=
cussion on IRC about some ISPs being sensitive about which source address i=
s used with their DNS server. This information isn’t currently propag=
ated in the information available _from_
 the ISPs explicitly (it’s implicit by definition), yet for even home=
net routers to work correctly if there’s multiple upstream ISPs, the =
information needs to be available within the homenet (e.g. ‘we got th=
is delegated prefix and this DNS address, use them
 together’) for the DNS resolution to work consistently.  Obviou=
sly, this can be also fixed by the homenet routers and then presenting just=
 themselves as DNS servers to the clients.






 






As another random example, even if the ISP at end of=
 3G dongle isn’t providing explicit PVD, implicit PVD information sho=
uld be bundled into explicit one with the extra information available (in t=
his case, that it is not wired connection
 and has speed roughly of X, perhaps).






 






So I’m not really sure the text in 2.3 is that=
 reasonable, because it seems to assume implicit PVDs are generated (only?)=
 on hosts, but in case of homenet, I don’t see the point in non-expli=
cit PVDs coming _to_ hosts except perhaps in case
 of IPv4 (too much magic related to possibly more than one NAT needs to hap=
pen, and I’m not sure we really want to go there).






 






Some other thoughts..






 






5.2.3.1:






 






Also, I’d just rather treat PVD-bind as per-in=
terface or per-address one; if we can determine packet doesn’t belong=
 to it (outside the application), application shouldn’t know, and rem=
ote node shouldn’t know application is listening to
 some other PVD. So connection refused/equivalent.






 






Cheers,




 




-Markus
--_000_e423e57ead744358a5ee3361bcb2b15dSN2PR03MB077namprd03pro_-- From nobody Mon May 12 00:59:53 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE801A041E for ; Mon, 12 May 2014 00:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 TwplDaOyEIYP for ; Mon, 12 May 2014 00:59:48 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.198]) by ietfa.amsl.com (Postfix) with ESMTP id 39EA11A0437 for ; Mon, 12 May 2014 00:59:47 -0700 (PDT) Received: from kosame.lan (80.220.67.193) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D34B50202DCC4; Mon, 12 May 2014 10:59:37 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Markus Stenberg In-Reply-To: Date: Mon, 12 May 2014 10:59:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/mif/ddet4c33tZRk_nsPgil5AyUhRuo Cc: "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 07:59:51 -0000 On 10.5.2014, at 5.51, Dmitry Anipko = wrote: > Thank you for the comments. In the Homenet scenario you described, I = agree on the substance with what you wrote =96 if the router can do such = formation of explicit PVDs, it should do that to prevent mix-up of = configuration. Such text can be added into the section 4, example = network configuration and number of PVDs. That said, I don=92t think it = contradicts to 2.3, because Implicit PVDs by definition in 2.2. apply = only when there the network is non-PVD aware: > =20 > > It is likely that for a long time there may be networks which do = not > advertise explicit PVD information, since deployment of any new > features in networking protocols is a relatively slow process. > =20 > When connected to networks, which don't advertise explicit PVD > information, PVD-aware node shall automatically create separate = PVDs > for received configuration. Such PVDs are referred to in this > document as "implicit". > > =20 > So from the host perspective, presence of a router, which can/does = advertise PVDs, makes it a scenario with explicit PVDs, and not implicit = ones. 2.2 has also that mixed implicit+explicit mode which I=92d rather see = die in fire, because it makes the definition just more complicated. I = think interface should be either fully explicit, or fully implicit, = because mixed mode is a) more complicated, and b) possible to fail = (implicit in general does, and mixed doesn=92t help here). > >>, I don=92t see the point in non-explicit PVDs coming _to_ hosts = except perhaps in case of IPv4=20 > My understanding, is that the main reason we introduced the notion of = implicit PVD is to be able to handle configurations received on multiple = interfaces (which typically are connected to different networks) in the = same way as in the case of multiple explicit PVDs, basically to unify = and simplify conceptual host implementation. The acknowledged limitation = is that we don=92t know well how to form multiple implicit PVDs on one = interface (or form implicit PVDs, spanning multiple interface). See my comment above about fail - I=92m not convinced implicit PVDs work = well in any case. BCP38-ish filtering by upstream ISPs on either normal = data traffic or DNS requests, etc =3D> you can=92t just pool parameters = together implicitly and hope they work. > >> Also, I=92d just rather treat PVD-bind as per-interface or = per-address one; if we can determine packet doesn=92t belong to it = (outside the application), application shouldn=92t know, and remote node = shouldn=92t know application is listening to some other PVD. So = connection refused/equivalent. > =20 > The current text is > > If the determined receiving PVD of the packet is not in the allowed > subset of PVDs for the particular app/transport API object, the > packet should be handled in the same way as if there were no = listener > (alternatives - error message 'administratively prohibited', or = just > refer to pre-PVD behavior for legacy behavior for interface-scoped > binds). > > =20 > It seems the case you described would be where the =93allowed subset = of PVDs=94 contains only one PVD. If you think the current text is not = sufficient, can you please suggest the change? Well, I=92m mostly concerned about complexity of that whole section - = having dealt with brokenness of cross-platform dual AF IPv6 sockets = recently[1], I=92m not very keen to have very complicated semantics = anywhere. All of that reverse-RPF stuff etc sounds just overkill to me = (and potentially harmful, if you assume someone actually has PI address = space coming from multiple connections). If it was up to me, I=92d get = rid of cross-PVD filtering stuff altogether and leave it as exercise to = firewall vendor or whoever really cares. I don=92t see it affecting the = PVD semantics in any way, except adding extra text.=20 So: concrete proposal - nuke second paragraph, remove alternatives from = third paragraph. Cheers, -Markus From nobody Sat May 17 06:04:49 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4151A007D for ; Sat, 17 May 2014 06:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4udqXOLkD2h for ; Sat, 17 May 2014 06:04:42 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A251A007E for ; Sat, 17 May 2014 06:04:41 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id db11so4540654veb.1 for ; Sat, 17 May 2014 06:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qIokt/7U3DSSACfxfSPuDUpFpwn/7f1yC16WBL3CjJM=; b=TTw+qPmqIS2y+zXLetixbUOVPSYl0fo7TfyIuJVMqiFyKLz9pT0bP5NpRMzmSivlut SiEy29xlCE6Zul0ZlNJz7Dx6MHDiJQ7m6D17/OCgPJpMwvw1h2T7u+QcidFVZueVAJ2A /osx/qyD//QQvVIbpjCuMV2me/crAh/Fqpz0pCvdZpnVhxeMuvbR8KMzb+UWgVfTVWOJ 0zkjzEDS84f2qI9jhTv2EcrqCm0eiVdCX3/BUN7vYCmJqSOnjicX732SCIvBYDcr2tTO UGRPkpU6wrIT+2G14/PCH7alJkHrkbCkkLhYXQYpkkUNbhGGxXUEyNa9uuGZUn8PhQ6+ TR0w== MIME-Version: 1.0 X-Received: by 10.53.13.133 with SMTP id ey5mr2243719vdd.8.1400331873679; Sat, 17 May 2014 06:04:33 -0700 (PDT) Received: by 10.220.252.132 with HTTP; Sat, 17 May 2014 06:04:33 -0700 (PDT) In-Reply-To: <9913.1400250296@sandelman.ca> References: <9913.1400250296@sandelman.ca> Date: Sat, 17 May 2014 21:04:33 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/mixed; boundary=001a1134cd1ee60fa704f9982bde Archived-At: http://mailarchive.ietf.org/arch/msg/mif/EO66GbtJFQEB-SlYW8kSGFCKvX8 Subject: [mif] Fwd: NomCom 2014-2015 Call for Volunteers X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 13:04:47 -0000 --001a1134cd1ee60fa704f9982bde Content-Type: multipart/alternative; boundary=001a1134cd1ee60fa304f9982bdc --001a1134cd1ee60fa304f9982bdc Content-Type: text/plain; charset=UTF-8 Encouraging. ---------- Forwarded message ---------- From: Michael Richardson Date: 2014-05-16 22:24 GMT+08:00 Subject: NomCom 2014-2015 Call for Volunteers To: ietf@ietf.org {I have to post using my subscribed address. Appologies for duplicates} The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org --001a1134cd1ee60fa304f9982bdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Encouraging.

---------- = Forwarded message ----------
From: Michael= Richardson <mcr+ietf@sandelman.ca>
Date: 2014-05-16 22:24 GMT+08:00
Subject: NomCom 2014-2015 Call for Volu= nteers
To: ietf@ietf.org


{I have to post using my subscribed address. Appologies for duplicates}

The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,
and the IESG (including IETF Chair).

Ten voting members for the nomcom are selected in a verifiably random
way from a pool of volunteers. The more volunteers, the better chance we ha= ve of
choosing a random yet representative cross section of the IETF population.<= br>
Let's break the 200 volunteer mark again this year!

The details of the operation of the nomcom can be found in RFC 3777,
and BCP10/RFC3797 details the selection algorithm.

Volunteers must have attended 3 of the past 5 IETF meetings. =C2=A0As speci= fied in
RFC 3777, that means three out of the five past meetings up to the time thi= s
email announcement goes out to start the solicitation of volunteers.
The five meetings out of which you must have attended *three*
are IETF 85(Atlanta), =C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A086(Orlando), =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A087(Berlin), =C2=A0 =C2=A0 =C2=A0 =C2=A0 *= ** ANY THREE!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A088(Vancouver), =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A089(London) =C2=A0 =C2=A0 =C2=A0 =C2=A0/
If you qualify, please volunteer. =C2=A0 However, much as we want this, bef= ore you
decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible.

The list of people and posts whose terms end with the March 2015 IETF
meeting, and thus the positions for which this nomcom is responsible, are
IAOC:
To be confirmed

IAB:
Joel Halpern
Russ Housley
Eliot Lear
Xing Li
Andrew Sullivan
Dave Thaler

IESG:
Pete Resnick (Applications)
Ted Lemon (Internet)
Joel Jaeggli (Operations and Management)
Richard Barnes (RAI)
Adrian Farrel* (Routing)
Stephen Farrell (Security)
Spencer Dawkins (Transport)
Jari Arkko (Gen)

(names with * have publically indicated they will not serve another term)
The primary activity for this nomcom will begin in July 2014 and should be<= br> completed in January 2015. =C2=A0 The nomcom will have regularly scheduled<= br> conference calls to ensure progress. (We might dogfood WebRTC)
There will be activities to collect requirements from the community, review=
candidate questionnaires, review feedback from community members about
candidates, and talk to candidates.

Thus, being a nomcom member does require some time commitment; but it is al= so
a very rewarding experience.

It is very important that you be able to attend IETF91 to conduct interview= s.
Being at IETF90 is useful for training. =C2=A0Being at IETF92 is not essent= ial.

Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)<= br> June 22, 2013, as follows:

To: nomcom-chair-2014@ietf.or= g
Subject: Nomcom 2014-15 Volunteer

Please include the following information in the email body:

=C2=A0<Your Full Name>
=C2=A0 =C2=A0 // First/Given Name followed by Last/Family Name
=C2=A0 =C2=A0 // matching how you enter it in the IETF Registration Form)
=C2=A0<Current Primary Affiliation>
=C2=A0 =C2=A0 // Typically what goes in the Company field
=C2=A0 =C2=A0 // in the IETF Registration Form
[<All email addresses used to register for the past 5 IETF meetings>]=
=C2=A0<Preferred email address>
=C2=A0<Telephone number>
=C2=A0 =C2=A0 // For confirmation if selected

You should expect an email response from me within 3 business days stating<= br> whether or not you are qualified. =C2=A0If you don't receive this respo= nse,
please re-send your email with the tag "RESEND"" added to th= e subject line.

If you are not yet sure if you would like to volunteer, please consider
that nomcom members play a very important role in shaping the leadership of the IETF. =C2=A0Questions by email or voice are welcome.
Volunteering for the nomcom is a great way to contribute to the IETF!

You can find a detailed timeline on the nomcom web site at:
=C2=A0 =C2=A0 https://datatracker.ietf.org/nomcom/2014/

I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process,
within the next couple weeks.

Thank you!
Michael Richardson
mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org


--001a1134cd1ee60fa304f9982bdc-- --001a1134cd1ee60fa704f9982bde Content-Type: application/pgp-signature Content-Disposition: attachment Content-Transfer-Encoding: base64 X-Attachment-Id: 24b15937e7082341_0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdO VS9MaW51eCkNCg0KaVFFVkF3VUJVM1lmdDRDTGNQdmQwTjFsQVFLNEVnZi9WZmxWbmdiTHU3NEhp ai83WUtDbGVLcG8ybWZUVi90NA0KZXFoWnJ3ZFpIdUpYa203ZWVhM25OU3RuY0F0YmNHQ0dYVGV2 NVk4RDJBTHZCbWpnVGZaUWp6NGFzZHI1TVNwZw0KRndoQzVlU1JFUkVtWmJJTmZuN1gvY204dkVz VGlaMUNud09RR0cxbE9WMVRDVDhNaDRoQU1idmllYm1Ed050WQ0KTWVmU1VkV21SYkF4TkdqbDJm QkRoeDRvV3lNaDNaa1hyWnNwMlNHMzloUWoweFZUcGEvdXJvMGRqNFB3Q0NKSg0KY01xZ21FSndV dVV6S3N0Qnc2OFNwbE9weWVCK3g2cWdUMHJlWitGdkV4bW5PK2ZYQ3Q0SHNuckRvQ0JERHJKeA0K Z0lBUERpNWx1WmZKd3MzWnFuaEkvM2hVMU1odWlPR2JySFFGSmhhRG1qKzBOT1hvM1duRHZ3PT0N Cj1PUHM3DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0= --001a1134cd1ee60fa704f9982bde-- From nobody Sat May 17 19:08:44 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068581A02A6 for ; Sat, 17 May 2014 19:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSxEu_tqFuDK for ; Sat, 17 May 2014 19:08:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112481A02A5 for ; Sat, 17 May 2014 19:08:40 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.944.11; Sun, 18 May 2014 02:08:37 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.126]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.126]) with mapi id 15.00.0944.000; Sun, 18 May 2014 02:08:37 +0000 From: Dmitry Anipko To: Markus Stenberg Thread-Topic: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt Thread-Index: AQHPZ0rueEqsYx5Jz0inW8N3612uOJsvyYyegAG8QgCAB5zvwIADfugAgAkLLrk= Date: Sun, 18 May 2014 02:08:36 +0000 Message-ID: <1400378915555.221@microsoft.com> References: <20140504034218.19850.94379.idtracker@ietfa.amsl.com> <41ec8ac06a624cc1b89756c3d89626f4@SN2PR03MB077.namprd03.prod.outlook.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.22.40.63] x-forefront-prvs: 0215D7173F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(45914002)(377454003)(24454002)(51704005)(66066001)(80022001)(86362001)(64706001)(86612001)(20776003)(79102001)(21056001)(4396001)(85852003)(83072002)(87936001)(2656002)(81342001)(81542001)(83322001)(19580405001)(19580395003)(36756003)(77982001)(76482001)(74502001)(74662001)(101416001)(99396002)(99286001)(561944003)(46102001)(92566001)(54356999)(92726001)(31966008)(76176999)(50986999)(22906005); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dmitry.Anipko@microsoft.com; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/kgCnwtI-zCfOzQJTEvIeH7Z6a80 Cc: "mif@ietf.org" Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 02:08:43 -0000 Hi Markus,=0A= =0A= thank you for the discussion, please find my responses below:=0A= =0A= >>I think interface should be either fully explicit, or fully implicit, bec= ause mixed mode is a) more complicated, and b) possible to fail (implicit i= n general does, and mixed doesn=92t help here).=0A= =0A= I=92d be happy to kill the mix mode :-), but basically here is the line of = reasoning which lead to to it:=0A= =0A= 1. In practice, can the node encounter the mixed scenario - e.g. where the = node has an interface, connected to a link, with a PVD-aware and non-PVD aw= are routers? My default assumption is that it can, since it seems to me tec= hnically possible, and I couldn=92t think of any strong reason, why that wo= uld not happen in practice. If you think the node won=92t encounter such co= nfiguration, please elaborate why. =0A= =0A= 2. If you agree that the node can encounter such configuration, then should= the document describe a suggested node behavior, or leave it out of scope?= If the latter, why? If the former, what should the behavior be, if it is d= ifferent from what currently is in the text?=0A= =0A= >>See my comment above about fail - I=92m not convinced implicit PVDs work = well in any case. BCP38-ish filtering by upstream ISPs on either normal dat= a traffic or DNS requests, etc =3D> you can=92t just pool parameters togeth= er implicitly and hope they work.=0A= =0A= Somehow it seems on this item we=92re talking past each other. From my prev= ious email:=0A= =0A= the main reason we introduced the notion of implicit PVD is to be ab= le to handle configurations received on multiple interfaces (which typicall= y are connected to different networks)=0A= =0A= Do you agree that in the scenario in the quote, where the node has interfac= e 1 connected to ISP A, and interface 2 connected to ISP B, implicit PVDs c= an improve the behavior? (because config from the different ISPs is not acc= identally mixed across interfaces) =0A= =0A= If you disagree, please elaborate why. (If this is what the BCP38 text was = referring to, please elaborate, because I could not follow how it would rel= ate to this scenario) =0A= =0A= If you agree, then if the implicit PVDs do help in this scenario, and don= =92t help and don=92t harm in other scenarios (such as the one you seem to = be describing), it seems that it is appropriate to let them be? Additional = potential benefit is that having implicit PVDs allows for the node to have = a common =93PVD-aware=94 code path to handle all cases, instead of having s= pecial =93PVD=94 and =93non-PVD=94 code scattered around).=0A= =0A= >>So: concrete proposal - nuke second paragraph, remove alternatives from t= hird paragraph.=0A= =0A= Thanks. I=92ll remove the alternatives from the third paragraph, and replac= e the second paragraph with a phrase along the lines, that a node OS or mid= dleware, such as firewall, may apply more complex techniques for incoming t= raffic filtering, but that =92s out of scope for this document. Will that w= ork?=0A= =0A= -Dmitry=0A= ________________________________________=0A= From: Markus Stenberg =0A= Sent: Monday, May 12, 2014 12:59 AM=0A= To: Dmitry Anipko=0A= Cc: Markus (Old) Stenberg; mif@ietf.org=0A= Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt=0A= =0A= On 10.5.2014, at 5.51, Dmitry Anipko wrote:= =0A= > Thank you for the comments. In the Homenet scenario you described, I agre= e on the substance with what you wrote =96 if the router can do such format= ion of explicit PVDs, it should do that to prevent mix-up of configuration.= Such text can be added into the section 4, example network configuration a= nd number of PVDs. That said, I don=92t think it contradicts to 2.3, becaus= e Implicit PVDs by definition in 2.2. apply only when there the network is = non-PVD aware:=0A= >=0A= > =0A= > It is likely that for a long time there may be networks which do not= =0A= > advertise explicit PVD information, since deployment of any new=0A= > features in networking protocols is a relatively slow process.=0A= >=0A= > When connected to networks, which don't advertise explicit PVD=0A= > information, PVD-aware node shall automatically create separate PVDs= =0A= > for received configuration. Such PVDs are referred to in this=0A= > document as "implicit".=0A= > =0A= >=0A= > So from the host perspective, presence of a router, which can/does advert= ise PVDs, makes it a scenario with explicit PVDs, and not implicit ones.=0A= =0A= 2.2 has also that mixed implicit+explicit mode which I=92d rather see die i= n fire, because it makes the definition just more complicated. I think inte= rface should be either fully explicit, or fully implicit, because mixed mod= e is a) more complicated, and b) possible to fail (implicit in general does= , and mixed doesn=92t help here).=0A= =0A= > >>, I don=92t see the point in non-explicit PVDs coming _to_ hosts except= perhaps in case of IPv4=0A= > My understanding, is that the main reason we introduced the notion of imp= licit PVD is to be able to handle configurations received on multiple inter= faces (which typically are connected to different networks) in the same way= as in the case of multiple explicit PVDs, basically to unify and simplify = conceptual host implementation. The acknowledged limitation is that we don= =92t know well how to form multiple implicit PVDs on one interface (or form= implicit PVDs, spanning multiple interface).=0A= =0A= See my comment above about fail - I=92m not convinced implicit PVDs work we= ll in any case. BCP38-ish filtering by upstream ISPs on either normal data = traffic or DNS requests, etc =3D> you can=92t just pool parameters together= implicitly and hope they work.=0A= =0A= > >> Also, I=92d just rather treat PVD-bind as per-interface or per-address= one; if we can determine packet doesn=92t belong to it (outside the applic= ation), application shouldn=92t know, and remote node shouldn=92t know appl= ication is listening to some other PVD. So connection refused/equivalent.= =0A= >=0A= > The current text is=0A= > =0A= > If the determined receiving PVD of the packet is not in the allowed=0A= > subset of PVDs for the particular app/transport API object, the=0A= > packet should be handled in the same way as if there were no listener= =0A= > (alternatives - error message 'administratively prohibited', or just= =0A= > refer to pre-PVD behavior for legacy behavior for interface-scoped=0A= > binds).=0A= > =0A= >=0A= > It seems the case you described would be where the =93allowed subset of P= VDs=94 contains only one PVD. If you think the current text is not sufficie= nt, can you please suggest the change?=0A= =0A= Well, I=92m mostly concerned about complexity of that whole section - havin= g dealt with brokenness of cross-platform dual AF IPv6 sockets recently[1],= I=92m not very keen to have very complicated semantics anywhere. All of th= at reverse-RPF stuff etc sounds just overkill to me (and potentially harmfu= l, if you assume someone actually has PI address space coming from multiple= connections). If it was up to me, I=92d get rid of cross-PVD filtering stu= ff altogether and leave it as exercise to firewall vendor or whoever really= cares. I don=92t see it affecting the PVD semantics in any way, except add= ing extra text.=0A= =0A= So: concrete proposal - nuke second paragraph, remove alternatives from thi= rd paragraph.=0A= =0A= Cheers,=0A= =0A= -Markus=0A= =0A=