From Dirk.von-Hugo@telekom.de Fri Oct 1 03:59:42 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F8D3A6B6F for ; Fri, 1 Oct 2010 03:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq00dJHAQArt for ; Fri, 1 Oct 2010 03:59:41 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 0AE923A6BDD for ; Fri, 1 Oct 2010 03:59:40 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 01 Oct 2010 13:00:24 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 13:00:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Oct 2010 13:00:22 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC802784802A22A56@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis thread-index: Actg8dNNDiPGkZcmR/myR0N6Q77PAwAADJogABZTHfA= References: <4CA12C64.1090606@computer.org> <4CA513F6.8000508@earthlink.net> From: To: X-OriginalArrivalTime: 01 Oct 2010 11:00:23.0978 (UTC) FILETIME=[D8EEF8A0:01CB6157] Cc: julienl@qualcomm.com, mext-chairs@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 10:59:42 -0000 Hi Charlie, ... and I MAY have detected further very minor nits like P.21 "Home Address Destination option" =3D> "Home Address destination option" = P.22 "the Binding Updates messages" =3D> "the Binding Update messages" P.66=20 "is the first Prefix Length bits" =3D> "is given by the first Prefix = Length bits" P.106 "Mobile Prefix Advertisements messages" =3D> "Mobile Prefix Advertisement messages" ... and finally beside 50 something times spelling "Binding Cache entry" = we also have still 8 times "binding cache entry" within the document - = IMHO this should be harmonized ;-)=20 Otherwise it's fine with me - thanks! Best regards Dirk =20 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von = Laganier, Julien Gesendet: Freitag, 1. Oktober 2010 00:56 An: Charles E. Perkins; mext@ietf.org Cc: mext-chairs@tools.ietf.org Betreff: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: = Finishing RFC 3775bis Hello Charlie, Charles E. Perkins wrote: >=20 > Hello again folks, >=20 > I made a slight boo-boo in my previous message > about finishing rfc3775bis. Namely... >=20 > On 9/27/2010 4:44 PM, Charles E. Perkins wrote: >=20 > > #18 Subject: Issues regarding Home Address Option & ICMP / > > Binding errors > > [Fabian Mauchle] > ... > > Proposal: To avoid spoofing, add to the first paragraph in > > 11.3.6: If the source of the ICMP error message is a Home > > Agent, it MUST be ignored. >=20 > It was decided not to incorporate this proposal, after all. >=20 > I have made the next revision of rfc3775bis: > www.psg.com/~charliep/txt/ietf79/draft-ietf-mext-rfc3775bis-07.txt >=20 > I expect to submit it very soon unless there is some > gross error somewhere. Thanks, I've only found two nits that you might want to fix before = submitting: 1. "A more detailed list of the changes since RFC 3775 may be found in = (see Appendix A)" =3D> "A more detailed list of the changes since RFC = 3775 may be found in Appendix A." 2. I'd personally prefer to have the changes in the last Appendix, so B = instead of A. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Fri Oct 1 10:36:15 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6D93A6C2C for ; Fri, 1 Oct 2010 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5UGCFXVeAbm for ; Fri, 1 Oct 2010 10:36:11 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 1E4F23A6CC2 for ; Fri, 1 Oct 2010 10:36:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=o2FrAkSuxNb0RcurCf957CWAGPv6aH09Q/PIv1adZ2LBfuxrFPREGbVJMiTfirL9; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.130.202]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1P1jXO-0001Jq-JN; Fri, 01 Oct 2010 13:36:51 -0400 Message-ID: <4CA61C2B.4040903@earthlink.net> Date: Fri, 01 Oct 2010 10:36:43 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <4CA12C64.1090606@computer.org> <4CA513F6.8000508@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52cf1670b590171c5a74c4a71e24db460e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:36:15 -0000 Hello Julien, On 9/30/2010 3:55 PM, Laganier, Julien wrote: > Hello Charlie, > > Charles E. Perkins wrote: >> >> Hello again folks, >> I have made the next revision of rfc3775bis: >> www.psg.com/~charliep/txt/ietf79/draft-ietf-mext-rfc3775bis-07.txt >> >> I expect to submit it very soon unless there is some >> gross error somewhere. > > Thanks, I've only found two nits that you might want to fix before submitting: > > 1. "A more detailed list of the changes since RFC 3775 may be found in (see Appendix A)" => "A more detailed list of the changes since RFC 3775 may be found in Appendix A." > > 2. I'd personally prefer to have the changes in the last Appendix, so B instead of A. Done! Regards, Charlie P. From charles.perkins@earthlink.net Fri Oct 1 11:38:12 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E4A3A6CC8 for ; Fri, 1 Oct 2010 11:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51yBBSGWpEGp for ; Fri, 1 Oct 2010 11:38:10 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 273C13A6DEB for ; Fri, 1 Oct 2010 11:38:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BMJm6gL6UQ8KSEF6VOm4I6qxK8+8AD9wcsNY4+Iky65HepboJlJPhavbXWwwL4wj; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.130.202]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1P1kVU-0007ME-Bn; Fri, 01 Oct 2010 14:38:58 -0400 Message-ID: <4CA62AB8.1050104@earthlink.net> Date: Fri, 01 Oct 2010 11:38:48 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <4CA12C64.1090606@computer.org> <4CA513F6.8000508@earthlink.net> <643B0A1D1A13AB498304E0BBC802784802A22A56@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC802784802A22A56@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52bb70a3f6c2ba253664ed9205b7d23ae4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext@ietf.org Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 18:38:13 -0000 Hello Dirk, Thanks for your observant review! On 10/1/2010 4:00 AM, Dirk.von-Hugo@telekom.de wrote: > Hi Charlie, > > ... and I MAY have detected further very minor nits like > > P.21 > "Home Address Destination option" => "Home Address destination option" > P.22 > "the Binding Updates messages" => "the Binding Update messages" > P.66 > "is the first Prefix Length bits" => "is given by the first Prefix Length bits" > P.106 > "Mobile Prefix > Advertisements messages" => "Mobile Prefix > Advertisement messages" > > ... and finally beside 50 something times spelling "Binding Cache entry" we also > have still 8 times "binding cache entry" within the document - IMHO this should > be harmonized ;-) Done! ... although I won't absolutely guarantee all instances of the latter... I also fixed "binding update" to be "Binding Update". I put the revised document again at the following URL: www.psg.com/~charliep/txt/ietf79/draft-ietf-mext-rfc3775bis-07.txt Regards, Charlie P. From julienl@qualcomm.com Fri Oct 1 13:32:59 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07FB3A6E06 for ; Fri, 1 Oct 2010 13:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSQLk99M7d97 for ; Fri, 1 Oct 2010 13:32:56 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A50513A6D4F for ; Fri, 1 Oct 2010 13:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1285965221; x=1317501221; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Charles=20E.=20Perkins"=20,=0D=0A=09"Dirk.von-Hugo@telekom.de"=20|CC:=20"mext@ietf.org"=20 |Date:=20Fri,=201=20Oct=202010=2013:33:36=20-0700 |Subject:=20RE:=20[MEXT]=20draft-ietf-mext-rfc3775bis-07. txt=3B=20and,=20Re:=20Finishing=0D=0A=20RFC=203775bis |Thread-Topic:=20[MEXT]=20draft-ietf-mext-rfc3775bis-07.t xt=3B=20and,=20Re:=20Finishing=0D=0A=20RFC=203775bis |Thread-Index:=20Acthl/OAO+t+yd10RX+MiK/aJ2pkGAAD91hA |Message-ID:=20|References:=20<4CA12C64.1090606@computer.org>=0D=0A =09<4CA513F6.8000508@earthlink.net>=0D=0A=09=0D=0A=09<643B0A1D1A13AB498304E0BBC802784802A22A56@S4DE 8PSAAQC.mitte.t-com.de>=0D=0A=20<4CA62AB8.1050104@earthli nk.net>|In-Reply-To:=20<4CA62AB8.1050104@earthlink.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=T3Gdenm6Pdw1ociTpLyDwhnSWSxDiZe8lvxDbG8KKJU=; b=OSxqYh3omcyS+jO17k3yKk5pa9eHDOwJHOv0HKIoK3wfqAoazON/C1aI nSDADegxGBfFUA8KNWc8Kfhd0U4v2DIkcm6kuCaWuL03cxmkP+d3E6WFG qDjYjG0BcZsylNAtCwe8gqiEaHjmdLOcVXiOL0nJjd46E1Y0Al+ziLxX/ 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6123"; a="56402087" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 01 Oct 2010 13:33:41 -0700 X-IronPort-AV: E=Sophos;i="4.57,266,1283756400"; d="scan'208";a="88402274" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 01 Oct 2010 13:33:41 -0700 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 1 Oct 2010 13:33:41 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 1 Oct 2010 08:33:40 -1200 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Fri, 1 Oct 2010 13:33:40 -0700 From: "Laganier, Julien" To: "Charles E. Perkins" , "Dirk.von-Hugo@telekom.de" Date: Fri, 1 Oct 2010 13:33:36 -0700 Thread-Topic: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis Thread-Index: Acthl/OAO+t+yd10RX+MiK/aJ2pkGAAD91hA Message-ID: References: <4CA12C64.1090606@computer.org> <4CA513F6.8000508@earthlink.net> <643B0A1D1A13AB498304E0BBC802784802A22A56@S4DE8PSAAQC.mitte.t-com.de> <4CA62AB8.1050104@earthlink.net> In-Reply-To: <4CA62AB8.1050104@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: Finishing RFC 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:33:00 -0000 Thanks Charlie, I think you can post the revised version and I will follow = up with requesting publication. --julien > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Charles E. Perkins > Sent: Friday, October 01, 2010 11:39 AM > To: Dirk.von-Hugo@telekom.de > Cc: mext@ietf.org > Subject: Re: [MEXT] draft-ietf-mext-rfc3775bis-07.txt; and, Re: > Finishing RFC 3775bis >=20 >=20 > Hello Dirk, >=20 > Thanks for your observant review! >=20 > On 10/1/2010 4:00 AM, Dirk.von-Hugo@telekom.de wrote: > > Hi Charlie, > > > > ... and I MAY have detected further very minor nits like > > > > P.21 > > "Home Address Destination option" =3D> "Home Address destination > option" > > P.22 > > "the Binding Updates messages" =3D> "the Binding Update messages" > > P.66 > > "is the first Prefix Length bits" =3D> "is given by the first Prefix > Length bits" > > P.106 > > "Mobile Prefix > > Advertisements messages" =3D> "Mobile Prefix > > Advertisement messages" > > > > ... and finally beside 50 something times spelling "Binding Cache > entry" we also > > have still 8 times "binding cache entry" within the document - IMHO > this should > > be harmonized ;-) >=20 >=20 > Done! ... although I won't absolutely guarantee all > instances of the latter... >=20 > I also fixed "binding update" to be "Binding Update". >=20 > I put the revised document again at the following URL: > www.psg.com/~charliep/txt/ietf79/draft-ietf-mext-rfc3775bis-07.txt >=20 > Regards, > Charlie P. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Mon Oct 4 01:27:47 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6165F3A6F56 for ; Mon, 4 Oct 2010 01:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znQh2e3jE24a for ; Mon, 4 Oct 2010 01:27:46 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8D8433A6F54 for ; Mon, 4 Oct 2010 01:27:46 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 2A7B2FDCE for ; Mon, 4 Oct 2010 10:28:37 +0200 (CEST) Message-ID: <4CA99034.9080504@it.uc3m.es> Date: Mon, 04 Oct 2010 10:28:36 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17682.003 Subject: [MEXT] Agenda items for beijing X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 08:27:47 -0000 Let us know if you want a slot for the beijing meeting Regards, marcelo From behcetsarikaya@yahoo.com Mon Oct 4 09:30:57 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD8E3A702A for ; Mon, 4 Oct 2010 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in--aOUjK157 for ; Mon, 4 Oct 2010 09:30:36 -0700 (PDT) Received: from web111412.mail.gq1.yahoo.com (web111412.mail.gq1.yahoo.com [67.195.15.198]) by core3.amsl.com (Postfix) with SMTP id A60D83A7018 for ; Mon, 4 Oct 2010 09:30:27 -0700 (PDT) Received: (qmail 82068 invoked by uid 60001); 4 Oct 2010 16:31:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1286209875; bh=tWBfM76NThr1AAAQUYxJLSiHMDJbAgMXyaDiY+FIiH8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=nsr1dwq2ypf/tagZyCIwT/RAuvC9WhkGTQvFFUxLBIc3v+QSapRVRfaLr4gngzul03HT38firCqpCYVLPhXIhUP7JXC7sgv7Or8ANJpPY19rd0Xqhe5cnV3uw4a6wE65esjhv7B7yWh5b3Ctz4uohdm/8aNXBXoYqarwje0kYXQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=uGXdYn6u3P5Vg8z3k/4ePhEPvB6WgDd0LJrI9WAe9iF5uJ0Xtyp5vo8voeQCeyHXyA6pqXkosTU//e5Iq9UmgO0BU3cvbg5TzG2RSi4X5uV9twgKDU6VqwUYsKTEZaiVV9n/+rsBkVEuWM4seAJEyRklPpEfZlQyYmNCJCKfbm8=; Message-ID: <783818.78542.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: 2KO0nGoVM1mVS4ATSkA1lrEuU2YGQidze5XWOkyXw3clQSI cYgzJP_1OWtPxFK6v6lPI8oZvuLTPPqJ080D.oYCAJ98QLTT5qYR80YPF4YP Hxm9Cc.HUUzKLAtzQqrb_kCbBjGayfqbP7_tmfEsWRgidFxYpAKKZofHM_zu _mWgADaPB4FA26meXV8Sl8CZwRKgED.mJSbMbvOctBqIZiS142pIS4H0DKGQ ..vaZ7lkm5e1kfIC6eARMwiAwQHjmbfICFlAOUoawh.iEORxlTpyM6.kH2Jx c19zwNs013bRTXrpYa9Kt1hhbm0S7DswyVChViSIMaOWLD.eWDnNcVA-- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Mon, 04 Oct 2010 09:31:15 PDT X-Mailer: YahooMailRC/497 YahooMailWebService/0.8.105.279950 Date: Mon, 4 Oct 2010 09:31:15 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis , Hesham Soliman , mext@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1939168131-1286209875=:78542" Cc: George Tsirtsis Subject: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 16:30:57 -0000 --0-1939168131-1286209875=:78542 Content-Type: text/plain; charset=us-ascii Dear authors, There was an action field in Flow Identification Mobility Option in -09. This field has been removed in -10. Any explanation why? Please indicate if there was a comment for removing it. Regards, Behcet --0-1939168131-1286209875=:78542 Content-Type: text/html; charset=us-ascii
Dear authors,
  There was an action field in Flow Identification Mobility Option in -09. This field has been removed in -10.

Any explanation why? Please indicate if there was a comment for removing it.

Regards,

Behcet

--0-1939168131-1286209875=:78542-- From julienl@qualcomm.com Mon Oct 4 10:42:47 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04A33A6FB7 for ; Mon, 4 Oct 2010 10:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhjYi2t7OJs6 for ; Mon, 4 Oct 2010 10:42:45 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 848FB3A6D8A for ; Mon, 4 Oct 2010 10:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286214220; x=1317750220; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Behcet=20Sarikaya=20,=20George =20Tsirtsis=0D=0A=09,=20Hesham =20Soliman=20,=0D=0A=09"mext@ie tf.org"=20|CC:=20"Tsirtsis,=20George"=20|Date:=20Mon,=204=20Oct=202010=2010: 43:32=20-0700|Subject:=20RE:=20[MEXT]=20draft-ietf-mext-f low-binding=20-09=20vs=20-10|Thread-Topic:=20[MEXT]=20dra ft-ietf-mext-flow-binding=20-09=20vs=20-10|Thread-Index: =20Actj4xtOC9BokXvtSn2QQEIWL6PbHAACFMRw|Message-ID:=20|References:=20<783818.78542.qm@web111412.mai l.gq1.yahoo.com>|In-Reply-To:=20<783818.78542.qm@web11141 2.mail.gq1.yahoo.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_BF345F63074F8040B58C00A186FCA57F29EDEA3251NALAS EXMB04na_"|MIME-Version:=201.0; bh=qe2xNmeWU85Y3ahKD/6c0P4CQG5TTlznMtax4w0Itl8=; b=TM07hjFY5682UICMR5VjZaXs8tNwd35c+GptX6SAN87nBnwNor7lq1LU id8CfE+z4spDRjLClNgXB3SVl2YtoqT9Idt5t9mwyB8JAqe5x29lveIEd DCdsZx6rR8ljY9Nb32SGIfzCnAYXWnsAh7BtzWKWzXxL3ukGW5gj8Ks43 E=; X-IronPort-AV: E=McAfee;i="5400,1158,6126"; a="56536126" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 04 Oct 2010 10:43:40 -0700 X-IronPort-AV: E=Sophos;i="4.57,279,1283756400"; d="scan'208,217";a="17086955" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 04 Oct 2010 10:43:40 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Oct 2010 10:43:39 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Mon, 4 Oct 2010 10:43:39 -0700 From: "Laganier, Julien" To: Behcet Sarikaya , George Tsirtsis , Hesham Soliman , "mext@ietf.org" Date: Mon, 4 Oct 2010 10:43:32 -0700 Thread-Topic: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 Thread-Index: Actj4xtOC9BokXvtSn2QQEIWL6PbHAACFMRw Message-ID: References: <783818.78542.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <783818.78542.qm@web111412.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF345F63074F8040B58C00A186FCA57F29EDEA3251NALASEXMB04na_" MIME-Version: 1.0 Cc: "Tsirtsis, George" Subject: Re: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 17:42:47 -0000 --_000_BF345F63074F8040B58C00A186FCA57F29EDEA3251NALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There were only two meaningful values for the Action field, forward and dis= card. Lars Eggert (TSV AD) had a DISCUSS on the basis that the discard acti= on turns MIPv6 into a firewall control protocol, and thus we removed the di= scard action. With only one Action left, i.e., forward, the Action field lo= st its meaning and was removed. --julien From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Beh= cet Sarikaya Sent: Monday, October 04, 2010 9:31 AM To: George Tsirtsis; Hesham Soliman; mext@ietf.org Cc: Tsirtsis, George Subject: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 Dear authors, There was an action field in Flow Identification Mobility Option in -09. = This field has been removed in -10. Any explanation why? Please indicate if there was a comment for removing it= . Regards, Behcet --_000_BF345F63074F8040B58C00A186FCA57F29EDEA3251NALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There were only two meaningful values for the Action field, forward and discard. Lars Eggert (TSV AD) had a DISCUSS on the basis that t= he discard action turns MIPv6 into a firewall control protocol, and thus we removed the discard action. With only one Action left, i.e., forward, the Action field lost its meaning and was removed.

 

--julien

 

From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Be= hcet Sarikaya
Sent: Monday, October 04, 2010 9:31 AM
To: George Tsirtsis; Hesham Soliman; mext@ietf.org
Cc: Tsirtsis, George
Subject: [MEXT] draft-ietf-mext-flow-binding -09 vs -10

 

Dear authors,
  There was an action field in Flow Identification Mobility Option in = -09. This field has been removed in -10.

Any explanation why? Please indicate if there was a comment for removing it= .

Regards,

Behcet

 

--_000_BF345F63074F8040B58C00A186FCA57F29EDEA3251NALASEXMB04na_-- From behcetsarikaya@yahoo.com Mon Oct 4 11:45:52 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACADB3A7053 for ; Mon, 4 Oct 2010 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzl+xr3hNzot for ; Mon, 4 Oct 2010 11:45:51 -0700 (PDT) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id DE19F3A705D for ; Mon, 4 Oct 2010 11:45:48 -0700 (PDT) Received: (qmail 9767 invoked by uid 60001); 4 Oct 2010 18:46:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1286218002; bh=E9Mrg+l6+49TRLbQ1CpUqrbA8xOfr1qsYjYy5Yma7vk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3FYEv12OZImVJrTiE97rfLcvzHdwr4UGuKsKGBis6zAmQnE5d5gaahuXNyv/EQn6w7OZn/holyYnIDmntQTpZTjMaW5+GaAPvF9lm+ehfhDJyAieABf9ftULYVctt+WORYfmAXBZ3KMAySKFVFtwPpkgeWlppN2XlXIRb1Fb8HE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=INIqKgf4rxi0knudfg1EbsFa6a+mn45MMT3Sgj3JX8e6gY54tbk5yG7HEFqfeXo7mo5x70EaIY9S6zFw+PZ2s2kHr8WCOlA15CD6lfPuat41AKWDYEfVeU10BsOYQKzOZdOQqL5vt8Euie18ZK1ax+mjwwE0vLthiIbXl/mImqc=; Message-ID: <11456.8708.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: Upll6N8VM1le6Li1nd5_1trTbnxDOT64CEfzTf6IhWFk2a6 LLDqAcP3.DFQsAOxFd8L0QsN.wLtdjcN9h7FCAzY.N.BqQqaFbLft4PdgnW6 cKG8ZPRixPipp8_6vOw5ASNM1QB0dNCocgD6wB7Ss1to.jh5Z8aSOv46J.7k rsO2QtzJv.pBR0hBIcFASD61QW9MripiBmXh0NcNPOsX3B92k5BdpYqqBKxe u2zATFd3XG1JdvP8T3H9GFTE_g5wvIYKYEbxrsVwa651cUxQM_lXHHyobltl NzEqvPwIN9ECHPaY53xQMaFi_uWqEY5uuXAVpF32URFkkMF1rzCHX6TWO8gO 52XwC8s5mE3qh8QwivjlaWSG2Dw-- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 04 Oct 2010 11:46:41 PDT X-Mailer: YahooMailRC/497 YahooMailWebService/0.8.105.279950 References: <783818.78542.qm@web111412.mail.gq1.yahoo.com> Date: Mon, 4 Oct 2010 11:46:41 -0700 (PDT) From: Behcet Sarikaya To: "Laganier, Julien" , George Tsirtsis , Hesham Soliman , "mext@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Tsirtsis, George" Subject: Re: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 18:45:52 -0000 > >From: "Laganier, Julien" >To: Behcet Sarikaya ; George Tsirtsis >; Hesham Soliman ; >"mext@ietf.org" >Cc: "Tsirtsis, George" >Sent: Mon, October 4, 2010 12:43:32 PM >Subject: RE: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 > > >There were only two meaningful values for the Action field, forward and discard. > >Lars Eggert (TSV AD) had a DISCUSS on the basis that the discard action turns >MIPv6 into a firewall control protocol, and thus we removed the discard action. >With only one Action left, i.e., forward, the Action field lost its meaning and >was removed. I respectfully disagree. This field has been there all over. It should be kept possibly with a statement other actions TBD. Regards, Behcet > >--julien > >From:mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet >Sarikaya >Sent: Monday, October 04, 2010 9:31 AM >To: George Tsirtsis; Hesham Soliman; mext@ietf.org >Cc: Tsirtsis, George >Subject: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 > >Dear authors, > There was an action field in Flow Identification Mobility Option in -09. This >field has been removed in -10. > >Any explanation why? Please indicate if there was a comment for removing it. > >Regards, > >Behcet > From tsirtsis@gmail.com Mon Oct 4 12:05:13 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F3A3A706C for ; Mon, 4 Oct 2010 12:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3pBR1WLGOim for ; Mon, 4 Oct 2010 12:05:12 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 969B13A706A for ; Mon, 4 Oct 2010 12:05:12 -0700 (PDT) Received: by pwi3 with SMTP id 3so1862508pwi.31 for ; Mon, 04 Oct 2010 12:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CXWabN9VEoLCpfRFU0hE+727JFmSW3QD6GSefaPnNLA=; b=vnr7/V8U201V5ZRcuuLJsd4q3PhfvtOKCX6uxDNpZKy0Y066J5F8Z54XpnMRlwyNPO GEyHE0Z1n+XeO9x72EwmODSpSaUUT66K2nNKWzd0kLQSJw3Oaavv2Zq3VaVlyw7g51Fz 9vnzrQsL27S2Tpy+v4iA+qdiRUu/TwsEb6PKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mbCKL4OP4u88YHbzUZ72R15K9XyYTIlqNkK4AdFfTZoT8/WIrmVZGAL6OUWD69FxQm 634MQotFjK670eJf9azfKOBtWDHcnq8gzWIrkhBXq2V167m58GnZ11bq2aBeBzuEVNQL 2xOjMVX9wWTopS95RBJ/U0D/2fj4zgkbj46Tg= MIME-Version: 1.0 Received: by 10.142.222.12 with SMTP id u12mr9090516wfg.321.1286219168207; Mon, 04 Oct 2010 12:06:08 -0700 (PDT) Received: by 10.142.14.7 with HTTP; Mon, 4 Oct 2010 12:06:08 -0700 (PDT) In-Reply-To: <11456.8708.qm@web111403.mail.gq1.yahoo.com> References: <783818.78542.qm@web111412.mail.gq1.yahoo.com> <11456.8708.qm@web111403.mail.gq1.yahoo.com> Date: Mon, 4 Oct 2010 20:06:08 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 04 Oct 2010 12:05:53 -0700 Cc: "mext@ietf.org" , "Tsirtsis, George" , "Laganier, Julien" , Hesham Soliman Subject: Re: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:05:13 -0000 FWIW, the bits that used to make up the Action field are still there and still available (i.e., reserved for future use). The WG can at any time turn these back to a Action field, assuming someone comes up with a valid action. The effort needed to do this is not a lot more than having to define a new action value had we retained the Action field in the specification, so in practice there is no difference and no flexibility/extensibility has been lost. Having said that, there aren't that many things one can do to a packet (i.e., possible actions) and we have considered a number of them, all of which have been rejected. George On Mon, Oct 4, 2010 at 7:46 PM, Behcet Sarikaya wrote: > > > >> >>From: "Laganier, Julien" >>To: Behcet Sarikaya ; George Tsirtsis >>; Hesham Soliman ; >>"mext@ietf.org" >>Cc: "Tsirtsis, George" >>Sent: Mon, October 4, 2010 12:43:32 PM >>Subject: RE: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 >> >> >>There were only two meaningful values for the Action field, forward and d= iscard. >> >>Lars Eggert (TSV AD) had a DISCUSS on the basis that the discard action t= urns >>MIPv6 into a firewall control protocol, and thus we removed the discard a= ction. > >>With only one Action left, i.e., forward, the Action field lost its meani= ng and > >>was removed. > > I respectfully disagree. > > This field has been there all over. It should be kept possibly with a sta= tement > other actions TBD. > > Regards, > > Behcet > >> >>--julien >> >>From:mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Be= hcet >>Sarikaya >>Sent: Monday, October 04, 2010 9:31 AM >>To: George Tsirtsis; Hesham Soliman; mext@ietf.org >>Cc: Tsirtsis, George >>Subject: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 >> >>Dear authors, >> =C2=A0There was an action field in Flow Identification Mobility Option i= n -09. This > >>field has been removed in -10. >> >>Any explanation why? Please indicate if there was a comment for removing = it. >> >>Regards, >> >>Behcet >> > > > > From julienl@qualcomm.com Mon Oct 4 12:10:17 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B013A7066 for ; Mon, 4 Oct 2010 12:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xlDw4qXVkTS for ; Mon, 4 Oct 2010 12:10:12 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8AF2E3A707D for ; Mon, 4 Oct 2010 12:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286219463; x=1317755463; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Behcet=20Sarikaya=20,=20George =20Tsirtsis=0D=0A=09,=20Hesham =20Soliman=20,=0D=0A=09"mext@ie tf.org"=20|CC:=20"Tsirtsis,=20George"=20|Date:=20Mon,=204=20Oct=202010=2012: 10:55=20-0700|Subject:=20RE:=20[MEXT]=20draft-ietf-mext-f low-binding=20-09=20vs=20-10|Thread-Topic:=20[MEXT]=20dra ft-ietf-mext-flow-binding=20-09=20vs=20-10|Thread-Index: =20Actj9H1cKlMtG8RKRbiZy0X2li6sjwAAwKZQ|Message-ID:=20|References:=20<783818.78542.qm@web111412.mai l.gq1.yahoo.com>=0D=0A=20=0D=0A=20<11456.8 708.qm@web111403.mail.gq1.yahoo.com>|In-Reply-To:=20<1145 6.8708.qm@web111403.mail.gq1.yahoo.com>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=eOOznI2QlBG96C2cmc2NxMhPtsHhMaQaUCAncIhkzqE=; b=EUjo6cmROeu+QJntYIfh4w5jiqmKQ7fSFlfP2kRmS5lGVMEIjUnrCjq/ OV3Mj36wosjpYDg8QL2Fkz2SsEE8gyG2woy4JKy6VVBbWe9+yAZA8h+da gI65YPf0UG2iwh2t0/8gFqWZUqJDAQoxHicFOGJfK2d5EcbCpzXg2kn6n 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6126"; a="56548500" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 04 Oct 2010 12:10:59 -0700 X-IronPort-AV: E=Sophos;i="4.57,279,1283756400"; d="scan'208";a="19598217" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 04 Oct 2010 12:10:59 -0700 Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Oct 2010 12:10:59 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 4 Oct 2010 12:10:59 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Mon, 4 Oct 2010 12:10:58 -0700 From: "Laganier, Julien" To: Behcet Sarikaya , George Tsirtsis , Hesham Soliman , "mext@ietf.org" Date: Mon, 4 Oct 2010 12:10:55 -0700 Thread-Topic: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 Thread-Index: Actj9H1cKlMtG8RKRbiZy0X2li6sjwAAwKZQ Message-ID: References: <783818.78542.qm@web111412.mail.gq1.yahoo.com> <11456.8708.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <11456.8708.qm@web111403.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tsirtsis, George" Subject: Re: [MEXT] draft-ietf-mext-flow-binding -09 vs -10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:10:17 -0000 Behcet Sarikaya wrote: >=20 > Laganier, Julien wrote: > > > > There were only two meaningful values for the Action field, forward > > and discard. > > > > Lars Eggert (TSV AD) had a DISCUSS on the basis that the discard > > action turns MIPv6 into a firewall control protocol, and thus we > > removed the discard action. > > > > With only one Action left, i.e., forward, the Action field lost its > > meaning and was removed. >=20 > I respectfully disagree. >=20 > This field has been there all over. It should be kept possibly with a > statement other actions TBD. Having a field which always encode a single value (i.e., forward) is useles= s.=20 If you ever come up with an action that needs to be signaled in the FID opt= ion, there are still 8 bits reserved there so you're fine. --julien=20 =20 From wwwrun@core3.amsl.com Mon Oct 4 14:36:45 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4FAA33A6E8A; Mon, 4 Oct 2010 14:36:45 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101004213645.4FAA33A6E8A@core3.amsl.com> Date: Mon, 4 Oct 2010 14:36:45 -0700 (PDT) Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Protocol Action: 'Flow Bindings in Mobile IPv6 and NEMO Basic Support' to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 21:36:45 -0000 The IESG has approved the following document: - 'Flow Bindings in Mobile IPv6 and NEMO Basic Support' as a Proposed Standard This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mext-flow-binding/ Technical Summary This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. Working Group Summary The document has been discussed in depth in the WG. The WG feels that this is an important document and should be published. The main controversy was whether there should be one or more traffic selector format defined. The current spec. supports multiple formats, but only one is being defined at this point. This is issue is related to this document, but not specific to this document, as i stated before, this spec supports multiple formats. Document Quality There is at least on ongoing effort for implementing this specification. There were many reviewers of the document, but especial in depth reviews were provided by Dave Craig, Benjamin Lim, Sundararajan Jay Kumar, Raj Patil, Conny Larson, Yuri Ismailov. Personnel Document Shepherd is Marcelo Braun and the responsible Area Director is Jari Arkko. From root@core3.amsl.com Mon Oct 4 16:30:10 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 592BB3A6C0F; Mon, 4 Oct 2010 16:30:09 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101004233009.592BB3A6C0F@core3.amsl.com> Date: Mon, 4 Oct 2010 16:30:09 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 23:30:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : C. Perkins, et al. Filename : draft-ietf-mext-rfc3775bis-07.txt Pages : 175 Date : 2010-10-04 This document specifies Mobile IPv6, a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-04162242.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Oct 5 06:30:04 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5D88D3A6F67; Tue, 5 Oct 2010 06:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101005133004.5D88D3A6F67@core3.amsl.com> Date: Tue, 5 Oct 2010 06:30:04 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-flow-binding-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 13:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Flow Bindings in Mobile IPv6 and NEMO Basic Support Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mext-flow-binding-11.txt Pages : 38 Date : 2010-10-05 This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-flow-binding-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-05062053.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Oct 5 07:00:01 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E0F863A6F8E; Tue, 5 Oct 2010 07:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101005140001.E0F863A6F8E@core3.amsl.com> Date: Tue, 5 Oct 2010 07:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binary-ts-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Traffic Selectors for Flow Bindings Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mext-binary-ts-05.txt Pages : 19 Date : 2010-10-05 This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binary-ts-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-05065414.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Tue Oct 5 08:24:26 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CA43A6F87 for ; Tue, 5 Oct 2010 08:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yECR8gRb1VK for ; Tue, 5 Oct 2010 08:24:25 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A7E053A6F74 for ; Tue, 5 Oct 2010 08:24:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o95FPLDR019916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 5 Oct 2010 17:25:21 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o95FPLb5015970 for ; Tue, 5 Oct 2010 17:25:21 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o95FPKfF006342 for ; Tue, 5 Oct 2010 17:25:21 +0200 Message-ID: <4CAB4360.3030602@gmail.com> Date: Tue, 05 Oct 2010 17:25:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mext References: <20101004233009.592BB3A6C0F@core3.amsl.com> In-Reply-To: <20101004233009.592BB3A6C0F@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 15:24:26 -0000 Thanks for this new 3775bis. At some point there was discussion and agreement to refer rfc3963 (aka nemov6) in 3775bis... Alex Le 05/10/2010 01:30, Internet-Drafts@ietf.org a écrit : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. > > > Title : Mobility Support in IPv6 > Author(s) : C. Perkins, et al. > Filename : draft-ietf-mext-rfc3775bis-07.txt > Pages : 175 > Date : 2010-10-04 > > This document specifies Mobile IPv6, a protocol which allows nodes to > remain reachable while moving around in the IPv6 Internet. Each > mobile node is always identified by its home address, regardless of > its current point of attachment to the Internet. While situated away > from its home, a mobile node is also associated with a care-of > address, which provides information about the mobile node's current > location. IPv6 packets addressed to a mobile node's home address are > transparently routed to its care-of address. The protocol enables > IPv6 nodes to cache the binding of a mobile node's home address with > its care-of address, and to then send any packets destined for the > mobile node directly to it at this care-of address. To support this > operation, Mobile IPv6 defines a new IPv6 protocol and a new > destination option. All IPv6 nodes, whether mobile or stationary, > can communicate with mobile nodes. This document obsoletes RFC 3775. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From charles.perkins@earthlink.net Tue Oct 5 16:00:08 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C8A3A6EB1 for ; Tue, 5 Oct 2010 16:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmU05Ymz83NT for ; Tue, 5 Oct 2010 16:00:07 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 5F2A93A6EAE for ; Tue, 5 Oct 2010 16:00:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NUD+Lgba4cCJTX4t/ABps0MAlV7YFPguQ5Y6wo9B28FZ5gjLY4oTIy8oPXOhXzJo; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.170]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1P3GVN-0001OC-1A; Tue, 05 Oct 2010 19:01:06 -0400 Message-ID: <4CABAE2D.5080500@earthlink.net> Date: Tue, 05 Oct 2010 16:01:01 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Alexandru Petrescu References: <20101004233009.592BB3A6C0F@core3.amsl.com> <4CAB4360.3030602@gmail.com> In-Reply-To: <4CAB4360.3030602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5293cefd6386739117693855e798f7f5a1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 23:00:08 -0000 Hello Alex, I'm almost out of time before travel. Could you suggest a good place for the citation? Regards, Charlie P. On 10/5/2010 8:25 AM, Alexandru Petrescu wrote: > Thanks for this new 3775bis. > > At some point there was discussion and agreement to refer rfc3963 (aka > nemov6) in 3775bis... > > Alex > > Le 05/10/2010 01:30, Internet-Drafts@ietf.org a écrit : >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility EXTensions for IPv6 Working >> Group of the IETF. >> >> >> Title : Mobility Support in IPv6 >> Author(s) : C. Perkins, et al. >> Filename : draft-ietf-mext-rfc3775bis-07.txt >> Pages : 175 >> Date : 2010-10-04 >> >> This document specifies Mobile IPv6, a protocol which allows nodes to >> remain reachable while moving around in the IPv6 Internet. Each >> mobile node is always identified by its home address, regardless of >> its current point of attachment to the Internet. While situated away >> from its home, a mobile node is also associated with a care-of >> address, which provides information about the mobile node's current >> location. IPv6 packets addressed to a mobile node's home address are >> transparently routed to its care-of address. The protocol enables >> IPv6 nodes to cache the binding of a mobile node's home address with >> its care-of address, and to then send any packets destined for the >> mobile node directly to it at this care-of address. To support this >> operation, Mobile IPv6 defines a new IPv6 protocol and a new >> destination option. All IPv6 nodes, whether mobile or stationary, >> can communicate with mobile nodes. This document obsoletes RFC 3775. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-07.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From julienl@qualcomm.com Tue Oct 5 16:46:44 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC793A6E1A for ; Tue, 5 Oct 2010 16:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSeTjED1Wko0 for ; Tue, 5 Oct 2010 16:46:43 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 683983A6E10 for ; Tue, 5 Oct 2010 16:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286322462; x=1317858462; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20,=20mext=20|Date:=20Tue,=205=20Oct=2020 10=2016:47:31=20-0700|Subject:=20RE:=20[MEXT]=20I-D=20Act ion:draft-ietf-mext-rfc3775bis-07.txt|Thread-Topic:=20[ME XT]=20I-D=20Action:draft-ietf-mext-rfc3775bis-07.txt |Thread-Index:=20ActkoYtAs9Bom/h9S+miVxVzY/bICwARd00A |Message-ID:=20|References:=20<20101004233 009.592BB3A6C0F@core3.amsl.com>=0D=0A=20<4CAB4360.3030602 @gmail.com>|In-Reply-To:=20<4CAB4360.3030602@gmail.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=OMhfthYdC0NX0zSd49xYGyPAXuVqawO6VxRbhouKeYk=; b=JJ4lzMhcz9PoJF/h7sK1ch8ZJcqXH4JEDNyueWFYwmG3jCCUeuTGYLmM UvhyYUIjSQWy96fGlbtZlLriUij9pY1tefceMntM8Ho7nmOMaFNX4S/NI 8hkeM+62Jfcbh2jI7PhmSyIHdR04kntOI9QlZCCUlm+fG0FRdTLSU2HOG 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6127"; a="56842242" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 05 Oct 2010 16:47:37 -0700 X-IronPort-AV: E=Sophos;i="4.57,285,1283756400"; d="scan'208";a="11210162" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 05 Oct 2010 16:47:37 -0700 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 5 Oct 2010 16:47:37 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 5 Oct 2010 11:47:37 -1200 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 5 Oct 2010 16:47:34 -0700 From: "Laganier, Julien" To: Alexandru Petrescu , mext Date: Tue, 5 Oct 2010 16:47:31 -0700 Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt Thread-Index: ActkoYtAs9Bom/h9S+miVxVzY/bICwARd00A Message-ID: References: <20101004233009.592BB3A6C0F@core3.amsl.com> <4CAB4360.3030602@gmail.com> In-Reply-To: <4CAB4360.3030602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 23:46:45 -0000 Alex:=20 I do not recall that discussion and agreement, could you please provide us = with a pointer to the relevant thread? --julien Alexandru Petrescu wrote: >=20 > Thanks for this new 3775bis. >=20 > At some point there was discussion and agreement to refer rfc3963 (aka > nemov6) in 3775bis... >=20 > Alex >=20 > Le 05/10/2010 01:30, Internet-Drafts@ietf.org a =E9crit : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Mobility EXTensions for IPv6 Working > Group of the IETF. > > > > > > Title : Mobility Support in IPv6 > > Author(s) : C. Perkins, et al. > > Filename : draft-ietf-mext-rfc3775bis-07.txt > > Pages : 175 > > Date : 2010-10-04 > > > > This document specifies Mobile IPv6, a protocol which allows nodes to > > remain reachable while moving around in the IPv6 Internet. Each > > mobile node is always identified by its home address, regardless of > > its current point of attachment to the Internet. While situated away > > from its home, a mobile node is also associated with a care-of > > address, which provides information about the mobile node's current > > location. IPv6 packets addressed to a mobile node's home address are > > transparently routed to its care-of address. The protocol enables > > IPv6 nodes to cache the binding of a mobile node's home address with > > its care-of address, and to then send any packets destined for the > > mobile node directly to it at this care-of address. To support this > > operation, Mobile IPv6 defines a new IPv6 protocol and a new > > destination option. All IPv6 nodes, whether mobile or stationary, > > can communicate with mobile nodes. This document obsoletes RFC 3775. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-07.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From root@core3.amsl.com Wed Oct 6 00:30:02 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B20803A6E3E; Wed, 6 Oct 2010 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101006073002.B20803A6E3E@core3.amsl.com> Date: Wed, 6 Oct 2010 00:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-08.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 07:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : C. Perkins, et al. Filename : draft-ietf-mext-rfc3775bis-08.txt Pages : 176 Date : 2010-10-06 This document specifies Mobile IPv6, a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-06002912.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Wed Oct 6 05:48:48 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA4B3A6D93 for ; Wed, 6 Oct 2010 05:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZjHyyw32LOF for ; Wed, 6 Oct 2010 05:48:47 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E2FFB3A6F3E for ; Wed, 6 Oct 2010 05:48:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o96CnjmA018965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Oct 2010 14:49:45 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o96CnjVa016129; Wed, 6 Oct 2010 14:49:45 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o96Cnjjd013089; Wed, 6 Oct 2010 14:49:45 +0200 Message-ID: <4CAC7069.8010500@gmail.com> Date: Wed, 06 Oct 2010 14:49:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <20101004233009.592BB3A6C0F@core3.amsl.com> <4CAB4360.3030602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 12:48:48 -0000 Le 06/10/2010 01:47, Laganier, Julien a écrit : > Alex: > > I do not recall that discussion and agreement, could you please > provide us with a pointer to the relevant thread? Right, discussion is at url below. Now that I see it I realize I may have appreciated agreement wrongly. It is half-half agreement. http://www.ietf.org/mail-archive/web/mext/current/msg03695.html Alex > > --julien > > Alexandru Petrescu wrote: >> >> Thanks for this new 3775bis. >> >> At some point there was discussion and agreement to refer rfc3963 >> (aka nemov6) in 3775bis... >> >> Alex >> >> Le 05/10/2010 01:30, Internet-Drafts@ietf.org a écrit : >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >> directories. >>> This draft is a work item of the Mobility EXTensions for IPv6 >>> Working >> Group of the IETF. >>> >>> >>> Title : Mobility Support in IPv6 Author(s) : C. >>> Perkins, et al. Filename : >>> draft-ietf-mext-rfc3775bis-07.txt Pages : 175 Date : >>> 2010-10-04 >>> >>> This document specifies Mobile IPv6, a protocol which allows >>> nodes to remain reachable while moving around in the IPv6 >>> Internet. Each mobile node is always identified by its home >>> address, regardless of its current point of attachment to the >>> Internet. While situated away from its home, a mobile node is >>> also associated with a care-of address, which provides >>> information about the mobile node's current location. IPv6 >>> packets addressed to a mobile node's home address are >>> transparently routed to its care-of address. The protocol >>> enables IPv6 nodes to cache the binding of a mobile node's home >>> address with its care-of address, and to then send any packets >>> destined for the mobile node directly to it at this care-of >>> address. To support this operation, Mobile IPv6 defines a new >>> IPv6 protocol and a new destination option. All IPv6 nodes, >>> whether mobile or stationary, can communicate with mobile nodes. >>> This document obsoletes RFC 3775. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-07.txt >>> >>> >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> >>> _______________________________________________ I-D-Announce >>> mailing list I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft >>> directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Wed Oct 6 05:52:47 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411443A6D93 for ; Wed, 6 Oct 2010 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmntZLlSm5QQ for ; Wed, 6 Oct 2010 05:52:46 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 1004D3A6F42 for ; Wed, 6 Oct 2010 05:52:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o96Crh3r013999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Oct 2010 14:53:43 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o96Crhua017830; Wed, 6 Oct 2010 14:53:43 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o96Crgc0015129; Wed, 6 Oct 2010 14:53:43 +0200 Message-ID: <4CAC7156.2040601@gmail.com> Date: Wed, 06 Oct 2010 14:53:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Charles E. Perkins" References: <20101004233009.592BB3A6C0F@core3.amsl.com> <4CAB4360.3030602@gmail.com> <4CABAE2D.5080500@earthlink.net> In-Reply-To: <4CABAE2D.5080500@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 12:52:47 -0000 Le 06/10/2010 01:01, Charles E. Perkins a écrit : > > Hello Alex, > > I'm almost out of time before travel. Could you suggest a > good place for the citation? Hi Charles, I believe your early suggestion to add it next to the first occurence of Mobile Router would be: Old: > o Mobile routers. New: o Mobile Routers: a related document describes extensions to Mobile IPv6 for Mobile Routers and Mobile Networks - RFC 3963 [RFC3963]. How would this sound? http://www.ietf.org/mail-archive/web/mext/current/msg03695.html Alex > > Regards, > Charlie P. > > > On 10/5/2010 8:25 AM, Alexandru Petrescu wrote: >> Thanks for this new 3775bis. >> >> At some point there was discussion and agreement to refer rfc3963 (aka >> nemov6) in 3775bis... >> >> Alex >> >> Le 05/10/2010 01:30, Internet-Drafts@ietf.org a écrit : >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Mobility EXTensions for IPv6 Working >>> Group of the IETF. >>> >>> >>> Title : Mobility Support in IPv6 >>> Author(s) : C. Perkins, et al. >>> Filename : draft-ietf-mext-rfc3775bis-07.txt >>> Pages : 175 >>> Date : 2010-10-04 >>> >>> This document specifies Mobile IPv6, a protocol which allows nodes to >>> remain reachable while moving around in the IPv6 Internet. Each >>> mobile node is always identified by its home address, regardless of >>> its current point of attachment to the Internet. While situated away >>> from its home, a mobile node is also associated with a care-of >>> address, which provides information about the mobile node's current >>> location. IPv6 packets addressed to a mobile node's home address are >>> transparently routed to its care-of address. The protocol enables >>> IPv6 nodes to cache the binding of a mobile node's home address with >>> its care-of address, and to then send any packets destined for the >>> mobile node directly to it at this care-of address. To support this >>> operation, Mobile IPv6 defines a new IPv6 protocol and a new >>> destination option. All IPv6 nodes, whether mobile or stationary, >>> can communicate with mobile nodes. This document obsoletes RFC 3775. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-07.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > From julienl@qualcomm.com Wed Oct 6 10:10:52 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351CF3A6F9A for ; Wed, 6 Oct 2010 10:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqTd+mLEkjqF for ; Wed, 6 Oct 2010 10:10:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A49473A6F56 for ; Wed, 6 Oct 2010 10:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286385104; x=1317921104; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20|CC:=20mext=20|Date:=20Wed,=206=20Oct =202010=2010:11:39=20-0700|Subject:=20RE:=20[MEXT]=20I-D =20Action:draft-ietf-mext-rfc3775bis-07.txt|Thread-Topic: =20[MEXT]=20I-D=20Action:draft-ietf-mext-rfc3775bis-07.tx t|Thread-Index:=20ActlVPlZax+GcJgZTfyIEj9QOi/pqAAI+Gsg |Message-ID:=20|References:=20<20101004233 009.592BB3A6C0F@core3.amsl.com>=0D=0A=20<4CAB4360.3030602 @gmail.com>=0D=0A=20=0D=0A=20<4CAC7069.801 0500@gmail.com>|In-Reply-To:=20<4CAC7069.8010500@gmail.co m>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ihhxkyXOWETGaOaYdMznSl7Q9Nqy3rzcg8+0s2++6bs=; b=JOpPe3O15CrJiGiHcEH70YsCvbHookQxqBop8dVrDmdeAohlrZGH75eT Tcu/+uwBTHoNt0O7jtlZoNkKH80gBbzGOLmbbxp82/f4LX3jUDGRzFxl0 yasyy+hTUtodakqRYcKFYsL6U6fRNA5TILx6her98x1KVNAlT99Z6cIpx w=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56932303" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 06 Oct 2010 10:11:44 -0700 X-IronPort-AV: E=Sophos;i="4.57,290,1283756400"; d="scan'208";a="11283544" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 10:11:44 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 10:11:43 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 6 Oct 2010 10:11:43 -0700 From: "Laganier, Julien" To: Alexandru Petrescu Date: Wed, 6 Oct 2010 10:11:39 -0700 Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt Thread-Index: ActlVPlZax+GcJgZTfyIEj9QOi/pqAAI+Gsg Message-ID: References: <20101004233009.592BB3A6C0F@core3.amsl.com> <4CAB4360.3030602@gmail.com> <4CAC7069.8010500@gmail.com> In-Reply-To: <4CAC7069.8010500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:10:52 -0000 Alexandru Petrescu wrote: >=20 > Le 06/10/2010 01:47, Laganier, Julien a =E9crit : > > > > Alexandru Petrescu wrote: > > > > > > Thanks for this new 3775bis. > > > > > > At some point there was discussion and agreement to refer rfc3963 > > > (aka nemov6) in 3775bis... > > > > I do not recall that discussion and agreement, could you please > > provide us with a pointer to the relevant thread? >=20 > Right, discussion is at url below. Now that I see it I realize I may > have appreciated agreement wrongly. It is half-half agreement. >=20 > http://www.ietf.org/mail-archive/web/mext/current/msg03695.html I have reviewed this thread and I do not see (rough) consensus to add a ref= erence to NEMO.=20 (That's orthogonal, but I also do not see a reasoning why we should have a = reference to NEMO. On the other hand I see a valid point that we're not goi= ng to reference all extensions to Mobile IPv6, and thus nothing make NEMO s= pecial.) --julien =20 From charles.perkins@earthlink.net Wed Oct 6 10:15:43 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725903A70FA for ; Wed, 6 Oct 2010 10:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnBYm9WWn-D1 for ; Wed, 6 Oct 2010 10:15:42 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 26F143A6D33 for ; Wed, 6 Oct 2010 10:15:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=R0AtA3Xeu5nze1LSnPqK0ZpfT2Ebg9pcBPddFSaz74BMvVlUTu0y9S7Qozohlbm5; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.130.202]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1P3Xbd-0008Np-JN; Wed, 06 Oct 2010 13:16:41 -0400 Message-ID: <4CACAEF6.7050605@earthlink.net> Date: Wed, 06 Oct 2010 10:16:38 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <20101004233009.592BB3A6C0F@core3.amsl.com><4CAB4360.3030602@gmail.com><4CAC7069.8010500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5237c9ef96348bbf0ac1541bf7347abe8f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:15:43 -0000 Hello folks, I've taken the path of least resistance on this, and submitted revision ...-08.txt without the citation for NEMO. I can very easily make another revision including the citation if that is needed. Regards, Charlie P. On 10/6/2010 10:11 AM, Laganier, Julien wrote: > Alexandru Petrescu wrote: >> >> Le 06/10/2010 01:47, Laganier, Julien a écrit : >>> >>> Alexandru Petrescu wrote: >>>> >>>> Thanks for this new 3775bis. >>>> >>>> At some point there was discussion and agreement to refer rfc3963 >>>> (aka nemov6) in 3775bis... >>> >>> I do not recall that discussion and agreement, could you please >>> provide us with a pointer to the relevant thread? >> >> Right, discussion is at url below. Now that I see it I realize I may >> have appreciated agreement wrongly. It is half-half agreement. >> >> http://www.ietf.org/mail-archive/web/mext/current/msg03695.html > > I have reviewed this thread and I do not see (rough) consensus to add a reference to NEMO. > > (That's orthogonal, but I also do not see a reasoning why we should have a reference to NEMO. On the other hand I see a valid point that we're not going to reference all extensions to Mobile IPv6, and thus nothing make NEMO special.) > > --julien > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Wed Oct 6 11:26:58 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF363A701E for ; Wed, 6 Oct 2010 11:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CZqIdYisvcJ for ; Wed, 6 Oct 2010 11:26:55 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 77FD03A6CB5 for ; Wed, 6 Oct 2010 11:26:53 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D21C0940093; Wed, 6 Oct 2010 20:27:48 +0200 (CEST) Message-ID: <4CACBF9D.1000909@gmail.com> Date: Wed, 06 Oct 2010 20:27:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <20101004233009.592BB3A6C0F@core3.amsl.com> <4CAB4360.3030602@gmail.com> <4CAC7069.8010500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101006-0, 06/10/2010), Outbound message X-Antivirus-Status: Clean Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 18:26:58 -0000 Le 06/10/2010 19:11, Laganier, Julien a écrit : > Alexandru Petrescu wrote: >> >> Le 06/10/2010 01:47, Laganier, Julien a écrit : >>> >>> Alexandru Petrescu wrote: >>>> >>>> Thanks for this new 3775bis. >>>> >>>> At some point there was discussion and agreement to refer >>>> rfc3963 (aka nemov6) in 3775bis... >>> >>> I do not recall that discussion and agreement, could you please >>> provide us with a pointer to the relevant thread? >> >> Right, discussion is at url below. Now that I see it I realize I >> may have appreciated agreement wrongly. It is half-half >> agreement. >> >> http://www.ietf.org/mail-archive/web/mext/current/msg03695.html > > I have reviewed this thread and I do not see (rough) consensus to add > a reference to NEMO. > > (That's orthogonal, but I also do not see a reasoning why we should > have a reference to NEMO. On the other hand I see a valid point that > we're not going to reference all extensions to Mobile IPv6, and thus > nothing make NEMO special.) Are you saying this as Chair? If yes then the decision is simple, as you suggest. On another hand, What is an MN and does 3775bis support MNs? An MN by 3775bis-without-3963 is actually a Mobile Host. ("node" is a "device that implements IP", and "host" is a "any node that is not a router". Hence, a Mobile Node which is not a Mobile Router (no 3963) is actually a Mobile Host. Should I suggest to change "MN" to "MH" throughout 3775bis (and not refer to 3963)? Alex > > --julien > > > From julienl@qualcomm.com Wed Oct 6 11:52:50 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F243A6CBE for ; Wed, 6 Oct 2010 11:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snPmkitFJjvu for ; Wed, 6 Oct 2010 11:52:49 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 51D0A3A6FE5 for ; Wed, 6 Oct 2010 11:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286391230; x=1317927230; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20|CC:=20mext=20|Date:=20Wed,=206=20Oct =202010=2011:53:44=20-0700|Subject:=20RE:=20[MEXT]=20I-D =20Action:draft-ietf-mext-rfc3775bis-07.txt|Thread-Topic: =20[MEXT]=20I-D=20Action:draft-ietf-mext-rfc3775bis-07.tx t|Thread-Index:=20ActlhE9nnrJrudQzSRazU9rCuKU6SwAA3Bjg |Message-ID:=20|References:=20<20101004233 009.592BB3A6C0F@core3.amsl.com>=0D=0A=09<4CAB4360.3030602 @gmail.com>=0D=0A=09=0D=0A=09<4CAC7069.801 0500@gmail.com>=0D=0A=09=0D=0A=20<4CACBF9D .1000909@gmail.com>|In-Reply-To:=20<4CACBF9D.1000909@gmai l.com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=Z+bHWriJngNCEq9IICg/elcLOrfDms4lmTBjRNLtCzc=; b=XG5V8SU2U8WjclyJ9zjpHoeq5acVfHmhGmOgbgOs0NWNpASRAdBqKjai 1AXP5s80rx4Zc+QkO6TFwVG+JrqeCubbr0xKL3qsqCRDNjwsXDwYPpyZK v7PLe/IsBvWKVmAy8Z2Sd3w014SrggiJm2uVq4oBtmRTO/p4hHfZcCnzA A=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56837828" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 06 Oct 2010 11:53:47 -0700 X-IronPort-AV: E=Sophos;i="4.57,291,1283756400"; d="scan'208";a="20480425" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 11:53:47 -0700 Received: from nasanexhc06.na.qualcomm.com (172.30.48.3) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 11:53:47 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc06.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 6 Oct 2010 11:53:47 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 6 Oct 2010 11:53:47 -0700 From: "Laganier, Julien" To: Alexandru Petrescu Date: Wed, 6 Oct 2010 11:53:44 -0700 Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt Thread-Index: ActlhE9nnrJrudQzSRazU9rCuKU6SwAA3Bjg Message-ID: References: <20101004233009.592BB3A6C0F@core3.amsl.com> <4CAB4360.3030602@gmail.com> <4CAC7069.8010500@gmail.com> <4CACBF9D.1000909@gmail.com> In-Reply-To: <4CACBF9D.1000909@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 18:52:50 -0000 Alexandru Petrescu wrote: > Sent: Wednesday, October 06, 2010 11:28 AM > To: Laganier, Julien > Cc: mext > Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt >=20 > Le 06/10/2010 19:11, Laganier, Julien a =E9crit : > > Alexandru Petrescu wrote: > >> > >> Le 06/10/2010 01:47, Laganier, Julien a =E9crit : > >>> > >>> Alexandru Petrescu wrote: > >>>> > >>>> Thanks for this new 3775bis. > >>>> > >>>> At some point there was discussion and agreement to refer > >>>> rfc3963 (aka nemov6) in 3775bis... > >>> > >>> I do not recall that discussion and agreement, could you please > >>> provide us with a pointer to the relevant thread? > >> > >> Right, discussion is at url below. Now that I see it I realize I > >> may have appreciated agreement wrongly. It is half-half > >> agreement. > >> > >> http://www.ietf.org/mail-archive/web/mext/current/msg03695.html > > > > I have reviewed this thread and I do not see (rough) consensus to add > > a reference to NEMO. > > > > (That's orthogonal, but I also do not see a reasoning why we should > > have a reference to NEMO. On the other hand I see a valid point that > > we're not going to reference all extensions to Mobile IPv6, and thus > > nothing make NEMO special.) >=20 > Are you saying this as Chair? If yes then the decision is simple, as > you suggest. Yes. --julien From alexandru.petrescu@gmail.com Wed Oct 6 11:52:55 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2ED3A7190 for ; Wed, 6 Oct 2010 11:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrNBUJe6yMf5 for ; Wed, 6 Oct 2010 11:52:54 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B56D13A7189 for ; Wed, 6 Oct 2010 11:52:53 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id A4CB6940162 for ; Wed, 6 Oct 2010 20:53:49 +0200 (CEST) Message-ID: <4CACC5B6.501@gmail.com> Date: Wed, 06 Oct 2010 20:53:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 101006-0, 06/10/2010), Outbound message X-Antivirus-Status: Clean Subject: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 18:52:55 -0000 I think it makes sense to suggest adding references in 3775bis to several extensions based on Mobile IPv6 messages: FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? Current 3775bis-08 has 44 references. 5 more references is not much. Why shouldn't these references be added? (besides: Normative reference [11] FIPS Secure Has is not used anywhere in 3775bis - should be removed. Informative reference [29] BU attacks is an individual draft expired (updated?) Informative reference [37] securing RH is also individual and expired (updated?)) Alex From julienl@qualcomm.com Wed Oct 6 11:57:30 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4311F3A7092 for ; Wed, 6 Oct 2010 11:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a49h1p0elJSD for ; Wed, 6 Oct 2010 11:57:28 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6E9E03A6CBE for ; Wed, 6 Oct 2010 11:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286391506; x=1317927506; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20,=20mext=20|Date:=20Wed,=206=20Oct=2020 10=2011:58:22=20-0700|Subject:=20RE:=20[MEXT]=20Suggestio n=20to=203775bis=20to=20add=20references=20to=20MIP6=0D =0A=20extensions|Thread-Topic:=20[MEXT]=20Suggestion=20to =203775bis=20to=20add=20references=20to=20MIP6=0D=0A=20ex tensions|Thread-Index:=20Actlh9wcQLvDZJF9RyaJSHwvimv3NQAA BCBw|Message-ID:=20|References:=20<4CACC5B 6.501@gmail.com>|In-Reply-To:=20<4CACC5B6.501@gmail.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=2gY0/hzykvi0Og/EscfUZr9eVIDk8uWiGel2Fwq34Mo=; b=nw2N+EpETY4bL5DkpEgRt5NTNPnozaVmLF3paVGVJWbRTkuen2Nn4g7F hx/T0pPHo8uNrIYgsV3kT/AB6kBiSktZ6XvZh5CxdlqKkcwFQ82o5gwIf 5OIsfeTwFoP1ErCCTGryjvXNKjS5q38yn/vLBuV1hR2WB9PW4BQEm2YnK Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56945873" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 06 Oct 2010 11:58:25 -0700 X-IronPort-AV: E=Sophos;i="4.57,290,1283756400"; d="scan'208";a="75187995" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 11:58:25 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 11:58:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 6 Oct 2010 11:58:24 -0700 From: "Laganier, Julien" To: Alexandru Petrescu , mext Date: Wed, 6 Oct 2010 11:58:22 -0700 Thread-Topic: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions Thread-Index: Actlh9wcQLvDZJF9RyaJSHwvimv3NQAABCBw Message-ID: References: <4CACC5B6.501@gmail.com> In-Reply-To: <4CACC5B6.501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 18:57:30 -0000 Alex: Alexandru Petrescu wrote: > > I think it makes sense to suggest adding references in 3775bis to > several extensions based on Mobile IPv6 messages: >=20 > FMIPv6 > HMIPv6 > NEMOv6 > PMIPv6 > other? > > Current 3775bis-08 has 44 references. 5 more references is not much. How about 10? That's irrelevant as a metric. > Why shouldn't these references be added? Because: - It makes no sense. - There's no consensus to do so. - WGLC is finished. (the revisions of 3775bis that are currently made are o= nly those necessary to resolve WGLC comments and pass IDnits checks.) =20 --julien From alexandru.petrescu@gmail.com Wed Oct 6 12:27:22 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8983A7004 for ; Wed, 6 Oct 2010 12:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vsg1GqOnGI-Z for ; Wed, 6 Oct 2010 12:27:21 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id F3D893A6FD4 for ; Wed, 6 Oct 2010 12:27:19 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id F1082940099; Wed, 6 Oct 2010 21:28:14 +0200 (CEST) Message-ID: <4CACCDC8.9050805@gmail.com> Date: Wed, 06 Oct 2010 21:28:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <4CACC5B6.501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101006-0, 06/10/2010), Outbound message X-Antivirus-Status: Clean Cc: mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:27:22 -0000 Le 06/10/2010 20:58, Laganier, Julien a écrit : > Alex: > > Alexandru Petrescu wrote: >> >> I think it makes sense to suggest adding references in 3775bis to >> several extensions based on Mobile IPv6 messages: >> >> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? >> >> Current 3775bis-08 has 44 references. 5 more references is not >> much. > > How about 10? That's irrelevant as a metric. If there are 10 such extensions to Mobile IPv6 then all should be referred and cited. I don't understand why not. Maybe only RFCs StdsTrack which are old enough is a better criterion? >> Why shouldn't these references be added? > > Because: - It makes no sense. - There's no consensus to do so. - WGLC > is finished. (the revisions of 3775bis that are currently made are > only those necessary to resolve WGLC comments and pass IDnits > checks.) The reference suggestion was made during WGLC. Now we are past the WGLC, I agree. The idnits couldn't capture this suggestion, but as a sidenote it could capture reference [11] which is not cited. There is reference [33] bu3way expired - if so then one thinks to add draft-perkins-bake-01 which did secure RO too. Idnits couldn't capture this either. Alex > > --julien > > From julienl@qualcomm.com Wed Oct 6 12:30:29 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2773A7209 for ; Wed, 6 Oct 2010 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+PyVJvOV0DH for ; Wed, 6 Oct 2010 12:30:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 033D63A720B for ; Wed, 6 Oct 2010 12:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286393459; x=1317929459; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20|CC:=20mext=20|Date:=20Wed,=206=20Oct =202010=2012:30:57=20-0700|Subject:=20RE:=20[MEXT]=20Sugg estion=20to=203775bis=20to=20add=20references=20to=20MIP6 =0D=0A=20extensions|Thread-Topic:=20[MEXT]=20Suggestion =20to=203775bis=20to=20add=20references=20to=20MIP6=0D=0A =20extensions|Thread-Index:=20ActljKcuecj4vIlDSgGqk+HxB7V eegAACBUw|Message-ID:=20|References:=20<4C ACC5B6.501@gmail.com>=0D=0A=20=0D=0A=20<4C ACCDC8.9050805@gmail.com>|In-Reply-To:=20<4CACCDC8.905080 5@gmail.com>|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"iso-8859-1"|Content-Transfer-Encoding:=20quote d-printable|MIME-Version:=201.0; bh=pC/9ZswnZYq9eksn3J6ZUoWVjGdudV0MOlMpwXurQn8=; b=dA1VtF/NwANz4SOXXUtegGMTKvmnxoyep6Flgu1fXqRK+nBQRXmn20XA Xw4ayV7nk1CcndQXlPsHuwxIdIpeshgtEFsz073y5lKcWnGb6Req1CV6l mb5DUdeRZsZ6ZHnBRbPpaVKcWKSQA+WWF0pj7F4cpxdQ9+8Lp0w+6/RBl c=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56950100" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 06 Oct 2010 12:30:59 -0700 X-IronPort-AV: E=Sophos;i="4.57,290,1283756400"; d="scan'208";a="11297873" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 12:30:59 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 12:30:59 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 6 Oct 2010 12:30:59 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 6 Oct 2010 12:30:58 -0700 From: "Laganier, Julien" To: Alexandru Petrescu Date: Wed, 6 Oct 2010 12:30:57 -0700 Thread-Topic: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions Thread-Index: ActljKcuecj4vIlDSgGqk+HxB7VeegAACBUw Message-ID: References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> In-Reply-To: <4CACCDC8.9050805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:30:29 -0000 Alexandru Petrescu wrote: >=20 > Le 06/10/2010 20:58, Laganier, Julien a =E9crit : > > Alex: > > > > Alexandru Petrescu wrote: > >> > >> I think it makes sense to suggest adding references in 3775bis to > >> several extensions based on Mobile IPv6 messages: > >> > >> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? > >> > >> Current 3775bis-08 has 44 references. 5 more references is not > >> much. > > > > How about 10? That's irrelevant as a metric. >=20 > If there are 10 such extensions to Mobile IPv6 then all should be > referred and cited. =20 You're the only one thinking so. > I don't understand why not. Because 3775bis is not a catalog of MIPv6 extensions, it is the MIPv6 speci= fication. =20 > Maybe only RFCs StdsTrack which are old enough is a better criterion? >=20 > >> Why shouldn't these references be added? > > > > Because: - It makes no sense. - There's no consensus to do so. - WGLC > > is finished. (the revisions of 3775bis that are currently made are > > only those necessary to resolve WGLC comments and pass IDnits > > checks.) >=20 > The reference suggestion was made during WGLC. Now we are past the > WGLC, I agree. The reference suggestion did not gather WG consensus. =20 --julien From suresh.krishnan@ericsson.com Wed Oct 6 12:41:09 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45D03A7239 for ; Wed, 6 Oct 2010 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgLbvOBwgGyH for ; Wed, 6 Oct 2010 12:41:04 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 822B53A7240 for ; Wed, 6 Oct 2010 12:39:06 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o96Je5ZA032168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Oct 2010 14:40:06 -0500 Received: from [142.133.10.113] (147.117.20.213) by eusaamw0707.eamcs.ericsson.se (147.117.20.92) with Microsoft SMTP Server id 8.2.234.1; Wed, 6 Oct 2010 15:40:05 -0400 Message-ID: <4CACD040.2000107@ericsson.com> Date: Wed, 6 Oct 2010 15:38:40 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Laganier, Julien" References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:41:09 -0000 I am with Julien here. This is a slippery slope to follow. I am not for adding references to extensions in 3775bis. Cheers Suresh On 10-10-06 03:30 PM, Laganier, Julien wrote: > Alexandru Petrescu wrote: >> Le 06/10/2010 20:58, Laganier, Julien a écrit : >>> Alex: >>> >>> Alexandru Petrescu wrote: >>>> I think it makes sense to suggest adding references in 3775bis to >>>> several extensions based on Mobile IPv6 messages: >>>> >>>> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? >>>> >>>> Current 3775bis-08 has 44 references. 5 more references is not >>>> much. >>> How about 10? That's irrelevant as a metric. >> If there are 10 such extensions to Mobile IPv6 then all should be >> referred and cited. > > You're the only one thinking so. > >> I don't understand why not. > > Because 3775bis is not a catalog of MIPv6 extensions, it is the MIPv6 specification. > >> Maybe only RFCs StdsTrack which are old enough is a better criterion? >> >>>> Why shouldn't these references be added? >>> Because: - It makes no sense. - There's no consensus to do so. - WGLC >>> is finished. (the revisions of 3775bis that are currently made are >>> only those necessary to resolve WGLC comments and pass IDnits >>> checks.) >> The reference suggestion was made during WGLC. Now we are past the >> WGLC, I agree. > > The reference suggestion did not gather WG consensus. > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From suresh.krishnan@ericsson.com Wed Oct 6 12:42:12 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7BF3A7111 for ; Wed, 6 Oct 2010 12:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STrCKKjZPWKf for ; Wed, 6 Oct 2010 12:42:11 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 6F5D23A7074 for ; Wed, 6 Oct 2010 12:42:11 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o96JwWIg032124; Wed, 6 Oct 2010 14:58:35 -0500 Received: from [142.133.10.113] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.2.234.1; Wed, 6 Oct 2010 15:42:59 -0400 Message-ID: <4CACD0EF.2010603@ericsson.com> Date: Wed, 6 Oct 2010 15:41:35 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "charliep@computer.org" References: <4CA12C64.1090606@computer.org> In-Reply-To: <4CA12C64.1090606@computer.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "mext@ietf.org" Subject: Re: [MEXT] Finishing RFC 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:42:12 -0000 Hi Charlie, I am happy with the resolution for issue #13 and I think the document is ready to go forward on the publication process. Thanks Suresh On 10-09-27 07:44 PM, Charles E. Perkins wrote: > Hello folks, > > One of the new requirements for rfc3775bis is a section > detailing the changes from RFC 3775. Here's what I wrote > up. If I forgot one, please remind me and I will > add it. It's quite painful to go through rfcdiff, yow. > The numbers are the issue numbers from: > http://trac.tools.ietf.org/wg/mext/trac/report/6 > > =========================================================== > > #1 Last Accepted SQN [Ahmad Muhanna] > > Solution: specify that the mobile node update its binding > sequence number to match the sequence number given in the > Binding Acknowledgement (if the Binding Acknowledgement > correctly passes authentication and the status is 135 > (Sequence Number out of window). > > > #4 Remove references to site-local addresses [George Tsirtsis] > > fixed. > > #5 Wrong protocol number used in discussion about checksum > pseudo-header: > > fixed. > > #8 Application using the care-of address [Julien Laganier] > > Cite IPv6 Socket API for Source Address Selection [RFC5014]. > > #10 The usage of "HA lifetime" [Ryuji Wakikawa] > > The mobile node SHOULD store the list of home agents for later > use in case the home agent currently managing the mobile node's > care-of address forwarding should become unavailable. > > #11 De-registration when returning home [Vijay Devarapalli] > > To be able to send and receive packets using its home address > from the home link, the mobile node MUST send a Binding Update to > its home agent to instruct its home agent to no longer intercept > or tunnel packets for it. Until the mobile node sends such a > de-registration Binding Update, it MUST NOT attempt to send and > receive packets using its home address from the home link. > > > #12 BErr sent by HA too, not only by CN [Alexandru Petrescu] > > Fixed. > > #13 Home Link Detection [Suresh Krishnan] > > Proposal: add new section [11.5.2] for Home Link Detection, > drawing on Internet Draft draft-krishnan-mext-hld. > > #14 References to Bootstrapping [Vijay Devarapalli] > > Cited "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026 > > #17 Multi-homed mobile node can cause routing loop between > home agents [Benjamin Lim] > > Added advisory security considerations in section 15.1, to > highlight risk of routing loop among HAs (e.g., in 3GPP): > > A malicious mobile node associated to multiple home agents > could create a routing loop amongst them. This would happen > when a mobile node binds one home address located on a first > home agent to another home address on a second home agent. > > #18 Subject: Issues regarding Home Address Option & ICMP / > Binding errors > [Fabian Mauchle] > > Proposal: Use the value in the Next Header field {50 (ESP), > 51 (AH), 135 (Mobility Header)} to determine, if a Binding > Cache entry is required. > > Proposal: To avoid spoofing, add to the first paragraph in > 11.3.6: If the source of the ICMP error message is a Home > Agent, it MUST be ignored. > > Proposal: If the Binding Error Message was sent by the Home > Agent, the Mobile Node SHOULD send a Binding Update to the > Home Agent according to Section 11.7.1. > > > #19 BU de-registration race condition [Kilian Weniger] > > Problem arises if de-registration arrives at Home Agent > before an immediately preceding Binding Update. > > Solution: Home Agent defers BCE removal after sending > the Binding Acknowledgement. > > #6 Minor editorial corrections and updates > > NOT done: > #3 BRR, BErr are sent by HA too, not only by CN > [Alexandru Petrescu] > #7 DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] > #9 Simultaneous Mobility [Ashutosh Dutta] > #15 BRR sent by HA too, not only by CN [Ahmad Muhanna] > #16 HA behaviour upon MN returning Home [Pascal Thubert] > > > =========================================================== > > Regards, > Charlie P. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Wed Oct 6 13:19:00 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6605A3A71F4 for ; Wed, 6 Oct 2010 13:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gp8Gu2zmOLLX for ; Wed, 6 Oct 2010 13:18:58 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CE8A03A720A for ; Wed, 6 Oct 2010 13:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286396399; x=1317932399; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Suresh=20Krishnan=20 ,=20"charliep@computer.org"=0D=0A=09|CC:=20"mext@ietf.org"=20|Date:=20Wed, =206=20Oct=202010=2013:19:54=20-0700|Subject:=20RE:=20[ME XT]=20Finishing=20RFC=203775bis|Thread-Topic:=20[MEXT]=20 Finishing=20RFC=203775bis|Thread-Index:=20ActljrnXKwHsFix 6RkWYQlw7RZxsYwABN6Nw|Message-ID:=20 |References:=20=0D=0A=09=0D =0A=09<4CA12C64.1090606@computer.org>=20<4CACD0EF.2010603 @ericsson.com>|In-Reply-To:=20<4CACD0EF.2010603@ericsson. com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=y7xqzbDjwQ4jBOsEnAbd9/D+gK7FD84ZpFerLyM0C5E=; b=juEO14CJELZ6hnSoIFkDmdLJh010k2TPyAmDe/ifIFidfz2E8tTgjNzg 7N3vgHpCBq96agzBg2zaG0Reaoys/fz24/lHlrYyYtr+EuPKuAIowp99W /5q6SHdANazLawb2Q5mOcUbTBzV5KS6Mv3YErlL8UvLKR1+iFlMJXYiXa o=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56847767" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 06 Oct 2010 13:19:59 -0700 X-IronPort-AV: E=Sophos;i="4.57,290,1283756400"; d="scan'208";a="11302835" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 13:19:59 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 13:19:59 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 6 Oct 2010 13:19:59 -0700 From: "Laganier, Julien" To: Suresh Krishnan , "charliep@computer.org" Date: Wed, 6 Oct 2010 13:19:54 -0700 Thread-Topic: [MEXT] Finishing RFC 3775bis Thread-Index: ActljrnXKwHsFix6RkWYQlw7RZxsYwABN6Nw Message-ID: References: <4CA12C64.1090606@computer.org> <4CACD0EF.2010603@ericsson.com> In-Reply-To: <4CACD0EF.2010603@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] Finishing RFC 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:19:00 -0000 Just for clarification: We will request to IESG publication of the next ver= sion of the document that fixes remaining IDnits.=20 --julien > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Suresh Krishnan > Sent: Wednesday, October 06, 2010 12:42 PM > To: charliep@computer.org > Cc: mext@ietf.org > Subject: Re: [MEXT] Finishing RFC 3775bis >=20 > Hi Charlie, > I am happy with the resolution for issue #13 and I think the > document > is ready to go forward on the publication process. >=20 > Thanks > Suresh >=20 > On 10-09-27 07:44 PM, Charles E. Perkins wrote: > > Hello folks, > > > > One of the new requirements for rfc3775bis is a section > > detailing the changes from RFC 3775. Here's what I wrote > > up. If I forgot one, please remind me and I will > > add it. It's quite painful to go through rfcdiff, yow. > > The numbers are the issue numbers from: > > http://trac.tools.ietf.org/wg/mext/trac/report/6 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > #1 Last Accepted SQN [Ahmad Muhanna] > > > > Solution: specify that the mobile node update its binding > > sequence number to match the sequence number given in the > > Binding Acknowledgement (if the Binding Acknowledgement > > correctly passes authentication and the status is 135 > > (Sequence Number out of window). > > > > > > #4 Remove references to site-local addresses [George Tsirtsis] >=20 > > > > fixed. > > > > #5 Wrong protocol number used in discussion about checksum > > pseudo-header: > > > > fixed. > > > > #8 Application using the care-of address [Julien Laganier] > > > > Cite IPv6 Socket API for Source Address Selection [RFC5014]. > > > > #10 The usage of "HA lifetime" [Ryuji Wakikawa] > > > > The mobile node SHOULD store the list of home agents for later > > use in case the home agent currently managing the mobile node's > > care-of address forwarding should become unavailable. > > > > #11 De-registration when returning home [Vijay Devarapalli] >=20 > > > > To be able to send and receive packets using its home address > > from the home link, the mobile node MUST send a Binding Update to > > its home agent to instruct its home agent to no longer intercept > > or tunnel packets for it. Until the mobile node sends such a > > de-registration Binding Update, it MUST NOT attempt to send and > > receive packets using its home address from the home link. > > > > > > #12 BErr sent by HA too, not only by CN [Alexandru Petrescu] > > > > Fixed. > > > > #13 Home Link Detection [Suresh Krishnan] > > > > Proposal: add new section [11.5.2] for Home Link Detection, > > drawing on Internet Draft draft-krishnan-mext-hld. > > > > #14 References to Bootstrapping [Vijay Devarapalli] > > > > Cited "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026 > > > > #17 Multi-homed mobile node can cause routing loop between > > home agents [Benjamin Lim] > > > > Added advisory security considerations in section 15.1, to > > highlight risk of routing loop among HAs (e.g., in 3GPP): > > > > A malicious mobile node associated to multiple home agents > > could create a routing loop amongst them. This would happen > > when a mobile node binds one home address located on a first > > home agent to another home address on a second home agent. > > > > #18 Subject: Issues regarding Home Address Option & ICMP / > > Binding errors > > [Fabian Mauchle] > > > > Proposal: Use the value in the Next Header field {50 (ESP), > > 51 (AH), 135 (Mobility Header)} to determine, if a Binding > > Cache entry is required. > > > > Proposal: To avoid spoofing, add to the first paragraph in > > 11.3.6: If the source of the ICMP error message is a Home > > Agent, it MUST be ignored. > > > > Proposal: If the Binding Error Message was sent by the Home > > Agent, the Mobile Node SHOULD send a Binding Update to the > > Home Agent according to Section 11.7.1. > > > > > > #19 BU de-registration race condition [Kilian Weniger] > > > > Problem arises if de-registration arrives at Home Agent > > before an immediately preceding Binding Update. > > > > Solution: Home Agent defers BCE removal after sending > > the Binding Acknowledgement. > > > > #6 Minor editorial corrections and updates > > > > NOT done: > > #3 BRR, BErr are sent by HA too, not only by CN > > [Alexandru Petrescu] > > #7 DSMIPv6 BU format and RFC 3775 [Tero Kauppinen] > > #9 Simultaneous Mobility [Ashutosh Dutta] > > #15 BRR sent by HA too, not only by CN [Ahmad Muhanna] > > #16 HA behaviour upon MN returning Home [Pascal Thubert] > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Regards, > > Charlie P. > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Wed Oct 6 13:28:06 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A2F3A7004 for ; Wed, 6 Oct 2010 13:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIqtHwUOutwE for ; Wed, 6 Oct 2010 13:28:05 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 315D83A700E for ; Wed, 6 Oct 2010 13:28:03 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 31769940159; Wed, 6 Oct 2010 22:28:58 +0200 (CEST) Message-ID: <4CACDC04.2070308@gmail.com> Date: Wed, 06 Oct 2010 22:28:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101006-0, 06/10/2010), Outbound message X-Antivirus-Status: Clean Cc: mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:28:06 -0000 Le 06/10/2010 21:30, Laganier, Julien a écrit : > Alexandru Petrescu wrote: >> >> Le 06/10/2010 20:58, Laganier, Julien a écrit : >>> Alex: >>> >>> Alexandru Petrescu wrote: >>>> >>>> I think it makes sense to suggest adding references in 3775bis >>>> to several extensions based on Mobile IPv6 messages: >>>> >>>> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? >>>> >>>> Current 3775bis-08 has 44 references. 5 more references is >>>> not much. >>> >>> How about 10? That's irrelevant as a metric. >> >> If there are 10 such extensions to Mobile IPv6 then all should be >> referred and cited. > > You're the only one thinking so. > >> I don't understand why not. > > Because 3775bis is not a catalog of MIPv6 extensions, it is the MIPv6 > specification. Well the MIPv6 specification is wrong, at least with respect to Mobile Nodes - it claims doing Mobile Nodes whereas what it does is Mobile Hosts. (any node that is not a router is a host, and 3775 does not do routers). (sidenote: PMIPv6 spec clearly states 3775 is hosts only, and DS-MIPv6 clearly states 3775 _and_ 3963 do "nodes"). The effects of the 3775 spec error (claim "nodes" whereas what it does is "hosts") can be seen in documents mentioning Mobile IPv6. Rfc4861 talks Mobile Nodes as MIPv6 only (no 3963). 4861 authors are under the impression that 3775bis does mobile routers too, which it actually doesn't. draft-ietf-6man-node-req-bis-05 (which also claims to not be such a catalog) cites 3775 as _the_ mobility specification, and says "a node". When suggested to add 3963 it was said fine but would 3775 be sufficient (yes, it would, provided 3775 cites 3963). Were 3775bis to say a MR is 3963 then the 6man draft and 4861 would be less wrong with respect to a "node". Moreover, 3775-wo-3963 leaves the place to interpretation such that a Mobile Router does not necessarily implement NEMOv6. Because the NEMO terminology RFC itself does not state a Mobile Router runs Mobile IPv6, but "possibly a dynamic routing protocol." The Mobility Terminology RFC doesn't say a Mobile Router runs Mobile IPv6 either. Alex > >> Maybe only RFCs StdsTrack which are old enough is a better >> criterion? >> >>>> Why shouldn't these references be added? >>> >>> Because: - It makes no sense. - There's no consensus to do so. - >>> WGLC is finished. (the revisions of 3775bis that are currently >>> made are only those necessary to resolve WGLC comments and pass >>> IDnits checks.) >> >> The reference suggestion was made during WGLC. Now we are past >> the WGLC, I agree. > > The reference suggestion did not gather WG consensus. > > --julien > From alexandru.petrescu@gmail.com Wed Oct 6 13:28:59 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E013A723E for ; Wed, 6 Oct 2010 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8-Im8v-swSa for ; Wed, 6 Oct 2010 13:28:52 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id CFDDE3A7223 for ; Wed, 6 Oct 2010 13:28:49 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id CB8879400E1; Wed, 6 Oct 2010 22:29:44 +0200 (CEST) Message-ID: <4CACDC31.4060504@gmail.com> Date: Wed, 06 Oct 2010 22:29:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Suresh Krishnan References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> <4CACD040.2000107@ericsson.com> In-Reply-To: <4CACD040.2000107@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101006-0, 06/10/2010), Outbound message X-Antivirus-Status: Clean Cc: "Laganier, Julien" , mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:28:59 -0000 Le 06/10/2010 21:38, Suresh Krishnan a écrit : > I am with Julien here. This is a slippery slope to follow. I am not for > adding references to extensions in 3775bis. How about the slippery slope of 4861 claiming 3775 does nodes? Alex > > Cheers > Suresh > > On 10-10-06 03:30 PM, Laganier, Julien wrote: >> Alexandru Petrescu wrote: >>> Le 06/10/2010 20:58, Laganier, Julien a écrit : >>>> Alex: >>>> >>>> Alexandru Petrescu wrote: >>>>> I think it makes sense to suggest adding references in 3775bis to >>>>> several extensions based on Mobile IPv6 messages: >>>>> >>>>> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? >>>>> >>>>> Current 3775bis-08 has 44 references. 5 more references is not >>>>> much. >>>> How about 10? That's irrelevant as a metric. >>> If there are 10 such extensions to Mobile IPv6 then all should be >>> referred and cited. >> >> You're the only one thinking so. >> >>> I don't understand why not. >> >> Because 3775bis is not a catalog of MIPv6 extensions, it is the MIPv6 >> specification. >> >>> Maybe only RFCs StdsTrack which are old enough is a better criterion? >>> >>>>> Why shouldn't these references be added? >>>> Because: - It makes no sense. - There's no consensus to do so. - WGLC >>>> is finished. (the revisions of 3775bis that are currently made are >>>> only those necessary to resolve WGLC comments and pass IDnits >>>> checks.) >>> The reference suggestion was made during WGLC. Now we are past the >>> WGLC, I agree. >> >> The reference suggestion did not gather WG consensus. >> >> --julien >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From julienl@qualcomm.com Wed Oct 6 14:20:26 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C328D3A6FB2 for ; Wed, 6 Oct 2010 14:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s--PdLdDH42L for ; Wed, 6 Oct 2010 14:20:25 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 30FAB3A6F49 for ; Wed, 6 Oct 2010 14:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286400086; x=1317936086; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20|CC:=20mext=20|Date:=20Wed,=206=20Oct =202010=2014:21:19=20-0700|Subject:=20RE:=20[MEXT]=20Sugg estion=20to=203775bis=20to=20add=20references=20to=20MIP6 =0D=0A=20extensions|Thread-Topic:=20[MEXT]=20Suggestion =20to=203775bis=20to=20add=20references=20to=20MIP6=0D=0A =20extensions|Thread-Index:=20ActllSH+7jGFwTTtQdmwKHuhRcV G1AABx4vA|Message-ID:=20|References:=20<4C ACC5B6.501@gmail.com>=0D=0A=20=0D=0A=20<4C ACCDC8.9050805@gmail.com>=0D=0A=20=0D=0A =20<4CACDC04.2070308@gmail.com>|In-Reply-To:=20<4CACDC04. 2070308@gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=wYseZ+MoJ411qmkOV4iKCvGcNah2z00o0BufvEeXoUY=; b=wW2GxAuRKQvmbm3pHaHcfIciYxhk1PoSjjcETkzeE0FAKeaThpGDqWSq cyy9Gs88iHciDt+LIL0dwEgvNbR1JvMdurRfa99Vj0mxw7zyCT0n3FMNh v3aAL1gS/sW3rOlBfR+cd3sbLcJ+g6hXR50i7Q91pBlLnzU6rpnl+jIyx A=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56962027" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 06 Oct 2010 14:21:26 -0700 X-IronPort-AV: E=Sophos;i="4.57,290,1283756400"; d="scan'208";a="75195144" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 14:21:26 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 14:21:26 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 6 Oct 2010 14:21:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 6 Oct 2010 14:21:22 -0700 From: "Laganier, Julien" To: Alexandru Petrescu Date: Wed, 6 Oct 2010 14:21:19 -0700 Thread-Topic: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions Thread-Index: ActllSH+7jGFwTTtQdmwKHuhRcVG1AABx4vA Message-ID: References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> <4CACDC04.2070308@gmail.com> In-Reply-To: <4CACDC04.2070308@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:20:26 -0000 Alex, As I said, WGLC is finished, and the revisions to 3775bis that are currentl= y made are only those necessary to resolve WGLC comments and pass IDnits ch= ecks. We are NOT making further changes. --julien > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, October 06, 2010 1:29 PM > To: Laganier, Julien > Cc: mext > Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 > extensions >=20 > Le 06/10/2010 21:30, Laganier, Julien a =E9crit : > > Alexandru Petrescu wrote: > >> > >> Le 06/10/2010 20:58, Laganier, Julien a =E9crit : > >>> Alex: > >>> > >>> Alexandru Petrescu wrote: > >>>> > >>>> I think it makes sense to suggest adding references in 3775bis > >>>> to several extensions based on Mobile IPv6 messages: > >>>> > >>>> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? > >>>> > >>>> Current 3775bis-08 has 44 references. 5 more references is > >>>> not much. > >>> > >>> How about 10? That's irrelevant as a metric. > >> > >> If there are 10 such extensions to Mobile IPv6 then all should be > >> referred and cited. > > > > You're the only one thinking so. > > > >> I don't understand why not. > > > > Because 3775bis is not a catalog of MIPv6 extensions, it is the MIPv6 > > specification. >=20 > Well the MIPv6 specification is wrong, at least with respect to Mobile > Nodes - it claims doing Mobile Nodes whereas what it does is Mobile > Hosts. (any node that is not a router is a host, and 3775 does not do > routers). (sidenote: PMIPv6 spec clearly states 3775 is hosts only, > and > DS-MIPv6 clearly states 3775 _and_ 3963 do "nodes"). >=20 > The effects of the 3775 spec error (claim "nodes" whereas what it does > is "hosts") can be seen in documents mentioning Mobile IPv6. >=20 > Rfc4861 talks Mobile Nodes as MIPv6 only (no 3963). 4861 authors are > under the impression that 3775bis does mobile routers too, which it > actually doesn't. >=20 > draft-ietf-6man-node-req-bis-05 (which also claims to not be such a > catalog) cites 3775 as _the_ mobility specification, and says "a node". > When suggested to add 3963 it was said fine but would 3775 be > sufficient (yes, it would, provided 3775 cites 3963). Were 3775bis to > say a MR is 3963 then the 6man draft and 4861 would be less wrong with > respect to a "node". >=20 > Moreover, >=20 > 3775-wo-3963 leaves the place to interpretation such that a Mobile > Router does not necessarily implement NEMOv6. >=20 > Because the NEMO terminology RFC itself does not state a Mobile Router > runs Mobile IPv6, but "possibly a dynamic routing protocol." The > Mobility Terminology RFC doesn't say a Mobile Router runs Mobile IPv6 > either. >=20 > Alex >=20 > > > >> Maybe only RFCs StdsTrack which are old enough is a better > >> criterion? > >> > >>>> Why shouldn't these references be added? > >>> > >>> Because: - It makes no sense. - There's no consensus to do so. - > >>> WGLC is finished. (the revisions of 3775bis that are currently > >>> made are only those necessary to resolve WGLC comments and pass > >>> IDnits checks.) > >> > >> The reference suggestion was made during WGLC. Now we are past > >> the WGLC, I agree. > > > > The reference suggestion did not gather WG consensus. > > > > --julien > > From alexandru.petrescu@gmail.com Wed Oct 6 14:33:44 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CE93A7227 for ; Wed, 6 Oct 2010 14:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh5PG6kqqgGN for ; Wed, 6 Oct 2010 14:33:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 44A993A6F95 for ; Wed, 6 Oct 2010 14:33:22 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6BF0D9400C0; Wed, 6 Oct 2010 23:34:18 +0200 (CEST) Message-ID: <4CACEB53.7030001@gmail.com> Date: Wed, 06 Oct 2010 23:34:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> <4CACDC04.2070308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 101006-0, 06/10/2010), Outbound message X-Antivirus-Status: Clean Cc: mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:33:44 -0000 Le 06/10/2010 23:21, Laganier, Julien a écrit : > Alex, > > As I said, WGLC is finished, and the revisions to 3775bis that are > currently made are only those necessary to resolve WGLC comments and > pass IDnits checks. We are NOT making further changes. So are the WGLC comments solved? Alex > > --julien > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, October 06, >> 2010 1:29 PM To: Laganier, Julien Cc: mext Subject: Re: [MEXT] >> Suggestion to 3775bis to add references to MIP6 extensions >> >> Le 06/10/2010 21:30, Laganier, Julien a écrit : >>> Alexandru Petrescu wrote: >>>> >>>> Le 06/10/2010 20:58, Laganier, Julien a écrit : >>>>> Alex: >>>>> >>>>> Alexandru Petrescu wrote: >>>>>> >>>>>> I think it makes sense to suggest adding references in >>>>>> 3775bis to several extensions based on Mobile IPv6 >>>>>> messages: >>>>>> >>>>>> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? >>>>>> >>>>>> Current 3775bis-08 has 44 references. 5 more references >>>>>> is not much. >>>>> >>>>> How about 10? That's irrelevant as a metric. >>>> >>>> If there are 10 such extensions to Mobile IPv6 then all should >>>> be referred and cited. >>> >>> You're the only one thinking so. >>> >>>> I don't understand why not. >>> >>> Because 3775bis is not a catalog of MIPv6 extensions, it is the >>> MIPv6 specification. >> >> Well the MIPv6 specification is wrong, at least with respect to >> Mobile Nodes - it claims doing Mobile Nodes whereas what it does is >> Mobile Hosts. (any node that is not a router is a host, and 3775 >> does not do routers). (sidenote: PMIPv6 spec clearly states 3775 >> is hosts only, and DS-MIPv6 clearly states 3775 _and_ 3963 do >> "nodes"). >> >> The effects of the 3775 spec error (claim "nodes" whereas what it >> does is "hosts") can be seen in documents mentioning Mobile IPv6. >> >> Rfc4861 talks Mobile Nodes as MIPv6 only (no 3963). 4861 authors >> are under the impression that 3775bis does mobile routers too, >> which it actually doesn't. >> >> draft-ietf-6man-node-req-bis-05 (which also claims to not be such >> a catalog) cites 3775 as _the_ mobility specification, and says "a >> node". When suggested to add 3963 it was said fine but would 3775 >> be sufficient (yes, it would, provided 3775 cites 3963). Were >> 3775bis to say a MR is 3963 then the 6man draft and 4861 would be >> less wrong with respect to a "node". >> >> Moreover, >> >> 3775-wo-3963 leaves the place to interpretation such that a Mobile >> Router does not necessarily implement NEMOv6. >> >> Because the NEMO terminology RFC itself does not state a Mobile >> Router runs Mobile IPv6, but "possibly a dynamic routing protocol." >> The Mobility Terminology RFC doesn't say a Mobile Router runs >> Mobile IPv6 either. >> >> Alex >> >>> >>>> Maybe only RFCs StdsTrack which are old enough is a better >>>> criterion? >>>> >>>>>> Why shouldn't these references be added? >>>>> >>>>> Because: - It makes no sense. - There's no consensus to do >>>>> so. - WGLC is finished. (the revisions of 3775bis that are >>>>> currently made are only those necessary to resolve WGLC >>>>> comments and pass IDnits checks.) >>>> >>>> The reference suggestion was made during WGLC. Now we are >>>> past the WGLC, I agree. >>> >>> The reference suggestion did not gather WG consensus. >>> >>> --julien >>> > > From julienl@qualcomm.com Wed Oct 6 14:35:23 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A503A7235 for ; Wed, 6 Oct 2010 14:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fD+odLfzrXP for ; Wed, 6 Oct 2010 14:35:22 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8C9A33A6C73 for ; Wed, 6 Oct 2010 14:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286400983; x=1317936983; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20|CC:=20mext=20|Date:=20Wed,=206=20Oct =202010=2014:36:19=20-0700|Subject:=20RE:=20[MEXT]=20Sugg estion=20to=203775bis=20to=20add=20references=20to=20MIP6 =0D=0A=20extensions|Thread-Topic:=20[MEXT]=20Suggestion =20to=203775bis=20to=20add=20references=20to=20MIP6=0D=0A =20extensions|Thread-Index:=20ActlnkoYRipOZJrdQpWPyvFOY7p lmQAAAgaA|Message-ID:=20|References:=20<4C ACC5B6.501@gmail.com>=0D=0A=20=0D=0A=20<4C ACCDC8.9050805@gmail.com>=0D=0A=20=0D=0A =20<4CACDC04.2070308@gmail.com>=0D=0A=20 =0D=0A=20<4CACEB53.7030001@gmail.com>|In-Reply-To:=20<4CA CEB53.7030001@gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=SN0lRoMRHiDhPU3x5i2ndc6Vm8pu75Xv4mBfg18BKMw=; b=RU1uiPnWqiiuemxy/hEWXm/dwXHTYRuzxeE3dkjyu6vNW1u5wG30nLRk N+2L470ivsP2dCOcAKMJqGxMb70/O2OuEc0eIqZE/tJzzegWvv5FGYMrb LYNfciVgfICFurQMF/2Pbw2sWNFsoDbYMldl004AdylDBYowShMBOVEH5 w=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="56963410" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 06 Oct 2010 14:36:21 -0700 X-IronPort-AV: E=Sophos;i="4.57,290,1283756400"; d="scan'208";a="11309234" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Oct 2010 14:36:20 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Oct 2010 14:36:21 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 6 Oct 2010 14:36:20 -0700 From: "Laganier, Julien" To: Alexandru Petrescu Date: Wed, 6 Oct 2010 14:36:19 -0700 Thread-Topic: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions Thread-Index: ActlnkoYRipOZJrdQpWPyvFOY7plmQAAAgaA Message-ID: References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> <4CACDC04.2070308@gmail.com> <4CACEB53.7030001@gmail.com> In-Reply-To: <4CACEB53.7030001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:35:23 -0000 > Le 06/10/2010 23:21, Laganier, Julien a =E9crit : > > Alex, > > > > As I said, WGLC is finished, and the revisions to 3775bis that are > > currently made are only those necessary to resolve WGLC comments and > > pass IDnits checks. We are NOT making further changes. >=20 > So are the WGLC comments solved? All the WGLC comments for which we reached WG consensus on a proposed resol= ution were resolved as per this WG consensus. We are not making additional = changes. Thank you for the discussion. --julien From gaurav19285@gmail.com Wed Oct 6 14:37:31 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F49C3A6C73 for ; Wed, 6 Oct 2010 14:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6o+b7SpdzM3 for ; Wed, 6 Oct 2010 14:37:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 36C2B3A6FB2 for ; Wed, 6 Oct 2010 14:37:27 -0700 (PDT) Received: by fxm6 with SMTP id 6so20692fxm.31 for ; Wed, 06 Oct 2010 14:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VOrNZD0x9FxTwKUsi83MlYR731IwlEkwKb19gfabV3U=; b=jtDsptVLeeXHIZX9ojudPqaQIgkuInydHewaDFyuFXahUrYqCjsvg0rM8/USgztzIh fQEmHJ+LKE/1i7Ijv/5Wr4BnD+5aF7wAV4xS9bohdi5RwbT6YsVqZMoT/8bAhDKVxCJZ T9NdZeNAsYMZeCcmskCZ9dC2wqH6G2QGUFLnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Clra7CsHFhh3OiVykJVz/at/G+zwkthX/UiJTgUU5kSJULQYXmWxYlEbuR7Zt8+Vrw w03AEC5mtFn5DzTjYsuY8MxRlh7ei9igatNIUMMpHd6++72BdLngG0+fRPD7B/oReoW5 VVqezd5ROWSb3UIJI4hcqH/OlaItksUUwYyyE= MIME-Version: 1.0 Received: by 10.239.141.83 with SMTP id b19mr1323923hba.50.1286401106961; Wed, 06 Oct 2010 14:38:26 -0700 (PDT) Received: by 10.239.191.206 with HTTP; Wed, 6 Oct 2010 14:38:26 -0700 (PDT) In-Reply-To: <4CACEB53.7030001@gmail.com> References: <4CACC5B6.501@gmail.com> <4CACCDC8.9050805@gmail.com> <4CACDC04.2070308@gmail.com> <4CACEB53.7030001@gmail.com> Date: Wed, 6 Oct 2010 17:38:26 -0400 Message-ID: From: Gaurav Goswami To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001485f20c1604e5800491f999e6 Cc: "Laganier, Julien" , mext Subject: Re: [MEXT] Suggestion to 3775bis to add references to MIP6 extensions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:37:31 -0000 --001485f20c1604e5800491f999e6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable *ALL,* ** *I am not the intended recipient for this email.Please DO NOT forward me th= e email now on.* ** *Thanks* *--* *Gaurav * On Wed, Oct 6, 2010 at 5:34 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 06/10/2010 23:21, Laganier, Julien a =E9crit : > >> Alex, >> >> As I said, WGLC is finished, and the revisions to 3775bis that are >> currently made are only those necessary to resolve WGLC comments and >> pass IDnits checks. We are NOT making further changes. >> > > So are the WGLC comments solved? > > Alex > > >> --julien >> >> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, October 06, >>> 2010 1:29 PM To: Laganier, Julien Cc: mext Subject: Re: [MEXT] >>> Suggestion to 3775bis to add references to MIP6 extensions >>> >>> Le 06/10/2010 21:30, Laganier, Julien a =E9crit : >>> >>>> Alexandru Petrescu wrote: >>>> >>>>> >>>>> Le 06/10/2010 20:58, Laganier, Julien a =E9crit : >>>>> >>>>>> Alex: >>>>>> >>>>>> Alexandru Petrescu wrote: >>>>>> >>>>>>> >>>>>>> I think it makes sense to suggest adding references in >>>>>>> 3775bis to several extensions based on Mobile IPv6 >>>>>>> messages: >>>>>>> >>>>>>> FMIPv6 HMIPv6 NEMOv6 PMIPv6 other? >>>>>>> >>>>>>> Current 3775bis-08 has 44 references. 5 more references >>>>>>> is not much. >>>>>>> >>>>>> >>>>>> How about 10? That's irrelevant as a metric. >>>>>> >>>>> >>>>> If there are 10 such extensions to Mobile IPv6 then all should >>>>> be referred and cited. >>>>> >>>> >>>> You're the only one thinking so. >>>> >>>> I don't understand why not. >>>>> >>>> >>>> Because 3775bis is not a catalog of MIPv6 extensions, it is the >>>> MIPv6 specification. >>>> >>> >>> Well the MIPv6 specification is wrong, at least with respect to >>> Mobile Nodes - it claims doing Mobile Nodes whereas what it does is >>> Mobile Hosts. (any node that is not a router is a host, and 3775 >>> does not do routers). (sidenote: PMIPv6 spec clearly states 3775 >>> is hosts only, and DS-MIPv6 clearly states 3775 _and_ 3963 do >>> "nodes"). >>> >>> The effects of the 3775 spec error (claim "nodes" whereas what it >>> does is "hosts") can be seen in documents mentioning Mobile IPv6. >>> >>> Rfc4861 talks Mobile Nodes as MIPv6 only (no 3963). 4861 authors >>> are under the impression that 3775bis does mobile routers too, >>> which it actually doesn't. >>> >>> draft-ietf-6man-node-req-bis-05 (which also claims to not be such >>> a catalog) cites 3775 as _the_ mobility specification, and says "a >>> node". When suggested to add 3963 it was said fine but would 3775 >>> be sufficient (yes, it would, provided 3775 cites 3963). Were >>> 3775bis to say a MR is 3963 then the 6man draft and 4861 would be >>> less wrong with respect to a "node". >>> >>> Moreover, >>> >>> 3775-wo-3963 leaves the place to interpretation such that a Mobile >>> Router does not necessarily implement NEMOv6. >>> >>> Because the NEMO terminology RFC itself does not state a Mobile >>> Router runs Mobile IPv6, but "possibly a dynamic routing protocol." >>> The Mobility Terminology RFC doesn't say a Mobile Router runs >>> Mobile IPv6 either. >>> >>> Alex >>> >>> >>>> Maybe only RFCs StdsTrack which are old enough is a better >>>>> criterion? >>>>> >>>>> Why shouldn't these references be added? >>>>>>> >>>>>> >>>>>> Because: - It makes no sense. - There's no consensus to do >>>>>> so. - WGLC is finished. (the revisions of 3775bis that are >>>>>> currently made are only those necessary to resolve WGLC >>>>>> comments and pass IDnits checks.) >>>>>> >>>>> >>>>> The reference suggestion was made during WGLC. Now we are >>>>> past the WGLC, I agree. >>>>> >>>> >>>> The reference suggestion did not gather WG consensus. >>>> >>>> --julien >>>> >>>> >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --001485f20c1604e5800491f999e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
ALL,
=A0
I am not the intended recipient for th= is email.Please DO NOT forward me the email now on.<= /div>
=A0
Thanks
--
Gaurav

On Wed, Oct 6, 2010 at 5:34 PM, Alexandru Petres= cu <al= exandru.petrescu@gmail.com> wrote:
Le 06/10/2010 23:21, Laganier, J= ulien a =E9crit :
Alex,

As I said, WGLC is = finished, and the revisions to 3775bis that are
currently made are only = those necessary to resolve WGLC comments and
pass IDnits checks. We are NOT making further changes.

= So are the WGLC comments solved?

Alex


--julien

-----Original Message----- From:= Alexandru Petrescu
[mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, Oc= tober 06,
2010 1:29 PM To: Laganier, Julien Cc: mext Subject: Re: [MEXT]
Suggestio= n to 3775bis to add references to MIP6 extensions

Le 06/10/2010 21:3= 0, Laganier, Julien a =E9crit :
Alexandru Petrescu wrote:

Le 06/10/2010 20:58, Laganie= r, Julien a =E9crit :
Alex:

Alexandru Petrescu = wrote:

I think it makes sense to su= ggest adding references in
3775bis to several extensions based on Mobile= IPv6
messages:

FMIPv6 HMIPv6 NEMOv6 PMIPv6 other?

Current 3775bis-= 08 has 44 references. =A05 more references
is not much.
=
How about 10? That's irrelevant as a metric.

If there are 10 such extensions to Mobile IPv6 then all should
be referr= ed and cited.

You're the only one thinking so.
<= br>
I don't understand why not.<= br>

Because 3775bis is not a catalog of MIPv6 extensions, i= t is the
MIPv6 specification.

Well the MIPv6 specification is wr= ong, at least with respect to
Mobile Nodes - it claims doing Mobile Node= s whereas what it does is
Mobile Hosts. (any node that is not a router i= s a host, and 3775
does not do routers). =A0(sidenote: PMIPv6 spec clearly states 3775
is h= osts only, and DS-MIPv6 clearly states 3775 _and_ 3963 do
"nodes&qu= ot;).

The effects of the 3775 spec error (claim "nodes" wh= ereas what it
does is "hosts") can be seen in documents mentioning Mobile IPv6.=

Rfc4861 talks Mobile Nodes as MIPv6 only (no 3963). =A04861 authors=
are under the impression that 3775bis does mobile routers too,
which= it actually doesn't.

draft-ietf-6man-node-req-bis-05 (which also claims to not be such
a = catalog) cites 3775 as _the_ mobility specification, and says "a
no= de". When suggested to add 3963 it was said fine but would 3775
be sufficient (yes, it would, provided 3775 cites 3963). =A0Were
3775bis= to say a MR is 3963 then the 6man draft and 4861 would be
less wrong wi= th respect to a "node".

Moreover,

3775-wo-3963 leav= es the place to interpretation such that a Mobile
Router does not necessarily implement NEMOv6.

Because the NEMO termi= nology RFC itself does not state a Mobile
Router runs Mobile IPv6, but &= quot;possibly a dynamic routing protocol."
The Mobility Terminology= RFC doesn't say a Mobile Router runs
Mobile IPv6 either.

Alex


Maybe only RFCs StdsTrack which = are old enough is a better
criterion?

Why shouldn't these referenc= es be added?

Because: - It makes no sense. - There'= s no consensus to do
so. - WGLC is finished. (the revisions of 3775bis that are
currently mad= e are only those necessary to resolve WGLC
comments and pass IDnits chec= ks.)

The reference suggestion was made during WGLC. =A0= Now we are
past the WGLC, I agree.

The reference suggestion did no= t gather WG consensus.

--julien



_______________________________________________
MEXT mailing list
MEX= T@ietf.org
https://www.ietf.org/mailman/listinfo/mext




--001485f20c1604e5800491f999e6-- From hesham@elevatemobile.com Wed Oct 6 16:46:05 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A2E3A6EA0 for ; Wed, 6 Oct 2010 16:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQeVkj-kDxAR for ; Wed, 6 Oct 2010 16:46:04 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 087033A6EB2 for ; Wed, 6 Oct 2010 16:46:03 -0700 (PDT) Received: from [138.217.157.238] (helo=[10.0.0.8]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1P3dhN-0007pT-82; Thu, 07 Oct 2010 10:47:01 +1100 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 07 Oct 2010 10:46:57 +1000 From: Hesham Soliman To: "Laganier, Julien" , Alexandru Petrescu Message-ID: Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt Thread-Index: ActlVPlZax+GcJgZTfyIEj9QOi/pqAAI+GsgAA35/Xk= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 23:46:05 -0000 On 7/10/10 3:11 AM, "Laganier, Julien" wrote: > Alexandru Petrescu wrote: >>=20 >> Le 06/10/2010 01:47, Laganier, Julien a =E9crit : >>>=20 >>> Alexandru Petrescu wrote: >>>>=20 >>>> Thanks for this new 3775bis. >>>>=20 >>>> At some point there was discussion and agreement to refer rfc3963 >>>> (aka nemov6) in 3775bis... >>>=20 >>> I do not recall that discussion and agreement, could you please >>> provide us with a pointer to the relevant thread? >>=20 >> Right, discussion is at url below. Now that I see it I realize I may >> have appreciated agreement wrongly. It is half-half agreement. >>=20 >> http://www.ietf.org/mail-archive/web/mext/current/msg03695.html >=20 > I have reviewed this thread and I do not see (rough) consensus to add a > reference to NEMO. >=20 > (That's orthogonal, but I also do not see a reasoning why we should have = a > reference to NEMO. On the other hand I see a valid point that we're not g= oing > to reference all extensions to Mobile IPv6, and thus nothing make NEMO > special.) =3D> I agree with not referencing any extensions, including NEMO. Hesham >=20 > --julien >=20 > =20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From thierry.ernst@inria.fr Thu Oct 7 00:26:36 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF2F3A6D4F for ; Thu, 7 Oct 2010 00:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iBvTFIgizWG for ; Thu, 7 Oct 2010 00:26:35 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id 064E73A6D2D for ; Thu, 7 Oct 2010 00:26:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,296,1283724000"; d="vcf'?scan'208";a="71915907" Received: from vpn-rocq-184.inria.fr (HELO Mont-Ventoux.local) ([128.93.42.184]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 Oct 2010 09:27:34 +0200 Message-ID: <4CAD7665.9020603@inria.fr> Date: Thu, 07 Oct 2010 09:27:33 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Charles E. Perkins" References: <20101004233009.592BB3A6C0F@core3.amsl.com><4CAB4360.3030602@gmail.com><4CAC7069.8010500@gmail.com> <871400556.1348741.1286385415959.JavaMail.root@zmbs1.inria.fr> In-Reply-To: <871400556.1348741.1286385415959.JavaMail.root@zmbs1.inria.fr> Content-Type: multipart/mixed; boundary="------------010901090204010509000100" Cc: "Laganier, Julien" , mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 07:26:36 -0000 This is a multi-part message in MIME format. --------------010901090204010509000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, I don't know what the discussion was but it would seem a bit logical to me that NEMO (RFC 3963) is given as a reference once Mobile Routers are mentioned. That is the very least we can do. Regards, Thierry. On 06/10/10 19:16, Charles E. Perkins wrote: > > Hello folks, > > I've taken the path of least resistance on this, > and submitted revision ...-08.txt without the > citation for NEMO. I can very easily make another > revision including the citation if that is needed. > > Regards, > Charlie P. > > > On 10/6/2010 10:11 AM, Laganier, Julien wrote: >> Alexandru Petrescu wrote: >>> >>> Le 06/10/2010 01:47, Laganier, Julien a écrit : >>>> >>>> Alexandru Petrescu wrote: >>>>> >>>>> Thanks for this new 3775bis. >>>>> >>>>> At some point there was discussion and agreement to refer rfc3963 >>>>> (aka nemov6) in 3775bis... >>>> >>>> I do not recall that discussion and agreement, could you please >>>> provide us with a pointer to the relevant thread? >>> >>> Right, discussion is at url below. Now that I see it I realize I may >>> have appreciated agreement wrongly. It is half-half agreement. >>> >>> http://www.ietf.org/mail-archive/web/mext/current/msg03695.html >> >> I have reviewed this thread and I do not see (rough) consensus to add >> a reference to NEMO. >> >> (That's orthogonal, but I also do not see a reasoning why we should >> have a reference to NEMO. On the other hand I see a valid point that >> we're not going to reference all extensions to Mobile IPv6, and thus >> nothing make NEMO special.) >> >> --julien >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------010901090204010509000100 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA - Project Team IMARA - LaRA JRU tel;work:+33 1 3963 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------010901090204010509000100-- From Basavaraj.Patil@nokia.com Thu Oct 7 07:46:11 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FAF3A6F46 for ; Thu, 7 Oct 2010 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toFDUxF8qMW9 for ; Thu, 7 Oct 2010 07:46:10 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DC3013A6F52 for ; Thu, 7 Oct 2010 07:46:09 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o97EkxBG031317; Thu, 7 Oct 2010 17:47:05 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 17:46:56 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 17:46:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Oct 2010 17:46:38 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 7 Oct 2010 16:46:38 +0200 From: To: , , Date: Thu, 7 Oct 2010 16:46:36 +0200 Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt Thread-Index: ActlVPlZax+GcJgZTfyIEj9QOi/pqAAI+GsgAA35/XkAH2t/5A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2010 14:46:38.0581 (UTC) FILETIME=[72818250:01CB662E] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 14:46:11 -0000 On 10/6/10 7:46 PM, "ext Hesham Soliman" wrote: >=20 >=20 >=20 >=20 > On 7/10/10 3:11 AM, "Laganier, Julien" wrote: >=20 >> I have reviewed this thread and I do not see (rough) consensus to add a >> reference to NEMO. >>=20 >> (That's orthogonal, but I also do not see a reasoning why we should have= a >> reference to NEMO. On the other hand I see a valid point that we're not = going >> to reference all extensions to Mobile IPv6, and thus nothing make NEMO >> special.) >=20 > =3D> I agree with not referencing any extensions, including NEMO. +1=20 -Raj >=20 > Hesham >=20 >>=20 >> --julien >>=20 From julienl@qualcomm.com Thu Oct 7 09:06:52 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5073F3A6F42 for ; Thu, 7 Oct 2010 09:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkLlqLR8UtYz for ; Thu, 7 Oct 2010 09:06:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 112DD3A6F2A for ; Thu, 7 Oct 2010 09:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286467673; x=1318003673; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Thierry=20Ernst=20,=20"Cha rles=20E.=20Perkins"=0D=0A=09|CC:=20mext=20|Date:=20Thu,=207=20Oct =202010=2009:07:44=20-0700|Subject:=20RE:=20[MEXT]=20I-D =20Action:draft-ietf-mext-rfc3775bis-07.txt|Thread-Topic: =20[MEXT]=20I-D=20Action:draft-ietf-mext-rfc3775bis-07.tx t|Thread-Index:=20Actl8SM2kjAwmbprRG+iGim3SwhotAASG00w |Message-ID:=20|References:=20<20101004233 009.592BB3A6C0F@core3.amsl.com><4CAB4360.3030602@gmail.co m><4CAC7069.8010500@gmail.com>=0D=0A=09=0D=0A=09<871400556.1348741.1286385415959.Jav aMail.root@zmbs1.inria.fr>=0D=0A=20<4CAD7665.9020603@inri a.fr>|In-Reply-To:=20<4CAD7665.9020603@inria.fr> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=vsQtcgtoynwUpkwrCJndTJgKA6g1MrfJD35nSMJWXuU=; b=SUS7Z94OtDrWH/GenBzCf1RZ0qNodhDm+jaK+6/YX+n/jgnLuv9wb2b6 rpULqBXmeXhw0ff1ax9tceGXtYjdqdoCcJPfbT3chcHFuT9X2iHIq86W1 ZCbNMj8Q+QskPGRkbOgyNsU+pttywkS8KZmmGWAto5mbc30djHRyCDHWM o=; X-IronPort-AV: E=McAfee;i="5400,1158,6128"; a="57057611" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 07 Oct 2010 09:07:45 -0700 X-IronPort-AV: E=Sophos;i="4.57,297,1283756400"; d="scan'208";a="75301316" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 07 Oct 2010 09:07:45 -0700 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Oct 2010 09:07:45 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 7 Oct 2010 09:07:45 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Thu, 7 Oct 2010 09:07:45 -0700 From: "Laganier, Julien" To: Thierry Ernst , "Charles E. Perkins" Date: Thu, 7 Oct 2010 09:07:44 -0700 Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt Thread-Index: Actl8SM2kjAwmbprRG+iGim3SwhotAASG00w Message-ID: References: <20101004233009.592BB3A6C0F@core3.amsl.com><4CAB4360.3030602@gmail.com><4CAC7069.8010500@gmail.com> <871400556.1348741.1286385415959.JavaMail.root@zmbs1.inria.fr> <4CAD7665.9020603@inria.fr> In-Reply-To: <4CAD7665.9020603@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:06:52 -0000 Thierry Ernst wrote: >=20 > Dear all, >=20 > I don't know what the discussion was but it would seem a bit logical to > me that NEMO (RFC 3963) is given as a reference once Mobile Routers are > mentioned. That is the very least we can do. As I said, we are not adding new references to this document at this point.= As to the discussion, there was never consensus to reference NEMO in this = specification. --julien =20 From root@core3.amsl.com Thu Oct 7 16:30:03 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8BFB33A6FDE; Thu, 7 Oct 2010 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101007233002.8BFB33A6FDE@core3.amsl.com> Date: Thu, 7 Oct 2010 16:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-09.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 23:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : C. Perkins, et al. Filename : draft-ietf-mext-rfc3775bis-09.txt Pages : 177 Date : 2010-10-07 This document specifies Mobile IPv6, a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-07162135.I-D@ietf.org> --NextPart-- From thierry.ernst@inria.fr Fri Oct 8 04:46:20 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E87E3A6889 for ; Fri, 8 Oct 2010 04:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44VaS9OMid9O for ; Fri, 8 Oct 2010 04:46:19 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id E59AB3A6884 for ; Fri, 8 Oct 2010 04:46:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,302,1283724000"; d="vcf'?scan'208";a="73025268" Received: from dslb-188-097-147-054.pools.arcor-ip.net (HELO Mont-Ventoux.local) ([188.97.147.54]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 08 Oct 2010 13:47:21 +0200 Message-ID: <4CAF04C7.3070009@inria.fr> Date: Fri, 08 Oct 2010 13:47:19 +0200 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: <20101004233009.592BB3A6C0F@core3.amsl.com><4CAB4360.3030602@gmail.com><4CAC7069.8010500@gmail.com> <871400556.1348741.1286385415959.JavaMail.root@zmbs1.inria.fr> <4CAD7665.9020603@inria.fr> <71656327.1415567.1286467698756.JavaMail.root@zmbs1.inria.fr> In-Reply-To: <71656327.1415567.1286467698756.JavaMail.root@zmbs1.inria.fr> Content-Type: multipart/mixed; boundary="------------070307040703080008070808" Cc: mext Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 11:46:20 -0000 This is a multi-part message in MIME format. --------------070307040703080008070808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It is written somewhere: In particular, this protocol does not attempt to solve: * Mobile routers. If would make sense to me to indicate to the reader that it is solved in RFC 3963. Or, I would provide a reference to the NEMO terminology. Regards, Thierry On 07/10/10 18:08, Laganier, Julien wrote: > Thierry Ernst wrote: >> Dear all, >> >> I don't know what the discussion was but it would seem a bit logical to >> me that NEMO (RFC 3963) is given as a reference once Mobile Routers are >> mentioned. That is the very least we can do. > As I said, we are not adding new references to this document at this point. As to the discussion, there was never consensus to reference NEMO in this specification. > > --julien > --------------070307040703080008070808 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA - Project Team IMARA - LaRA JRU tel;work:+33 1 3963 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------070307040703080008070808-- From julienl@qualcomm.com Mon Oct 11 09:30:48 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796CC3A6B0A for ; Mon, 11 Oct 2010 09:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB8aIw5IdDiv for ; Mon, 11 Oct 2010 09:30:46 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4141C3A6A00 for ; Mon, 11 Oct 2010 09:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1286814718; x=1318350718; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Charles=20E.=20Perkins"=20|CC:=20mext=20|Date:=20Mon,=2011 =20Oct=202010=2009:31:56=20-0700|Subject:=20-09=20of=2037 75bis|Thread-Topic:=20-09=20of=203775bis|Thread-Index:=20 ActpYdGjHcvbOdOCSY6mJjU8oLVLjg=3D=3D|Message-ID:=20|Accept-Language:=20en-US|Content-Language:=20en -US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0; bh=2pp9w4hmOPq3ZS6BvZXPJpwTdfexYFSqyb5mZX71HVQ=; b=vDdwCm1Oc2p/84K4vnGLf0oRABq0uA/d5tSYMXiEcywCvZxPQleEhMzD bLGgm6e7d+T868D4OtmnQbJ1EAVx+9GxV38sUoM4zor3p9S8glMZvbLr2 32LXPrbpc0ttVVuusvzSprOXnD7wo135475vTLc4XO9ZLf6cVsQGKONLf s=; X-IronPort-AV: E=McAfee;i="5400,1158,6133"; a="57471130" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 11 Oct 2010 09:31:58 -0700 X-IronPort-AV: E=Sophos;i="4.57,311,1283756400"; d="scan'208";a="22070486" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 11 Oct 2010 09:31:58 -0700 Received: from nasanexhc06.na.qualcomm.com (172.30.48.3) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 11 Oct 2010 09:31:58 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhc06.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 11 Oct 2010 09:31:57 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Mon, 11 Oct 2010 09:31:57 -0700 From: "Laganier, Julien" To: "Charles E. Perkins" Date: Mon, 11 Oct 2010 09:31:56 -0700 Thread-Topic: -09 of 3775bis Thread-Index: ActpYdGjHcvbOdOCSY6mJjU8oLVLjg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mext Subject: [MEXT] -09 of 3775bis X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 16:30:49 -0000 Hello Charlie, Thanks for publishing the update that passes IDnits. There is one last thing we need to do before sending it to IESG: I am seein= g that IKEv2/RFC5996 is informative in RFC3775bis while IKE/RFC2409 was nor= mative in RFC3775. I am sorry that I didn't caught this earlier. Can you fi= x this so that 5996 is normative? After that we should be ready for IESG... Best, --julien From jan@go6.si Wed Oct 13 00:34:11 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D73C3A68D3 for ; Wed, 13 Oct 2010 00:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+6zrXmEblQT for ; Wed, 13 Oct 2010 00:34:04 -0700 (PDT) Received: from ipv6.go6.si (go6.si [212.44.108.1]) by core3.amsl.com (Postfix) with ESMTP id CDC1B3A63D3 for ; Wed, 13 Oct 2010 00:34:03 -0700 (PDT) Received: from [193.77.29.28] (unknown [193.77.29.28]) (Authenticated sender: jan@go6.si) by ipv6.go6.si (Postfix) with ESMTP id E311D2378059 for ; Wed, 13 Oct 2010 09:35:15 +0200 (CEST) Message-ID: <4CB5612E.3090900@go6.si> Date: Wed, 13 Oct 2010 09:35:10 +0200 From: "Jan Zorz @ go6.si" Organization: go6.si User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: mext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 07:34:11 -0000 >> The chairs have received a request from the authors of >> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec that their draft >> be adopted as one of the WG deliverables for our "alternative security >> mechanisms" work item. >> >> Before we go ahead with this, the chairs would like to solicit at least three >> thorough review of the document to ensure that the has an adequate >> understanding of the proposal and its implications. >> >> Please support the WG process by volunteering as a reviewer. I volunteer to do a review. When some versions of this implementation from Nokia became "public" I tested and used it for a long time. Some things to fix, some things to add... Thank you, Jan Zorz go6.si From marcelo@it.uc3m.es Wed Oct 13 00:39:22 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A183A6877 for ; Wed, 13 Oct 2010 00:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLu+CbY1yr9p for ; Wed, 13 Oct 2010 00:39:21 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9AF173A688D for ; Wed, 13 Oct 2010 00:39:20 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 02AB5ADB7C9 for ; Wed, 13 Oct 2010 09:40:36 +0200 (CEST) Message-ID: <4CB56273.5020605@it.uc3m.es> Date: Wed, 13 Oct 2010 09:40:35 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mext@ietf.org References: <4CB5612E.3090900@go6.si> In-Reply-To: <4CB5612E.3090900@go6.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17700.004 Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 07:39:22 -0000 Great thanks! When can we have your review? I mean, we are waiting for the reivews to decide whether we accept this as a WG document or not. Regards, marcelo El 13/10/10 9:35, Jan Zorz @ go6.si escribió: > >>> The chairs have received a request from the authors of >>> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec that >>> their draft >>> be adopted as one of the WG deliverables for our "alternative security >>> mechanisms" work item. >>> >>> Before we go ahead with this, the chairs would like to solicit at >>> least three >>> thorough review of the document to ensure that the has an adequate >>> understanding of the proposal and its implications. >>> >>> Please support the WG process by volunteering as a reviewer. > > I volunteer to do a review. > > When some versions of this implementation from Nokia became "public" I > tested and used it for a long time. Some things to fix, some things to > add... > > Thank you, Jan Zorz > go6.si > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From root@core3.amsl.com Wed Oct 13 09:00:06 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C9CD43A69AE; Wed, 13 Oct 2010 09:00:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101013160003.C9CD43A69AE@core3.amsl.com> Date: Wed, 13 Oct 2010 09:00:03 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-10.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 16:00:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : C. Perkins, et al. Filename : draft-ietf-mext-rfc3775bis-10.txt Pages : 177 Date : 2010-10-13 This document specifies Mobile IPv6, a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13085632.I-D@ietf.org> --NextPart-- From dvijay@gmail.com Wed Oct 13 16:18:41 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608893A6A5E for ; Wed, 13 Oct 2010 16:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUzgXm47KJw9 for ; Wed, 13 Oct 2010 16:18:39 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id F31AF3A69DF for ; Wed, 13 Oct 2010 16:18:38 -0700 (PDT) Received: by pwj8 with SMTP id 8so175pwj.31 for ; Wed, 13 Oct 2010 16:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=M2xYS56Fr4mpfebl8enlkKGRfPrrn73PrYPfWtIkhVE=; b=DFbJlkWB7fLCUX8Yxxj+41mIZUXM3AHv/j67vuMYdUYXY66yJB8K5yVj9iMulHQhDQ /Hg7URYkYEq56zDRSLzNOJBtWYuTyVgGOV3Yrj3rQLj88N6emDrfPX/YndxlzZbdcoyo LTnp8TSotnyaCE4BHRnYRBGBNw690GMsuan88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jwCU3FRQYSLWILkgsMBRUQzEaJZ3/nBpiOcgf1vd73AKp0KaX6ICb132Hpl4UgQeXS U3g9eZl3gDqfS2+3Ti/XJqM1gb2PXJ93Vje1DVZKfvBIxBy6iGW0MPVVFLgzZhwAvCIA ENa/hytIwWQisGdRBZPO/WKDjW3zkND7q4Gns= Received: by 10.142.103.10 with SMTP id a10mr8153839wfc.116.1287011995305; Wed, 13 Oct 2010 16:19:55 -0700 (PDT) Received: from vijay-mac-2.local (adsl-99-96-187-86.dsl.pltn13.sbcglobal.net [99.96.187.86]) by mx.google.com with ESMTPS id v19sm10584195wfh.12.2010.10.13.16.19.52 (version=SSLv3 cipher=RC4-MD5); Wed, 13 Oct 2010 16:19:53 -0700 (PDT) Message-ID: <4CB63E98.2020104@gmail.com> Date: Wed, 13 Oct 2010 16:19:52 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Laganier, Julien" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-korhonen-mext-mip6-altsec@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 23:18:41 -0000 I can review the document (in a week or two). Vijay On 9/23/10 12:30 PM, Laganier, Julien wrote: > Folks, > > The chairs have received a request from the authors of http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec that their draft be adopted as one of the WG deliverables for our "alternative security mechanisms" work item. > > Before we go ahead with this, the chairs would like to solicit at least three thorough review of the document to ensure that the has an adequate understanding of the proposal and its implications. > > Please support the WG process by volunteering as a reviewer. > > --julien& marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Wed Oct 13 22:48:48 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1253A6A55 for ; Wed, 13 Oct 2010 22:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z++Img1JIBqP for ; Wed, 13 Oct 2010 22:48:47 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 259763A68A8 for ; Wed, 13 Oct 2010 22:48:46 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (190.30.18.95.dynamic.jazztel.es [95.18.30.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 239B7BF4CED for ; Thu, 14 Oct 2010 07:50:03 +0200 (CEST) Message-ID: <4CB69A0A.2030503@it.uc3m.es> Date: Thu, 14 Oct 2010 07:50:02 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: mext@ietf.org References: <4CB63E98.2020104@gmail.com> In-Reply-To: <4CB63E98.2020104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17702.003 Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 05:48:48 -0000 great, thanks! El 14/10/10 1:19, Vijay Devarapalli escribió: > I can review the document (in a week or two). > > Vijay > > On 9/23/10 12:30 PM, Laganier, Julien wrote: >> Folks, >> >> The chairs have received a request from the authors of >> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec that >> their draft be adopted as one of the WG deliverables for our >> "alternative security mechanisms" work item. >> >> Before we go ahead with this, the chairs would like to solicit at >> least three thorough review of the document to ensure that the has an >> adequate understanding of the proposal and its implications. >> >> Please support the WG process by volunteering as a reviewer. >> >> --julien& marcelo >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From sgundave@cisco.com Thu Oct 14 08:39:55 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7053A6AB7 for ; Thu, 14 Oct 2010 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXr6pWEBroEx for ; Thu, 14 Oct 2010 08:39:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A9A523A6A6E for ; Thu, 14 Oct 2010 08:39:54 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGrBtkyrR7Hu/2dsb2JhbAChKXGjKpx5hUgEhFOFc4MJ X-IronPort-AV: E=Sophos;i="4.57,330,1283731200"; d="scan'208";a="603980607" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2010 15:41:14 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9EFfDNa007601; Thu, 14 Oct 2010 15:41:14 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 08:41:13 -0700 Received: from 10.32.243.124 ([10.32.243.124]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 14 Oct 2010 15:41:13 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 14 Oct 2010 08:41:51 -0700 From: Sri Gundavelli To: marcelo bagnulo braun , Message-ID: Thread-Topic: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec Thread-Index: ActrtlHA4+AG8j/wzEOGiOYcqCYPZg== In-Reply-To: <4CB69A0A.2030503@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Oct 2010 15:41:13.0744 (UTC) FILETIME=[3B8BF900:01CB6BB6] Cc: Jari Arkko Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 15:39:55 -0000 Marcelo/Julien: Clarifying question ? Given that, this (Alternative Security Mechanisms for MIPv6) is now a chartered work item under experimental category, wondering about the future and the relation of the candidate solution with two existing security mechanisms, before we spin one more. We have IPsec, a normative standard, Authentication Option, an informative standard, and hopefully a perfect new solution as an experimental standard. So, what is the evolution plan, if we love this new experimental standard and MIP deployments get adopted and phase out GTP in 3GPP, will this get promoted to be an informational standard or a normative standard ? :) =20 Secondly, for Auth-Opt to be considered an alternative security mechanism, since that is some what black listed with that famous IESG note, will it be a demotion or a promotion to get that under this Experimental standard, fro= m informational standard with a red dot. :) Just curious, we will surely have excellent interoperability between vendors. Its better to put few forward looking statements around this work, else it will confuse the hell out of every one. Sri On 10/13/10 10:50 PM, "marcelo bagnulo braun" wrote: >=20 > great, thanks! >=20 > El 14/10/10 1:19, Vijay Devarapalli escribi=F3: >> I can review the document (in a week or two). >>=20 >> Vijay >>=20 >> On 9/23/10 12:30 PM, Laganier, Julien wrote: >>> Folks, >>>=20 >>> The chairs have received a request from the authors of >>> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec that >>> their draft be adopted as one of the WG deliverables for our >>> "alternative security mechanisms" work item. >>>=20 >>> Before we go ahead with this, the chairs would like to solicit at >>> least three thorough review of the document to ensure that the has an >>> adequate understanding of the proposal and its implications. >>>=20 >>> Please support the WG process by volunteering as a reviewer. >>>=20 >>> --julien& marcelo >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Thu Oct 14 10:03:02 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062D73A6B4B for ; Thu, 14 Oct 2010 10:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.154 X-Spam-Level: X-Spam-Status: No, score=-105.154 tagged_above=-999 required=5 tests=[AWL=-1.331, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuFBTUEop6Tw for ; Thu, 14 Oct 2010 10:03:00 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B8B763A6B71 for ; Thu, 14 Oct 2010 10:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287075860; x=1318611860; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Sri=20Gundavelli=20,=20marcelo =20bagnulo=20braun=0D=0A=09,=20"mext@ ietf.org"=20|CC:=20Jari=20Arkko=20|Date:=20Thu,=2014=20Oct=202010=2010:04:13 =20-0700|Subject:=20RE:=20[MEXT]=20Reviews=20of=20draft-k orhonen-mext-mip6-altsec|Thread-Topic:=20[MEXT]=20Reviews =20of=20draft-korhonen-mext-mip6-altsec|Thread-Index:=20A ctrtlHA4+AG8j/wzEOGiOYcqCYPZgACgp+g|Message-ID:=20|References:=20<4CB69A0A.2030503@it.uc3m.es>=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=Y9WWvFDt1hDyKg2JiMw0tCLALy8ip3GmET42yJaKyTw=; b=aSXhg0qEd7zdoVvUn24Wc+oggp9HF4bOaP5WKdhopxEA2pfTjSF2EtmC Cpak9+L1G40V2MUtkEkcMu5SDVfOJBsKWnI6SYOKGfCRglPlYhyzq9NlN HYX/E11IZ8okOmdjY5W/k2G9I3XMu9wePYazU5G1sEB853DyebCfA5YX9 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6136"; a="57821696" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 14 Oct 2010 10:04:19 -0700 X-IronPort-AV: E=Sophos;i="4.57,328,1283756400"; d="scan'208";a="23461408" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 14 Oct 2010 10:04:19 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 14 Oct 2010 10:04:19 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 14 Oct 2010 10:04:19 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 14 Oct 2010 10:04:18 -0700 From: "Laganier, Julien" To: Sri Gundavelli , marcelo bagnulo braun , "mext@ietf.org" Date: Thu, 14 Oct 2010 10:04:13 -0700 Thread-Topic: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec Thread-Index: ActrtlHA4+AG8j/wzEOGiOYcqCYPZgACgp+g Message-ID: References: <4CB69A0A.2030503@it.uc3m.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jari Arkko Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 17:03:02 -0000 Sri, Sri Gundavelli wrote: >=20 > Marcelo/Julien: >=20 > Clarifying question ? Sure. =20 > Given that, this (Alternative Security Mechanisms for MIPv6) is now a > chartered work item under experimental category, wondering about the > future and the relation of the candidate solution with two existing secur= ity > mechanisms, before we spin one more. To be exact: we do not spin one more, we are spinning more experimental mec= hanisms, to experiment with security model alternatives. There might be one= more, two more, etc. It all depends on what the WG think is worth experime= nting with. =20 > We have IPsec, a normative standard, Authentication Option, an > informative standard, and hopefully a perfect new solution as an experime= ntal > standard. To be exact: RFC 4285 (Authentication option) does not specify an Internet = standard of any kind. > So, what is the evolution plan, if we love this new experimental > standard and MIP deployments get adopted and phase out GTP in 3GPP, will = this > get promoted to be an informational standard or a normative standard ? :) Any new experimental RFC that the WG publish will define an Experimental Pr= otocol for the Internet community. It will not specify an Internet standar= d of any kind. As a result of the experiment, if one of the proposals is considered succes= sful we might consider progressing it on the standard track. =20 > Secondly, for Auth-Opt to be considered an alternative security > mechanism, since that is some what black listed with that famous IESG not= e, will > it be a demotion or a promotion to get that under this Experimental stand= ard, > from informational standard with a red dot. :) Since neither experimental RFCs not informational RFC defines Internet stan= dard or any kind, there does not seem to be a huge difference. However from= my perspective the experimental status highlights that an experiment is on= going and thus that at some point the results can be evaluated by the commu= nity. =20 > Just curious, we will surely have excellent interoperability between > vendors. Its better to put few forward looking statements around this > work, else it will confuse the hell out of every one. Standard wise there is no reason for anyone to be confused. IPsec remains t= he standard track, mandatory to implement security mechanism that guarantee= s interoperability. --julien From marcelo@it.uc3m.es Thu Oct 14 10:57:01 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0A53A69DC for ; Thu, 14 Oct 2010 10:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.141 X-Spam-Level: X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16qZFRpfax9o for ; Thu, 14 Oct 2010 10:57:00 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CCB7C3A699F for ; Thu, 14 Oct 2010 10:56:59 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (190.30.18.95.dynamic.jazztel.es [95.18.30.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 285FA7118F3; Thu, 14 Oct 2010 19:58:14 +0200 (CEST) Message-ID: <4CB744B4.7070109@it.uc3m.es> Date: Thu, 14 Oct 2010 19:58:12 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Laganier, Julien" References: <4CB69A0A.2030503@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17702.006 Cc: "mext@ietf.org" , Jari Arkko Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 17:57:01 -0000 I agree with all Julien stated. Just one more comment. I personally would be interested to understand for each new proposed solution, what would be the interoperability plan with the current solutions. I mean, it could be as simple as: " we assume that all nodes in the network implement the new solution", but maybe there is something more into it (e.g. the HA will support multiple security mechanisms, and the MNs will support only one). I think it would be worth doing the exercise. Regards, marcelo El 14/10/10 19:04, Laganier, Julien escribió: > Sri, > > Sri Gundavelli wrote: >> Marcelo/Julien: >> >> Clarifying question ? > Sure. > >> Given that, this (Alternative Security Mechanisms for MIPv6) is now a >> chartered work item under experimental category, wondering about the >> future and the relation of the candidate solution with two existing security >> mechanisms, before we spin one more. > To be exact: we do not spin one more, we are spinning more experimental mechanisms, to experiment with security model alternatives. There might be one more, two more, etc. It all depends on what the WG think is worth experimenting with. > >> We have IPsec, a normative standard, Authentication Option, an >> informative standard, and hopefully a perfect new solution as an experimental >> standard. > To be exact: RFC 4285 (Authentication option) does not specify an Internet standard of any kind. > >> So, what is the evolution plan, if we love this new experimental >> standard and MIP deployments get adopted and phase out GTP in 3GPP, will this >> get promoted to be an informational standard or a normative standard ? :) > Any new experimental RFC that the WG publish will define an Experimental Protocol for the Internet community. It will not specify an Internet standard of any kind. > > As a result of the experiment, if one of the proposals is considered successful we might consider progressing it on the standard track. > >> Secondly, for Auth-Opt to be considered an alternative security >> mechanism, since that is some what black listed with that famous IESG note, will >> it be a demotion or a promotion to get that under this Experimental standard, >> from informational standard with a red dot. :) > Since neither experimental RFCs not informational RFC defines Internet standard or any kind, there does not seem to be a huge difference. However from my perspective the experimental status highlights that an experiment is ongoing and thus that at some point the results can be evaluated by the community. > >> Just curious, we will surely have excellent interoperability between >> vendors. Its better to put few forward looking statements around this >> work, else it will confuse the hell out of every one. > Standard wise there is no reason for anyone to be confused. IPsec remains the standard track, mandatory to implement security mechanism that guarantees interoperability. > > --julien > From julienl@qualcomm.com Fri Oct 15 09:25:04 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8F93A6A31; Fri, 15 Oct 2010 09:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.872 X-Spam-Level: X-Spam-Status: No, score=-105.872 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lisIeinD7scR; Fri, 15 Oct 2010 09:25:02 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7981B3A695D; Fri, 15 Oct 2010 09:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287159984; x=1318695984; h=from:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |CC:=20Jari=20Arkko=20,=20"mext@iet f.org"=20,=0D=0A=09marcelo=20bagnulo=20bra un=20|Date:=20Fri,=2015=20Oct=202010 =2009:26:17=20-0700|Subject:=20Request=20to=20publish=20d raft-ietf-mext-rfc3775bis-10=20as=20Standard=20track=0D =0A=20RFC|Thread-Topic:=20Request=20to=20publish=20draft- ietf-mext-rfc3775bis-10=20as=20Standard=0D=0A=20track=20R FC|Thread-Index:=20ActshbFhcZgrQV3WSwW4gtKw5VasbQ=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach:=20yes |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/mixed=3B=0D=0A=09boundary=3D"_ 002_BF345F63074F8040B58C00A186FCA57F29F5837A2CNALASEXMB04 na_"|MIME-Version:=201.0; bh=k+SNdvbMo21qpG/BPRS6tdxrymGzn6VfX0NxVFcLNJM=; b=PUfGI0cHDQfmKDi/AxAsqlPKmBiPiRk2kTERJAPX9OpWkMSGm57VFWqT zvRR8NPtAzK/L2+oc1iNokluhk0n7m9oLQtivxgoTKWVV1w9CrBnv3t5H rzdM41DZ9iGmFeO9scyo+O7hWB6xLMESnRzMM/XlrB3YmEdKEJbR4l5Rx w=; X-IronPort-AV: E=McAfee;i="5400,1158,6137"; a="58076706" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 15 Oct 2010 09:26:24 -0700 X-IronPort-AV: E=Sophos;i="4.57,336,1283756400"; d="txt'?scan'208";a="89502838" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Oct 2010 09:26:23 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 15 Oct 2010 09:26:23 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Fri, 15 Oct 2010 09:26:23 -0700 From: "Laganier, Julien" Date: Fri, 15 Oct 2010 09:26:17 -0700 Thread-Topic: Request to publish draft-ietf-mext-rfc3775bis-10 as Standard track RFC Thread-Index: ActshbFhcZgrQV3WSwW4gtKw5VasbQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_BF345F63074F8040B58C00A186FCA57F29F5837A2CNALASEXMB04na_" MIME-Version: 1.0 Cc: Jari Arkko , "mext@ietf.org" Subject: [MEXT] Request to publish draft-ietf-mext-rfc3775bis-10 as Standard track RFC X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 16:25:04 -0000 --_002_BF345F63074F8040B58C00A186FCA57F29F5837A2CNALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Secretariat (BCC'd): This is a request to publish draft-ietf-mext-rfc3775bis-10 as Standard trac= k RFC. The PROTO I-D write-up is attached. =20 Best regards, --julien --_002_BF345F63074F8040B58C00A186FCA57F29F5837A2CNALASEXMB04na_ Content-Type: text/plain; name="rfc3775bis-writeup.txt" Content-Description: rfc3775bis-writeup.txt Content-Disposition: attachment; filename="rfc3775bis-writeup.txt"; size=6608; creation-date="Fri, 17 Sep 2010 12:46:05 GMT"; modification-date="Fri, 15 Oct 2010 09:19:45 GMT" Content-Transfer-Encoding: base64 ICAoMS5hKSBXaG8gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGZvciB0aGlzIGRvY3VtZW50PyBI YXMgdGhlDQogICAgICAgIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2aWV3ZWQgdGhp cyB2ZXJzaW9uIG9mIHRoZSANCiAgICAgICAgZG9jdW1lbnQgYW5kLCBpbiBwYXJ0aWN1bGFyLCBk b2VzIGhlIG9yIHNoZSBiZWxpZXZlIHRoaXMgDQogICAgICAgIHZlcnNpb24gaXMgcmVhZHkgZm9y IGZvcndhcmRpbmcgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uPyANCg0KCVRoZSBEb2N1bWVu dCBTaGVwaGVyZCBpcyBKdWxpZW4gTGFnYW5pZXIsIE1FWFQgY28tY2hhaXIuIEhlDQogICAgICAg IGhhcyBwZXJzb25hbGx5IGRvbmUgYSB0aG9yb3VnaCByZXZpZXcgb2YgdGhlIGRvY3VtZW50LiBI ZQ0KICAgICAgICBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgZm9yd2FyZGluZyB0 byBJRVNHIGZvcg0KICAgICAgICBwdWJsaWNhdGlvbi4NCgkNCiAgKDEuYikgSGFzIHRoZSBkb2N1 bWVudCBoYWQgYWRlcXVhdGUgcmV2aWV3IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycyANCiAgICAg ICAgYW5kIGZyb20ga2V5IG5vbi1XRyBtZW1iZXJzPyBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVy ZCBoYXZlIA0KICAgICAgICBhbnkgY29uY2VybnMgYWJvdXQgdGhlIGRlcHRoIG9yIGJyZWFkdGgg b2YgdGhlIHJldmlld3MgdGhhdCANCiAgICAgICAgaGF2ZSBiZWVuIHBlcmZvcm1lZD8gIA0KDQog ICAgICAgIFRoZSBkb2N1bWVudCB3YXMgZ2l2ZW4gYWRlcXVhdGUgcmV2aWV3cy4gVGhlIERvY3Vt ZW50IFNoZXBoZXJkIGhhcw0KICAgICAgICBubyBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3Ig YnJlYWR0aCBvZiB0aGVzZSByZXZpZXdzLg0KDQogICgxLmMpIERvZXMgdGhlIERvY3VtZW50IFNo ZXBoZXJkIGhhdmUgY29uY2VybnMgdGhhdCB0aGUgZG9jdW1lbnQgDQogICAgICAgIG5lZWRzIG1v cmUgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGJyb2FkZXIgcGVyc3BlY3RpdmUsIA0KICAg ICAgICBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZSBmYW1p bGlhciB3aXRoIA0KICAgICAgICBBQUEsIGludGVybmF0aW9uYWxpemF0aW9uIG9yIFhNTD8gDQoN CiAgICAgICAgVGhlIERvY3VtZW50IFNoZXBoZXJkIGhhcyBubyBzdWNoIGNvbmNlcm5zLg0KDQog ICgxLmQpIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IHNwZWNpZmljIGNvbmNl cm5zIG9yIA0KICAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3Bv bnNpYmxlIEFyZWEgRGlyZWN0b3INCiAgICAgICAgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBiZSBh d2FyZSBvZj8gRm9yIGV4YW1wbGUsIHBlcmhhcHMgaGUgDQogICAgICAgIG9yIHNoZSBpcyB1bmNv bWZvcnRhYmxlIHdpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIA0KICAgICAg ICBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gSW4g YW55IA0KICAgICAgICBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVz IGFuZCBoYXMgaW5kaWNhdGVkIA0KICAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZh bmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlIA0KICAgICAgICBjb25jZXJucyBoZXJlLiBI YXMgYW4gSVBSIGRpc2Nsb3N1cmUgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50IA0KICAgICAgICBi ZWVuIGZpbGVkPyBJZiBzbywgcGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhlIA0KICAg ICAgICBkaXNjbG9zdXJlIGFuZCBzdW1tYXJpemUgdGhlIFdHIGRpc2N1c3Npb24gYW5kIGNvbmNs dXNpb24gb24gDQogICAgICAgIHRoaXMgaXNzdWUuIA0KDQogICAgICAgIFRoZSBEb2N1bWVudCBT aGVwaGVyZCBoYXMgbm8gc3VjaCBjb25jZXJucy4NCg0KICAoMS5lKSBIb3cgc29saWQgaXMgdGhl IFdHIGNvbnNlbnN1cyBiZWhpbmQgdGhpcyBkb2N1bWVudD8gRG9lcyBpdCANCiAgICAgICAgcmVw cmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ugb2YgYSBmZXcgaW5kaXZpZHVhbHMsIHdpdGgg DQogICAgICAgIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdHIGFzIGEgd2hvbGUg dW5kZXJzdGFuZCBhbmQgDQogICAgICAgIGFncmVlIHdpdGggaXQ/ICAgDQoNCglUaGVyZSBpcyBX RyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQuDQoNCiAgKDEuZikgSGFzIGFueW9uZSB0 aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUgDQogICAg ICAgIGRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25m bGljdCBpbiANCiAgICAgICAgc2VwYXJhdGUgZW1haWwgbWVzc2FnZXMgdG8gdGhlIFJlc3BvbnNp YmxlIEFyZWEgRGlyZWN0b3IuIChJdCANCiAgICAgICAgc2hvdWxkIGJlIGluIGEgc2VwYXJhdGUg ZW1haWwgYmVjYXVzZSB0aGlzIHF1ZXN0aW9ubmFpcmUgaXMgDQogICAgICAgIGVudGVyZWQgaW50 byB0aGUgSUQgVHJhY2tlci4pIA0KDQogICAgICAgIE5vLg0KDQogICgxLmcpIEhhcyB0aGUgRG9j dW1lbnQgU2hlcGhlcmQgcGVyc29uYWxseSB2ZXJpZmllZCB0aGF0IHRoZSANCiAgICAgICAgZG9j dW1lbnQgc2F0aXNmaWVzIGFsbCBJRCBuaXRzPyAoU2VlIHRoZSBJbnRlcm5ldC1EcmFmdHMgQ2hl Y2tsaXN0IA0KICAgICAgICBhbmQgaHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy8p LiBCb2lsZXJwbGF0ZSBjaGVja3MgYXJlIA0KICAgICAgICBub3QgZW5vdWdoOyB0aGlzIGNoZWNr IG5lZWRzIHRvIGJlIHRob3JvdWdoLiBIYXMgdGhlIGRvY3VtZW50IA0KICAgICAgICBtZXQgYWxs IGZvcm1hbCByZXZpZXcgY3JpdGVyaWEgaXQgbmVlZHMgdG8sIHN1Y2ggYXMgdGhlIE1JQiANCiAg ICAgICAgRG9jdG9yLCBtZWRpYSB0eXBlIGFuZCBVUkkgdHlwZSByZXZpZXdzPyANCg0KCVllcy4N Cg0KICAoMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0cyByZWZlcmVuY2VzIGludG8gbm9y bWF0aXZlIGFuZCANCiAgICAgICAgaW5mb3JtYXRpdmU/IEFyZSB0aGVyZSBub3JtYXRpdmUgcmVm ZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdCANCiAgICAgICAgYXJlIG5vdCByZWFkeSBmb3IgYWR2 YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1bmNsZWFyIA0KICAgICAgICBzdGF0ZT8g SWYgc3VjaCBub3JtYXRpdmUgcmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgDQogICAgICAg IHN0cmF0ZWd5IGZvciB0aGVpciBjb21wbGV0aW9uPyBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVy ZW5jZXMgDQogICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFzIGRlc2NyaWJl ZCBpbiBbUkZDMzk2N10/IElmIA0KICAgICAgICBzbywgbGlzdCB0aGVzZSBkb3dud2FyZCByZWZl cmVuY2VzIHRvIHN1cHBvcnQgdGhlIEFyZWEgDQogICAgICAgIERpcmVjdG9yIGluIHRoZSBMYXN0 IENhbGwgcHJvY2VkdXJlIGZvciB0aGVtIFtSRkMzOTY3XS4gDQoNCglUaGUgZG9jdW1lbnQgaGFz IHNwbGl0IGl0cyByZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFuZA0KICAgICAgICBpbmZvcm1h dGl2ZS4gVGhlcmUgYXJlIG5laXRoZXIgbm9ybWF0aXZlIHJlZmVyZW5jZXMgaW4gYW4gdW5jbGVh cg0KICAgICAgICBzdGF0ZSwgbm9yIGRvd253YXJkIHJlZmVyZW5jZXMuIA0KDQogICgxLmkpIEhh cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCB0aGUgZG9jdW1lbnQgSUFOQSAN CiAgICAgICAgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cyBhbmQgaXMgY29uc2lzdGVudCB3 aXRoIHRoZSBib2R5IA0KICAgICAgICBvZiB0aGUgZG9jdW1lbnQ/IElmIHRoZSBkb2N1bWVudCBz cGVjaWZpZXMgcHJvdG9jb2wgDQogICAgICAgIGV4dGVuc2lvbnMsIGFyZSByZXNlcnZhdGlvbnMg cmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkEgDQogICAgICAgIHJlZ2lzdHJpZXM/IEFyZSB0 aGUgSUFOQSByZWdpc3RyaWVzIGNsZWFybHkgaWRlbnRpZmllZD8gSWYgDQogICAgICAgIHRoZSBk b2N1bWVudCBjcmVhdGVzIGEgbmV3IHJlZ2lzdHJ5LCBkb2VzIGl0IGRlZmluZSB0aGUgDQogICAg ICAgIHByb3Bvc2VkIGluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lzdHJ5IGFuZCBhbiBhbGxv Y2F0aW9uIA0KICAgICAgICBwcm9jZWR1cmUgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zPyBEb2Vz IGl0IHN1Z2dlc3QgYSANCiAgICAgICAgcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lz dHJ5PyBTZWUgW1JGQzUyMjZdLiBJZiB0aGUgDQogICAgICAgIGRvY3VtZW50IGRlc2NyaWJlcyBh biBFeHBlcnQgUmV2aWV3IHByb2Nlc3MgaGFzIFNoZXBoZXJkIA0KICAgICAgICBjb25mZXJyZWQg d2l0aCB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3RvciBzbyB0aGF0IHRoZSBJRVNHIA0KICAg ICAgICBjYW4gYXBwb2ludCB0aGUgbmVlZGVkIEV4cGVydCBkdXJpbmcgdGhlIElFU0cgRXZhbHVh dGlvbj8gDQoNCiAgICAgICAgWWVzLg0KDQogICgxLmopIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhl cmQgdmVyaWZpZWQgdGhhdCBzZWN0aW9ucyBvZiB0aGUgDQogICAgICAgIGRvY3VtZW50IHRoYXQg YXJlIHdyaXR0ZW4gaW4gYSBmb3JtYWwgbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIA0KICAgICAgICBj b2RlLCBCTkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywgZXRjLiwgdmFsaWRhdGUgY29ycmVjdGx5 IGluIA0KICAgICAgICBhbiBhdXRvbWF0ZWQgY2hlY2tlcj8gDQoNCiAgICAgICAgVGhlcmUgYXJl IG5vIHN1Y2ggc2VjdGlvbnMuDQoNCiAgKDEuaykgVGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2Vt ZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQgDQogICAgICAgIEFubm91bmNlbWVudCBXcml0ZS1VcC4g UGxlYXNlIHByb3ZpZGUgc3VjaCBhIERvY3VtZW50IA0KICAgICAgICBBbm5vdW5jZW1lbnQgV3Jp dGUtVXA/IFJlY2VudCBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlDQogICAgICAgICJBY3Rp b24iIGFubm91bmNlbWVudHMgZm9yIGFwcHJvdmVkIGRvY3VtZW50cy4gVGhlIGFwcHJvdmFsIA0K ICAgICAgICBhbm5vdW5jZW1lbnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBzZWN0aW9uczogDQoN CiAgICAgVGVjaG5pY2FsIFN1bW1hcnkgDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIE1v YmlsZSBJUHY2LCBhIHByb3RvY29sIHdoaWNoIGFsbG93cyBub2RlcyB0bw0KICAgcmVtYWluIHJl YWNoYWJsZSB3aGlsZSBtb3ZpbmcgYXJvdW5kIGluIHRoZSBJUHY2IEludGVybmV0LiAgRWFjaA0K ICAgbW9iaWxlIG5vZGUgaXMgYWx3YXlzIGlkZW50aWZpZWQgYnkgaXRzIGhvbWUgYWRkcmVzcywg cmVnYXJkbGVzcyBvZg0KICAgaXRzIGN1cnJlbnQgcG9pbnQgb2YgYXR0YWNobWVudCB0byB0aGUg SW50ZXJuZXQuICBXaGlsZSBzaXR1YXRlZCBhd2F5DQogICBmcm9tIGl0cyBob21lLCBhIG1vYmls ZSBub2RlIGlzIGFsc28gYXNzb2NpYXRlZCB3aXRoIGEgY2FyZS1vZg0KICAgYWRkcmVzcywgd2hp Y2ggcHJvdmlkZXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG1vYmlsZSBub2RlJ3MgY3VycmVudA0K ICAgbG9jYXRpb24uICBJUHY2IHBhY2tldHMgYWRkcmVzc2VkIHRvIGEgbW9iaWxlIG5vZGUncyBo b21lIGFkZHJlc3MgYXJlDQogICB0cmFuc3BhcmVudGx5IHJvdXRlZCB0byBpdHMgY2FyZS1vZiBh ZGRyZXNzLiAgVGhlIHByb3RvY29sIGVuYWJsZXMNCiAgIElQdjYgbm9kZXMgdG8gY2FjaGUgdGhl IGJpbmRpbmcgb2YgYSBtb2JpbGUgbm9kZSdzIGhvbWUgYWRkcmVzcyB3aXRoDQogICBpdHMgY2Fy ZS1vZiBhZGRyZXNzLCBhbmQgdG8gdGhlbiBzZW5kIGFueSBwYWNrZXRzIGRlc3RpbmVkIGZvciB0 aGUNCiAgIG1vYmlsZSBub2RlIGRpcmVjdGx5IHRvIGl0IGF0IHRoaXMgY2FyZS1vZiBhZGRyZXNz LiAgVG8gc3VwcG9ydCB0aGlzDQogICBvcGVyYXRpb24sIE1vYmlsZSBJUHY2IGRlZmluZXMgYSBu ZXcgSVB2NiBwcm90b2NvbCBhbmQgYSBuZXcNCiAgIGRlc3RpbmF0aW9uIG9wdGlvbi4gIEFsbCBJ UHY2IG5vZGVzLCB3aGV0aGVyIG1vYmlsZSBvciBzdGF0aW9uYXJ5LA0KICAgY2FuIGNvbW11bmlj YXRlIHdpdGggbW9iaWxlIG5vZGVzLiAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDM3NzUu DQoNCiAgICAgV29ya2luZyBHcm91cCBTdW1tYXJ5IA0KDQogICBUaGUgbm9ybWFsIFdHIHByb2Nl c3Mgd2FzIGZvbGxvd2VkIGFuZCB0aGUgZG9jdW1lbnQgcmV2aXNpb25zIGhhdmUgYmVlbiANCiAg IGRpc2N1c3NlZCBmb3Igb3ZlciB0d28geWVhcnMuIFRoZSBkb2N1bWVudCBhcyBpdCBpcyBub3cs IHJlZmxlY3RzIFdHDQogICBjb25zZW5zdXMsIHdpdGggbm90aGluZyBzcGVjaWFsIHdvcnRoIG5v dGluZy4NCg0KICAgICBEb2N1bWVudCBRdWFsaXR5IA0KDQogICBUaGUgZG9jdW1lbnQgd2FzIGdp dmVuIGFkZXF1YXRlIHJldmlld3MuIFRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMNCiAgIG5vIGNv bmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZXNlIHJldmlld3MuDQo= --_002_BF345F63074F8040B58C00A186FCA57F29F5837A2CNALASEXMB04na_-- From behcetsarikaya@yahoo.com Fri Oct 15 11:42:10 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CED13A6CF0 for ; Fri, 15 Oct 2010 11:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqaM5wzVP8TS for ; Fri, 15 Oct 2010 11:42:09 -0700 (PDT) Received: from nm16.bullet.mail.sp2.yahoo.com (nm16.bullet.mail.sp2.yahoo.com [98.139.91.86]) by core3.amsl.com (Postfix) with SMTP id 414F93A684F for ; Fri, 15 Oct 2010 11:42:09 -0700 (PDT) Received: from [98.139.91.67] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 15 Oct 2010 18:43:28 -0000 Received: from [98.139.91.1] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 15 Oct 2010 18:43:28 -0000 Received: from [127.0.0.1] by omp1001.mail.sp2.yahoo.com with NNFMP; 15 Oct 2010 18:43:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 292055.26243.bm@omp1001.mail.sp2.yahoo.com Received: (qmail 58120 invoked by uid 60001); 15 Oct 2010 18:43:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1287168207; bh=sisVAbD2Q+RO0Tj5Q2oUOfKsLSd9D5xdz525x+Cmv8k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eOHZCb2rwVfoQvhUlQ2XImmMZrUCTVXI4vyR/VyLRM00eBBjNfwDTykpNzTvpTXiJTDD4n4FJF1RMfncouLXbNYRqOGH6HqiNLLWxLzKdcgU9m3D8NqeD0l09jPzBgvOOzCrgewf7kPn5x/c3mDWGYWWeBsUO/Aszcj3p2Od+9c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jcCxTOfHU07iNbID45Q7dvH+NmYECLuJUVapFwt6An663aSzKv6CfPXatFut7Oj7A5W2ax4XNIXbtioBcpEVxfL4QpZISD1QlfH4Lac0JVkihPzUWGPiEQ0/bDcAf6W+MkR46lmPfFMn0dfAOhThBZ+X/iyAbrMWndMNvdFgLjk=; Message-ID: <688232.57301.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: n6Qw1LoVM1lNICUaMAu62ucGIr6QDiogUzZJ.0UMB9fzdaJ 4jNB6CDnXvSSjfSE8xHkgrqfEa0Of6x4muLk1eq_TdmpAmt.KauVzl.qTpCY w0bnFNdX1aMVEOI8n4NpU5FxaH9AVhjZ51jV2MhqOHH1oSbzUJ5BEMfX.oe9 DROd0gQpUPrvk1PSnue_bn0fZjE_E1N6eZxDaGsxUxoF54zUiO.MJmNtQLGe weJKIMtQKjnSqcZP_AJdo6vI0JNGhNyj1EIcAfl56yWLxiQ_iLq1.Urvj3l5 9jbGZIY7gNwJS9ML6Xq43vKsjX31g8U.DItZKFmdCPuiYMB2VNGuirBbBGUZ Dpa4gR26a4C_Oc1_DlTwFtF8O3Q-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 15 Oct 2010 11:43:27 PDT X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.106.282862 References: <4CB69A0A.2030503@it.uc3m.es> <4CB744B4.7070109@it.uc3m.es> Date: Fri, 15 Oct 2010 11:43:27 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun , "Laganier, Julien" In-Reply-To: <4CB744B4.7070109@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jari Arkko , "mext@ietf.org" Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 18:42:10 -0000 Hi Marcelo,=0A =0A From SDO point of view, I think that WiMAX already ado= pted RFC 4285 =0A(Authentication option) and=0A3GPP is happy with IPSec. = =0A=0AThis new experimental security mechanism is looking for a place to go= . I hope it =0Adoes find one.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Or= iginal Message ----=0A> From: marcelo bagnulo braun =0A= > To: "Laganier, Julien" =0A> Cc: "mext@ietf.org" ; Jari Arkko =0A> Sent: Thu, October 14, = 2010 12:58:12 PM=0A> Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip= 6-altsec=0A> =0A> I agree with all Julien stated.=0A> Just one more comme= nt.=0A> =0A> I personally would be interested to understand for each new p= roposed =0A> solution, what would be the interoperability plan with the cu= rrent =0A> solutions. I mean, it could be as simple as: " we assume that a= ll nodes =0A> in the network implement the new solution", but maybe there = is something =0A> more into it (e.g. the HA will support multiple security= mechanisms, and =0A> the MNs will support only one).=0A> I think it would= be worth doing the exercise.=0A> =0A> Regards, marcelo=0A> =0A> El 14/10/= 10 19:04, Laganier, Julien escribi=F3:=0A> > Sri,=0A> >=0A> > Sri Gundavel= li wrote:=0A> >> Marcelo/Julien:=0A> >>=0A> >> Clarifying question ?=0A> >= Sure.=0A> >=0A> >> Given that, this (Alternative Security Mechanisms for = MIPv6) is now a=0A> >> chartered work item under experimental category, w= ondering about the=0A> >> future and the relation of the candidate solutio= n with two existing =0A>security=0A> >> mechanisms, before we spin one mor= e.=0A> > To be exact: we do not spin one more, we are spinning more experi= mental =0A>mechanisms, to experiment with security model alternatives. Ther= e might be one =0A>more, two more, etc. It all depends on what the WG thin= k is worth experimenting =0A>with.=0A> >=0A> >> We have IPsec, a normative= standard, Authentication Option, an=0A> >> informative standard, and hope= fully a perfect new solution as an =0A>experimental=0A> >> standard.=0A> >= To be exact: RFC 4285 (Authentication option) does not specify an Interne= t =0A>standard of any kind.=0A> >=0A> >> So, what is the evolution plan, i= f we love this new experimental=0A> >> standard and MIP deployments get ad= opted and phase out GTP in 3GPP, will =0A>this=0A> >> get promoted to be a= n informational standard or a normative standard ? :)=0A> > Any new experi= mental RFC that the WG publish will define an Experimental =0A>Protocol fo= r the Internet community. It will not specify an Internet standard =0A>of= any kind.=0A> >=0A> > As a result of the experiment, if one of the propos= als is considered =0A>successful we might consider progressing it on the s= tandard track.=0A> >=0A> >> Secondly, for Auth-Opt to be considered an al= ternative security=0A> >> mechanism, since that is some what black listed = with that famous IESG note, =0A>will=0A> >> it be a demotion or a promotion= to get that under this Experimental =0A>standard,=0A> >> from information= al standard with a red dot. :)=0A> > Since neither experimental RFCs not = informational RFC defines Internet =0A>standard or any kind, there does not= seem to be a huge difference. However from =0A>my perspective the experim= ental status highlights that an experiment is ongoing =0A>and thus that at= some point the results can be evaluated by the community.=0A> >=0A> >> Ju= st curious, we will surely have excellent interoperability between=0A> >> = vendors. Its better to put few forward looking statements around this=0A> = >> work, else it will confuse the hell out of every one.=0A> > Standard wi= se there is no reason for anyone to be confused. IPsec remains =0A>the sta= ndard track, mandatory to implement security mechanism that guarantees =0A= >interoperability.=0A> >=0A> > --julien=0A> >=0A> =0A> ___________________= ____________________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> h= ttps://www.ietf.org/mailman/listinfo/mext=0A> =0A=0A=0A From jari.arkko@piuha.net Fri Oct 15 15:41:45 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D533A6AD7 for ; Fri, 15 Oct 2010 15:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiAs3+GNnXE8 for ; Fri, 15 Oct 2010 15:41:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CAD973A6A30 for ; Fri, 15 Oct 2010 15:41:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3D7552CC31; Sat, 16 Oct 2010 01:43:05 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpPOJ1tUYw26; Sat, 16 Oct 2010 01:43:04 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6B3962CC2F; Sat, 16 Oct 2010 01:43:04 +0300 (EEST) Message-ID: <4CB8D8F7.1040301@piuha.net> Date: Sat, 16 Oct 2010 01:43:03 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "mext@ietf.org" , "draft-ebalard-mext-pfkey-enhanced-migrate@tools.ietf.org" , "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MEXT] AD review of draft-ebalard-mext-pfkey-enhanced-migrate X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 22:41:45 -0000 I have reviewed this draft. I would like to move it to forward, but there are a few technical issues and a number of editorial problems. Please correct the editorial problems and respond on the technical issues. Also, Julien, would it be possible to get some IPsec experts to review this as well? Technical: > Mobile IPv6 may need to make an access to the SPD not only for > updating an endpoint address but also for deleting/inserting a > specific SPD entry. When the MN performs Foreign-to-Home movement, > IPsec SA established between the MN and HA to protect data traffic > should be deleted, and associated SPD entries should have no effect > anymore. On the other hand, when the MN performs Home-to-Foreign > movement, those IPsec SP should be restored. Hence security policy > entries that are associated with tunnel mode SA may dynamically be > added/removed (enabled/disabled) in along with MN's movements. As a > side note for such a scenario, Home Link detection mechanism becomes > critical security-wise [hld-sec ] Its not clear to me why this disabling is required. Can you elaborate? It seems that since the security policy dictates that communication with the home agent needs to be secured, I'll note that the de-registration BU still needs to be protected. And after that, if there is no communication with the home agent, what problem is solved by removing the SA/SP? Also, I'm not too happy about including references to major new pieces of needed mechanisms in other drafts, when those drafts are not in IETF process already. > o Key manager address information > * source address > * destination address > o Selector information: > * source address/port > * destination address/port > * upper layer protocol (i.e., Mobility Header) > * direction (inbound/outbound) For the tunnel SAs, there will not be a Mobility Header. You say later "For tunnel mode, the endpoint addresses refer to the source and destination IP addresses that appear in the IP header, and those should be provided by the MIGRAT E message." But above you seem to imply that the upper layer protocol is always MH. > o Old SA information: > * old source endpoint address > * old destination endpoint address > * IPsec protocol (ESP/AH) > * mode (Tunnel/Transport) > o New SA information: > * new source endpoint address > * new destination endpoint address > * IPsec protocol (ESP/AH) > * mode (Tunnel/Transport) > > I do not understand how you identify the SA/SPD entry with this. > It should be noted that delivery of PF_KEY MIGRATE messages cannot be > guaranteed, which is common to other PF_KEY messages. It may be > possible (even if highly unlikely) that a MIGRATE message be lost. > In such case, there will be inconsistency between the binding record > managed by Mobile IPv6 and IPsec database inside the kernel or the > IKE daemon. Once a PF_KEY MIGRATE message is lost, it would not be > possible for the receiver to process some subsequent MIGRATE messages > properly. Reinitialization of the Mobile IPv6 stack and IPsec > databases may be needed for recovery. > I'm not sure I understand why. If the MIGRATE message is copied back to all open PF_KEY sockets, presumably the Mobile IPv6 daemon would also see a copy if the kernel actually received the message. So what is the problem? Editorial: > This document is heavily based on a previous draft [MIGRATE ] written > by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply > reuses the MIGRATE mechanism defined in the expired document, removes > a companion extension (SADB_X_EXT_PACKET) based on implementation > feedback (complexity, limitations, ...) and fills the gap by very > simple changes to MIGRATE mechanism. This results in a more simple > and consistent mechanism, which also proved to be easier to > implement. This document is expected to serve as a continuation of > [MIGRATE ] work. For that reason, the name of the extension has been > kept. > This material belongs somewhere else (maybe the introduction or the acknowledgements section) but not in the abstract. Actually, I think the paragraph at the end of Section 1 already is sufficient, so you might be able to remove this text altogether. > For the IPsec stack, this allows migrating the endpoint addresses of > the IPsec SA (and associated SP). SP is not defined. > This memo proposes such an API based > on PF_KEY framework both to document the needs and ease > interoperability between components which may be provided by > different vendors. > Just say "... based on the PF_KEY framework." The rest repeats too much of what was already said in the introduction. > 5.1.2. Bootstrapping > > > In the bootstrapping stage of Mobile IPv6 This is somewhat confusing because bootstrapping has a different meaning in the existing mobile IPv6 RFCs; I think you mean the initial registration. > With that information, the key manager is able to inflect > its usual processing where it selects by default the source address > of the SA for the negotiation (i.e. as local address of the IKE_SA). > .. able to change its usual ... ? > associated with that SP. The information SHOUD also be used by the SHOULD > A PF_KEY MIGRATE message should be formed, based on security policy > configuration and binding record. What is a binding record? Do you mean a binding cache entry, or a binding update list entry? Section 6 should probably be an appendix. Likewise for Section 7. I'm not sure I see much value in keeping Section 10 at all. > o Modifications to IPsec stack: > * Processing PF_KEY MIGRATE messages: the kernel should be able > to process PF_KEY MIGRATE messages sent by the Mobile IPv6 > code. Unless the message is invalid, it should be sent to all > open PF_KEY sockets. > Something is missing here. I think you meant to say that once it is processed by the kernel, it shall be copied to all open PF_KEY sockets. > == The document seems to lack the recommended RFC 2119 boilerplate, > even if > it appears to use RFC 2119 keywords -- however, there's a > paragraph with > a matching beginning. Boilerplate error? (From idnits) This seems like an error that you should should fix. > > ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) > > ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) > Please check that you are referring to the RFCs that you wanted to refer to. If there is no specific reason to refer to old ones, please use the new ones instead. Jari From julienl@qualcomm.com Fri Oct 15 16:15:16 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D683A6B0B for ; Fri, 15 Oct 2010 16:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpClImDltOPU for ; Fri, 15 Oct 2010 16:15:15 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4C5473A6ADF for ; Fri, 15 Oct 2010 16:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287184597; x=1318720597; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20,=20"mext@iet f.org"=20,=0D=0A=09"draft-ebalard-mext-pfk ey-enhanced-migrate@tools.ietf.org"=0D=0A=09|Date:=20Fri ,=2015=20Oct=202010=2016:16:32=20-0700|Subject:=20RE:=20[ MEXT]=20AD=20review=20of=20draft-ebalard-mext-pfkey-enhan ced-migrate|Thread-Topic:=20[MEXT]=20AD=20review=20of=20d raft-ebalard-mext-pfkey-enhanced-migrate|Thread-Index:=20 ActsulokhkMMJrqBQTe2X2XSbXymEwABFPQw|Message-ID:=20|References:=20<4CB8D8F7.1040301@piuha.net> |In-Reply-To:=20<4CB8D8F7.1040301@piuha.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=UkcA/zRYZglbzuw/FQBB5BhDBWsAad33MLU3YNHkqfo=; b=yhopWe8TN6UwXT/sN/UN2j5tSnzBvuOWjqclPHpW6nyeewez1H/wD9oF BKeNzAaokBUkPkRoSTBl+6XUMzP8+IFSWr4SxIqx8iW2GpX48uF3OwULs uq0/GyTmld9H/L4N8YyBAMxkKgnISGUkO/cqyor6UfNUz+snw5Cl3eb1g E=; X-IronPort-AV: E=McAfee;i="5400,1158,6137"; a="58122142" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 15 Oct 2010 16:16:35 -0700 X-IronPort-AV: E=Sophos;i="4.57,337,1283756400"; d="scan'208";a="20423041" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Oct 2010 16:16:35 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 15 Oct 2010 16:16:35 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Fri, 15 Oct 2010 16:16:35 -0700 From: "Laganier, Julien" To: Jari Arkko , "mext@ietf.org" , "draft-ebalard-mext-pfkey-enhanced-migrate@tools.ietf.org" Date: Fri, 15 Oct 2010 16:16:32 -0700 Thread-Topic: [MEXT] AD review of draft-ebalard-mext-pfkey-enhanced-migrate Thread-Index: ActsulokhkMMJrqBQTe2X2XSbXymEwABFPQw Message-ID: References: <4CB8D8F7.1040301@piuha.net> In-Reply-To: <4CB8D8F7.1040301@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] AD review of draft-ebalard-mext-pfkey-enhanced-migrate X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 23:15:16 -0000 Jari Arkko wrote: >=20 > I have reviewed this draft. I would like to move it to forward, but > there are a few technical issues and a number of editorial problems. > Please correct the editorial problems and respond on the technical > issues. Also, Julien, would it be possible to get some IPsec experts to > review this as well? Certainly. I'll recruit some people. --julien From sijeon79@gmail.com Fri Oct 15 21:42:18 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4610D3A6A8B; Fri, 15 Oct 2010 21:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcKd8GhVbReS; Fri, 15 Oct 2010 21:42:17 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 4DC7C3A6A79; Fri, 15 Oct 2010 21:42:17 -0700 (PDT) Received: by pvg16 with SMTP id 16so303291pvg.31 for ; Fri, 15 Oct 2010 21:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc:subject :date:organization:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:x-mimeole; bh=KXvMLPtIL0w5etYMiMTbf3climRmTjqE56KOMHs+ccA=; b=TuT2O2LPlPERIU9IjPEJOOB67abBXevxQSXfxGZfMD0UKr7wT/p90wsV9DBxOPhl2k Wstgbg8Dk4U3B6S3c3E0yUhh7xlQDJHMuuUQ/VSSbj7QDEpUyrY4+PrNxZEoDB/cc9g2 WWNBdEn2fjtN+hbHaVu16gYHJkUk48ffmiT98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:x-mimeole; b=hv5DpUg2hcm+UX0kliheuMU0pgehKiH3sWGoXaMYu2j8Eze7SYNvUuRN+jlj6xcwsG b7PVRnE/i/eCD6lNvG5H4nrrX2Q9qfpR5nQ0eU2OZAwSRia8YsSpycR0H32eWnroPhVP HgDrzSA+c6WWXLVXxPH3p4SWyaYW7qO2Ko3U8= Received: by 10.142.217.14 with SMTP id p14mr1350337wfg.334.1287204218427; Fri, 15 Oct 2010 21:43:38 -0700 (PDT) Received: from kjwkor ([220.149.84.225]) by mx.google.com with ESMTPS id p8sm17106255wff.4.2010.10.15.21.43.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 Oct 2010 21:43:37 -0700 (PDT) From: "Seil Jeon" To: Date: Sat, 16 Oct 2010 13:44:04 +0900 Organization: dcn Message-ID: <3582989EF6254B459E24958511667629@kjwkor> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acts6svy4utL1l78S+WyChQH9UnwOQAAN8Ig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: netlmm@ietf.org Subject: [MEXT] FW: Manual Post Requested for draft-sijeon-mext-nemo-pmip6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 04:42:18 -0000 Hi, mext folks, We just submitted NEMO-enabled PMIPv6 solution by employing proxy router. We actively welcome a variety of opinions. Regards, Seil Jeon -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Saturday, October 16, 2010 1:29 PM To: internet-drafts@ietf.org Cc: sijeon@dcn.ssu.ac.kr; younghak@ssu.ac.kr; jwjang84@dcn.ssu.ac.kr Subject: Manual Post Requested for draft-sijeon-mext-nemo-pmip6 Manual Posting Requested for following Internet-Draft: I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=27192 Filename: draft-sijeon-mext-nemo-pmip6 Version: 00 Staging URL: http://www.ietf.org/staging/draft-sijeon-mext-nemo-pmip6- 00.txt Title: Network Mobility Support in the Proxy Mobile IPv6 Domain Creation_date: 2010-10-16 WG ID: Individual Submission Number_of_pages: 15 Abstract: Network mobility (NEMO) enables all the nodes within a mobile network to provide session continuity without requiring their involvement when the mobile network moves. To provide NEMO support, the NEMO basic support protocol (NEMO-BSP) is specified in [RFC 3963]. With the advances of the network-based mobility management protocol referred to as Proxy Mobile IPv6 (PMIPv6), interest in applicable NEMO support in the PMIPv6 domain is increasing however, the standard PMIPv6, defined in [RFC 5213], handles only a single mobile node. This document presents a NEMO-enabled PMIPv6 using a Proxy Router (PR) rather than the MR defined in [RFC 3963] and describes detailed operations for network/node mobility support in the PMIPv6 domain. Submitter: Seil Jeon (sijeon@dcn.ssu.ac.kr) Author(s): Seil Jeon, sijeon@dcn.ssu.ac.kr Young-Han Kim, younghak@ssu.ac.kr Jiwon Jang, jwjang84@dcn.ssu.ac.kr From arno@natisbad.org Sat Oct 16 04:57:45 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009893A6AA4 for ; Sat, 16 Oct 2010 04:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.385 X-Spam-Level: X-Spam-Status: No, score=-4.385 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRxV3etYVB3t for ; Sat, 16 Oct 2010 04:57:42 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id D773E3A6AE3 for ; Sat, 16 Oct 2010 04:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: Message-ID:MIME-Version:Content-Type; bh=T+GFMkIzMJryW8I6krWhfO2 WP2l1eKtb1gSX1IBmaqU=; b=PrE4Va/OkH4LgtkHjJ2eycJwehqVdjAtsSQuMi8 KsFXXFpU1WWRMixY4+Yrk3cENhaeZiAPvE2nbdnO6ySfR3f3Q0fNS+rEpbejv+sl k/g5P4nKGK4c/E7KTTJ0ne3bcKpN4Vq9wp4wYu7vKZAN5UFhyEdWUGgRCSesoRlh M32A= Received: from [2a01:e35:2efc:86d0:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P75PM-0002mA-Fs; Sat, 16 Oct 2010 13:58:40 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Jari Arkko References: <4CB8D8F7.1040301@piuha.net> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B X-Hashcash: 1:20:101016:julienl@qualcomm.com::6koBWeBZL9nL7QpZ:00000000000000000000000000000000000000000391e X-Hashcash: 1:20:101016:draft-ebalard-mext-pfkey-enhanced-migrate@tools.ietf.org::CkqXoK552+o1JcQL:000007EFw X-Hashcash: 1:20:101016:mext@ietf.org::6fzGJoekJZEuYOH3:0000EaEr X-Hashcash: 1:20:101016:jari.arkko@piuha.net::JKY/I8bWdCW4dmmS:00000000000000000000000000000000000000000Hf3V Date: Sat, 16 Oct 2010 13:59:20 +0200 Message-ID: <87y69ybb6v.fsf@small.ssi.corp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "draft-ebalard-mext-pfkey-enhanced-migrate@tools.ietf.org" , "Laganier, Julien" , "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ebalard-mext-pfkey-enhanced-migrate X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 11:57:45 -0000 Hi, Jari Arkko writes: > I have reviewed this draft. I would like to move it to forward, but > there are a few technical issues and a number of editorial > problems. Please correct the editorial problems and respond on the > technical issues. Also, Julien, would it be possible to get some IPsec > experts to review this as well? > > Technical: > >> Mobile IPv6 may need to make an access to the SPD not only for >> updating an endpoint address but also for deleting/inserting a >> specific SPD entry. When the MN performs Foreign-to-Home movement, >> IPsec SA established between the MN and HA to protect data traffic >> should be deleted, and associated SPD entries should have no effect >> anymore. On the other hand, when the MN performs Home-to-Foreign >> movement, those IPsec SP should be restored. Hence security policy >> entries that are associated with tunnel mode SA may dynamically be >> added/removed (enabled/disabled) in along with MN's movements. As a >> side note for such a scenario, Home Link detection mechanism becomes >> critical security-wise [hld-sec ] > > Its not clear to me why this disabling is required. Can you elaborate? RFC 4877 has: o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. The security policy entries, which were used for protecting tunneled traffic between the mobile node and the home agent, SHOULD be made inactive (for instance, by removing them and installing them back later through an API). ... The trigger for the removal of the SP is the Home Link Detection mechanism, i.e. the reception of a RA advertising the home subnet prefix. Everyone can send such packets and have the MN believe it is at home. For a MN using IPsec for protecting data traffic, the result is that it may start sending its data unprotected on a foreign network. There is more in the draft (associated with the authorized format of dereg BU) but this is the bottom line. Note that after publishing hld-sec draft, I was pointed the following draft: http://tools.ietf.org/html/draft-sheffer-ipsecme-secure-beacon > It seems that since the security policy dictates that communication > with the home agent needs to be secured, I'll note that the > de-registration BU still needs to be protected. MIPv6 Signaling traffic (BU/BA) is indeed *always* protected with IPsec. But if you have time to read the draft, you'll discover that some parts of the specification (3775) and the use of RH2/HAO make it possible to subvert that protection as long as we manage to have the MN generate a protected BU. > And after that, if there is no communication with the home agent, what > problem is solved by removing the SA/SP? Tell me if I misunderstand your question: AFAICT, the removal of the tunnel mode SP/SA protecting data traffic has been specified to prevent the MN to IPsec-tunnel data traffic to the HA in front of it when it is at home and simply have its data packets routed via its HA. To make it simple, I *think* the purpose of this default removal of tunnel SP/SA is to reduce the load on the HA induced by MN which are at home (i.e. a somewhat safer place than foreign networks). > Also, I'm not too happy about including references to major new pieces > of needed mechanisms in other drafts, when those drafts are not in > IETF process already. I can remove the reference if you prefer. It was added at some point as a pointer in order for the reader interested by MN movements and IPsec/IKE to be aware of the fact that Home Link Detection mechanism as defined in base specifications is something heuristic (reception of a RA with the Home Prefix) which is used as a trigger for something important security-wise: removal of SP protecting data traffic. >> o Key manager address information * >> source address * destination >> address o Selector information: >> * source address/port * >> destination address/port * upper layer >> protocol (i.e., Mobility Header) * direction >> (inbound/outbound) > > For the tunnel SAs, there will not be a Mobility Header. You say later > "For tunnel mode, the endpoint addresses refer to the source and > destination IP addresses that appear in the IP header, and those > should be provided by the MIGRAT E message." But above you seem to > imply that the upper layer protocol is always MH. Yes. I will s/i.e./e.g./ >> o Old SA information: * >> old source endpoint address * old >> destination endpoint address * IPsec protocol >> (ESP/AH) * mode (Tunnel/Transport) >> o New SA information: * new >> source endpoint address * new destination >> endpoint address * IPsec protocol (ESP/AH) >> * mode (Tunnel/Transport) > > I do not understand how you identify the SA/SPD entry with this. Rereading it, I agree the picture is not clear enough. Below is a fresh example of the message emitted by the MIPv6 module to the kernel and received by the IKE daemon when changing CoA (I just somewhat anonymized addresses). It is followed by a modified version of the picture. Tell me if you think it provides a better introduction for the reader (as a side note, a detailed version of the message is found in Appendix A of the document). ###[ PF_KEY SADB_X_MIGRATE message ]### version= 2 type= SADB_X_MIGRATE errno= 0 satype= SADB_SATYPE_ESP len= 40 res= 0 seq= 0L pid= 0L ###[ PF_KEY Key Manager Addresses extension ]### len= 8 type= SADB_EXT_X_KMADDRESS res= 0L \local\ |###[ sockaddr_in6 structure - Linux version ]### | sin6_family= AF_INET6 | sin6_port= 0 | sin6_flowinfo= 0L | sin6_addr= 2001:db8:1::221:70ff:febd:effb (New CoA) | sin6_scope_id= 0L \remote\ |###[ sockaddr_in6 structure - Linux version ]### | sin6_family= AF_INET6 | sin6_port= 0 | sin6_flowinfo= 0L | sin6_addr= 2001:db8:2::211:43ff:fe44:e4a0 (HA) | sin6_scope_id= 0L ###[ PF_KEY IPv4/IPv6 source address extension ]### len= 5 type= SADB_EXT_ADDRESS_SRC proto= 0 plen= 0 res= 0 \addr\ |###[ sockaddr_in6 structure - Linux version ]### | sin6_family= AF_INET6 | sin6_port= 0 | sin6_flowinfo= 0L | sin6_addr= :: | sin6_scope_id= 0L ###[ PF_KEY IPv4/IPv6 destination address extension ]### len= 5 type= SADB_EXT_ADDRESS_DST proto= 0 plen= 128 res= 0 \addr\ |###[ sockaddr_in6 structure - Linux version ]### | sin6_family= AF_INET6 | sin6_port= 0 | sin6_flowinfo= 0L | sin6_addr= 2001:db8:2::20d:93ff:fe55:8f79 (HoA) | sin6_scope_id= 0L ###[ PF_KEY POLICY extension ]### len= 20 type= SADB_EXT_X_POLICY poltype= IPsec dir= IN res= 255 id= 0L prio= 0L \reqs\ |###[ IPsec Request (sadb_x_ipsecrequest) ]### | len= 72 | proto= ESP | mode= Tunnel | level= Require | res1= 0 | id= 0L | res2= 0L | \sockaddr1\ | |###[ sockaddr_in6 structure - Linux version ]### | | sin6_family= AF_INET6 | | sin6_port= 0 | | sin6_flowinfo= 0L | | sin6_addr= 2001:db8:2::211:43ff:fe44:e4a0 (HA) | | sin6_scope_id= 0L | \sockaddr2\ | |###[ sockaddr_in6 structure - Linux version ]### | | sin6_family= AF_INET6 | | sin6_port= 0 | | sin6_flowinfo= 0L | | sin6_addr= 2001:db8:1::216:eaff:feec:ae14 (Old CoA) | | sin6_scope_id= 0L |###[ IPsec Request (sadb_x_ipsecrequest) ]### | len= 72 | proto= ESP | mode= Tunnel | level= Require | res1= 0 | id= 0L | res2= 0L | \sockaddr1\ | |###[ sockaddr_in6 structure - Linux version ]### | | sin6_family= AF_INET6 | | sin6_port= 0 | | sin6_flowinfo= 0L | | sin6_addr= 2001:db8:2::211:43ff:fe44:e4a0 (HA) | | sin6_scope_id= 0L | \sockaddr2\ | |###[ sockaddr_in6 structure - Linux version ]### | | sin6_family= AF_INET6 | | sin6_port= 0 | | sin6_flowinfo= 0L | | sin6_addr= 2001:db8:1::221:70ff:febd:effb (New Coa) | | sin6_scope_id= 0L Current version: o Key manager address information \ * source address | For IKE only * destination address / o Selector information: \ * source address/port | * destination address/port | * upper layer protocol (i.e., Mobility Header) | * direction (inbound/outbound) | o Old SA information: | * old source endpoint address | For IKE and * old destination endpoint address | IPsec stack * IPsec protocol (ESP/AH) | * mode (Tunnel/Transport) | o New SA information: | * new source endpoint address | * new destination endpoint address | * IPsec protocol (ESP/AH) | * mode (Tunnel/Transport) / Proposed update: o Key manager address (SADB_EXT_X_KMADDRESS) \ * source address | For IKE only * destination address / o Traffic selectors (SADB_EXT_ADDRESS_{SRC,DST}) \ * source address/port | * destination address/port | * upper layer protocol (i.e., Mobility Header) | * direction (inbound/outbound) | o Policy information (SADB_EXT_X_POLICY) | o Old IPsec request (sadb_x_ipsecrequest): | * old source endpoint address | For IKE and * old destination endpoint address | IPsec stack * IPsec protocol (ESP/AH) | * mode (Tunnel/Transport) | o New IPsec request (sadb_x_ipsecrequest): | * new source endpoint address | * new destination endpoint address | * IPsec protocol (ESP/AH) | * mode (Tunnel/Transport) / >> It should be noted that delivery of PF_KEY MIGRATE messages cannot be >> guaranteed, which is common to other PF_KEY messages. It may be >> possible (even if highly unlikely) that a MIGRATE message be lost. >> In such case, there will be inconsistency between the binding record >> managed by Mobile IPv6 and IPsec database inside the kernel or the >> IKE daemon. Once a PF_KEY MIGRATE message is lost, it would not be >> possible for the receiver to process some subsequent MIGRATE messages >> properly. Reinitialization of the Mobile IPv6 stack and IPsec >> databases may be needed for recovery. >> > > I'm not sure I understand why. If the MIGRATE message is copied back > to all open PF_KEY sockets, presumably the Mobile IPv6 daemon would > also see a copy if the kernel actually received the message. So what > is the problem? It's a corner case inherited from PF_KEY spec. It depends on the size of socket buffers and hence on what userspace does on that aspect. Section 1.4 of RFC 2367 has: PF_KEY message delivery is not guaranteed, especially in cases where kernel or socket buffers are exhausted and messages are dropped. You are right that MIPv6 userland process could monitor that the message is delivered by the kernel but this would not *guarantee* that another PF_KEY process has indeed received it even if this is likely. If you think it does not belong to the spec (i.e. we can expect the reader to be aware of it already), I can remove it. > Editorial: > >> This document is heavily based on a previous draft [MIGRATE ] written >> by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply >> reuses the MIGRATE mechanism defined in the expired document, removes >> a companion extension (SADB_X_EXT_PACKET) based on implementation >> feedback (complexity, limitations, ...) and fills the gap by very >> simple changes to MIGRATE mechanism. This results in a more simple >> and consistent mechanism, which also proved to be easier to >> implement. This document is expected to serve as a continuation of >> [MIGRATE ] work. For that reason, the name of the extension has been >> kept. >> > > This material belongs somewhere else (maybe the introduction or the > acknowledgements section) but not in the abstract. Actually, I think > the paragraph at the end of Section 1 already is sufficient, so you > might be able to remove this text altogether. I will remove the paragraph from the abstract and change the last paragraph of section 1 from: As stated in the abstract, this document is heavily based on the content of a previous draft [MIGRATE]. This expired memo served as the basis for this work both from technical and editorial standpoints. Numerous technical discussions with some of its authors took place while working on this memo and associated implementations. to: This document is heavily based on the content of a previous draft [OLDMIGRATE]. This expired memo served as the basis for this work both from technical and editorial standpoints. Numerous technical discussions with some of its authors took place while working on this memo and associated implementations. >> For the IPsec stack, this allows migrating the endpoint addresses of >> the IPsec SA (and associated SP). > > SP is not defined. will replace it by "Security Policy (SP)" >> This memo proposes such an API based >> on PF_KEY framework both to document the needs and ease >> interoperability between components which may be provided by >> different vendors. >> > > Just say "... based on the PF_KEY framework." The rest repeats too > much of what was already said in the introduction. Ack. >> 5.1.2. Bootstrapping >> >> >> In the bootstrapping stage of Mobile IPv6 > > This is somewhat confusing because bootstrapping has a different > meaning in the existing mobile IPv6 RFCs; I think you mean the initial > registration. Yes. Will use "initial registration". >> With that information, the key manager is able to inflect >> its usual processing where it selects by default the source address >> of the SA for the negotiation (i.e. as local address of the IKE_SA). >> > .. able to change its usual ... ? > >> associated with that SP. The information SHOUD also be used by the > > SHOULD Ack. >> A PF_KEY MIGRATE message should be formed, based on security policy >> configuration and binding record. > > What is a binding record? Do you mean a binding cache entry, or a > binding update list entry? Based on which side (MN or HA/CN) we are considering, either BULe or BCe respectively. I will change that to: and binding record (e.g. Binding Update List entry on the MN, Binding Cache entry on the HA) > Section 6 should probably be an appendix. > > Likewise for Section 7. ok. > I'm not sure I see much value in keeping Section 10 at all. Except for the last point of the list in section 10: o Currently, large portion of the proposed mechanism is implementation dependent due to lack of standard interface to access the SPD (PF_POLICY?). everything is already in the document so I guess we can remove it w/o issues. If you think it may help the reader I will just put somewhere in the document a pointer to the following (obviously non-normative) reference: http://www.kame.net/newsletter/20021210/ http://tools.ietf.org/html/draft-schilcher-mobike-pfkey-extension-01 This gives some good explanation and introduction of what is already in major PF_KEY implementations (Linux, BSD) to deal with SPD. >> o Modifications to IPsec stack: >> * Processing PF_KEY MIGRATE messages: the kernel should be able >> to process PF_KEY MIGRATE messages sent by the Mobile IPv6 >> code. Unless the message is invalid, it should be sent to all >> open PF_KEY sockets. >> > > Something is missing here. I think you meant to say that once it is > processed by the kernel, it shall be copied to all open PF_KEY > sockets. Yes, should is wrong. Will modify last sentence as follows: "Unless the message is invalid, once it is processed by the kernel, it shall be copied to all open PF_KEY sockets." >> == The document seems to lack the recommended RFC 2119 boilerplate, >> even if >> it appears to use RFC 2119 keywords -- however, there's a >> paragraph with >> a matching beginning. Boilerplate error? yep. Will correct that. > (From idnits) > > This seems like an error that you should should fix. > >> >> ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) >> >> ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) >> > > Please check that you are referring to the RFCs that you wanted to > refer to. If there is no specific reason to refer to old ones, please > use the new ones instead. I will remove the reference to RFC 2401 which is due to: be updated. Basically the information should contain necessary elements which characterize traffic selector as specified in the IPsec architecture ([RFC2401], [RFC4301]). With regard to the upper layer protocol, when the Mobile IPv6 stack is not fully aware of For RFC 2409, it is due to the link in the terminology section: In this document, the term IKE implicitly stands for both IKEv1 [RFC2409] and IKEv2 [RFC5996]. IKEv2 terminology is used preferentially when describing actions performed by the key manager but they also apply to the IKEv1 counterparts. For instance, when actions occur on IKE_SA, they also apply to ISAKMP SA for IKEv1, except otherwise specified. The terms "IKE daemon" and "Key Manager (KM)" are used interchangeably in the document. I think it makes sense to keep it that way. Note that idnits seems unaware of the fact that 4306 has been obsoleted by RFC 5996 ;-) Thanks for your time and effort, Jari. Cheers, a+ From maxpassion@gmail.com Tue Oct 19 01:13:16 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A4D3A6A65 for ; Tue, 19 Oct 2010 01:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flKyM97hxeTF for ; Tue, 19 Oct 2010 01:13:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E7DD23A6C21 for ; Tue, 19 Oct 2010 01:13:14 -0700 (PDT) Received: by yxk30 with SMTP id 30so1123925yxk.31 for ; Tue, 19 Oct 2010 01:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TnsGJNVnA/6YI9x2dVdnAPetbrgvouJrO+OD2prume8=; b=gHgCHqMfEHt5PO25Btmzy6SzGcfr7r755QH0J2oCb4wCbGRobRo3Q0dWiCtUdb28p0 hQJEvTVSFQonoI2tqfhoL4bR0pzAMTslOaN/4AM57owA+PlVLGEBl2wm1I9+KXnS4OLE cZHHOFjktss9eJzvYaBL7kTYOWAsyNG1+rN6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RASr98qnKdcYc5HLEjRkDyfxm84eFSnWd7GCH32jMy50VqXI13cZMN2MnOiMnc6GEO D0WWa0QBx4hTuyOv6j4nTFkyixVyXz6bM0VD5lJsoUOKJmOscOkUS9Jyd8pfCMaAyTyF uybv5h6POMYUavg0WFcGUTfFET076nmKi6vQk= MIME-Version: 1.0 Received: by 10.42.76.145 with SMTP id e17mr4251710ick.62.1287476084251; Tue, 19 Oct 2010 01:14:44 -0700 (PDT) Received: by 10.220.10.211 with HTTP; Tue, 19 Oct 2010 01:14:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Oct 2010 16:14:44 +0800 Message-ID: From: liu dapeng To: mext Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] Fwd: DMM problem statement and scenario draft X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 08:13:16 -0000 ---------- Forwarded message ---------- From: liu dapeng Date: Tue, 19 Oct 2010 16:12:30 +0800 Subject: DMM problem statement and scenario draft To: dmm Cc: "charles.perkins" , yokota , MELIA TELEMACO , Wassim Haddad , Anthony Chan , "elena.demaria" , denghui02 , caozhen Hello all, After several weeks and many contributor's hard working, we finished DMM problem statement and scenario draft: http://tools.ietf.org/html/draft-chan-distributed-mobility-ps-00 http://tools.ietf.org/html/draft-yokota-dmm-scenario-00 Besides, we have the following introduction and initial work plan of DMM: ---------------------------------------------------------------------------= -------------------------- Work plan proposal -- Distributed and Dynamic Mobility Management =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the past decade a fair number of mobility protocols have been standardized. Although the protocols differ in terms of functions and associated message format, we can identify a few key common features: =95presence of a centralized mobility anchor providing global reachability and an always-on experience =95extensions to optimize handover performance while users roam across wireless cells =95extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones) The presence of the centralized mobility anchor allows a mobile device to be reachable when it is not connected to its home domain. The anchor, among other tasks, ensures forwarding of packets destined to or sent from the mobile device. As such, most of the deployed architectures today have a small number of centralized anchors managing the traffic of millions of mobile subscribers. To optimize handovers for mobile users, the base protocols have been extended to efficiently handle packet forwarding between the previous and new points of attachment. These extensions are necessary when applications impose stringent requirements in terms of delay. Notions of localization and distribution of local agents have been introduced to reduce signalling overhead. Unfortunately today we witness difficulties in getting such protocols deployed, often leading to sub-optimal choices. Moreover, all the availability of multi-mode devices and the possibility to use several network interfaces simultaneously have motivated the development of more new protocol extensions. Mobile users are, more than ever, consuming Internet content, and impose new requirements on mobile core networks for data traffic delivery. When this traffic demand exceeds available capacity, service providers need to implement new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, the localization of content providers closer to the Mobile/Fixed Internet Service Providers network requires taking into account local Content Delivery Networks (CDNs) while providing mobility services. As long as demand exceeds capactity, both offloading and CDN techniques could benefit from the development of more flat mobile architectures (i.e., fewer levels of routing hierarchy introduced into the data path by the mobility management system). This view is reinforced by the shift in users=92 traffic behaviour, aimed at increasing direct communications among peers in the same geographical area. The development of truly flat mobile architectures would result in anchoring the traffic closer to point of attachment of the user and overcoming the suboptimal routing issues of a centralized mobility scheme. While deploying [1] today=92s mobile networks, service providers face new challenges. More often than not, mobile devices remain attached to the same point of attachment, in which case specific IP mobility management support is not required for applications that launch and complete while connected to the same point of attachment. However, the mobility support has been designed to be always on and to maintain the context for each mobile subscriber as long as they are connected to the network. This can result in a waste of resources and ever-increasing costs for the service provider. Infrequent mobility and intelligence of many applications suggest that mobility can be provided dynamically, thus simplifying the context maintained in the different nodes of the mobile network. The proposed charter will address two complementary aspects of mobility management procedures: the distribution of mobility anchors to achieve a more flat design and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. The former has the goal of positioning mobility anchors (HA, LMA) closer to the user; ideally, these mobility anchors could be collocated with the first hop router. The latter, facilitated by the distribution of mobility anchors, aims at identifying when mobility must be activated and identifying sessions that do not impose mobility management -- thus reducing the amount of state information to be maintained in the various mobility anchors of the mobile network. The key idea is that dynamic mobility management relaxes some constraints while also repositioning mobility anchors; it avoids the establishment of non optimal tunnels between two anchors topologically distant. Considering the above, the working group will: =95Define the problem statement and associated requirements for distributed mobility management. This work aims at defining the problem space and identifies the key functional requirements. =95Produce a gap analysis mapping the above requirements against existing solutions. =95Give best practices for the deployment of existing mobility protocols in a distributed mobility management and describe limitations of each such approach. =95Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures [1] G. Kirby, "Locating the User", Communication International, 1995 ---------------------------------------------------------------------------= ------------------------- Please feel free to comment. Thanks. Best Regards, Dapeng Liu From alper.yegin@yegin.org Wed Oct 20 05:37:28 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2D73A6768 for ; Wed, 20 Oct 2010 05:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.576 X-Spam-Level: X-Spam-Status: No, score=-99.576 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSTw6EYtS9TI for ; Wed, 20 Oct 2010 05:37:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 787423A6931 for ; Wed, 20 Oct 2010 05:37:26 -0700 (PDT) Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LymTv-1Oc9WD2D7X-015hhw; Wed, 20 Oct 2010 08:38:54 -0400 From: "Alper Yegin" To: "'Sri Gundavelli'" , "'marcelo bagnulo braun'" , References: <4CB69A0A.2030503@it.uc3m.es> In-Reply-To: Date: Wed, 20 Oct 2010 15:38:38 +0300 Message-ID: <016e01cb7053$c16b9200$4442b600$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActrtlHA4+AG8j/wzEOGiOYcqCYPZgEnNdWA Content-Language: en-us X-Provags-ID: V02:K0:Ns9HT6QgXZFRYizS+LFJUsdi4fy6TBum9gsTDL/4DGm pKiUj0wedT6c+7HqWQKtPM+7PJhVENA02V8DV7N6r7Tp19zEwK QN091D3pxtEQCWgQUyeJ3fxxGQBL+X5L2t4pPFWjnzn0557Xgw Ud6PH9/vfFl23VS9XlpgIcZVj45uam5rSbC7T2GeIl26Dcxheg C0Tzq2Kyd4QMoRpbIFrTNdLk6JccwUC8CMFQKvmSCY= Cc: 'Jari Arkko' Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 12:37:28 -0000 Sri, > Secondly, for Auth-Opt to be considered an alternative security > mechanism, > since that is some what black listed with that famous IESG note, will > it be > a demotion or a promotion to get that under this Experimental = standard, > from > informational standard with a red dot. :) Good point. When a vendor, operator, or SDO look at the picture, if they don't want = to use IPsec, what would it mean if one alternative is informational (with = some IESG note) and one or more others are experimental? How would the experimental vs informational status play into it? > Just curious, we will surely have excellent interoperability between > vendors. Its better to put few forward looking statements around this > work, > else it will confuse the hell out of every one. I think so too. Alper >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 10/13/10 10:50 PM, "marcelo bagnulo braun" > wrote: >=20 > > > > great, thanks! > > > > El 14/10/10 1:19, Vijay Devarapalli escribi=F3: > >> I can review the document (in a week or two). > >> > >> Vijay > >> > >> On 9/23/10 12:30 PM, Laganier, Julien wrote: > >>> Folks, > >>> > >>> The chairs have received a request from the authors of > >>> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec that > >>> their draft be adopted as one of the WG deliverables for our > >>> "alternative security mechanisms" work item. > >>> > >>> Before we go ahead with this, the chairs would like to solicit at > >>> least three thorough review of the document to ensure that the has > an > >>> adequate understanding of the proposal and its implications. > >>> > >>> Please support the WG process by volunteering as a reviewer. > >>> > >>> --julien& marcelo > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From alper.yegin@yegin.org Wed Oct 20 05:49:32 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB073A682E for ; Wed, 20 Oct 2010 05:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.764 X-Spam-Level: X-Spam-Status: No, score=-100.764 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bPyF0SwGbIK for ; Wed, 20 Oct 2010 05:49:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 2B4FC3A6935 for ; Wed, 20 Oct 2010 05:49:31 -0700 (PDT) Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MN1SC-1P1yYY2CCG-0075us; Wed, 20 Oct 2010 08:51:02 -0400 From: "Alper Yegin" To: "'Sri Gundavelli'" , "'marcelo bagnulo braun'" , References: <4CB69A0A.2030503@it.uc3m.es> In-Reply-To: Date: Wed, 20 Oct 2010 15:50:47 +0300 Message-ID: <016f01cb7055$733d4f40$59b7edc0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActrtlHA4+AG8j/wzEOGiOYcqCYPZgEnNdWAAACLSjA= Content-Language: en-us X-Provags-ID: V02:K0:20DVzb/HBE21V2U6v7mrkmEFryik+wOxCiIQVHE/7b/ 6kd2xa4SpbNBTAC/I22H35G7CW+iSKbwHHsGSDP3HrDgg/LCl7 uUFpMHFN1DAmlg88ZbbcnM7rK7dVN0OJaqK67whMbucSAP46ld MQFn/6dU5xB+V1T/sTfhk1od0yOmNqUo+LdxCQSY3iiWYpbbAp W5jfYlE8tylS++0zqlPWKzbxDJo35fbxPVAfZtlFOQ= Cc: 'Jari Arkko' Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 12:49:32 -0000 RFC 4285 IESG Note This RFC is not a candidate for any level of Internet Standard. RFC 3775 and 3776 define Mobile IPv6 and its security mechanism. This document presents an alternate security mechanism for Mobile IPv6 used in 3GPP2 networks. The security properties of this mechanism have not been reviewed in the IETF. Conducting this review proved difficult because the standards-track security mechanism for Mobile IPv6 is tightly integrated into the protocol; extensions to Mobile IPv6 and the core documents make assumptions about the properties of the security model without explicitly stating what assumptions are being made. There is no documented service model. What is a "service model"? Thus it is difficult to replace the security mechanism and see if the current protocol and future extensions meet appropriate security requirements both under the original and new security mechanisms. If a service model for Mobile IPv6 security is ever formally defined and reviewed, a mechanism similar to this one could be produced and fully reviewed. I'd guess we need to overcome this "service model" barrier even for the other experimental RFCs for them to ever become a standard. From domagoj.premec@gmail.com Wed Oct 20 07:28:48 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C663A69D0 for ; Wed, 20 Oct 2010 07:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibSTExowcOZt for ; Wed, 20 Oct 2010 07:28:46 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D512A3A69E3 for ; Wed, 20 Oct 2010 07:28:46 -0700 (PDT) Received: by pvg4 with SMTP id 4so458077pvg.31 for ; Wed, 20 Oct 2010 07:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=wQNDVsZjPEzgJMWDaBP5Z1Izk7QIbv1lcLnVTpGE8K8=; b=hTaNdxJ3XRWHztiSb/OKtMqHDjo+p+sYn8xn0xX3p7Z3TkTW8R9AECZ+p+Mq5AJU14 qqyroq5MMV1FSbbwJBA9diMwl7s/ju8Ykhty15OTn2mcw2JSmLSaCCXTLVOd+4vCLbdp G4JZOdySgymBpWTEveEL4WRQMd2k2QcVMdpiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=e1akiZ4qEpqfnO0M6hd7k/jxvNrNv856NBdPRlXpgVRbth0mMi8HnlGmkqE7TjGP4B eD9wLKqtPMuhl4U277HWR2FNvyWdAdvI0DxMOp34AeEtzBR4KcEdMQj5k1RuOkeOsHEM 4DAmgYBsv32YoKFJJQLMjBYy1Z6BG1ToN7+4E= MIME-Version: 1.0 Received: by 10.142.203.17 with SMTP id a17mr5854732wfg.361.1287585020181; Wed, 20 Oct 2010 07:30:20 -0700 (PDT) Received: by 10.220.46.232 with HTTP; Wed, 20 Oct 2010 07:30:20 -0700 (PDT) In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6806C340AE@zagh223a.ww300.siemens.net> References: <3C31CDD06342EA4A8137716247B1CD6806C340AE@zagh223a.ww300.siemens.net> Date: Wed, 20 Oct 2010 16:30:20 +0200 Message-ID: From: Domagoj Premec To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 20 Oct 2010 08:02:34 -0700 Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:33:38 -0000 Hi everyone, This is my review of the mip6-altsec draft. I think the draft is in a good shape and I haven't found any issues that would affect the overall concept. The comments I have should serve mainly as means to identify places where some additional explanation is needed to tighten the text up. I find that the way the (DS)MIP6 interacts with the IPsec is complex and difficult to grasp and implement and in this regard this is an interesting draft and I believe it should be progressed further. I have also played around with a MIP6 implementation based on this draft, I was able to get it up and running quickly and it performed without any problems. Here are my comments... > 4.3. Security Association Management > ... > The HA may want the MN to re-establish the SA even if the existing SA > is still valid. The HA can indicate this to the MN using a dedicated > Status Code in a BA (value set to REINIT_SA_WITH_HAC). After responding with REINIT_SA_WITH_HAC, will the HA accept the incoming packets protected with the existing SA? > Sequence numbers: > > A monotonically increasing unsigned sequence number used in all > protected packets exchanged between the MN and the HA in the same > direction. The definition it is not clear if the scope of the sequence number is the SA or the session with the HA. Please clarify that in the case when an existing SA gets replaced with a new one, the sequence number of the new SA is initialized to zero. >4.4. Bootstrapping of Additional Mobile IPv6 Parameters >... > Home Link Prefix: > > Concerns the IPv6 Home link prefix and the associated prefix > length. Should it also cover the IPv4 subnet? > 5.3. Request-Response Message Exchange This section introduces the MHAuth-Init and MHAuth-Done messages. I couldn't find the TV-header indicating the message type, i.e. something like "msg-type : MHAuth-Init". If the protocol does not contain the indication of the message type, then I would suggest talking simply in terms of first/last request/response message and not using the terms like MHAuth-Init/Done. At least for me it was confusing as I kept looking for the definition of the MHAuth-Init/Done messages and couldn't find one. > The first request message - MHAuth-Init - (i.e. the Identifier is 1) > MUST always contain at least the following parameters: > > MN-Identity - See Section 5.5.1. > Authentication Method - See Section 5.5.2. Is mn-rand optional? Sections 5.8 and 5.9 give impression that it is always required? Related to the usage of the MHAuth-Done, the draft gives the impression that the MHAuth-Init request is always responded with the MHAuth-Init response. Can the HAC respond to the MHAuth-Init request with the, for example "MHAuth-Done(status=internal error)"? Does the MN need to acknowledge such MHAuth-Done by replying with another MHAuth-Done? It would be good to clarify this. > 5.5.1. Mobile Node Identifier ... > nai = username > | "@" realm > | username "@" realm What is the use case for the realm without the user name? The definition of the NAI is followed by an ellipsis, a typo? > 5.5.4. Status Code > > The "status-code" MUST only be present in the response message that > ends the request-response message exchange. If it is present only in the final message, what is the usage for the value 100 - Continue? > 5.5.5. Message Authenticator > > The "auth" header contains data used for authentication purposes. It > MUST be the last TV-header in the message and calculated over the > whole message till the start of the "msg-header": Could you provide a pointer to the "msg-header" definition? At least I'm not sure what the msg-header refers to. > 5.5.6. Retry After > > retry-after = "retry-after" ":" rfc1123-date CRLF Maybe a pointer to RFC 2616 or some other document for usage? > 5.5.7. End of Message Content > > end-of-message = 2CRLF Is this needed given that there is a Length field in the message container header? > 5.8. Authentication of the Mobile Node ... > The > MHAuth-Done messages are used to deal with error situations. This may sound like the MHAuth-Done are not used in a success case, maybe a different formulation would help avoid such misunderstanding? > 1) Request/MHAuth-Init: (MN -> HAC) > mn-id, mn-rand, auth-method=psk It looks like the parameters from the MHAuth-Init request are not protected. Why is the auth header omitted here, or would it security-wise make sense to include these parameters in the calculation of the auth signature in message 3? > 2) Response/MHAuth-Init: (MN <- HAC) > [mn-rand, hac-rand, auth-method=psk, [status],] auth Is the auth-method optional? According to section 5.3, it is a mandatory parameter? What is status, is this the status-code TV header from section 5.5.4? According to section 5.5.4, it may appear only in the "response message that ends the request-response message exchange", which is not in line with the usage in this section. When exactly would the HAC echo the mn-rand and what is the use case behind this? > 3) Request/MHAuth-Done: (MN -> HAC) > mn-rand, hac-rand, sa-scope, ciphersuite-list, auth sa-scope and ciphersuite-list may be optional here? If repeating the mn-rand and the hac-rand here makes sense security-wise, it would be good to include a note clarifying that. What about repeating the mn-id? > 4) Response/MHAuth-Done: (MN <- HAC) > [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, > hac-rand, status, auth sa-scope, sa-data and ciphersuite should be mandatory in the successful MHAuth-Done? > The MN verifies the received MAC and the consistency of the > identities, nonces, and ciphersuite parameters transmitted in MHAuth- > Auth. s/MHAuth-Auth/MHAuth-Init? It seems that the last paragraph in section 5.8 is about the MN sending the MHAuth-Done, which is step 3 whereas the preceding paragraph talks about the HAC sending the MHAuth-Done, which is step 4. Please consider revising the text so that it follows the message sequence from fig. 4. >5.9. Extensible Authentication Protocol Methods ... > 2) Response/MHAuth-Init: (MN <- HAC) > [auth-method=eap, eap, [status,]] auth Auth method and eap payload are not optional? Status is supposed to be used only in the final message? > 6) Response/MHAuth-Done: (MN <- HAC) > [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, > status, auth sa-scope, sa-data and ciphersuite need to be mandatory here? > 6. Mobile Node to Home Agent communication >... > The > Mobile IPv6 service MAY use any ephemeral port number as the UDP > source port, and MUST use the Mobile IPv6 service port number > (HALTSEC) as the UDP destination port. Is the response sent to the source port from the request or to the Mobile IPv6 service port number? s/or a, an encrypted/or an encrypted > There is always only one SPI per MN-HA mobility session and the same > SPI is used for all types of protected packets independent of the > direction. When the current SA gets replaced with the new SA, isn't there some period of overlap where both SAs are active and hence there would be two SPIs per the MN-HA mobility session? s/as treated as data packets /are treated as data packets > 6.3. Binding Management Message Formats > For a SPI value of 0 (zero) that indicates an unprotected > packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT > be present. This sentence probably needs to be removed from this section as the binding management messages must be protected. The encoding for the Payload Data field in not explained. Please add some text/pointer as to how this field is encoded. The same applies to the user data packet format section in case of encrypted user traffic. Regards, Domagoj > > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of Laganier, Julien >> Sent: Thursday, September 23, 2010 9:31 PM >> To: mext@ietf.org >> Cc: draft-korhonen-mext-mip6-altsec@tools.ietf.org >> Subject: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec >> >> Folks, >> >> The chairs have received a request from the authors of >> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec >> that their draft be adopted as one of the WG deliverables for >> our "alternative security mechanisms" work item. >> >> Before we go ahead with this, the chairs would like to >> solicit at least three thorough review of the document to >> ensure that the has an adequate understanding of the proposal >> and its implications. >> >> Please support the WG process by volunteering as a reviewer. >> >> --julien & marcelo >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From root@core3.amsl.com Wed Oct 20 10:45:02 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 35C583A68BA; Wed, 20 Oct 2010 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101020174502.35C583A68BA@core3.amsl.com> Date: Wed, 20 Oct 2010 10:45:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Home Agent Reliability Protocol (HARP) Author(s) : R. Wakikawa Filename : draft-ietf-mip6-hareliability-07.txt Pages : 44 Date : 2010-10-20 The home agent can be a single point of failure when Mobile IPv6 and its associated supporting protocols are operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides mechanisms of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mip6-hareliability-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20103121.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Wed Oct 20 14:08:12 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D313A680C for ; Wed, 20 Oct 2010 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXRcDn1nBnK1 for ; Wed, 20 Oct 2010 14:08:10 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 07EB83A67FB for ; Wed, 20 Oct 2010 14:08:09 -0700 (PDT) Received: by eyf6 with SMTP id 6so1038941eyf.31 for ; Wed, 20 Oct 2010 14:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=JgU1mEV0T64QN6eGxCGdpv/MkZDafoJeFFeMILbpFR4=; b=HaXzUjzXEH3B8/+zCQT/LS00XjNR1n/UklaVxBX1bgJLuxEmaf+X1+VrWQOEbEi+tC fKdkFvGUvetMKYCL5GL+OWjsxxthPdZ/RzFrnWENmLI4KwqvizYKv70W3TGyCQgO4NvN EVUzr+KiCxwl0NQgwblmxQQzd2JnaIf4QkREc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ZsS5ehWv0LGbG7QUuH68KjXynFMCu2kFo369sEHZd4fU2WE1qQ79XyU3sH3cRAR3fw xnGc8PV352getOSpv1DB1x9F/kFFpnFrsHLZS4ot7lH/syHhTXftHEQoyb337h2Omqh7 XQnwU04PfHEuVTeegPpU/iKmu2Qu6Iy2rgENc= Received: by 10.103.181.7 with SMTP id i7mr2153516mup.135.1287608983257; Wed, 20 Oct 2010 14:09:43 -0700 (PDT) Received: from host-82-135-119-68.customer.m-online.net (host-82-135-119-68.customer.m-online.net [82.135.119.68]) by mx.google.com with ESMTPS id 10sm437166fax.18.2010.10.20.14.09.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 14:09:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 21 Oct 2010 00:09:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C31CDD06342EA4A8137716247B1CD6806C340AE@zagh223a.ww300.siemens.net> To: Domagoj Premec X-Mailer: Apple Mail (2.1078) Cc: mext@ietf.org Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:08:12 -0000 Hi Damagoj, THanks for the thorough review! See my responses inline: On Oct 20, 2010, at 5:30 PM, Domagoj Premec wrote: > Hi everyone, >=20 > This is my review of the mip6-altsec draft. I think the draft is in a > good shape and I haven't found any issues that would affect the > overall concept. The comments I have should serve mainly as means to > identify places where some additional explanation is needed to tighten > the text up. >=20 > I find that the way the (DS)MIP6 interacts with the IPsec is complex > and difficult to grasp and implement and in this regard this is an > interesting draft and I believe it should be progressed further. I > have also played around with a MIP6 implementation based on this > draft, I was able to get it up and running quickly and it performed > without any problems. >=20 > Here are my comments... >=20 >> 4.3. Security Association Management >> ... >> The HA may want the MN to re-establish the SA even if the existing = SA >> is still valid. The HA can indicate this to the MN using a = dedicated >> Status Code in a BA (value set to REINIT_SA_WITH_HAC). >=20 > After responding with REINIT_SA_WITH_HAC, will the HA accept the > incoming packets protected with the existing SA? The HA would accept incoming packets until the MN contacts the HAC, = re-establishes the SA and as a result the HAC pushes new SA information = to the HA. >=20 >> Sequence numbers: >>=20 >> A monotonically increasing unsigned sequence number used in all >> protected packets exchanged between the MN and the HA in the same >> direction. >=20 > The definition it is not clear if the scope of the sequence number is > the SA or the session with the HA. Please clarify that in the case > when an existing SA gets replaced with a new one, the sequence number > of the new SA is initialized to zero. Right, sequence numbers fate-share the SA. We'll clarify this. >=20 >> 4.4. Bootstrapping of Additional Mobile IPv6 Parameters >> ... >> Home Link Prefix: >>=20 >> Concerns the IPv6 Home link prefix and the associated prefix >> length. >=20 > Should it also cover the IPv4 subnet? Good point. We actually have discussed this to some extent. There was = the issue whether it should be possible for the MN to be e.g. at home on = IPv4 but on foreign link on IPv6 in a case the MN is attached to a = dual-stack link.. >=20 >> 5.3. Request-Response Message Exchange >=20 > This section introduces the MHAuth-Init and MHAuth-Done messages. I > couldn't find the TV-header indicating the message type, i.e. > something like "msg-type : MHAuth-Init". If the protocol does not > contain the indication of the message type, then I would suggest > talking simply in terms of first/last request/response message and not > using the terms like MHAuth-Init/Done. At least for me it was > confusing as I kept looking for the definition of the MHAuth-Init/Done > messages and couldn't find one. Ok. Got the point. We should actually just use request/response as the = messages are the same and only matched using the identifier in the = container. >=20 >> The first request message - MHAuth-Init - (i.e. the Identifier is 1) >> MUST always contain at least the following parameters: >>=20 >> MN-Identity - See Section 5.5.1. >> Authentication Method - See Section 5.5.2. >=20 > Is mn-rand optional? Sections 5.8 and 5.9 give impression that it is > always required? In a case the message exchange fails immediately, the HAC would response = (section 5.8, step 2) with error status code and auth. The message would = not contain mn-rand, hac-rand, auth-method in that case. Note that it seems the current text is not really clear on this, nor = completely inline regarding the use of MNAuth-Done, status code etc. >=20 > Related to the usage of the MHAuth-Done, the draft gives the > impression that the MHAuth-Init request is always responded with the > MHAuth-Init response. Can the HAC respond to the MHAuth-Init request > with the, for example "MHAuth-Done(status=3Dinternal error)"? Does the > MN need to acknowledge such MHAuth-Done by replying with another > MHAuth-Done? It would be good to clarify this. See above. >=20 >> 5.5.1. Mobile Node Identifier > ... >> nai =3D username >> | "@" realm >> | username "@" realm >=20 > What is the use case for the realm without the user name? Like a corporate treats all its employers as the same? You can have a = "group" without individuals using realm only. >=20 > The definition of the NAI is followed by an ellipsis, a typo? Three dots you mean? It is a left over, or actually lazyness from my = side not to point properly to RFC4282 or completing the BNF for NAI. >=20 >> 5.5.4. Status Code >>=20 >> The "status-code" MUST only be present in the response message that >> ends the request-response message exchange. >=20 > If it is present only in the final message, what is the usage for the > value 100 - Continue? Good point. We'll remove it. >=20 >> 5.5.5. Message Authenticator >>=20 >> The "auth" header contains data used for authentication purposes. = It >> MUST be the last TV-header in the message and calculated over the >> whole message till the start of the "msg-header": >=20 > Could you provide a pointer to the "msg-header" definition? At least > I'm not sure what the msg-header refers to. Good catch. The start of msg-header is supposed to mean the start of = auth header. >=20 >> 5.5.6. Retry After >>=20 >> retry-after =3D "retry-after" ":" rfc1123-date CRLF >=20 > Maybe a pointer to RFC 2616 or some other document for usage? Ok. >=20 >> 5.5.7. End of Message Content >>=20 >> end-of-message =3D 2CRLF >=20 > Is this needed given that there is a Length field in the message > container header? It is not needed. >=20 >> 5.8. Authentication of the Mobile Node > ... >> The >> MHAuth-Done messages are used to deal with error situations. >=20 > This may sound like the MHAuth-Done are not used in a success case, > maybe a different formulation would help avoid such misunderstanding? See my comment for Section 3.. The current text is not the best = regarding MNAuth-Done. >=20 >> 1) Request/MHAuth-Init: (MN -> HAC) >> mn-id, mn-rand, auth-method=3Dpsk >=20 > It looks like the parameters from the MHAuth-Init request are not > protected. Why is the auth header omitted here, or would it > security-wise make sense to include these parameters in the > calculation of the auth signature in message 3? Could be.. I'll let the more security biased authors to express their = opinion ;) >=20 >> 2) Response/MHAuth-Init: (MN <- HAC) >> [mn-rand, hac-rand, auth-method=3Dpsk, [status],] auth >=20 > Is the auth-method optional? According to section 5.3, it is a > mandatory parameter? >=20 In a case authentication fails immediately, the response would contain = only status & auth. > What is status, is this the status-code TV header from section 5.5.4? > According to section 5.5.4, it may appear only in the "response > message that ends the request-response message exchange", which is not > in line with the usage in this section. Again, see the comment for Section 3. >=20 > When exactly would the HAC echo the mn-rand and what is the use case > behind this? mn-rand is echoed always after message 2.. in case of PSK. >=20 >> 3) Request/MHAuth-Done: (MN -> HAC) >> mn-rand, hac-rand, sa-scope, ciphersuite-list, auth >=20 > sa-scope and ciphersuite-list may be optional here? If repeating the no. > mn-rand and the hac-rand here makes sense security-wise, it would be > good to include a note clarifying that. What about repeating the > mn-id? Ok. >=20 >> 4) Response/MHAuth-Done: (MN <- HAC) >> [sa-scope, sa-data, ciphersuite, bootstrapping-data,] = mn-rand, >> hac-rand, status, auth >=20 > sa-scope, sa-data and ciphersuite should be mandatory in the > successful MHAuth-Done? Yes. Actually, some parameters shown in the square brackets do not seem = to be in sync with the rest of the text anymore. Meaning those = parameters has to match for naming used otherwhere in the text. >=20 >> The MN verifies the received MAC and the consistency of the >> identities, nonces, and ciphersuite parameters transmitted in = MHAuth- >> Auth. >=20 > s/MHAuth-Auth/MHAuth-Init? Ack. >=20 > It seems that the last paragraph in section 5.8 is about the MN > sending the MHAuth-Done, which is step 3 whereas the preceding > paragraph talks about the HAC sending the MHAuth-Done, which is step > 4. Please consider revising the text so that it follows the message > sequence from fig. 4. Ack. >=20 >> 5.9. Extensible Authentication Protocol Methods > ... >> 2) Response/MHAuth-Init: (MN <- HAC) >> [auth-method=3Deap, eap, [status,]] auth >=20 > Auth method and eap payload are not optional? Status is supposed to be > used only in the final message? See the comment for Section 3. >=20 >> 6) Response/MHAuth-Done: (MN <- HAC) >> [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, >> status, auth >=20 > sa-scope, sa-data and ciphersuite need to be mandatory here? The last response can indicate an error and in that case those are not = needed. >=20 >> 6. Mobile Node to Home Agent communication >> ... >> The >> Mobile IPv6 service MAY use any ephemeral port number as the UDP >> source port, and MUST use the Mobile IPv6 service port number >> (HALTSEC) as the UDP destination port. >=20 > Is the response sent to the source port from the request or to the > Mobile IPv6 service port number? Responses are sent to the port from the request. The service port is = defined only as where the HA listens for UDP packets. >=20 > s/or a, an encrypted/or an encrypted Ack. >=20 >> There is always only one SPI per MN-HA mobility session and the same >> SPI is used for all types of protected packets independent of the >> direction. >=20 > When the current SA gets replaced with the new SA, isn't there some > period of overlap where both SAs are active and hence there would be > two SPIs per the MN-HA mobility session? Hmm.. yes. Good catch. We'll reword the text accordingly. >=20 > s/as treated as data packets /are treated as data packets Ack. >=20 >> 6.3. Binding Management Message Formats >=20 >> For a SPI value of 0 (zero) that indicates an unprotected >> packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT >> be present. >=20 > This sentence probably needs to be removed from this section as the > binding management messages must be protected. Ack. >=20 > The encoding for the Payload Data field in not explained. Please add > some text/pointer as to how this field is encoded. The same applies to > the user data packet format section in case of encrypted user traffic. Ack. Will add another pointer to RFC4304. - Jouni >=20 > Regards, > Domagoj >=20 >=20 >>=20 >>=20 >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >>> Behalf Of Laganier, Julien >>> Sent: Thursday, September 23, 2010 9:31 PM >>> To: mext@ietf.org >>> Cc: draft-korhonen-mext-mip6-altsec@tools.ietf.org >>> Subject: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec >>>=20 >>> Folks, >>>=20 >>> The chairs have received a request from the authors of >>> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec >>> that their draft be adopted as one of the WG deliverables for >>> our "alternative security mechanisms" work item. >>>=20 >>> Before we go ahead with this, the chairs would like to >>> solicit at least three thorough review of the document to >>> ensure that the has an adequate understanding of the proposal >>> and its implications. >>>=20 >>> Please support the WG process by volunteering as a reviewer. >>>=20 >>> --julien & marcelo >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Fri Oct 22 13:19:52 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2B23A6818 for ; Fri, 22 Oct 2010 13:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKe+kctxJ9UB for ; Fri, 22 Oct 2010 13:19:43 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E53D03A68C5 for ; Fri, 22 Oct 2010 13:19:42 -0700 (PDT) Received: by pwi6 with SMTP id 6so115286pwi.31 for ; Fri, 22 Oct 2010 13:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:references:to:message-id :mime-version:x-mailer; bh=iQtPO/RRrkfEIJhM7XDwJz2SahklUJjYAbRHhZ+9Oag=; b=VwH6MmZsBgwQZYJuDgq3bhMKTAGphJyYvaqMVzodab9w2aU7mjuC8G0KMio0IiBc0c EPgl40qIvSuu04Y0XTrnEa7muyc2g4Xg8fB89oBvzHgQOLx8RVuYyFZawsef4W7BbpJ/ 5gYb4v1F96TUk+ukiQKqPCal/8LAZZ7TBKXN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; b=iKZEPtmVlhnnghKgeH/30jY52+Isi6wKmMUsWdiDhqBe101NWDP5CnCWzYHPoUDQOg hEYktgSD+ur4yNIICgjFEeUe5tbgHu3kJpMogP7AhrZqpW+qWBldHid8hh8w5q65eN5I M2L05a9LvCU/mN1minrXW9pENfJB7926npLMk= Received: by 10.142.178.12 with SMTP id a12mr2673566wff.85.1287778881569; Fri, 22 Oct 2010 13:21:21 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id p8sm5055760wff.16.2010.10.22.13.21.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 13:21:19 -0700 (PDT) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2010 13:21:18 -0700 References: <20101020173124.DB6173A68B8@core3.amsl.com> To: IETF WG ML MEXT Message-Id: <0CF297BA-189B-4DA7-AF2A-655605E0A8B4@gmail.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [MEXT] Fwd: New Version Notification for draft-ietf-mip6-hareliability-07 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 20:19:52 -0000 We have submitted the new version.=20 regards, ryuji Begin forwarded message: > From: IETF I-D Submission Tool > Date: 2010/10/20 10:31:21GMT-07:00 > To: ryuji.wakikawa@gmail.com > Subject: New Version Notification for draft-ietf-mip6-hareliability-07=20= >=20 >=20 > A new version of I-D, draft-ietf-mip6-hareliability-07.txt has been = successfully submitted by Ryuji Wakikawa and posted to the IETF = repository. >=20 > Filename: draft-ietf-mip6-hareliability > Revision: 07 > Title: Home Agent Reliability Protocol (HARP) > Creation_date: 2010-10-20 > WG ID: mext > Number_of_pages: 44 >=20 > Abstract: > The home agent can be a single point of failure when Mobile IPv6 and > its associated supporting protocols are operated in a system. It is > critical to provide home agent reliability in the event of a home > agent crashing or becoming unavailable. This would allow another > home agent to take over and continue providing service to the mobile > nodes. This document describes the problem scope briefly and > provides mechanisms of home agent failure detection, home agent state > transfer, and home agent switching for home agent redundancy and > reliability. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From ryuji.wakikawa@gmail.com Fri Oct 22 13:39:03 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D7128C0D8 for ; Fri, 22 Oct 2010 13:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK+1iw0QtIxm for ; Fri, 22 Oct 2010 13:39:00 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id AAF7C3A693E for ; Fri, 22 Oct 2010 13:39:00 -0700 (PDT) Received: by pxi13 with SMTP id 13so197625pxi.31 for ; Fri, 22 Oct 2010 13:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=SaJWSSbKkWZeQyD88XYcPrYqLz/jMfpvksNsQo7XOIw=; b=u+rztFQzizL24E3wMjnHxoecm9iSWU9/sO8Atx7G/SC6TOsq4Dzc9RwtcmFtvN0F8q v6P2rulDc+EstttCSxFZZNZCps0TLql9iypuBR4Pg3wjePqqooRtuqBYwyBg6ZGaI3Yu pL3fnRVrzj96w3UgF0bey3ZNb9U5OwOrwLpa0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AjBeIBrrewkRCAvXyna6DovFDxsvLxQXUo5DOaILouvmb4MnVT6dZCHwFB6le0V72B I2NIqu3I4OlaLHYO+kXUl1vmQakjTrb1gfeXiJaiLnJlJbX2bCiP6gkckOn3U74o95pU uJ0uVRXpcw0uszquj9kSkWQHaXuCkT1zWkfpI= Received: by 10.142.217.21 with SMTP id p21mr2586517wfg.297.1287780039212; Fri, 22 Oct 2010 13:40:39 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id w22sm5082249wfd.19.2010.10.22.13.40.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 13:40:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: Date: Fri, 22 Oct 2010 13:40:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1081) Cc: mext@ietf.org Subject: Re: [MEXT] Fwd: I-D Action:draft-ietf-mip6-hareliability-06.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 20:39:03 -0000 Hi Raj, Thanks for review. Some comments inline. On 2010/08/06, at 13:48, = wrote: >=20 > Hello, >=20 > Below is my review of the MIP6 HA reliability protocol I-D. I am > skeptical about the usefulness of this protocol (please see comments > in the review below). Publishing it as an experimental RFC may allow > implementations and results from those can determine the viability in > real-world deployments. There are several implementations and experimentations for HA = redundancy. IMO, if it is useless, we shouldn't publish it as any RFC. > Comment: In section 2, the I-D says: > "For protecting the Home Agent Switch, the mobile > node should have IPsec Security Associations (SA) with the standby > home agent before any failover. The mobile node may pre-establish > multiple IPsec SAs with all the home agents." >=20 > This is a pretty steep requirement. Not only does the MN have to > establish an IPsec SA with the active HA, it now needs to have an SA > with the standby HA(s) as well. This approach does not seem like a > feasible one for real-world deployments. >=20 > I-D states: "IPsec/IKE states synchronization is out of scope in = this > document." >=20 > Given the lack of synchronization of the IPsec SA and IKEv2 state, how > useful is the protocol if the MN has to re-establish an SA and then > send the BU.=20 IPsec/IKE sync is not the scope of MEXT. This was clear point.=20 Unfortunately, there are no protocol-based state sync for IPsec/IKE at = this moment. Rather, each vender develop own solution.=20 > VHARP seems to be a better way to provide the reliability. However the > I-D states that VHARP is optional. VHARP is an optional, because it requires IPsec/IKE functions (out of = this document). > - d/However, some Virtual Private Network (VPN) products have > proprietary IPsec/IKEv2 state synchronization among multiple boxes. >=20 > The above statement is irrelevant in the context of this I-D. >=20 > - s/This specification provides for a manual home agent management./ > This specification enables manual intervention for home agent > management. >=20 > Comment: >=20 > In the case of HARP, the standby HA which takes over will send a > message to all MNs and the MNs have to perform registration. If the HA > is serving a very large number of MNs, this would be a difficult > operation (flooding, delays, retransmissions). This is warned in the document (section 4.5).=20 If there are a large number of mobile nodes served by the failed home agent, the overhead sending Home Agent Switch messages is high. This overhead cannot be avoided if the active home agent suddenly stop serving mobile node because of unexpected reasons (crash, network trouble, etc). However, if this switch over is operated under the administrative operation (maintenance, etc), the previous active home agent may continue serving the mobile nodes until the switch over is completed. Until the mobile node sends a binding update to the new active home agent, it still sends the packet to the previous home agent. > - In sec 4.4 s/It can carry several state information about /It can = carry > multiple aspects of the state information associated with >=20 > Comment: >=20 > The I-D states: "When a home agent need to send the state of multiple > mobile nodes in a single state synchronization message (SS-REQ or > SS-REP), a Binding Cache Information option is used as a separator. > For each mobile node, a Binding Cache Information option is placed > first, followed by any other options related to the mobile node if > necessary. " >=20 > If an HA serves a million or more MNs (as an example), the approach of > sending state information presented in the I-D is suboptimal. There > needs to be a better way to transfer bulk state. Has this been > considered? This is discussed. However, the optimization is required not for all the = cases. The optimization brings complexity. so there is pros & cons.=20 We need to exchange binding states anyway for a million or more MNs . Using other transport protocol (other than MH) may be beneficial in such = case.=20 > > - In sec 4.5:=20 > "MUST use IPsec ESP to the Home Agent Switch message" > Why? The only thing is that the message needs to be securely > delivered. IPsec is one way of enabling security. But mandating that > this message MUST be secured by IPsec ESP is not required. HAswitch message MUST be protected by ESP. This is clearly defined in = RFC5142. >=20 > - Not clear what this sentence means: "MUST set only that standby home > agent address in the Home Agent Switch message". Rephrase. >=20 > Comment: > In Sec 4.5 the I-D states: > "When the failed home agent recovers from failure and would return to > the active home agent, it MUST re-establish IPsec SA with all the > mobile nodes. All the mobile nodes lost IPsec SA with the home = agent > when the failure is occurred. Otherwise, it cannot be either a > standby or active home agent for the mobile nodes. Therefore, as > soon as the active home agent detects the recovery of the failed = home > agent, it sends a Home Agent Rekey message to all the mobile nodes > served by other home agents in the same redundant home agent set, = and > includes the recovered home agent address in the Home Agent = Addresses > field. > " >=20 > I dont see how this is practical in the scenario where an HA serves > millions of MNs.=20 >=20 > And it goes on to say: > "Alternatively, the mobile node MAY start a new IKE session with the > recovered home agent." >=20 > Reducing the overhead of signaling has been a concern with > MIP6. Imagine initiating IKEv2 signaling for a very large number of > MNs and the associated overhead on various types of access networks. As far as MIP6 stick to IPsec, this extra-signalings cannot be omitted.. >=20 > - In sec 5: s/Non of operations /None of the operations described >=20 > Comment: > In Sec 5.1 the I-D states: > "A mobile node authenticates itself to two or more home agents and > creates IPsec SAs with them during bootstrapping. When the active > home agent fails, another home agent can use the pre-existing SA to > notify the mobile node about the failure by sending a Home Agent > Switch mesage" >=20 > Reliability at the cost of establishing multiple IPsec SAs with > multiple HAs for each MN is just not acceptable in many deployment > environments.=20 The second SA is necessary for sending HA switch messages.=20 > Comment: >=20 > In Sec 7 the I-D states: > " All the messages newly defined in this document SHOULD be > authenticated by IPsec AH and MAY be encrypted by IPsec ESP. " >=20 > Mandating IPsec for securing the signaling between HAs is > unnecessary. The choice of how the messages are secured should be left > to deployments. The only requirement is that the reliability signaling > messages be secured. right. This is also stated in the document. 7. Security Considerations All the messages newly defined in this document SHOULD be secured by IPsec ESP. When a HA-HELLO message is multicast, the multicast extensions to IPsec [RFC-5374] is used. In some operational scenarios, home agents are located in deeply core network and securely managed. If there is a secure transport network between home agents, some of security mechanism can be turned off depending on administrative policy. thanks, ryuji >=20 >=20 >=20 > On 7/14/10 7:56 PM, "ext Ryuji Wakikawa" = wrote: >=20 >> Hi all, >>=20 >> We submitted the newer version of HA reliability document with a lot = of >> editorial updates and small technical update such as IKE resumption >> interaction support. >> Please provide your comments, this document stays as WG doc for 4 = years >> without progress ... >>=20 >> thanks in advance, >>=20 >> ryuji >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Internet-Drafts@ietf.org >>> Date: 2010/07/12 01:30:03GMT-07:00 >>> To: i-d-announce@ietf.org >>> Cc: mext@ietf.org >>> Subject: [MEXT] I-D Action:draft-ietf-mip6-hareliability-06.txt >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Mobility EXTensions for IPv6 = Working Group >>> of the IETF. >>>=20 >>>=20 >>> Title : Home Agent Reliability Protocol (HARP) >>> Author(s) : R. Wakikawa >>> Filename : draft-ietf-mip6-hareliability-06.txt >>> Pages : 43 >>> Date : 2010-07-12 >>>=20 >>> The home agent can be a single point of failure when Mobile IPv6 and >>> its compatible protocols are operated in a system. It is critical = to >>> provide home agent reliability in the event of a home agent crashing >>> or becoming unavailable. This would allow another home agent to = take >>> over and continue providing service to the mobile nodes. This >>> document describes the problem scope briefly and provides mechanisms >>> of home agent failure detection, home agent state transfer, and home >>> agent switching for home agent redundancy and reliability. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-mip6-hareliability-06.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >=20 From julienl@qualcomm.com Tue Oct 26 07:34:30 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DC73A6948 for ; Tue, 26 Oct 2010 07:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhDpW37Qh5dR for ; Tue, 26 Oct 2010 07:34:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 586A33A683F for ; Tue, 26 Oct 2010 07:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1288103774; x=1319639774; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20mext=20|CC:=20marcelo=20bagnulo=20b raun=20|Date:=20Tue,=2026=20Oct=20201 0=2007:36:10=20-0700|Subject:=20DRAFT=20agenda=20-=20Mobi lity=20EXTensions=20for=20IPv6=20WG|Thread-Topic:=20DRAFT =20agenda=20-=20Mobility=20EXTensions=20for=20IPv6=20WG |Thread-Index:=20Act1GyH/D0qn24FyTYOq7P1GtfgjSQ=3D=3D |Message-ID:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=7vHclF6WrioCc150I8A92pxlRWCjJAOoz+m0BU0fTgE=; b=S09y9BCgvMKesmuPzJ2GRvt3jGqgGCKH/2G02holoxt0BuWd4eXchLnP umDVwLgzCdLGzS2lWB1rfa6K7w7lVKaHUou7LNr+73xnCbMfQKyDGEw0Z kCQMg3U5OvifVuHkEF0aE6jNTcbRo5n/FGo5abOvDt1tYWhm5QRZFRVsn 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6147"; a="59370713" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 26 Oct 2010 07:36:13 -0700 X-IronPort-AV: E=Sophos;i="4.58,239,1286175600"; d="scan'208";a="27070581" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 26 Oct 2010 07:36:13 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 26 Oct 2010 07:36:13 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 26 Oct 2010 07:36:12 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 26 Oct 2010 07:36:12 -0700 From: "Laganier, Julien" To: mext Date: Tue, 26 Oct 2010 07:36:10 -0700 Thread-Topic: DRAFT agenda - Mobility EXTensions for IPv6 WG Thread-Index: Act1GyH/D0qn24FyTYOq7P1GtfgjSQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:34:30 -0000 MONDAY, November 8, 2010 0900-1130 Morning Session I Valley Ballroom C INT mext Mobility EXTensions for IPv6 WG - Overlapping IPv4 Address Assignment Support for Dual-stack Mobile IPv6, S= ri Gundavelli http://tools.ietf.org/html/draft-gundavelli-mext-dsmip-ipv4-overlap=20 [10 min] - Security On Demand for Mobile IPv6 and Dual-stack Mobile IPv6, Basavaraj = Patil http://tools.ietf.org/html/draft-bajko-mext-sod [10 min] - Authorizing Mobile IPv6 Binding Update with Cryptographically Generated, = Julien Laganier http://tools.ietf.org/html/draft-laganier-mext-cga [10 min] - 3GPP TFT Reference for Flow Binding, Mohana Jeyatharan http://tools.ietf.org/html/draft-jeyatharan-mext-flow-tftemp-reference [10 min] - Distributed and Dynamic Mobility Management Discussion http://tools.ietf.org/html/draft-chan-distributed-mobility-ps http://tools.ietf.org/html/draft-yokota-dmm-scenario [90 min] --julien & marcelo From Dirk.von-Hugo@telekom.de Thu Oct 28 08:02:44 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FCC3A6882 for ; Thu, 28 Oct 2010 08:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S47pPG1Puxz for ; Thu, 28 Oct 2010 08:02:42 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 776C43A67DA for ; Thu, 28 Oct 2010 08:02:41 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail81.telekom.de with ESMTP; 28 Oct 2010 17:04:29 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Oct 2010 17:04:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Oct 2010 17:04:20 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC802784802C20773@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG Thread-Index: Act1GyH/D0qn24FyTYOq7P1GtfgjSQBlfzyQ References: From: To: , X-OriginalArrivalTime: 28 Oct 2010 15:04:24.0822 (UTC) FILETIME=[68B5B960:01CB76B1] Subject: Re: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:02:44 -0000 Dear chairs, Thanks for that - and what will be the agenda of the 2nd slot? THURSDAY, November 11, 2010 1740-1940 Afternoon Session III Valley Ballroom C INT mext Mobility EXTensions for IPv6 WG=20 Thanks and best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von = Laganier, Julien Gesendet: Dienstag, 26. Oktober 2010 16:36 An: mext Betreff: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG MONDAY, November 8, 2010 0900-1130 Morning Session I Valley Ballroom C INT mext Mobility EXTensions for IPv6 WG - Overlapping IPv4 Address Assignment Support for Dual-stack Mobile = IPv6, Sri Gundavelli http://tools.ietf.org/html/draft-gundavelli-mext-dsmip-ipv4-overlap = [10 min] - Security On Demand for Mobile IPv6 and Dual-stack Mobile IPv6, = Basavaraj Patil http://tools.ietf.org/html/draft-bajko-mext-sod [10 min] - Authorizing Mobile IPv6 Binding Update with Cryptographically = Generated, Julien Laganier http://tools.ietf.org/html/draft-laganier-mext-cga [10 min] - 3GPP TFT Reference for Flow Binding, Mohana Jeyatharan = http://tools.ietf.org/html/draft-jeyatharan-mext-flow-tftemp-reference [10 min] - Distributed and Dynamic Mobility Management Discussion http://tools.ietf.org/html/draft-chan-distributed-mobility-ps http://tools.ietf.org/html/draft-yokota-dmm-scenario [90 min] --julien & marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From julienl@qualcomm.com Thu Oct 28 09:50:33 2010 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583CD3A6855 for ; Thu, 28 Oct 2010 09:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIb6uO6HRTj0 for ; Thu, 28 Oct 2010 09:50:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CDFE83A686A for ; Thu, 28 Oct 2010 09:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1288284743; x=1319820743; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Dirk.von-Hugo@telekom.de"=20,=20"mext@ietf.org"=0D=0A=09|Date:=20 Thu,=2028=20Oct=202010=2009:52:21=20-0700|Subject:=20RE: =20[MEXT]=20DRAFT=20agenda=20-=20Mobility=20EXTensions=20 for=20IPv6=20WG|Thread-Topic:=20[MEXT]=20DRAFT=20agenda =20-=20Mobility=20EXTensions=20for=20IPv6=20WG |Thread-Index:=20Act1GyH/D0qn24FyTYOq7P1GtfgjSQBlfzyQAAGl 4tA=3D|Message-ID:=20|References:=20=0D=0A=20<643B0A1D1A13AB498304E0BBC802784802C207 73@S4DE8PSAAQC.mitte.t-com.de>|In-Reply-To:=20<643B0A1D1A 13AB498304E0BBC802784802C20773@S4DE8PSAAQC.mitte.t-com.de >|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ou27LdLL+1qC/s/2PMLAazDV8aI+pOc65lWdeS+pY6M=; b=GJAIosnCTyifRI2WM1fbdBRjKs7xBxXEuEhoiWPtUg+VfmE4SbcrdEdd YLqHCPYUz4JtrNYJk8Sz+F7oF+PpDdQrDSqoSlCqssvY9p7fOe2KijLjt xJ1pxeuWYpoGBuiGk6Tjtbx+4VxL8i4c+B7T4F4zczVtzsyRNCXLbxMk8 E=; X-IronPort-AV: E=McAfee;i="5400,1158,6150"; a="59595354" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 28 Oct 2010 09:52:23 -0700 X-IronPort-AV: E=Sophos;i="4.58,253,1286175600"; d="scan'208";a="14890422" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 28 Oct 2010 09:52:23 -0700 Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 28 Oct 2010 09:52:22 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 28 Oct 2010 09:52:22 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 28 Oct 2010 09:52:22 -0700 From: "Laganier, Julien" To: "Dirk.von-Hugo@telekom.de" , "mext@ietf.org" Date: Thu, 28 Oct 2010 09:52:21 -0700 Thread-Topic: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG Thread-Index: Act1GyH/D0qn24FyTYOq7P1GtfgjSQBlfzyQAAGl4tA= Message-ID: References: <643B0A1D1A13AB498304E0BBC802784802C20773@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC802784802C20773@S4DE8PSAAQC.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 16:50:33 -0000 Dirk - The DRAFT agenda is still in flux. Right now it seems we will have the disc= ussion on Distributed Mobility Management on Monday morning, and rest of ou= r business on Thursday evening: MONDAY, November 8, 2010 0900-1130 Morning Session I Valley Ballroom C INT mext Mobility EXTensions for IPv6 WG - Administrativia, Chairs [10 min] - Problem statement for distributed and dynamic mobility management http://tools.ietf.org/html/draft-chan-distributed-mobility-ps [30 min] - Use case scenarios for Distributed Mobility Management http://tools.ietf.org/html/draft-yokota-dmm-scenario [30 min] - Discussion on Distributed Mobility Management [80 min] THURSDAY, November 11, 2010 1740-1940 Afternoon Session III Valley Ballroom C INT mext Mobility EXTensions for IPv6 WG=20 - Administrativia & Status Update, Chairs [20 min] - Overlapping IPv4 Address Assignment Support for Dual-stack Mobile IPv6, S= ri Gundavelli http://tools.ietf.org/html/draft-gundavelli-mext-dsmip-ipv4-overlap=20 [20 min] - Security On Demand for Mobile IPv6 and Dual-stack Mobile IPv6, Basavaraj = Patil http://tools.ietf.org/html/draft-bajko-mext-sod [20 min] - Authorizing Mobile IPv6 Binding Update with Cryptographically Generated, = Julien Laganier http://tools.ietf.org/html/draft-laganier-mext-cga [20 min] - 3GPP TFT Reference for Flow Binding, Mohana Jeyatharan http://tools.ietf.org/html/draft-jeyatharan-mext-flow-tftemp-reference [20 min] - NAT64 for Dual Stack Mobile IPv6, Behcet Sarikaya http://tools.ietf.org/id/draft-sarikaya-behave-mext-nat64-dsmip [20 min] --julien > -----Original Message----- > From: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] > Sent: Thursday, October 28, 2010 8:04 AM > To: Laganier, Julien; mext@ietf.org > Subject: AW: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG >=20 > Dear chairs, > Thanks for that - and what will be the agenda of the 2nd slot? >=20 > THURSDAY, November 11, 2010 > 1740-1940 Afternoon Session III > Valley Ballroom C INT mext Mobility EXTensions for > IPv6 WG >=20 >=20 > Thanks and best regards > Dirk >=20 > -----Urspr=FCngliche Nachricht----- > Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag > von Laganier, Julien > Gesendet: Dienstag, 26. Oktober 2010 16:36 > An: mext > Betreff: [MEXT] DRAFT agenda - Mobility EXTensions for IPv6 WG >=20 > MONDAY, November 8, 2010 > 0900-1130 Morning Session I > Valley Ballroom C INT mext Mobility EXTensions for IPv6 WG >=20 > - Overlapping IPv4 Address Assignment Support for Dual-stack Mobile > IPv6, Sri Gundavelli > http://tools.ietf.org/html/draft-gundavelli-mext-dsmip-ipv4- > overlap > [10 min] >=20 > - Security On Demand for Mobile IPv6 and Dual-stack Mobile IPv6, > Basavaraj Patil > http://tools.ietf.org/html/draft-bajko-mext-sod > [10 min] >=20 > - Authorizing Mobile IPv6 Binding Update with Cryptographically > Generated, Julien Laganier > http://tools.ietf.org/html/draft-laganier-mext-cga > [10 min] >=20 > - 3GPP TFT Reference for Flow Binding, Mohana Jeyatharan > http://tools.ietf.org/html/draft-jeyatharan-mext-flow-tftemp- > reference > [10 min] >=20 > - Distributed and Dynamic Mobility Management Discussion > http://tools.ietf.org/html/draft-chan-distributed-mobility-ps > http://tools.ietf.org/html/draft-yokota-dmm-scenario > [90 min] >=20 > --julien & marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext