From root@core3.amsl.com Tue Aug 4 08:30:02 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 14DCB28C419; Tue, 4 Aug 2009 08: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: <20090804153002.14DCB28C419@core3.amsl.com> Date: Tue, 4 Aug 2009 08:30:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-aero-reqs-04.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, 04 Aug 2009 15:30: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 : Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks Author(s) : W. Eddy, et al. Filename : draft-ietf-mext-aero-reqs-04.txt Pages : 31 Date : 2009-08-04 This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-04.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-aero-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-04082330.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Wed Aug 5 05:16:58 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id A91793A6860; Wed, 5 Aug 2009 05:16:58 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090805121658.A91793A6860@core3.amsl.com> Date: Wed, 5 Aug 2009 05:16:58 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] Last Call: draft-ietf-mext-aero-reqs (Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks) to Informational RFC X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 12:16:58 -0000 The IESG has received a request from the Mobility EXTensions for IPv6 WG (mext) to consider the following document: - 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16799&rfc_flag=0 From wwwrun@core3.amsl.com Wed Aug 5 07:01:50 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 40D463A6BF9; Wed, 5 Aug 2009 07:01:49 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090805140150.40D463A6BF9@core3.amsl.com> Date: Wed, 5 Aug 2009 07:01:50 -0700 (PDT) Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Protocol Action: 'Multiple Care-of Addresses Registration' 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: Wed, 05 Aug 2009 14:01:50 -0000 The IESG has approved the following document: - 'Multiple Care-of Addresses Registration ' 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: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-14.txt Technical Summary According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. Working Group Summary This is a product of the former MONAMI6 WG, now part of MEXT WG. Document Quality There are 3 implementations of the protocol: An implementation for MIPL (LINUX), more information: http://www.nautilus6.org/implementation/index.php http://software.nautilus6.org/MCoA/ One implementation for BSD called SHISA which is part of WIDE and is being maintained. Another implementation KDDI R&D. Interoperability between KDDI and SHISA in 2005. http://www.ietf.org/proceedings/05nov/slides/monami6-8.pdf This feature is a must for the automotive industry standardization effort made at ISO. There were many reviewers of the document, but especial in depth reviews were provided by George Tsirtsis, Chan-Wah Ng and Benjamin Lim. No MIB review nor media type reviews were needed. Personnel The Document Shepherd is Marcelo Bagnulo, and the AD is Jari Arkko. From julienl@qualcomm.com Wed Aug 5 08:19:58 2009 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 19A7528C0F2 for ; Wed, 5 Aug 2009 08:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.72 X-Spam-Level: X-Spam-Status: No, score=-105.72 tagged_above=-999 required=5 tests=[AWL=0.879, 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 scCG8tijRU9Y for ; Wed, 5 Aug 2009 08:19:57 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2393928C5A6 for ; Wed, 5 Aug 2009 08:19:57 -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=1249485600; x=1281021600; 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: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|CC:=20"marcelo@i t.uc3m.es"=20|Date:=20Wed,=205=20Aug =202009=2008:19:55=20-0700|Subject:=20[WGLC]=20RFC=203775 =20bis=20/=20draft-ietf-mext-rfc3775bis|Thread-Topic:=20[ WGLC]=20RFC=203775=20bis=20/=20draft-ietf-mext-rfc3775bis |Thread-Index:=20AcoV4C/MITZ832VfQMeSZMhEKAB5+Q=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|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5698"=3B=20a=3D"21696817"; bh=ZSWMr9mtFqQg0uoSTgpj+zAjOubQsNm27DoWQBO+Dv8=; b=DZR97mbZ9lKuS3LNwFZYovYY1NQhVGAm24oWhfR8THxtfPwlypZjE47e 5NAMFuAT4aje5kqZE0qA0UtAL4eOm0vedRq8XQeCrKkZL2/UfN9hmpdjD Iw8vLyoS3URYBefgMmb9PEpqT2coxGWgW+JMlxHfdCaBd4aHGJn7RI4NN o=; X-IronPort-AV: E=McAfee;i="5300,2777,5698"; a="21696817" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Aug 2009 08:19:59 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75FJx7i017059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2009 08:19:59 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n75FJuYJ013674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Aug 2009 08:19:59 -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.1.358.0; Wed, 5 Aug 2009 08:19:56 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 5 Aug 2009 08:19:56 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Wed, 5 Aug 2009 08:19:55 -0700 Thread-Topic: [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis Thread-Index: AcoV4C/MITZ832VfQMeSZMhEKAB5+Q== 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] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis 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, 05 Aug 2009 15:19:58 -0000 Folks, As discussed during the MEXT session in IETF-75 we're issuing a two weeks W= GLC on RFC 3775 bis that will follow the two rules below: - this WGLC is NOT intended for re-opening discussions on issues that were = resolved during the revision process neither for bringing up new issues.=20 - this WGLC is intended to be sanity check to see whether the various chang= es we agreed to made fit together. Editorial corrections are also welcome. Please review the specification and post a message to the mailing list if y= ou think the document is ready to be forwarded to IESG before 2009-08-15 6:= 00PM PST. Thank you for your support. --julien & Marcelo, MEXT chairs From behcetsarikaya@yahoo.com Thu Aug 6 08:56:22 2009 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 BC7883A6AA3 for ; Thu, 6 Aug 2009 08:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 5YBFa4FtMW3K for ; Thu, 6 Aug 2009 08:56:22 -0700 (PDT) Received: from web111408.mail.gq1.yahoo.com (web111408.mail.gq1.yahoo.com [67.195.15.174]) by core3.amsl.com (Postfix) with SMTP id 1A19C3A69C7 for ; Thu, 6 Aug 2009 08:56:21 -0700 (PDT) Received: (qmail 56578 invoked by uid 60001); 6 Aug 2009 15:56:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1249574183; bh=mVIXs4ObRj5/iau0/XRVmysjqZv3/T9HRFVPP45kLRE=; 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=tkmPEbca8IrQpMs4kQigbTsNGigIS6Qt1BwdIWud5ON1crcvl8QnK5ueEo7n4/mYu+KFf0Is97dtK2kE8NV4vKd44yFdmW5qVmZdzm3bz4ZA5Q9/B6TP8nst+03ZQZ1/7gBp1vj5FvhS9juP3Ft+SC31uYc/qlMeLd2ysT0O4S4= 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=NuSf0Lkhy8v7ho2jJ9z+nEnkYMw0pzUfB0KmgSDT8hIz4glV+HCiGtXqnxSHFnPj6HV+gDiUhEhCt1gWVHJqyxZGSdB504JZ2LNdrjgty9EUf97HI2LJm5Y76Ak6YlSD3oidZLBI5YS6b7tjmjNtmSK+3Eg/nZAtzSMiuf1Lkio=; Message-ID: <233607.56024.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: at1s7bwVM1lL3jEBOapwZXmVQk6.WNpSFDoCao3xnrtorr8pObb53SKGCuwNjxKRJAUVEPMZIuMYsiJyG7K90VVTpIbsx_Fg0k1jatIrGPVF3NVo.vJsK_7PAZtRQEnDmzjfPRMeyMWTeCHven27NyuH0kdMYiCwoDgyw1AZ9FhonpF0AvR6EYl3SjHpyE54Z2xBw_NG9jdwJOVziMavb_t3gUBY3S5KXAoBiRe99WD0elJL3sofMY4kUhEaPgc.gP3fdNNGMeflAK1wAkUfuLMCy1xGvFLtTCeUGpGhv89umMjIDVN0_dutbLY85Yhl_ZiPeoWikOtUdmdkGoIMiOt8Cl6GzTzOk7Lp Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Thu, 06 Aug 2009 08:56:23 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: <20090730074501.4115628C142@core3.amsl.com> Date: Thu, 6 Aug 2009 08:56:23 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: <20090730074501.4115628C142@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binary-ts-00.txt 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: Thu, 06 Aug 2009 15:56:22 -0000 Hi George,=0A=0A=0A=0A----- Original Message ----=0A> From: "Internet-Draft= s@ietf.org" =0A> To: i-d-announce@ietf.org=0A> Cc= : mext@ietf.org=0A> Sent: Thursday, July 30, 2009 2:45:01 AM=0A> Subject: [= MEXT] I-D Action:draft-ietf-mext-binary-ts-00.txt=0A> =0A> A New Internet-D= raft is available from the on-line Internet-Drafts directories.=0A> This dr= aft is a work item of the Mobility EXTensions for IPv6 Working Group of =0A= > the IETF.=0A> =0A> =0A> =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Binary Traff= ic Selectors for FB=0A=0AWhat is FB?=0A=0AIs it an agreed upon acronym so t= hat you can use it in a title?=0A=0AI have a feeling that it is not, so I s= uggest using its expanded form or something else.=0A=0ARegards,=0A=0ABehcet= =0A=0A=0A From julienl@qualcomm.com Thu Aug 6 09:32:20 2009 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 A29713A6B15 for ; Thu, 6 Aug 2009 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.779 X-Spam-Level: X-Spam-Status: No, score=-105.779 tagged_above=-999 required=5 tests=[AWL=0.820, 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 vAvcYd12Ve3V for ; Thu, 6 Aug 2009 09:32:19 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A3FA53A6A82 for ; Thu, 6 Aug 2009 09:32:19 -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=1249576343; x=1281112343; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Behcet=20Sarikaya=20,=0D=0A=20 =20=20=20=20=20=20=20"Tsirtsis,=20George"=0D=0A=09|CC:=20"mext@ietf.org"=20 |Date:=20Thu,=206=20Aug=202009=2009:32:17=20-0700 |Subject:=20RE:=20[MEXT]=20I-D=20Action:draft-ietf-mext-b inary-ts-00.txt|Thread-Topic:=20[MEXT]=20I-D=20Action:dra ft-ietf-mext-binary-ts-00.txt|Thread-Index:=20AcoWrnjyt4X sjQ7eS9mC0S/15WwHEwABLA6g|Message-ID:=20 |References:=20<20090730074501.4115628C142@core3.amsl.com >=0D=0A=20<233607.56024.qm@web111408.mail.gq1.yahoo.com> |In-Reply-To:=20<233607.56024.qm@web111408.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"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5699"=3B=20a=3D"21754536"; bh=bl+OqTrxR4jh2+PzUQMXZuEExEtzC2VA+KtnD52W2Zo=; b=gF4cZkIeooVYgWlvXF5dOuMcO5dPJp5UPBCiEO/8m2QL5N0jaaLJTdHc bYnGO4wdB7HHwd8waJdJqjawor3lq7IYCkHqFpvxjjU9z5+UzJ7+UbMKR x17JBuuzZNMOKA5m5fz9fNo2Zxozd0nHeHsFHnAYX5b/Szai++eicFV0M g=; X-IronPort-AV: E=McAfee;i="5300,2777,5699"; a="21754536" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Aug 2009 09:32:22 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n76GWMIv019437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Aug 2009 09:32:22 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n76GWCkJ006598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Aug 2009 09:32:22 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 6 Aug 2009 09:32:19 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Thu, 6 Aug 2009 09:32:18 -0700 From: "Laganier, Julien" To: Behcet Sarikaya , "Tsirtsis, George" Date: Thu, 6 Aug 2009 09:32:17 -0700 Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-binary-ts-00.txt Thread-Index: AcoWrnjyt4XsjQ7eS9mC0S/15WwHEwABLA6g Message-ID: References: <20090730074501.4115628C142@core3.amsl.com> <233607.56024.qm@web111408.mail.gq1.yahoo.com> In-Reply-To: <233607.56024.qm@web111408.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binary-ts-00.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, 06 Aug 2009 16:32:20 -0000 > From: Behcet Sarikaya >=20 > Hi George, >=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. > > > > > > =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Binary Traffic Selectors for FB >=20 > What is FB? Facebook? Flow binding? :) --julien From tsirtsis@googlemail.com Thu Aug 6 09:38:20 2009 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 200C33A6E1A for ; Thu, 6 Aug 2009 09:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 f6dYC7K66zne for ; Thu, 6 Aug 2009 09:38:19 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id EBA483A6A82 for ; Thu, 6 Aug 2009 09:38:18 -0700 (PDT) Received: by bwz25 with SMTP id 25so1008971bwz.11 for ; Thu, 06 Aug 2009 09:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TE1pVxP0IXtT6X0oawWm8HDMoy6h7Ep5wrEgHrkTnM8=; b=Vsr2Ai8DJInL+PFsWTBSLBs+UZnK9HOu7aGqDcPNHXMmbNsqOv+HUL8pWqcVb42t0L GGdKypcumjrySvHJcbeqIAlgrv+D9pZ+BLh57oqrHzY24bIRjYe5VAJ0cGhrore6bP+F sONzZWHvpPXuY/Ak/BQ+GucFPj2YtX8NJn4xI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZIgv/xgziRJNSExdlXPvLMIVmvk4XicD9OZivpHoKoR750RtygIGGoKMLwplTFNPPl 0hWISy+B87LRk06UX71s1KTae9XAn2EDD7/g4HDqLxQ7+24M3AE4l5pkPjeExLcD0+HP 9ilD0j8+kCR0iFg9PJE220TdKY/ib2bGrGO1A= MIME-Version: 1.0 Received: by 10.239.179.198 with SMTP id e6mr9558hbg.98.1249576696885; Thu, 06 Aug 2009 09:38:16 -0700 (PDT) In-Reply-To: References: <20090730074501.4115628C142@core3.amsl.com> <233607.56024.qm@web111408.mail.gq1.yahoo.com> Date: Thu, 6 Aug 2009 12:38:16 -0400 Message-ID: From: George Tsirtsis To: "Laganier, Julien" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Tsirtsis, George" , "mext@ietf.org" Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binary-ts-00.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, 06 Aug 2009 16:38:20 -0000 RFC5514 already defines "IPv6 over Social Networks", and running code exists for Facebook (http://apps.facebook.com/ipoverfb/). This draft simply defines its Traffic Selectors. George On Thu, Aug 6, 2009 at 12:32 PM, Laganier, Julien wro= te: >> From: Behcet Sarikaya >> >> Hi George, >> >> > 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. >> > >> > >> > =C2=A0=C2=A0=C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Binary Tr= affic Selectors for FB >> >> What is FB? > > Facebook? > > Flow binding? > > :) > > --julien > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From behcetsarikaya@yahoo.com Thu Aug 6 12:00:12 2009 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 D6EBE28C183 for ; Thu, 6 Aug 2009 12:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 3u9j4vM19CJP for ; Thu, 6 Aug 2009 12:00:10 -0700 (PDT) Received: from n6.bullet.re3.yahoo.com (n6.bullet.re3.yahoo.com [68.142.237.91]) by core3.amsl.com (Postfix) with SMTP id B63423A6942 for ; Thu, 6 Aug 2009 11:59:15 -0700 (PDT) Received: from [68.142.230.28] by n6.bullet.re3.yahoo.com with NNFMP; 06 Aug 2009 18:59:16 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 06 Aug 2009 19:13:26 -0000 Received: from [67.195.9.98] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 06 Aug 2009 18:59:16 -0000 Received: from [127.0.0.1] by omp102.mail.gq1.yahoo.com with NNFMP; 06 Aug 2009 18:59:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 194461.18783.bm@omp102.mail.gq1.yahoo.com Received: (qmail 43277 invoked by uid 60001); 6 Aug 2009 18:59:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1249585155; bh=+nU8FyJdrNqCAC4JExXYpQxykCEi6aDNSbJQ05LifiE=; 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=snGkYYV14Py62+dKbjmskc17/ZPy8PdIjvH5iFqMV1tpV97tKv9F/EyoQ3D/u71jeVt6btJv1kOaFmET0DybAhUYcpwv2cO/cf1lUp2LS7qCb0VNveIgA90RwXAWmhp1g4WRMDs22BnRwsINL/eJH1yAwcCHuGtlK4HnrMjkDOg= 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=LsBUolD//fNv5/5HRmkMpomPiPZrVK9FVD2lvc2G9BrjH/KZKhKW6nmVSx8unU6unwarmpOaU2ZMekNSqiuf4qtiqJtrQIiQ///ZzEggLRD5AgExOko3FfXhyuQlBAAdROjWsauTPqs9mmTWCpQaeB5ug9f9AkqimQypA7w2xAg=; Message-ID: <922400.38488.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: 8B1CP5kVM1n_7lTQf.RvoWpdZUPQlaaLzNmHJHcV_cdwem3wqgAQEs4.W_Av05QGW8tircWXMNNram3grbQZf4j5WIE8C8i_PH.lYYL6d5meTBGESTl1ZL521yBYpzQHEfZZjK3IKZFxm7eGLlx3haaNoEFV7TskU6YtgjL.70vnuU2868XDi6rfIMtA.Znf43ZIt1nuNX5aYaFkp.0k7Nqy1YIcB7v1RkOSA4YODpdCw.bGSg53nrx7giJplv9bHGhP9WukHoDU_Mt8QIi48CSquheHRgH0adhpSBXIaPZq_l73R0XfmP9Rg.hSly9vGa412WR396gpoBUXNw9_tys- Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Thu, 06 Aug 2009 11:59:15 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <20090730074501.4115628C142@core3.amsl.com> <233607.56024.qm@web111408.mail.gq1.yahoo.com> Date: Thu, 6 Aug 2009 11:59:15 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis , "Laganier, Julien" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binary-ts-00.txt 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: Thu, 06 Aug 2009 19:00:12 -0000 Facebook's acronym is f not fb :).=0A=0A--behcet=0A=0A=0A=0A----- Original = Message ----=0A> From: George Tsirtsis =0A> To: "L= aganier, Julien" =0A> Cc: Behcet Sarikaya ; "Tsirtsis, George" ; "mext@ietf.org" =0A> Sent: Thursday, August 6, 2009 11:38:16 AM=0A> Subject: Re: = [MEXT] I-D Action:draft-ietf-mext-binary-ts-00.txt=0A> =0A> RFC5514 already= defines "IPv6 over Social Networks", and running code=0A> exists for Faceb= ook (http://apps.facebook.com/ipoverfb/).=0A> This draft simply defines its= Traffic Selectors.=0A> =0A> George=0A> =0A> On Thu, Aug 6, 2009 at 12:32 P= M, Laganier, Julien wrote:=0A> >> From: Behcet Sarikaya=0A> >>=0A> >> Hi Ge= orge,=0A> >>=0A> >> > A New Internet-Draft is available from the on-line In= ternet-Drafts=0A> >> > directories.=0A> >> > This draft is a work item of t= he Mobility EXTensions for IPv6 Working=0A> >> > Group of the IETF.=0A> >> = >=0A> >> >=0A> >> > =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Binary Traffic Sel= ectors for FB=0A> >>=0A> >> What is FB?=0A> >=0A> > Facebook?=0A> >=0A> > F= low binding?=0A> >=0A> > :)=0A> >=0A> > --julien=0A> > ____________________= ___________________________=0A> > MEXT mailing list=0A> > MEXT@ietf.org=0A>= > https://www.ietf.org/mailman/listinfo/mext=0A> >=0A=0A=0A=0A From w52006@huawei.com Thu Aug 6 18:55:42 2009 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 4E3E53A69A2 for ; Thu, 6 Aug 2009 18:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.055 X-Spam-Level: X-Spam-Status: No, score=0.055 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, MANGLED_SIDE=2.3, RCVD_IN_PBL=0.905] 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 lz0qghCgEkzY for ; Thu, 6 Aug 2009 18:55:41 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 70DA63A6973 for ; Thu, 6 Aug 2009 18:55:41 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNZ00LOFHAAAA@szxga03-in.huawei.com> for mext@ietf.org; Fri, 07 Aug 2009 09:54:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNZ007ZXHAAMG@szxga03-in.huawei.com> for mext@ietf.org; Fri, 07 Aug 2009 09:54:10 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNZ005B7HA8VZ@szxml04-in.huawei.com> for mext@ietf.org; Fri, 07 Aug 2009 09:54:10 +0800 (CST) Date: Fri, 07 Aug 2009 09:54:08 +0800 From: Yungui Wang To: 'George Tsirtsis' Message-id: <009001ca1701$f3f64690$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnXJcXbG7LY0xerTje1j/btjd0iGwA/92TgD7ZrgzA= Cc: mext@ietf.org Subject: [MEXT] FW: Comments to draft-ietf-mext-binary-ts-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 01:55:42 -0000 Hello I had sent below comment at before. Re-forwarding it here. Welcome your clarification. Thanks. 1, Could the IPv4/IPv6 binary traffic selector sub-options be encoded as the TLV/TV (type, length, value) format? Consideration: TLV/TV format can save size of message. case 1, It may be not necessary to describe the traffic which includes all the parameters in the sub-option. e.g. the traffic is described as "UDP 21" case 2, On the other hand, one parameter may appear multiple times in the sub-option to describe the traffic. e.g. the traffic includes two flow which may be presented as TCP port 5000 and 5002. 2, Could the Ethernet service flow description sub-option be also introduced in this document? Consideration: The Ethernet service sub-option is senseful when Ethernet service is supported by MIP (referring to http://www.ietf.org/internet-drafts/draft-wu-mip4-ether-02.txt ). The format of the Ethernet serice sub-option can be: - Ethernet serice sub-option (TLV/TV format) 0x01 48bit,source MAC address 0x02 48bit,destination MAC address 0x03 16bit,ethernet type 0x04 16bit,vlan tag - Ethernet serice sub-option (proto header format) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|D|E|V| Reservered | (S) Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (S) Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (D)Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(D)Destination MAC Address | (E) Ethernet Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (V) VLAN tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B.R. Yungui From tsirtsis@googlemail.com Fri Aug 7 01:46:16 2009 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 067853A6E9A for ; Fri, 7 Aug 2009 01:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_SIDE=2.3] 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 OEhK9FdrZsHx for ; Fri, 7 Aug 2009 01:46:15 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id A6D243A6E88 for ; Fri, 7 Aug 2009 01:46:14 -0700 (PDT) Received: by fxm26 with SMTP id 26so1244512fxm.42 for ; Fri, 07 Aug 2009 01:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xZ1YX+cMDBr1AJ3aY/fluo1mONQrC6C0vLfTTnJjdP4=; b=PC2Yf2hLik/ZZwNgt5PWYOU3Vn/XVHzOAdpqiHmXevaGXfdpNlwCr3nMvQLzDmIfQV oMQaE53kx6zaa8uN8ONw0ID+a0IP7eo1lxzQQYbpn9tvMjUq3QuXjqowzcqsR22E9PpE mP+BWbHQ1UF20YHW09dNa0vOKDP+jX5VZYxEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WAqx0XdI/G4FGcO2eZeUViCx4SvezoV9iJ6tcCh6fce4+EfQ7jP9B+fukA9vaLeP3y NVJmm1uX25Vjnk5sugJAiBrr3HOZ6xSli9QmBHehCdl1wTaHNZwPwt5e0nq/qJCKuno3 ISs95KbCeuNUPC9GFpRi7BqmT8boIEWD901Ns= MIME-Version: 1.0 Received: by 10.239.179.198 with SMTP id e6mr106257hbg.98.1249634774324; Fri, 07 Aug 2009 01:46:14 -0700 (PDT) In-Reply-To: <009001ca1701$f3f64690$110ca40a@china.huawei.com> References: <009001ca1701$f3f64690$110ca40a@china.huawei.com> Date: Fri, 7 Aug 2009 04:46:14 -0400 Message-ID: From: George Tsirtsis To: w52006@huawei.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] FW: Comments to draft-ietf-mext-binary-ts-00.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, 07 Aug 2009 08:46:16 -0000 On Thu, Aug 6, 2009 at 9:54 PM, Yungui Wang wrote: > Hello > > I had sent below comment at before. Re-forwarding it here. Welcome > your clarification. Thanks. > > 1, Could the IPv4/IPv6 binary traffic selector sub-options be > encoded as the TLV/TV (type, length, value) format? > Consideration: TLV/TV format can save size of message. > case 1, It may be not necessary to describe the traffic which > includes all the parameters in the sub-option. e.g. the traffic is > described as "UDP 21" > case 2, On the other hand, one parameter may appear multiple times > in the sub-option to describe the traffic. e.g. the traffic > includes two flow which may be presented as TCP port 5000 and > 5002. > GT> I am not sure I understand. The existing format would result to (using IPv4 TS for the example): - case 1: in a 2+5byte suboption since only B flag (Protocol=3DUDP), and I flag (Dst port low=3D21) would be set - case 2 in 2+7byte suboption since B flag (Protocol=3DUDP), I flag (Dst portlow=3D5001), and K flag (Dst portlow=3D5001) would be set. How does the TLV/TV format allow for more efficient packing? > 2, =C2=A0Could the Ethernet service flow description sub-option be also > introduced in this document? > Consideration: > The Ethernet service sub-option is senseful when Ethernet service > is supported by MIP (referring to > http://www.ietf.org/internet-drafts/draft-wu-mip4-ether-02.txt ). > > The format of the Ethernet serice sub-option can be: > > - Ethernet serice sub-option (TLV/TV format) > 0x01 =C2=A0 48bit,source MAC address > 0x02 =C2=A0 48bit,destination MAC address > 0x03 =C2=A0 16bit,ethernet type > 0x04 =C2=A0 16bit,vlan tag > > - Ethernet serice sub-option (proto header format) > > =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 > =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |S|D|E|V| =C2=A0 =C2=A0 =C2=A0 Reservered =C2=A0 =C2=A0 =C2=A0| =C2=A0 (S= ) Source MAC Address =C2=A0 =C2=A0 =C2=A0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(S= ) Source MAC Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (D)Destination = MAC Address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |(D)Destination MAC Address =C2=A0 =C2=A0 | =C2=A0 (E) Ethernet Type =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | =C2=A0 =C2=A0 =C2=A0 =C2=A0(V) VLAN tag =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > B.R. > Yungui > GT> Given that draft-wu-mip4 is not a WG draft yet I do not think it makes sense to start adding TSs for this already in a WG doc. > > From w52006@huawei.com Sun Aug 9 17:40:15 2009 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 7BC5D3A6864 for ; Sun, 9 Aug 2009 17:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, MANGLED_SIDE=2.3] 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 WxX7ZqEbFb-5 for ; Sun, 9 Aug 2009 17:40:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8B9793A6861 for ; Sun, 9 Aug 2009 17:40:14 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO400MNCXV42C@szxga04-in.huawei.com> for mext@ietf.org; Mon, 10 Aug 2009 08:40:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO400MQJXV4NJ@szxga04-in.huawei.com> for mext@ietf.org; Mon, 10 Aug 2009 08:40:16 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO400IA8XV3G7@szxml04-in.huawei.com> for mext@ietf.org; Mon, 10 Aug 2009 08:40:16 +0800 (CST) Date: Mon, 10 Aug 2009 08:40:15 +0800 From: Yungui Wang In-reply-to: To: 'George Tsirtsis' Message-id: <00de01ca1953$213a9db0$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoXPNfUMNjdU55WSYGwbj9Vckh82gABIQwA Cc: mext@ietf.org Subject: Re: [MEXT] FW: Comments to draft-ietf-mext-binary-ts-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 00:40:15 -0000 Hello Got it. Thanks. However, in case 2, I mean that there needs multiple TS(s) for the non-continuous ports based traffic flows. In addition, it seems that the destination address is not required to be defined in the TS? Isn't the MN's HoA? The HA always knows it. B.R. Yungui > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com] > Sent: Friday, August 07, 2009 4:46 PM > To: w52006@huawei.com > Cc: mext@ietf.org > Subject: Re: FW: [MEXT] Comments to draft-ietf-mext-binary-ts-00.txt > > On Thu, Aug 6, 2009 at 9:54 PM, Yungui Wang wrote: > > Hello > > > > I had sent below comment at before. Re-forwarding it here. Welcome > > your clarification. Thanks. > > > > 1, Could the IPv4/IPv6 binary traffic selector sub-options > be encoded > > as the TLV/TV (type, length, value) format? > > Consideration: TLV/TV format can save size of message. > > case 1, It may be not necessary to describe the traffic > which includes > > all the parameters in the sub-option. e.g. the traffic is > described as > > "UDP 21" > > case 2, On the other hand, one parameter may appear > multiple times in > > the sub-option to describe the traffic. e.g. the traffic > includes two > > flow which may be presented as TCP port 5000 and 5002. > > > > GT> I am not sure I understand. The existing format would result to > (using IPv4 TS for the example): > - case 1: in a 2+5byte suboption since only B flag > (Protocol=UDP), and I flag (Dst port low=21) would be set > - case 2 in 2+7byte suboption since B flag (Protocol=UDP), > I flag (Dst portlow=5001), and K flag (Dst portlow=5001) would be set. > How does the TLV/TV format allow for more efficient packing? > > > 2, ?Could the Ethernet service flow description sub-option be also > > introduced in this document? > > Consideration: > > The Ethernet service sub-option is senseful when Ethernet > service is > > supported by MIP (referring to > > http://www.ietf.org/internet-drafts/draft-wu-mip4-ether-02.txt ). > > > > The format of the Ethernet serice sub-option can be: > > > > - Ethernet serice sub-option (TLV/TV format) > > 0x01 ? 48bit,source MAC address > > 0x02 ? 48bit,destination MAC address > > 0x03 ? 16bit,ethernet type > > 0x04 ? 16bit,vlan tag > > > > - Ethernet serice sub-option (proto header format) > > > > ?0 ? ? ? ? ? ? ? ? ? 1 ? ? ? ? ? ? ? ? ? 2 ? ? ? ? ? ? ? ? > ? 3 ?0 1 2 > > 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |S|D|E|V| ? ? ? Reservered ? ? ?| ? (S) Source MAC Address ? ? ?| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ? ? ? ? ? ? ? ? ? ?(S) Source MAC Address ? ? ? ? ? ? ? ? ? ? | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ? ? ? ? ? ? ? ? (D)Destination MAC Address ? ? ? ? ? ? ? ? ? ?| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |(D)Destination MAC Address ? ? | ? (E) Ethernet Type ? ? ? ? ? | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | ? ? ? ?(V) VLAN tag ? ? ? ? ? | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > B.R. > > Yungui > > > > GT> Given that draft-wu-mip4 is not a WG draft yet I do not think it > makes sense to start adding TSs for this already in a WG doc. > > > > > > From tsirtsis@googlemail.com Mon Aug 10 05:54:18 2009 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 5175E3A6E6A for ; Mon, 10 Aug 2009 05:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_SIDE=2.3] 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 KaLKrU9AiTlb for ; Mon, 10 Aug 2009 05:54:17 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 489D43A6E70 for ; Mon, 10 Aug 2009 05:54:13 -0700 (PDT) Received: by bwz19 with SMTP id 19so2545103bwz.37 for ; Mon, 10 Aug 2009 05:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hWsnJQF9KFGqCJ8EgDPweYiTbeV5qVOnUlZ5KsX17YU=; b=IxoyN5jFFxY1k0VSLcFrhoiYWRlE0Xp3ZqdLsskYkuSlcdBKgQBqfr/u2syxS5Pv7A B7xcynA8p0SSCSiUderwIsa1OYzF9qb97NQ2g2S1vrVlj53m6WI74F2OcmLbxTFTjC9y 7iBopMqSbkaSkoZ/5e5hKj7yoSOCLImi7SlNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Lz091a+lxG3cQmAcjrAcbZQUwz/wYX+GfcZhQ32r+f4FCn/wDG9e/IRFXPuD+8mzHF Ez7Q5hhjpIRBs8gyI8OR6Icgn0DFHB6rUaWdTnOcir0mf2si65TLkfe+IPf9QnGPSmfT eRql6BtKE97jRofQuaPUy6HAQDZyWFHJO+Ebw= MIME-Version: 1.0 Received: by 10.239.157.147 with SMTP id q19mr453424hbc.61.1249908855225; Mon, 10 Aug 2009 05:54:15 -0700 (PDT) In-Reply-To: <00de01ca1953$213a9db0$110ca40a@china.huawei.com> References: <00de01ca1953$213a9db0$110ca40a@china.huawei.com> Date: Mon, 10 Aug 2009 08:54:15 -0400 Message-ID: From: George Tsirtsis To: w52006@huawei.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] FW: Comments to draft-ietf-mext-binary-ts-00.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, 10 Aug 2009 12:54:18 -0000 On Sun, Aug 9, 2009 at 8:40 PM, Yungui Wang wrote: > Hello > > Got it. Thanks. However, in case 2, I mean that there needs > multiple TS(s) for the non-continuous ports based traffic flows. GT> True, for non-continuous ports you need multiple TSs, but can we do better than that? > In addition, it seems that the destination address is not required > to be defined in the TS? Isn't the MN's HoA? The HA always knows > it. GT> If the MN supports NEMO then you might want to identify specific IP address even for destination.. > > B.R. > Yungui > > >> -----Original Message----- >> From: George Tsirtsis [mailto:tsirtsis@googlemail.com] >> Sent: Friday, August 07, 2009 4:46 PM >> To: w52006@huawei.com >> Cc: mext@ietf.org >> Subject: Re: FW: [MEXT] Comments to > draft-ietf-mext-binary-ts-00.txt >> >> On Thu, Aug 6, 2009 at 9:54 PM, Yungui Wang > wrote: >> > Hello >> > >> > I had sent below comment at before. Re-forwarding it here. > Welcome >> > your clarification. Thanks. >> > >> > 1, Could the IPv4/IPv6 binary traffic selector sub-options >> be encoded >> > as the TLV/TV (type, length, value) format? >> > Consideration: TLV/TV format can save size of message. >> > case 1, It may be not necessary to describe the traffic >> which includes >> > all the parameters in the sub-option. e.g. the traffic is >> described as >> > "UDP 21" >> > case 2, On the other hand, one parameter may appear >> multiple times in >> > the sub-option to describe the traffic. e.g. the traffic >> includes two >> > flow which may be presented as TCP port 5000 and 5002. >> > >> >> GT> I am not sure I understand. The existing format would result > to >> (using IPv4 TS for the example): >> - =C2=A0case 1: in a 2+5byte suboption since only B flag >> (Protocol=3DUDP), and I flag (Dst port low=3D21) would be set >> - case 2 in 2+7byte suboption since B flag =C2=A0(Protocol=3DUDP), >> I flag (Dst portlow=3D5001), and K flag (Dst portlow=3D5001) would > be set. >> How does the TLV/TV format allow for more efficient packing? >> >> > 2, ?Could the Ethernet service flow description sub-option be > also >> > introduced in this document? >> > Consideration: >> > The Ethernet service sub-option is senseful when Ethernet >> service is >> > supported by MIP (referring to >> > http://www.ietf.org/internet-drafts/draft-wu-mip4-ether-02.txt > ). >> > >> > The format of the Ethernet serice sub-option can be: >> > >> > - Ethernet serice sub-option (TLV/TV format) >> > 0x01 ? 48bit,source MAC address >> > 0x02 ? 48bit,destination MAC address >> > 0x03 ? 16bit,ethernet type >> > 0x04 ? 16bit,vlan tag >> > >> > - Ethernet serice sub-option (proto header format) >> > >> > ?0 ? ? ? ? ? ? ? ? ? 1 ? ? ? ? ? ? ? ? ? 2 ? ? ? ? ? ? ? ? >> ? 3 ?0 1 2 >> > 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > |S|D|E|V| ? ? ? Reservered ? ? ?| ? (S) Source MAC Address ? ? > ?| >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | ? ? ? ? ? ? ? ? ? ?(S) Source MAC Address ? ? ? ? ? ? ? ? ? > ? | >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | ? ? ? ? ? ? ? ? (D)Destination MAC Address ? ? ? ? ? ? ? ? ? > ?| >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > |(D)Destination MAC Address ? ? | ? (E) Ethernet Type ? ? ? ? > ? | >> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | ? ? ? ?(V) VLAN tag ? ? ? ? ? | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> > B.R. >> > Yungui >> > >> >> GT> Given that draft-wu-mip4 is not a WG draft yet I do not > think it >> makes sense to start adding TSs for this already in a WG doc. >> >> > >> > >> > > From julienl@qualcomm.com Mon Aug 10 10:32:26 2009 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 6213528C0E2 for ; Mon, 10 Aug 2009 10:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.693 X-Spam-Level: X-Spam-Status: No, score=-105.693 tagged_above=-999 required=5 tests=[AWL=0.906, 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 DcetbSvWen5B for ; Mon, 10 Aug 2009 10:32:25 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E27B028C1A0 for ; Mon, 10 Aug 2009 10:32:24 -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=1249925549; x=1281461549; 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: x-cr-hashedpuzzle:x-cr-puzzleid:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20George=20Tsirtsis=20|CC: =20"mext@ietf.org"=20|Date:=20Mon,=2010=20 Aug=202009=2010:32:21=20-0700|Subject:=20ranges=20for=20d raft-ietf-mext-binary-ts-00.txt|Thread-Topic:=20ranges=20 for=20draft-ietf-mext-binary-ts-00.txt|Thread-Index:=20Ac oZub/Mm/YQjIgbQ5GAWqvPNYfVjQAJVrBg|Message-ID:=20|References:=20=0D=0A=09<00de01ca1953$213a9db0 $110ca40a@china.huawei.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator: |x-cr-hashedpuzzle:=20A/zo=20BW+T=20BeAD=20CL7v=20DTF9=20 Dd9C=20DzLk=20ELRa=20E4n/=20Hjir=20OBPl=0D=0A=20Otzw=20PP x7=20S9an=20UNNg=0D=0A=20UfKj=3B2=3BbQBlAHgAdABAAGkAZQB0A GYALgBvAHIAZwA7AHQAcwBpAHIAdABzAGkAcwBAAGcAbwBvAGcAbABlAG 0AYQBpAGwALgBjAG8AbQA=3D=3BSosha1_v1=3B7=3B{6777959E-9304 -4196-812D-FE970BDAA2A8}=3BagB1AGwAaQBlAG4AbABAAHEAdQBhAG wAYwBvAG0AbQAuAGMAbwBtAA=3D=3D=3BMon,=0D=0A=2010=20Aug=20 2009=2017:32:21=0D=0A=20GMT=3BcgBhAG4AZwBlAHMAIABmAG8AcgA gAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBtAGUAeAB0AC0AYgBpAG4AYQBy AHkALQB0AHMALQAwADAALgB0AHgAdAA=3D|x-cr-puzzleid:=20{6777 959E-9304-4196-812D-FE970BDAA2A8}|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5705"=3B=20 a=3D"21904351"; bh=dwpLYcfGZL5o6Oh+4R8513pSEcQPpwYIQ5OdsQ1Ptqs=; b=Reg7weMBdYJrCyyobm5/psllGR5L0ZTz8/BJxT6ZgH1jmJUsVhA50+qC sdaxwDo9Yv/WBOlno0CMNmRJnmA4orC6hCgfpAoJx2I4CmOK/wrNVQeuW 3ju2oYfpUjobBuTRH1NzmJfiJ2nzluzpla58jP2T4GDLaI8pUMVY44XzT w=; X-IronPort-AV: E=McAfee;i="5300,2777,5705"; a="21904351" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Aug 2009 10:32:28 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7AHWSGq025387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2009 10:32:28 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7AHWR6Y002718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Aug 2009 10:32:27 -0700 (PDT) Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 10 Aug 2009 10:32:27 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Mon, 10 Aug 2009 10:32:27 -0700 From: "Laganier, Julien" To: George Tsirtsis Date: Mon, 10 Aug 2009 10:32:21 -0700 Thread-Topic: ranges for draft-ietf-mext-binary-ts-00.txt Thread-Index: AcoZub/Mm/YQjIgbQ5GAWqvPNYfVjQAJVrBg Message-ID: References: <00de01ca1953$213a9db0$110ca40a@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A/zo BW+T BeAD CL7v DTF9 Dd9C DzLk ELRa E4n/ Hjir OBPl Otzw PPx7 S9an UNNg UfKj; 2; bQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA7AHQAcwBpAHIAdABzAGkAcwBAAGcAbwBvAGcAbABlAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {6777959E-9304-4196-812D-FE970BDAA2A8}; agB1AGwAaQBlAG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtAA==; Mon, 10 Aug 2009 17:32:21 GMT; cgBhAG4AZwBlAHMAIABmAG8AcgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBtAGUAeAB0AC0AYgBpAG4AYQByAHkALQB0AHMALQAwADAALgB0AHgAdAA= x-cr-puzzleid: {6777959E-9304-4196-812D-FE970BDAA2A8} acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mext@ietf.org" Subject: [MEXT] ranges for draft-ietf-mext-binary-ts-00.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, 10 Aug 2009 17:32:26 -0000 Rm9sa3MsDQoNCkkgd2FzIHJlYWRpbmcgdGhlIElQc2VjIG1haWxpbmcgbGlzdCBhbmQgZm91bmQg dHdvIGludGVyZXN0aW5nIGV4Y2VycHRzIHcuci50LiBmbG93IFRTLiANCg0KVGVybyBLaXZpbmVu IHdyb3RlOg0KPiBXaGVuIGRlZmluaW5nIHRyYWZmaWMgc2VsZWN0b3JzIGl0IHNob3VsZCBiZSBu b3RlZCwgYXQgYXMgUkZDNDMwMSBzdXBwb3J0cyBkZWNvcnJlbGF0ZWQgDQo+IHBvbGljaWVzIGFs bCB0aGUgdHJhZmZpYyBzZWxlY3RvcnMgc2hvdWxkIGJlIHN1Y2ggdGhhdCB0aGV5IGNhbiBiZSB1 c2VkIHRvIGV4cHJlc3MgZnVsbCANCj4gcmFuZ2VzLiBUaGUgY3VycmVudCB0cmFmZmljIHNlbGVj dG9ycyBhcmUgbm90IGRvaW5nIHRoYXQgYW5kIHRoYXQgaGFzIGNhdXNlZCBwcm9ibGVtcyBhcyAN Cj4gdGhlcmUgaXMgbm8gd2F5IHRvIGV4cGxhaW4gaG9sZSB3aXRob3V0IGxvdHMgb2YgZW50cmll cy4NCj4NCj4gSS5lLiBpZiB5b3UgaGF2ZSB0d28gb3ZlcmxhcHBpbmcgdHJhZmZpYyBzZWxlY3Rv cnMgd2hpY2ggb25lIGlzIHZlcnkgc3BlY2lmaWMgKGRvd24gdG8gaXAsDQo+IHByb3RvY29sIGFu ZCBwb3J0KSBhbmQgb3RoZXIgaXMgbW9yZSBnZW5lcmljIChmb3IgZXhhbXBsZSBhbnkgcG9ydCkg dGhlIGN1cnJlbnQgdHJhZmZpYyANCj4gc2VsZWN0b3Igc2V0IGNhbm5vdCBlZmZpY2VudGx5IGV4 cHJlc3MgdGhhdCwgYXMgdGhlIG1vcmUgZ2VuZXJpYyB0cmFmZmljIHNlbGVjdG9yIHdpbGwgDQo+ IGhhdmUgb25lIGhvbGUgaW4gdGhlIG1pZGRsZSwgYW5kIGFzIGZvcm1hdHMgNyBhbmQgOCBkbyBu b3QgaGF2ZSBwcm90b2NvbCByYW5nZXMsIHRoZXJlIGlzIA0KPiBubyB3YXkgdG8gZWZmaWNpZW50 bHkgZXhwcmVzcyBwcm90b2NvbHMgMCAuLiBuLTEgYW5kIG4rMSAuLiAyNTUuDQo+DQo+IFRoaXMg U0hPVUxEIE5PVCBiZSByZXBlYXRlZCBpbiBhbnkgbmV3IHRyYWZmaWMgc2VsZWN0b3JzLiBBbGwg bmV3IHRyYWZmaWMgc2VsZWN0b3JzIHNob3VsZCANCj4gaGF2ZSByYW5nZXMgZm9yIGFsbCBmaWVs ZHMuDQoNClN0ZXZlIEtlbnQgd3JvdGU6DQo+IFRoZSBwcm90b2NvbCBudW1iZXIgZXhhbXBsZSBy ZWZlcnMgdG8gdGhlIGZhY3QgdGhhdCB3ZSBjYW5ub3QgZXhwcmVzcyBwcm90b2NvbCAgbnVtYmVy IA0KPiByYW5nZXMgaW4gSUtFLCBhbmQgdGhhdCBjYXVzZWQgdXMgdG8gcmVtb3ZlIHN1cHBvcnQg Zm9yIHRoaXMgZmVhdHVyZSBmcm9tIElQc2VjLiBJIGFncmVlIA0KPiB3aXRoIFRlcm8gdGhhdCwg Z29pbmcgZm9yd2FyZCwgd2Ugc2hvdWxkIHJlcXVpcmUgc3VwcG9ydCBmb3IgcmFuZ2VzIG9mIHZh bHVlcyBmb3IgQUxMIG5ldyANCj4gVFMgdmFsdWVzIHRoYXQgd2UgZGVmaW5lLg0KDQpJJ20gZmVl bGluZyB3ZSBzaG91bGQgZm9sbG93IHRoaXMgZGVzaWduIGd1aWRlbGluZXMsIGFuZCBzdGFydCB0 byBtYWtlIGFsbCBmaWVsZHMgaW4gVFNzIGFzIHJhbmdlLg0KDQpXaGF0IGRvIHBlb3BsZSB0aGlu az8NCg0KLS1qdWxpZW4NCg== From AMUHANNA@nortel.com Wed Aug 12 01:35:12 2009 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 B15B73A6A50 for ; Wed, 12 Aug 2009 01:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, 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 476oHytDuQuD for ; Wed, 12 Aug 2009 01:35:11 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3F5C03A67C2 for ; Wed, 12 Aug 2009 01:35:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7C8XHF23239; Wed, 12 Aug 2009 08:33:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 03:32:59 -0500 Message-ID: In-Reply-To: <4A6B12F2.5060608@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-metxt-binding-revocation Thread-Index: AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUAN34jEw References: <4A6B12F2.5060608@piuha.net> From: "Ahmad Muhanna" To: "Jari Arkko" , , Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 12 Aug 2009 08:35:12 -0000 Hi, Jari, Since I need to post some of the text before publishing anyway, please take a look inline which address all of your comments. Thanks and sorry for the delay. Regards, Ahmad > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Saturday, July 25, 2009 9:13 AM > To: draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org > Subject: AD review of draft-ietf-metxt-binding-revocation >=20 > I have reviewed this draft. It is basically in very good=20 > shape, but I did see a few minor issues which I would like to=20 > get corrected before last call. >=20 > Here are my detailed comments: >=20 > Section 5 talks about NATs and UDP encapsulation, but only=20 > with respect to proxy mobility. Client mobility case should=20 > be handled as well. [Ahmad] I updated the whole section as follows, please let me know if that address your comment or if I need to add more details. " 5. Binding Revocation Messages over IPv4 Transport Network In some deployments, the network between the mobile access gateway and the local mobility anchor may only support IPv4 transport. Another case is when a mobile node which support client mobile IPv6 roam to an access network where only IPv4 addressing and transport is supported. In this case, the mobile node is required to register an IPv4 home address with its home agent using a mobile IPv6 Binding Update message. If the Proxy Binding Update and Proxy Binding Acknowledgment messages or the Binding Update and Binding Acknowledgement messages are sent using UDP encapsulation to traverse NATs, then the Binding Revocation messages are sent using the same UDP encapsulation. The same UDP port that was used for exchanging the Proxy Binding Update and Proxy Binding Acknowledgement or the Binding Update and Binding Acknowledgement messages will also be used when transporting Binding Revocation messages over IPv4 using UDP encapsulation. In other words, the destination UDP port of the Binding Revocation Indication message MUST be set to the source UDP port of the latest successfully processed Proxy Binding Update or Binding Update message which is already saved in the mobile node BCE. For more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively. " >=20 > The list of fields after Figure 4 might be more readable if=20 > you included all fields, such as MH Type. [Ahmad] Sure, what about the following: " MH Type which identifies the mobility message as a Binding Revocation message. Reserved 8-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Checksum 16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is calculated as described in [RFC3775]. Binding Revocation Type 8-bit unsigned integer. It defines the type of the Binding Revocation Message. It can be assigned one of the following values: 0 Reserved 1 Binding Revocation Indication Message 2 Binding Revocation Acknowledgement Message All other values are reserved Binding Revocation Message Data The Binding Revocation Message Data follows the Binding Revocation Message format that is defined in this document for the specified value in the Binding Revocation Type field. In this specification, it is either a Binding Revocation Indication as in Section 6.1 or Binding Revocation Acknowledgement as in Section 6.2. " >=20 > > Indication message, the responder MUST constructs the Binding > MUST construct >=20 > > Since some mobility entities, e.g., local mobility=20 > anchor and mobile > > access gateway, are allowed to receive and possibly send=20 > a Binding > > Revocation Indication or Binding Revocation Acknowledgement for > > different cases, therefore, if IPsec is used to secure signaling > > between the them, it prevents any possible man in the middle > > reflection attack. > > =20 >=20 > Its not clear to me what attacks you are talking about here.=20 > Reflection attacks normally mean that the attacker sends a=20 > packet that a third party responds to and sends the response=20 > to the victim. >=20 > Perhaps you meant to say "... prevents the processing of a=20 > message not constructed by an authorized party"? [Ahmad] Sure, here is the updated text: " Since some mobility entities, e.g., local mobility anchor and mobile access gateway, are allowed to receive and possibly send a Binding Revocation Indication or Binding Revocation Acknowledgement for different cases, therefore, if IPsec is used to secure signaling between the local mobility anchor and mobile access gateway, it prevents any of them from processing a Binding Revocation message that was not constructed by an authorized party. " >=20 > > BCE that belong to a specific realm, e.g.=20 > @companyabc.com, that are >=20 > Please use example.com instead. >=20 > > wildcard > > NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs > > that need to be removed. > > =20 > You need to specify what the syntax of the wildcard format=20 > is. Note that '*' is a legal character in the username=20 > portion of a NAI [RFC4282], so I would recommend considering=20 > another syntax (such as @example.com). [Ahmad] After thinking of this a little more, I think your suggestion of using @example.com" is much easier. So here the modified text: " When the local mobility anchor needs to revoke all mobile nodes proxy BCE that belong to a specific realm, e.g. @example.com, that are registered with the local mobility anchor and hosted at the mobile access gateway, the local mobility anchor MUST set the Global (G) bit and set the value of the Revocation Trigger field to "Revoking Mobility Node Local Policy". In this case, the local mobility anchor MUST include a mobility option in the Binding Revocation Indication to identify the impacted bindings, e.g., MN-ID option with an NAI value of @example.com, to identify all the mobile nodes BCEs that have a MN-ID with a realm that matches the NAI value in the received MN-ID option and need to be removed. " >=20 > I would like to change the retranmission procedure to use an=20 > exponential back-off, in a style similar to RFC 3775, Section=20 > 11.8. This procedure is both more friendly to other traffic=20 > in a congestion situation, as well as faster in resending a=20 > lost first packet. [Ahmad] Sure. Here is the updated text: " 7.3. Retransmission of Binding Revocation Indication If the sending mobility entity does not receive a Binding Revocation Acknowledgement in response to the outstanding initial Binding Revocation Indication before the InitMINDelayBRIs timer expires, the mobility entity, e.g. LMA, SHOULD retransmit the same BRI message up to the BRIMaxRetriesNumber as defined in Section 12. The retransmissions by the sending mobility entity MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BRACK_TIMEOUT. The sending mobility entity MAY continue to send these messages at this slower rate up to the BRIMaxRetriesNumber. If the revoking mobility entity does not receive a Binding Revocation Acknowledgement message after the maximum number of retransmits have been sent, the revoking mobility entity can clean the mobile node binding cache and all resources associated with this binding. The revoking mobility entity may log the event. " Also a new MAX_BRACK_TIMEOUT has been defined under section 12: " Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT) This variable specifies the maximum delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 2 seconds. " >=20 > Jari >=20 >=20 From jari.arkko@piuha.net Wed Aug 12 02:07:23 2009 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 3BAE03A6A04 for ; Wed, 12 Aug 2009 02:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 S6OqIAPrdf30 for ; Wed, 12 Aug 2009 02:07:22 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C4AFD3A67D9 for ; Wed, 12 Aug 2009 02:07:21 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 6A5BD19863E; Wed, 12 Aug 2009 12:06:48 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 0BB8919863D; Wed, 12 Aug 2009 12:06:48 +0300 (EEST) Message-ID: <4A828626.3000201@piuha.net> Date: Wed, 12 Aug 2009 12:06:46 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ahmad Muhanna References: <4A6B12F2.5060608@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 12 Aug 2009 09:07:23 -0000 Ahmad, > I updated the whole section as follows, please let me know if that > address your comment or if I need to add more details. > > " > 5. Binding Revocation Messages over IPv4 Transport Network > > In some deployments, the network between the mobile access gateway > and the local mobility anchor may only support IPv4 transport. > Another case is when a mobile node which support client mobile IPv6 > roam to an access network where only IPv4 addressing and transport is > supported. In this case, the mobile node is required to register an > IPv4 home address with its home agent using a mobile IPv6 Binding > Update message. > > If the Proxy Binding Update and Proxy Binding Acknowledgment messages > or the Binding Update and Binding Acknowledgement messages are sent > using UDP encapsulation to traverse NATs, then the Binding Revocation > messages are sent using the same UDP encapsulation. The same UDP > port that was used for exchanging the Proxy Binding Update and Proxy > Binding Acknowledgement or the Binding Update and Binding > Acknowledgement messages will also be used when transporting Binding > Revocation messages over IPv4 using UDP encapsulation. In other > words, the destination UDP port of the Binding Revocation Indication > message MUST be set to the source UDP port of the latest successfully > processed Proxy Binding Update or Binding Update message which is > already saved in the mobile node BCE. For more details on tunneling > Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see > [ID-PMIP6-IPv4] and [RFC5555], respectively. > " > Looks good to me. >> The list of fields after Figure 4 might be more readable if >> you included all fields, such as MH Type. >> > > [Ahmad] > Sure, what about the following: > > " > MH Type > > which identifies the mobility message as a Binding > Revocation message. > > Reserved > > 8-bit field reserved for future use. The value MUST be > initialized to zero by the sender, and MUST be ignored by the > receiver. > > Checksum > > 16-bit unsigned integer. This field contains the checksum of the > Mobility Header. The checksum is calculated as described in > [RFC3775]. > > Binding Revocation Type > > 8-bit unsigned integer. It defines the type of the Binding > Revocation Message. It can be assigned one of the following > values: > > 0 Reserved > 1 Binding Revocation Indication Message > 2 Binding Revocation Acknowledgement Message > All other values are reserved > > Binding Revocation Message Data > > The Binding Revocation Message Data follows the Binding Revocation > Message format that is defined in this document for the specified > value in the Binding Revocation Type field. In this > specification, it is either a Binding Revocation Indication as in > Section 6.1 or Binding Revocation Acknowledgement as in > Section 6.2. > " > OK > >>> Indication message, the responder MUST constructs the Binding >>> >> MUST construct >> >> >>> Since some mobility entities, e.g., local mobility >>> >> anchor and mobile >> >>> access gateway, are allowed to receive and possibly send >>> >> a Binding >> >>> Revocation Indication or Binding Revocation Acknowledgement for >>> different cases, therefore, if IPsec is used to secure signaling >>> between the them, it prevents any possible man in the middle >>> reflection attack. >>> >>> >> Its not clear to me what attacks you are talking about here. >> Reflection attacks normally mean that the attacker sends a >> packet that a third party responds to and sends the response >> to the victim. >> >> Perhaps you meant to say "... prevents the processing of a >> message not constructed by an authorized party"? >> > > [Ahmad] > Sure, here is the updated text: > > " > Since some mobility entities, e.g., local mobility anchor and mobile > access gateway, are allowed to receive and possibly send a Binding > Revocation Indication or Binding Revocation Acknowledgement for > different cases, therefore, if IPsec is used to secure signaling > between the local mobility anchor and mobile access gateway, it > prevents any of them from processing a Binding Revocation message > that was not constructed by an authorized party. > " > OK >>> BCE that belong to a specific realm, e.g. >>> >> @companyabc.com, that are >> >> Please use example.com instead. >> >> >>> wildcard >>> NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs >>> that need to be removed. >>> >>> >> You need to specify what the syntax of the wildcard format >> is. Note that '*' is a legal character in the username >> portion of a NAI [RFC4282], so I would recommend considering >> another syntax (such as @example.com). >> > > [Ahmad] > After thinking of this a little more, I think your suggestion of using > @example.com" is much easier. So here the modified text: > > " > When the local mobility anchor needs to revoke all mobile nodes proxy > BCE that belong to a specific realm, e.g. @example.com, that are > registered with the local mobility anchor and hosted at the mobile > access gateway, the local mobility anchor MUST set the Global (G) bit > and set the value of the Revocation Trigger field to "Revoking > Mobility Node Local Policy". In this case, the local mobility anchor > MUST include a mobility option in the Binding Revocation Indication > to identify the impacted bindings, e.g., MN-ID option with an NAI > value of @example.com, to identify all the mobile nodes BCEs that > have a MN-ID with a realm that matches the NAI value in the received > MN-ID option and need to be removed. > " > OK >> I would like to change the retranmission procedure to use an >> exponential back-off, in a style similar to RFC 3775, Section >> 11.8. This procedure is both more friendly to other traffic >> in a congestion situation, as well as faster in resending a >> lost first packet. >> > > [Ahmad] > Sure. Here is the updated text: > > " > 7.3. Retransmission of Binding Revocation Indication > > If the sending mobility entity does not receive a Binding Revocation > Acknowledgement in response to the outstanding initial Binding > Revocation Indication before the InitMINDelayBRIs timer expires, the > mobility entity, e.g. LMA, SHOULD retransmit the same BRI message up > to the BRIMaxRetriesNumber as defined in Section 12. > > The retransmissions by the sending mobility entity MUST use an > exponential back-off process in which the timeout period is doubled > upon each retransmission, until either the node receives a response > or the timeout period reaches the value MAX_BRACK_TIMEOUT. The > sending mobility entity MAY continue to send these messages at this > slower rate up to the BRIMaxRetriesNumber. > > If the revoking mobility entity does not receive a Binding Revocation > Acknowledgement message after the maximum number of retransmits have > been sent, the revoking mobility entity can clean the mobile node > binding cache and all resources associated with this binding. The > revoking mobility entity may log the event. > " > > Also a new MAX_BRACK_TIMEOUT has been defined under section 12: > > " > Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT) > > This variable specifies the maximum delay timeout in seconds > before the revoking mobility entity retransmits a BRI message. > The default is 2 seconds. > " > Looks good to me. Jari From root@core3.amsl.com Wed Aug 12 07:00:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DC0743A683F; Wed, 12 Aug 2009 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: <20090812140001.DC0743A683F@core3.amsl.com> Date: Wed, 12 Aug 2009 07:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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, 12 Aug 2009 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 : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-08.txt Pages : 41 Date : 2009-08-12 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-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-binding-revocation-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-12064800.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Wed Aug 12 07:33:02 2009 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 0BC223A6A6C for ; Wed, 12 Aug 2009 07:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, 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 4-ousiXTC62v for ; Wed, 12 Aug 2009 07:33:00 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8CB943A6886 for ; Wed, 12 Aug 2009 07:33:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7CEUqF19384; Wed, 12 Aug 2009 14:30:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Aug 2009 09:30:08 -0500 Message-ID: In-Reply-To: <4A828626.3000201@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-metxt-binding-revocation Thread-Index: AcobLDwxMQu4/kd7TYiATZUxlG3SnQAKAPdQ References: <4A6B12F2.5060608@piuha.net> <4A828626.3000201@piuha.net> From: "Ahmad Muhanna" To: Cc: Jari Arkko Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 12 Aug 2009 14:33:02 -0000 Hi, We have submitted rev 08 which addresses all of Jar's comments. Thanks. Regards, Ahmad +++++++++++++++++++++++++++++++++++++ From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, August 12, 2009 9:00 AM To: i-d-announce@ietf.org Cc: mext@ietf.org Subject: I-D Action:draft-ietf-mext-binding-revocation-08.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. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-08.txt Pages : 41 Date : 2009-08-12 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-0 8.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. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, August 12, 2009 4:07 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org > Subject: Re: AD review of draft-ietf-metxt-binding-revocation >=20 > Ahmad, >=20 > > I updated the whole section as follows, please let me know if that=20 > > address your comment or if I need to add more details. > > > > " > > 5. Binding Revocation Messages over IPv4 Transport Network > > > > In some deployments, the network between the mobile=20 > access gateway > > and the local mobility anchor may only support IPv4 transport. > > Another case is when a mobile node which support client=20 > mobile IPv6 > > roam to an access network where only IPv4 addressing and=20 > transport is > > supported. In this case, the mobile node is required to=20 > register an > > IPv4 home address with its home agent using a mobile IPv6 Binding > > Update message. > > > > If the Proxy Binding Update and Proxy Binding=20 > Acknowledgment messages > > or the Binding Update and Binding Acknowledgement=20 > messages are sent > > using UDP encapsulation to traverse NATs, then the=20 > Binding Revocation > > messages are sent using the same UDP encapsulation. The same UDP > > port that was used for exchanging the Proxy Binding=20 > Update and Proxy > > Binding Acknowledgement or the Binding Update and Binding > > Acknowledgement messages will also be used when=20 > transporting Binding > > Revocation messages over IPv4 using UDP encapsulation. In other > > words, the destination UDP port of the Binding=20 > Revocation Indication > > message MUST be set to the source UDP port of the latest=20 > successfully > > processed Proxy Binding Update or Binding Update message which is > > already saved in the mobile node BCE. For more details=20 > on tunneling > > Proxy Mobile IPv6 and Mobile IPv6 signaling messages=20 > over IPv4, see > > [ID-PMIP6-IPv4] and [RFC5555], respectively. > > " > > =20 >=20 > Looks good to me. >=20 > >> The list of fields after Figure 4 might be more readable if you=20 > >> included all fields, such as MH Type. > >> =20 > > > > [Ahmad] > > Sure, what about the following: > > > > " > > MH Type > > > > which identifies the mobility message as a Binding > > Revocation message. > > > > Reserved > > > > 8-bit field reserved for future use. The value MUST be > > initialized to zero by the sender, and MUST be ignored by the > > receiver. > > > > Checksum > > > > 16-bit unsigned integer. This field contains the=20 > checksum of the > > Mobility Header. The checksum is calculated as described in > > [RFC3775]. > > > > Binding Revocation Type > > > > 8-bit unsigned integer. It defines the type of the Binding > > Revocation Message. It can be assigned one of the following > > values: > > > > 0 Reserved > > 1 Binding Revocation Indication Message > > 2 Binding Revocation Acknowledgement Message > > All other values are reserved > > > > Binding Revocation Message Data > > > > The Binding Revocation Message Data follows the=20 > Binding Revocation > > Message format that is defined in this document for=20 > the specified > > value in the Binding Revocation Type field. In this > > specification, it is either a Binding Revocation=20 > Indication as in > > Section 6.1 or Binding Revocation Acknowledgement as in > > Section 6.2. > > " > > =20 >=20 > OK >=20 > > =20 > >>> Indication message, the responder MUST constructs the Binding > >>> =20 > >> MUST construct > >> > >> =20 > >>> Since some mobility entities, e.g., local mobility > >>> =20 > >> anchor and mobile > >> =20 > >>> access gateway, are allowed to receive and possibly send > >>> =20 > >> a Binding > >> =20 > >>> Revocation Indication or Binding Revocation Acknowledgement for > >>> different cases, therefore, if IPsec is used to secure=20 > signaling > >>> between the them, it prevents any possible man in the middle > >>> reflection attack. > >>> =20 > >>> =20 > >> Its not clear to me what attacks you are talking about here.=20 > >> Reflection attacks normally mean that the attacker sends a packet=20 > >> that a third party responds to and sends the response to=20 > the victim. > >> > >> Perhaps you meant to say "... prevents the processing of a message=20 > >> not constructed by an authorized party"? > >> =20 > > > > [Ahmad] > > Sure, here is the updated text: > > > > " > > Since some mobility entities, e.g., local mobility=20 > anchor and mobile > > access gateway, are allowed to receive and possibly send=20 > a Binding > > Revocation Indication or Binding Revocation Acknowledgement for > > different cases, therefore, if IPsec is used to secure signaling > > between the local mobility anchor and mobile access gateway, it > > prevents any of them from processing a Binding Revocation message > > that was not constructed by an authorized party. > > " > > =20 >=20 > OK >=20 > >>> BCE that belong to a specific realm, e.g.=20 > >>> =20 > >> @companyabc.com, that are > >> > >> Please use example.com instead. > >> > >> =20 > >>> wildcard > >>> NAI, e.g. *@companyabc.com, to identify all the mobile=20 > nodes BCEs > >>> that need to be removed. > >>> =20 > >>> =20 > >> You need to specify what the syntax of the wildcard format=20 > is. Note=20 > >> that '*' is a legal character in the username portion of a NAI=20 > >> [RFC4282], so I would recommend considering another syntax=20 > (such as=20 > >> @example.com). > >> =20 > > > > [Ahmad] > > After thinking of this a little more, I think your=20 > suggestion of using=20 > > @example.com" is much easier. So here the modified text: > > > > " > > When the local mobility anchor needs to revoke all=20 > mobile nodes proxy > > BCE that belong to a specific realm, e.g. @example.com, that are > > registered with the local mobility anchor and hosted at=20 > the mobile > > access gateway, the local mobility anchor MUST set the=20 > Global (G) bit > > and set the value of the Revocation Trigger field to "Revoking > > Mobility Node Local Policy". In this case, the local=20 > mobility anchor > > MUST include a mobility option in the Binding Revocation=20 > Indication > > to identify the impacted bindings, e.g., MN-ID option with an NAI > > value of @example.com, to identify all the mobile nodes BCEs that > > have a MN-ID with a realm that matches the NAI value in=20 > the received > > MN-ID option and need to be removed. > > " > > =20 >=20 > OK >=20 > >> I would like to change the retranmission procedure to use an=20 > >> exponential back-off, in a style similar to RFC 3775,=20 > Section 11.8.=20 > >> This procedure is both more friendly to other traffic in a=20 > congestion=20 > >> situation, as well as faster in resending a lost first packet. > >> =20 > > > > [Ahmad] > > Sure. Here is the updated text: > > > > " > > 7.3. Retransmission of Binding Revocation Indication > > > > If the sending mobility entity does not receive a=20 > Binding Revocation > > Acknowledgement in response to the outstanding initial Binding > > Revocation Indication before the InitMINDelayBRIs timer=20 > expires, the > > mobility entity, e.g. LMA, SHOULD retransmit the same=20 > BRI message up > > to the BRIMaxRetriesNumber as defined in Section 12. > > > > The retransmissions by the sending mobility entity MUST use an > > exponential back-off process in which the timeout period=20 > is doubled > > upon each retransmission, until either the node receives=20 > a response > > or the timeout period reaches the value MAX_BRACK_TIMEOUT. The > > sending mobility entity MAY continue to send these=20 > messages at this > > slower rate up to the BRIMaxRetriesNumber. > > > > If the revoking mobility entity does not receive a=20 > Binding Revocation > > Acknowledgement message after the maximum number of=20 > retransmits have > > been sent, the revoking mobility entity can clean the mobile node > > binding cache and all resources associated with this=20 > binding. The > > revoking mobility entity may log the event. > > " > > > > Also a new MAX_BRACK_TIMEOUT has been defined under section 12: > > > > " > > Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT) > > > > This variable specifies the maximum delay timeout in seconds > > before the revoking mobility entity retransmits a BRI message. > > The default is 2 seconds. > > " > > =20 >=20 > Looks good to me. >=20 > Jari >=20 >=20 From wwwrun@core3.amsl.com Wed Aug 12 08:59:29 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 32DBC3A6BA6; Wed, 12 Aug 2009 08:59:28 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090812155929.32DBC3A6BA6@core3.amsl.com> Date: Wed, 12 Aug 2009 08:59:29 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation (Binding Revocation for IPv6 Mobility) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 15:59:29 -0000 The IESG has received a request from the Mobility EXTensions for IPv6 WG (mext) to consider the following document: - 'Binding Revocation for IPv6 Mobility ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17614&rfc_flag=0 From julienl@qualcomm.com Wed Aug 12 16:40:32 2009 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 ADEA53A6B5E for ; Wed, 12 Aug 2009 16:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.728 X-Spam-Level: X-Spam-Status: No, score=-105.728 tagged_above=-999 required=5 tests=[AWL=0.871, 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 oX8tbWkJhhzj for ; Wed, 12 Aug 2009 16:40:27 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 11FF73A6900 for ; Wed, 12 Aug 2009 16:40: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=1250120430; x=1281656430; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Ahmad=20Muhanna=20,=20Jari=20 Arkko=20,=0D=0A=20=20=20=20=20=20 =20=20"draft-ietf-mext-binding-revocation@tools.ietf.org" =0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"mext@ietf.org"=0D=0A =09|Date:=20Wed,=2012=20Aug=202009=2016:39 :05=20-0700|Subject:=20RE:=20AD=20review=20of=20draft-iet f-metxt-binding-revocation|Thread-Topic:=20AD=20review=20 of=20draft-ietf-metxt-binding-revocation|Thread-Index:=20 AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUAN34jEwACRM+YA=3D |Message-ID:=20|References:=20<4A6B12F2.50 60608@piuha.net>=0D=0A=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-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5707"=3B=20a=3D"22031081"; bh=1KTg5h4Kk484Tv3sox4qvai9XoGLVg2VHXH61/dq60Q=; b=mM8ouk9osQOn5cTPb/7Rx8VEdN8gK5fP+g3189bwIUFj2Yx3mePVoYBl QTDRf0lhUtfyq8ZppYFk0Zb02ypVNBR7vIWteZE5jRDX+vrq9WNbLDSkV uueQhjNhAGZu/jYJNxZmkL4wB798HhjUHh7ocRp+4J4amKOZHKaGaKK+4 c=; X-IronPort-AV: E=McAfee;i="5300,2777,5707"; a="22031081" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Aug 2009 16:39:11 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7CNdA4K010594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Aug 2009 16:39:11 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7CNdA0w003349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Aug 2009 16:39:10 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 12 Aug 2009 16:39:10 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 12 Aug 2009 16:39:08 -0700 From: "Laganier, Julien" To: Ahmad Muhanna , Jari Arkko , "draft-ietf-mext-binding-revocation@tools.ietf.org" , "mext@ietf.org" Date: Wed, 12 Aug 2009 16:39:05 -0700 Thread-Topic: AD review of draft-ietf-metxt-binding-revocation Thread-Index: AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUAN34jEwACRM+YA= Message-ID: References: <4A6B12F2.5060608@piuha.net> 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 Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 12 Aug 2009 23:40:32 -0000 Hello Ahmad, Thanks for updating the draft. I have some comments on the text below. > 5. Binding Revocation Messages over IPv4 Transport Network >=20 > In some deployments, the network between the mobile access gateway > and the local mobility anchor may only support IPv4 transport. > Another case is when a mobile node which support client mobile IPv6 > roam to an access network where only IPv4 addressing and transport is > supported. In this case, the mobile node is required to register an > IPv4 home address with its home agent using a mobile IPv6 Binding > Update message. > > If the Proxy Binding Update and Proxy Binding Acknowledgment messages > or the Binding Update and Binding Acknowledgement messages are sent > using UDP encapsulation to traverse NATs, then the Binding Revocation > messages are sent using the same UDP encapsulation. The same UDP > port that was used for exchanging the Proxy Binding Update and Proxy > Binding Acknowledgement or the Binding Update and Binding > Acknowledgement messages will also be used when transporting Binding Shouldn't we say "The same source and destination IPv4 addresses and UDP po= rt numbers that were used to transmit the ..." Also, maybe a matter of taste but IMHO it would be more logic that the BU a= nd BA are mentioned before the PBU and PBA. > Revocation messages over IPv4 using UDP encapsulation. In other > words, the destination UDP port of the Binding Revocation Indication > message MUST be set to the source UDP port of the latest successfully > processed Proxy Binding Update or Binding Update message which is > already saved in the mobile node BCE. For more details on tunneling > Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see > [ID-PMIP6-IPv4] and [RFC5555], respectively. Here you're only covering the BRI sent by LMA to MAG, but you don't cover s= ending BRA, neither BRI being sent from MAG to LMA. Is this intentional? I = think we ought to be complete...=20 And again, I think it's better to mention BU before PBU. Best, --julien From Xiangsong.Cui@huawei.com Wed Aug 12 21:04:29 2009 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 AC1863A6ABA; Wed, 12 Aug 2009 21:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 s9IrPiQdY4gK; Wed, 12 Aug 2009 21:04:29 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C89293A691F; Wed, 12 Aug 2009 21:04:28 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOA00BFHR89BI@szxga03-in.huawei.com>; Thu, 13 Aug 2009 12:02:33 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOA009ZNR890O@szxga03-in.huawei.com>; Thu, 13 Aug 2009 12:02:33 +0800 (CST) Date: Thu, 13 Aug 2009 12:02:33 +0800 From: Xiangsong Cui To: ietf@ietf.org, IETF-Announce Message-id: <007d01ca1bca$e2dda240$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090812155929.32DBC3A6BA6@core3.amsl.com> Cc: mext@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) 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: Thu, 13 Aug 2009 04:04:29 -0000 Hi all, Thank the authors for the good job and I have a minor comment. In section 8.2 (the last paragraph), o If the Status field indicates any value other than success, the home agent SHOULD examine any mobility options included in the Binding Revocation Acknowledgement. The home agent MAY log the appropriate event to reflect the received status. I think it is not very clear how should the home agent handle the BCE (e.g. the resource and revocation in progress flag) and the revocation timer (if there is some timer is running). The corresponding part from LMA is better, I think. It is based on the local mobility anchor local policy how to handle the mobile node BCE(s) that the mobile access gateway indicated it failed the revocation procedure, however, the LMA MAY log the event. Regards Xiangsong ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: Sent: Wednesday, August 12, 2009 11:59 PM Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) to Proposed Standard > The IESG has received a request from the Mobility EXTensions for IPv6 WG > (mext) to consider the following document: > > - 'Binding Revocation for IPv6 Mobility ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-08-26. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-08.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17614&rfc_flag=0 > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From jari.arkko@piuha.net Wed Aug 12 21:13:01 2009 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 C54C33A694F for ; Wed, 12 Aug 2009 21:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 AIXrt52Us+39 for ; Wed, 12 Aug 2009 21:13:01 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AE7783A689C for ; Wed, 12 Aug 2009 21:13:00 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 5CBA3198646; Thu, 13 Aug 2009 07:13:00 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id F3A331985F8; Thu, 13 Aug 2009 07:12:59 +0300 (EEST) Message-ID: <4A8392CA.10905@piuha.net> Date: Thu, 13 Aug 2009 07:12:58 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Laganier, Julien" References: <4A6B12F2.5060608@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: "draft-ietf-mext-binding-revocation@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 13 Aug 2009 04:13:01 -0000 At least the first comment from Julien is something that probably should be fixed. Ahmad, feel free to make these updates by posting a new draft, even if the Last Call is going on. Or you could wait until there's more comments. Jari Laganier, Julien wrote: > Hello Ahmad, > > Thanks for updating the draft. I have some comments on the text below. > > >> 5. Binding Revocation Messages over IPv4 Transport Network >> >> In some deployments, the network between the mobile access gateway >> and the local mobility anchor may only support IPv4 transport. >> Another case is when a mobile node which support client mobile IPv6 >> roam to an access network where only IPv4 addressing and transport is >> supported. In this case, the mobile node is required to register an >> IPv4 home address with its home agent using a mobile IPv6 Binding >> Update message. >> >> If the Proxy Binding Update and Proxy Binding Acknowledgment messages >> or the Binding Update and Binding Acknowledgement messages are sent >> using UDP encapsulation to traverse NATs, then the Binding Revocation >> messages are sent using the same UDP encapsulation. The same UDP >> port that was used for exchanging the Proxy Binding Update and Proxy >> Binding Acknowledgement or the Binding Update and Binding >> Acknowledgement messages will also be used when transporting Binding >> > > Shouldn't we say "The same source and destination IPv4 addresses and UDP port numbers that were used to transmit the ..." > > Also, maybe a matter of taste but IMHO it would be more logic that the BU and BA are mentioned before the PBU and PBA. > > >> Revocation messages over IPv4 using UDP encapsulation. In other >> words, the destination UDP port of the Binding Revocation Indication >> message MUST be set to the source UDP port of the latest successfully >> processed Proxy Binding Update or Binding Update message which is >> already saved in the mobile node BCE. For more details on tunneling >> Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see >> [ID-PMIP6-IPv4] and [RFC5555], respectively. >> > > Here you're only covering the BRI sent by LMA to MAG, but you don't cover sending BRA, neither BRI being sent from MAG to LMA. Is this intentional? I think we ought to be complete... > > And again, I think it's better to mention BU before PBU. > > Best, > > --julien > > > From AMUHANNA@nortel.com Thu Aug 13 00:06:29 2009 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 AE9753A69B8 for ; Thu, 13 Aug 2009 00:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, 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 KOYHtg0p3KkT for ; Thu, 13 Aug 2009 00:06:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7E0AB3A69AA for ; Thu, 13 Aug 2009 00:06:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7D71OG28517; Thu, 13 Aug 2009 07:01:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 01:54:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-metxt-binding-revocation Thread-Index: AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUAN34jEwACRM+YAABpAPoA== References: <4A6B12F2.5060608@piuha.net> From: "Ahmad Muhanna" To: "Laganier, Julien" , "Jari Arkko" , , Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 13 Aug 2009 07:06:29 -0000 Hi Julien, Please inline. Regards, Ahmad =20 > -----Original Message----- > From: Laganier, Julien [mailto:julienl@qualcomm.com]=20 > Sent: Wednesday, August 12, 2009 6:39 PM > To: Muhanna, Ahmad (RICH1:2H10); Jari Arkko;=20 > draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org > Subject: RE: AD review of draft-ietf-metxt-binding-revocation >=20 > Hello Ahmad, >=20 > Thanks for updating the draft. I have some comments on the text below. >=20 > > 5. Binding Revocation Messages over IPv4 Transport Network > >=20 > > In some deployments, the network between the mobile=20 > access gateway > > and the local mobility anchor may only support IPv4 transport. > > Another case is when a mobile node which support client=20 > mobile IPv6 > > roam to an access network where only IPv4 addressing and=20 > transport is > > supported. In this case, the mobile node is required to=20 > register an > > IPv4 home address with its home agent using a mobile IPv6 Binding > > Update message. > > > > If the Proxy Binding Update and Proxy Binding=20 > Acknowledgment messages > > or the Binding Update and Binding Acknowledgement=20 > messages are sent > > using UDP encapsulation to traverse NATs, then the=20 > Binding Revocation > > messages are sent using the same UDP encapsulation. The same UDP > > port that was used for exchanging the Proxy Binding=20 > Update and Proxy > > Binding Acknowledgement or the Binding Update and Binding > > Acknowledgement messages will also be used when transporting=20 > > Binding >=20 > Shouldn't we say "The same source and destination IPv4=20 > addresses and UDP port numbers that were used to transmit the ..." [Ahmad] Sure, we will fix this one. Please see below. >=20 > Also, maybe a matter of taste but IMHO it would be more logic=20 > that the BU and BA are mentioned before the PBU and PBA. >=20 [Ahmad] Good taste Julien! :) Personally, I do not see any difference or significance value to which is mentioned first. > > Revocation messages over IPv4 using UDP encapsulation. In other > > words, the destination UDP port of the Binding=20 > Revocation Indication > > message MUST be set to the source UDP port of the latest=20 > successfully > > processed Proxy Binding Update or Binding Update message which is > > already saved in the mobile node BCE. For more details=20 > on tunneling > > Proxy Mobile IPv6 and Mobile IPv6 signaling messages=20 > over IPv4, see > > [ID-PMIP6-IPv4] and [RFC5555], respectively. >=20 > Here you're only covering the BRI sent by LMA to MAG, but you=20 > don't cover sending BRA, neither BRI being sent from MAG to=20 > LMA. Is this intentional? I think we ought to be complete...=20 [Ahmad] In the first sentence we used Binding Revocation messages to avoid mentioning BRI and BRA separately in order to optimize the text. However, when the BRI was mentioned, we should have said, for example. The idea here is just to clarify the first sentence. So what about the following: " If the Proxy Binding Update and Proxy Binding Acknowledgment messages or the Binding Update and Binding Acknowledgement messages are sent using UDP encapsulation to traverse NATs, then the Binding Revocation messages are sent using the same UDP encapsulation. The same UDP port, source IPv4 address, and destination IPv4 address that were used for exchanging the Proxy Binding Update and Proxy Binding Acknowledgement or the Binding Update and Binding Acknowledgement messages will also be used when transporting Binding Revocation messages over IPv4 using UDP encapsulation. In other words, e.g., the destination UDP port, the destination IPv4 address, and the source IPv4 address of the Binding Revocation Indication message MUST be set to the source UDP port, source IPv4 address, and destination IPv4 address of the latest successfully processed Proxy Binding Update or Binding Update message, respectively. For more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively." >=20 > And again, I think it's better to mention BU before PBU. >=20 > Best, >=20 > --julien >=20 From AMUHANNA@nortel.com Thu Aug 13 00:18:42 2009 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 221053A693B for ; Thu, 13 Aug 2009 00:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, 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 sZnitf-+ULrO for ; Thu, 13 Aug 2009 00:18:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 13F8F3A6925 for ; Thu, 13 Aug 2009 00:18:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7D71ZG28542; Thu, 13 Aug 2009 07:01:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 01:56:51 -0500 Message-ID: In-Reply-To: <4A8392CA.10905@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-metxt-binding-revocation Thread-Index: AcobzFsLlTNJutmMT22SW6nuDpfScAADraaw References: <4A6B12F2.5060608@piuha.net> <4A8392CA.10905@piuha.net> From: "Ahmad Muhanna" To: "Jari Arkko" , "Laganier, Julien" Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 13 Aug 2009 07:18:42 -0000 Hi, Jari, Sure will fix it. Will wait a couple of days just in case we receive more comments and then will publish a new revision. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Wednesday, August 12, 2009 11:13 PM > To: Laganier, Julien > Cc: Muhanna, Ahmad (RICH1:2H10);=20 > draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org > Subject: Re: AD review of draft-ietf-metxt-binding-revocation >=20 > At least the first comment from Julien is something that=20 > probably should be fixed. Ahmad, feel free to make these=20 > updates by posting a new draft, even if the Last Call is=20 > going on. Or you could wait until there's more comments. >=20 > Jari >=20 > Laganier, Julien wrote: > > Hello Ahmad, > > > > Thanks for updating the draft. I have some comments on the=20 > text below. > > > > =20 > >> 5. Binding Revocation Messages over IPv4 Transport Network > >> > >> In some deployments, the network between the mobile=20 > access gateway > >> and the local mobility anchor may only support IPv4 transport. > >> Another case is when a mobile node which support client=20 > mobile IPv6 > >> roam to an access network where only IPv4 addressing=20 > and transport is > >> supported. In this case, the mobile node is required=20 > to register an > >> IPv4 home address with its home agent using a mobile=20 > IPv6 Binding > >> Update message. > >> > >> If the Proxy Binding Update and Proxy Binding=20 > Acknowledgment messages > >> or the Binding Update and Binding Acknowledgement=20 > messages are sent > >> using UDP encapsulation to traverse NATs, then the=20 > Binding Revocation > >> messages are sent using the same UDP encapsulation. =20 > The same UDP > >> port that was used for exchanging the Proxy Binding=20 > Update and Proxy > >> Binding Acknowledgement or the Binding Update and Binding > >> Acknowledgement messages will also be used when transporting=20 > >> Binding > >> =20 > > > > Shouldn't we say "The same source and destination IPv4=20 > addresses and UDP port numbers that were used to transmit the ..." > > > > Also, maybe a matter of taste but IMHO it would be more=20 > logic that the BU and BA are mentioned before the PBU and PBA. > > > > =20 > >> Revocation messages over IPv4 using UDP encapsulation. In other > >> words, the destination UDP port of the Binding=20 > Revocation Indication > >> message MUST be set to the source UDP port of the=20 > latest successfully > >> processed Proxy Binding Update or Binding Update=20 > message which is > >> already saved in the mobile node BCE. For more details=20 > on tunneling > >> Proxy Mobile IPv6 and Mobile IPv6 signaling messages=20 > over IPv4, see > >> [ID-PMIP6-IPv4] and [RFC5555], respectively. > >> =20 > > > > Here you're only covering the BRI sent by LMA to MAG, but=20 > you don't cover sending BRA, neither BRI being sent from MAG=20 > to LMA. Is this intentional? I think we ought to be complete...=20 > > > > And again, I think it's better to mention BU before PBU. > > > > Best, > > > > --julien > > > > > > =20 >=20 >=20 From AMUHANNA@nortel.com Thu Aug 13 01:09:24 2009 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 3BE253A67E9 for ; Thu, 13 Aug 2009 01:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, 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 tsWsGVZKWrZA for ; Thu, 13 Aug 2009 01:09:23 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 091233A68B4 for ; Thu, 13 Aug 2009 01:09:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7D71gG28551; Thu, 13 Aug 2009 07:01:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 01:57:50 -0500 Message-ID: In-Reply-To: <007d01ca1bca$e2dda240$40106f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) to Proposed Standard Thread-Index: AcobyzlBNp9HByiNQpK1xCv6yKauTQAGA/7Q References: <20090812155929.32DBC3A6BA6@core3.amsl.com> <007d01ca1bca$e2dda240$40106f0a@china.huawei.com> From: "Ahmad Muhanna" To: "Xiangsong Cui" Cc: mext@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) 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: Thu, 13 Aug 2009 08:09:24 -0000 Hi, Sure, we will clarify the text for the HA in the next revision. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Xiangsong Cui > Sent: Wednesday, August 12, 2009 11:03 PM > To: ietf@ietf.org; IETF-Announce > Cc: mext@ietf.org > Subject: Re: [MEXT] Last Call:=20 > draft-ietf-mext-binding-revocation (BindingRevocation for=20 > IPv6 Mobility) to Proposed Standard >=20 > Hi all, >=20 > Thank the authors for the good job and I have a minor comment. >=20 > In section 8.2 (the last paragraph), >=20 > o If the Status field indicates any value other than success, the > home agent SHOULD examine any mobility options included in the > Binding Revocation Acknowledgement. The home agent MAY log the > appropriate event to reflect the received status. >=20 > I think it is not very clear how should the home agent handle=20 > the BCE (e.g. the resource and revocation in progress flag)=20 > and the revocation timer (if there is some timer is running). >=20 > The corresponding part from LMA is better, I think. >=20 > It is based on the local mobility anchor local policy how to > handle the mobile node BCE(s) that the mobile access gateway > indicated it failed the revocation procedure, however,=20 > the LMA MAY > log the event. >=20 > Regards >=20 > Xiangsong >=20 >=20 > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: > Sent: Wednesday, August 12, 2009 11:59 PM > Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation > (BindingRevocation for IPv6 Mobility) to Proposed Standard >=20 >=20 > > The IESG has received a request from the Mobility=20 > EXTensions for IPv6=20 > > WG > > (mext) to consider the following document: > > > > - 'Binding Revocation for IPv6 Mobility ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > final comments on this action. Please send substantive comments to=20 > > the ietf@ietf.org mailing lists by 2009-08-26.=20 > Exceptionally, comments=20 > > may be sent to iesg@ietf.org instead. In either case, please retain=20 > > the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation > > -08.txt > > > > > > IESG discussion can be tracked via > >=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > > g=3D17614&rfc_flag=3D0 > > > > _______________________________________________ > > 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 From tony.cheneau@it-sudparis.eu Thu Aug 13 02:51:55 2009 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 71E4F3A6902 for ; Thu, 13 Aug 2009 02:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 g7AC6zNZ9K+o for ; Thu, 13 Aug 2009 02:51:54 -0700 (PDT) Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 4F50F3A680D for ; Thu, 13 Aug 2009 02:51:54 -0700 (PDT) Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 7009AFE2A74; Thu, 13 Aug 2009 11:49:16 +0200 (CEST) Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id 3641C404FB6; Thu, 13 Aug 2009 11:49:13 +0200 (CEST) Received: from [157.159.100.251] (unknown [157.159.100.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 808F990011; Thu, 13 Aug 2009 11:49:12 +0200 (CEST) Date: Thu, 13 Aug 2009 11:49:10 +0200 (CEST) From: Tony Cheneau X-X-Sender: shad@whitebox To: draft-ietf-mext-rfc3775bis@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner-ID: 3641C404FB6.A85B3 X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-4.399, requis 6.01, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu Cc: mext@ietf.org Subject: [MEXT] Typos in draft-ietf-mext-rfc3775bis-04 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, 13 Aug 2009 09:51:55 -0000 Hello dear RFC3775-bis authors, Since I'm new to this working group, I can not give any technical comments on the content of the document. However, while reading through the document, I've noted some typos, which are as follow: - section 6.1.8: the status field is the third item to be described. In the format, it is the first field. I think it should be moved to be the first item. - section 11.3.4, please remove the dot: " The application uses the care-of address as a source address for multicast traffic, just like it would use a stationary address. This requires that the application either knows the care-of address, or uses an API such as the IPv6 Socket API for Source Address Selection specification [24]. to request the stack to use ^ the care-of address as a source address in sent packets. The mobile node MUST NOT use Home Address destination option in such traffic. " - section 11.5.2 contains self reference: " o The MN performs the procedure described in Section 11.5.2x and ^^^^^^^ configures an address. It also keeps track of all the on-link prefix(es) received in the RA along with their prefix lengths. " - section 11.7.4: " When a mobile node receives a packet containing a Binding Refresh Request message, the mobile node has a Binding Update List entry for ^^ add "if" the source of the Binding Refresh Request, and the mobile node wants to retain its binding cache entry at the correspondent node, then the mobile node should start a return routability procedure." Hope it helps. Best regards, Tony Cheneau From julienl@qualcomm.com Thu Aug 13 11:27:22 2009 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 16F7D3A6D0C for ; Thu, 13 Aug 2009 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.767 X-Spam-Level: X-Spam-Status: No, score=-103.767 tagged_above=-999 required=5 tests=[AWL=-1.168, 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 So5zZhKp2QZX for ; Thu, 13 Aug 2009 11:27:21 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E85763A6CFE for ; Thu, 13 Aug 2009 11:27:20 -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=1250188045; x=1281724045; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Ahmad=20Muhanna=20,=20Jari=20 Arkko=20,=0D=0A=20=20=20=20=20=20 =20=20"draft-ietf-mext-binding-revocation@tools.ietf.org" =0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"mext@ietf.org"=0D=0A =09|Date:=20Thu,=2013=20Aug=202009=2011:26 :57=20-0700|Subject:=20RE:=20AD=20review=20of=20draft-iet f-metxt-binding-revocation|Thread-Topic:=20AD=20review=20 of=20draft-ietf-metxt-binding-revocation|Thread-Index:=20 AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUAN34jEwACRM+YAABpAPoAAhY2YQ |Message-ID:=20|References:=20<4A6B12F2.50 60608@piuha.net>=0D=0A=20=0D=0A=20=0D=0A=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-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5708"=3B=20a=3D"22079777"; bh=muQafalv3FPjIA7+O4CP+o6fydazbJbxNZYhkhk9s4c=; b=OEfxA3G3UG8JDeEg3RXrgAwn5pVBHmJFjcu2atW/FhBn2CErCukzvIFf jg1dhD5+OqbgPhhRyxgrq1NzbHSPcPgB/S6TiubcyX2k1bK4ZSMupLBeb rRGbzIt/QXMSW3gXocVthhBDQK+xkCoKScO0SL+HAsXqFEw3czvq5FfTq M=; X-IronPort-AV: E=McAfee;i="5300,2777,5708"; a="22079777" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Aug 2009 11:27:12 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7DIRBgR017093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2009 11:27:12 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7DIQxh4025642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Aug 2009 11:27:05 -0700 (PDT) Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 13 Aug 2009 11:27:00 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Thu, 13 Aug 2009 11:26:59 -0700 From: "Laganier, Julien" To: Ahmad Muhanna , Jari Arkko , "draft-ietf-mext-binding-revocation@tools.ietf.org" , "mext@ietf.org" Date: Thu, 13 Aug 2009 11:26:57 -0700 Thread-Topic: AD review of draft-ietf-metxt-binding-revocation Thread-Index: AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUAN34jEwACRM+YAABpAPoAAhY2YQ Message-ID: References: <4A6B12F2.5060608@piuha.net> 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 Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 13 Aug 2009 18:27:22 -0000 Hello Ahmad, Pls. see below. [...] > In the first sentence we used Binding Revocation messages to avoid > mentioning BRI and BRA separately in order to optimize the text. > However, when the BRI was mentioned, we should have said, for example. > The idea here is just to clarify the first sentence. So what about the > following: >=20 > If the Proxy Binding Update and Proxy Binding Acknowledgment messages > or the Binding Update and Binding Acknowledgement messages are sent > using UDP encapsulation to traverse NATs, then the Binding Revocation > messages are sent using the same UDP encapsulation. The same UDP > port, source IPv4 address, and destination IPv4 address that were > used for exchanging the Proxy Binding Update and Proxy Binding > Acknowledgement or the Binding Update and Binding Acknowledgement > messages will also be used when transporting Binding Revocation > messages over IPv4 using UDP encapsulation. In other words, e.g., > the destination UDP port, the destination IPv4 address, and the > source IPv4 address of the Binding Revocation Indication message MUST > be set to the source UDP port, source IPv4 address, and destination > IPv4 address of the latest successfully processed Proxy Binding > Update or Binding Update message, respectively. For more details on > tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over > IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively. I still feel you're missing the source port in the above, aren't you? I mod= ified a bit your text below: If the Proxy Binding Update and Proxy Binding Acknowledgment messages or the Binding Update and Binding Acknowledgement messages are sent using UDP encapsulation to traverse NATs, then the Binding Revocation messages are sent using the same UDP encapsulation. The same UDP sourc= e=20 and destination port numbers and IPv4 addresses used for exchanging the Proxy Binding Update and Proxy Binding Acknowledgement or the Binding Update and Binding Acknowledgement messages will also be used when transporting Binding Revocation messages over IPv4 using UDP encapsulation. For example, the source UD= P port number, the destination UDP port number, the source IPv4 address,= =20 and the destination IPv4 address of the Binding Revocation Indication message MUST be set to the destination UDP port number, the source UDP port number, destination IPv4 address, and source IPv4 address of the latest successfully processed Proxy Binding Update or Binding Update message received, respectively. For more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see=20 [ID-PMIP6-IPv4] and [RFC5555], respectively. What do you think? --julien From AMUHANNA@nortel.com Thu Aug 13 12:04:37 2009 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 A68063A6D07 for ; Thu, 13 Aug 2009 12:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, 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 M8QYbKxc1DP2 for ; Thu, 13 Aug 2009 12:04:36 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 922DB3A6D34 for ; Thu, 13 Aug 2009 12:04:36 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7DJ4HJ15189; Thu, 13 Aug 2009 19:04:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 14:04:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-metxt-binding-revocation Thread-Index: AcoNMhHuc+0Jj6pfTVWGg8ESLlhuUAN34jEwACRM+YAABpAPoAAhY2YQAAGE0DA= References: <4A6B12F2.5060608@piuha.net> From: "Ahmad Muhanna" To: "Laganier, Julien" , "Jari Arkko" , , Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation 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, 13 Aug 2009 19:04:37 -0000 Hi Julien, > -----Original Message----- > Subject: RE: AD review of draft-ietf-metxt-binding-revocation >=20 > Hello Ahmad, >=20 > Pls. see below. >=20 > [...] > > In the first sentence we used Binding Revocation messages to avoid=20 > > mentioning BRI and BRA separately in order to optimize the text. > > However, when the BRI was mentioned, we should have said,=20 > for example. > > The idea here is just to clarify the first sentence. So=20 > what about the > > following: > >=20 > > If the Proxy Binding Update and Proxy Binding=20 > Acknowledgment messages > > or the Binding Update and Binding Acknowledgement=20 > messages are sent > > using UDP encapsulation to traverse NATs, then the=20 > Binding Revocation > > messages are sent using the same UDP encapsulation. The same UDP > > port, source IPv4 address, and destination IPv4 address that were > > used for exchanging the Proxy Binding Update and Proxy Binding > > Acknowledgement or the Binding Update and Binding Acknowledgement > > messages will also be used when transporting Binding Revocation > > messages over IPv4 using UDP encapsulation. In other=20 > words, e.g., > > the destination UDP port, the destination IPv4 address, and the > > source IPv4 address of the Binding Revocation Indication=20 > message MUST > > be set to the source UDP port, source IPv4 address, and=20 > destination > > IPv4 address of the latest successfully processed Proxy Binding > > Update or Binding Update message, respectively. For=20 > more details on > > tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling=20 > messages over > > IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively. >=20 > I still feel you're missing the source port in the above,=20 > aren't you? I modified a bit your text below: >=20 > If the Proxy Binding Update and Proxy Binding=20 > Acknowledgment messages > or the Binding Update and Binding Acknowledgement=20 > messages are sent > using UDP encapsulation to traverse NATs, then the=20 > Binding Revocation > messages are sent using the same UDP encapsulation. The=20 > same UDP source=20 > and destination port numbers and IPv4 addresses used for=20 > exchanging > the Proxy Binding Update and Proxy Binding > Acknowledgement or the Binding Update and Binding Acknowledgement > messages will also be used when transporting Binding Revocation > messages over IPv4 using UDP encapsulation. For example,=20 > the source UDP > port number, the destination UDP port number, the source=20 > IPv4 address,=20 > and the destination IPv4 address of the Binding=20 > Revocation Indication > message MUST be set to the destination UDP port number,=20 > the source UDP > port number, destination IPv4 address, and source IPv4=20 > address of the > latest successfully processed Proxy Binding Update or=20 > Binding Update > message received, respectively. For more details on=20 > tunneling Proxy > Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see=20 > [ID-PMIP6-IPv4] and [RFC5555], respectively. >=20 > What do you think? [Ahmad] Perfect. Thanks! >=20 > --julien >=20 From Xiangsong.Cui@huawei.com Thu Aug 13 20:10:46 2009 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 3CAE13A6955 for ; Thu, 13 Aug 2009 20:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, STOX_REPLY_TYPE=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 n2g+xPmLGMoR for ; Thu, 13 Aug 2009 20:10:43 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F282D3A6881 for ; Thu, 13 Aug 2009 20:10:42 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOC0035YJ6714@szxga02-in.huawei.com> for mext@ietf.org; Fri, 14 Aug 2009 11:03:43 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOC003YZJ661H@szxga02-in.huawei.com> for mext@ietf.org; Fri, 14 Aug 2009 11:03:43 +0800 (CST) Date: Fri, 14 Aug 2009 11:03:42 +0800 From: Xiangsong Cui To: Ahmad Muhanna Message-id: <00b701ca1c8b$d4e01e90$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20090812155929.32DBC3A6BA6@core3.amsl.com> <007d01ca1bca$e2dda240$40106f0a@china.huawei.com> Cc: mext@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) 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: Fri, 14 Aug 2009 03:10:46 -0000 Hi, There is an editorial issue in the author list, both the head and the end. I think "Startent Networks"should be "Starent Networks", right? Regards Xiangsong ----- Original Message ----- From: "Ahmad Muhanna" To: "Xiangsong Cui" Cc: Sent: Thursday, August 13, 2009 2:57 PM Subject: RE: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) to Proposed Standard Hi, Sure, we will clarify the text for the HA in the next revision. Thanks. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Xiangsong Cui > Sent: Wednesday, August 12, 2009 11:03 PM > To: ietf@ietf.org; IETF-Announce > Cc: mext@ietf.org > Subject: Re: [MEXT] Last Call: > draft-ietf-mext-binding-revocation (BindingRevocation for > IPv6 Mobility) to Proposed Standard > > Hi all, > > Thank the authors for the good job and I have a minor comment. > > In section 8.2 (the last paragraph), > > o If the Status field indicates any value other than success, the > home agent SHOULD examine any mobility options included in the > Binding Revocation Acknowledgement. The home agent MAY log the > appropriate event to reflect the received status. > > I think it is not very clear how should the home agent handle > the BCE (e.g. the resource and revocation in progress flag) > and the revocation timer (if there is some timer is running). > > The corresponding part from LMA is better, I think. > > It is based on the local mobility anchor local policy how to > handle the mobile node BCE(s) that the mobile access gateway > indicated it failed the revocation procedure, however, > the LMA MAY > log the event. > > Regards > > Xiangsong > > > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: > Sent: Wednesday, August 12, 2009 11:59 PM > Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation > (BindingRevocation for IPv6 Mobility) to Proposed Standard > > > > The IESG has received a request from the Mobility > EXTensions for IPv6 > > WG > > (mext) to consider the following document: > > > > - 'Binding Revocation for IPv6 Mobility ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive comments to > > the ietf@ietf.org mailing lists by 2009-08-26. > Exceptionally, comments > > may be sent to iesg@ietf.org instead. In either case, please retain > > the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation > > -08.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa > > g=17614&rfc_flag=0 > > > > _______________________________________________ > > 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 Dirk.von-Hugo@telekom.de Fri Aug 14 07:50:22 2009 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 356A43A6BE9 for ; Fri, 14 Aug 2009 07:50:22 -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 J0V7VmMNeor8 for ; Fri, 14 Aug 2009 07:50:21 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 7E39C3A6BD0 for ; Fri, 14 Aug 2009 07:50:19 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 14 Aug 2009 16:50:14 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 16:50:14 +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, 14 Aug 2009 16:50:11 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848013F439D@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <00b701ca1c8b$d4e01e90$40106f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) to Proposed Standard Thread-Index: AcocjOHg2fp8tUnTTDG8smUe5ryHjQAKgAig References: <20090812155929.32DBC3A6BA6@core3.amsl.com><007d01ca1bca$e2dda240$40106f0a@china.huawei.com> <00b701ca1c8b$d4e01e90$40106f0a@china.huawei.com> From: To: X-OriginalArrivalTime: 14 Aug 2009 14:50:14.0678 (UTC) FILETIME=[883A0B60:01CA1CEE] Cc: Xiangsong.Cui@huawei.com, mext@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) 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: Fri, 14 Aug 2009 14:50:22 -0000 Dear Ahmad, I also have only some formal remarks for the text:=20 On page 6: (G) is used without defining it before as Global bit, so I would suggest message with the Global (G) and (A) bits set Page 12: Another case is when a mobile node which support_s_ client mobile IPv6 roam_s_ to an access network If the Proxy Binding Update and Proxy Binding _Acknowledgement_ messages Page 28: Shouldn't it say o If the Status field indicates that the BRI was processed successfully, the local mobility anchor MUST delete the current = timer Instead of=20 o If the Status field indicates that the BRI was processed successfully, the local mobility anchor deletes the current timer Page 29, 31: =3D> I suggest to stick to a single expression throughout the draft: = either Acknowledge (A) bit or Acknowledgement (A) bit Page 30: When the local mobility anchor receive_s a valid Binding Revocation o In the case that one of the bindings identified in the received Binding Revocation Indication message has already been released before receiving the it,=20 =3D> delete _the_ after _receiving_ age 32: access gateway use_s the mobility ... Include (Binding Update List) after using acronym BUL (that's what it = stands for, right?) Page 33: When the mobile access gateway receive_s_ a valid Page 34: o The Acknowledge (A) bit MUST be set in the to request the local =3D> deleter either _in the_ or add _messsage_ after _in the_ The Alternate Care-of Address option(s) contain the proxy Care-of address(es) which their bindings are being impacted by this Binding Revocation Indication message. =3D> Do you mean ... the proxy Care-of address(es) the bindings of which = are ... ? Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von = Xiangsong Cui Gesendet: Freitag, 14. August 2009 05:04 An: Ahmad Muhanna Cc: mext@ietf.org Betreff: Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation = (BindingRevocation for IPv6 Mobility) to Proposed Standard Hi, There is an editorial issue in the author list, both the head and the = end. I think "Startent Networks"should be "Starent Networks", right? Regards Xiangsong ----- Original Message -----=20 From: "Ahmad Muhanna" To: "Xiangsong Cui" Cc: Sent: Thursday, August 13, 2009 2:57 PM Subject: RE: [MEXT] Last Call: draft-ietf-mext-binding-revocation=20 (BindingRevocation for IPv6 Mobility) to Proposed Standard Hi, Sure, we will clarify the text for the HA in the next revision. Thanks. Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Xiangsong Cui > Sent: Wednesday, August 12, 2009 11:03 PM > To: ietf@ietf.org; IETF-Announce > Cc: mext@ietf.org > Subject: Re: [MEXT] Last Call: > draft-ietf-mext-binding-revocation (BindingRevocation for > IPv6 Mobility) to Proposed Standard > > Hi all, > > Thank the authors for the good job and I have a minor comment. > > In section 8.2 (the last paragraph), > > o If the Status field indicates any value other than success, the > home agent SHOULD examine any mobility options included in the > Binding Revocation Acknowledgement. The home agent MAY log the > appropriate event to reflect the received status. > > I think it is not very clear how should the home agent handle > the BCE (e.g. the resource and revocation in progress flag) > and the revocation timer (if there is some timer is running). > > The corresponding part from LMA is better, I think. > > It is based on the local mobility anchor local policy how to > handle the mobile node BCE(s) that the mobile access gateway > indicated it failed the revocation procedure, however, > the LMA MAY > log the event. > > Regards > > Xiangsong > > > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: > Sent: Wednesday, August 12, 2009 11:59 PM > Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation > (BindingRevocation for IPv6 Mobility) to Proposed Standard > > > > The IESG has received a request from the Mobility > EXTensions for IPv6 > > WG > > (mext) to consider the following document: > > > > - 'Binding Revocation for IPv6 Mobility ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive comments to > > the ietf@ietf.org mailing lists by 2009-08-26. > Exceptionally, comments > > may be sent to iesg@ietf.org instead. In either case, please retain > > the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation > > -08.txt > > > > > > IESG discussion can be tracked via > > > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > > g=3D17614&rfc_flag=3D0 > > > > _______________________________________________ > > 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 AMUHANNA@nortel.com Fri Aug 14 09:55:53 2009 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 AE25828C1C3 for ; Fri, 14 Aug 2009 09:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 K4PXnCoby+Z5 for ; Fri, 14 Aug 2009 09:55:52 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 78B9A3A6830 for ; Fri, 14 Aug 2009 09:55:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7EGtq213018; Fri, 14 Aug 2009 16:55:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 11:55:46 -0500 Message-ID: In-Reply-To: <00b701ca1c8b$d4e01e90$40106f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) to Proposed Standard Thread-Index: AcocjNVUrZCthDEFRwexzdzHvxWveQAczVDA References: <20090812155929.32DBC3A6BA6@core3.amsl.com> <007d01ca1bca$e2dda240$40106f0a@china.huawei.com> <00b701ca1c8b$d4e01e90$40106f0a@china.huawei.com> From: "Ahmad Muhanna" To: "Xiangsong Cui" Cc: mext@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) 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: Fri, 14 Aug 2009 16:55:53 -0000 Thanks. Will fix it. Regards, Ahmad =20 > -----Original Message----- > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com]=20 > Sent: Thursday, August 13, 2009 10:04 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: Re: [MEXT] Last Call:=20 > draft-ietf-mext-binding-revocation (BindingRevocation for=20 > IPv6 Mobility) to Proposed Standard >=20 > Hi, >=20 > There is an editorial issue in the author list, both the head=20 > and the end. > I think "Startent Networks"should be "Starent Networks", right? >=20 > Regards > Xiangsong >=20 >=20 > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Xiangsong Cui" > Cc: > Sent: Thursday, August 13, 2009 2:57 PM > Subject: RE: [MEXT] Last Call: draft-ietf-mext-binding-revocation > (BindingRevocation for IPv6 Mobility) to Proposed Standard >=20 >=20 > Hi, > Sure, we will clarify the text for the HA in the next revision. >=20 > Thanks. >=20 > Regards, > Ahmad >=20 >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > On Behalf=20 > > Of Xiangsong Cui > > Sent: Wednesday, August 12, 2009 11:03 PM > > To: ietf@ietf.org; IETF-Announce > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Last Call: > > draft-ietf-mext-binding-revocation (BindingRevocation for > > IPv6 Mobility) to Proposed Standard > > > > Hi all, > > > > Thank the authors for the good job and I have a minor comment. > > > > In section 8.2 (the last paragraph), > > > > o If the Status field indicates any value other than=20 > success, the > > home agent SHOULD examine any mobility options included in the > > Binding Revocation Acknowledgement. The home agent=20 > MAY log the > > appropriate event to reflect the received status. > > > > I think it is not very clear how should the home agent=20 > handle the BCE=20 > > (e.g. the resource and revocation in progress flag) and the=20 > revocation=20 > > timer (if there is some timer is running). > > > > The corresponding part from LMA is better, I think. > > > > It is based on the local mobility anchor local policy how to > > handle the mobile node BCE(s) that the mobile access gateway > > indicated it failed the revocation procedure,=20 > however, the LMA=20 > > MAY > > log the event. > > > > Regards > > > > Xiangsong > > > > > > ----- Original Message ----- > > From: "The IESG" > > To: "IETF-Announce" > > Cc: > > Sent: Wednesday, August 12, 2009 11:59 PM > > Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation > > (BindingRevocation for IPv6 Mobility) to Proposed Standard > > > > > > > The IESG has received a request from the Mobility > > EXTensions for IPv6 > > > WG > > > (mext) to consider the following document: > > > > > > - 'Binding Revocation for IPv6 Mobility ' > > > as a=20 > Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, > > and solicits > > > final comments on this action. Please send substantive=20 > comments to=20 > > > the ietf@ietf.org mailing lists by 2009-08-26. > > Exceptionally, comments > > > may be sent to iesg@ietf.org instead. In either case,=20 > please retain=20 > > > the beginning of the Subject line to allow automated sorting. > > > > > > The file can be obtained via > > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation > > > -08.txt > > > > > > > > > IESG discussion can be tracked via > > > > >=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > > > g=3D17614&rfc_flag=3D0 > > > > > > _______________________________________________ > > > 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 >=20 >=20 From AMUHANNA@nortel.com Fri Aug 14 11:23:09 2009 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 BDC5D3A6B24 for ; Fri, 14 Aug 2009 11:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 UlbsPiU9ROZ6 for ; Fri, 14 Aug 2009 11:23:08 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6C9043A6B46 for ; Fri, 14 Aug 2009 11:23:08 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7EIKc908154; Fri, 14 Aug 2009 18:20:38 GMT 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, 14 Aug 2009 13:22:21 -0500 Message-ID: In-Reply-To: <643B0A1D1A13AB498304E0BBC8027848013F439D@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) to Proposed Standard Thread-Index: AcocjOHg2fp8tUnTTDG8smUe5ryHjQAKgAigABRjafA= References: <20090812155929.32DBC3A6BA6@core3.amsl.com><007d01ca1bca$e2dda240$40106f0a@china.huawei.com> <00b701ca1c8b$d4e01e90$40106f0a@china.huawei.com> <643B0A1D1A13AB498304E0BBC8027848013F439D@S4DE8PSAAQC.mitte.t-com.de> From: "Ahmad Muhanna" To: Cc: Xiangsong.Cui@huawei.com, mext@ietf.org Subject: Re: [MEXT] Last Call: draft-ietf-mext-binding-revocation (BindingRevocation for IPv6 Mobility) 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: Fri, 14 Aug 2009 18:23:09 -0000 Hello Dirk, Thanks for the comments, please see inline. Regards, Ahmad =20 > -----Original Message----- > From: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de]=20 > Sent: Friday, August 14, 2009 9:50 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org; Xiangsong.Cui@huawei.com > Subject: AW: [MEXT] Last Call:=20 > draft-ietf-mext-binding-revocation (BindingRevocation for=20 > IPv6 Mobility) to Proposed Standard >=20 > Dear Ahmad, >=20 > I also have only some formal remarks for the text:=20 > On page 6: > (G) is used without defining it before as Global bit, so I=20 > would suggest message with the Global (G) and (A) bits set [Ahmad] Thanks for catching this. Will fix it. >=20 > Page 12: > Another case is when a mobile node which support_s_ client=20 > mobile IPv6 roam_s_ to an access network [Ahmad] Ok. >=20 > If the Proxy Binding Update and Proxy Binding=20 > _Acknowledgement_ messages > [Ahmad] Ok. =20 > Page 28: > Shouldn't it say > o If the Status field indicates that the BRI was processed > successfully, the local mobility anchor MUST delete the=20 > current timer Instead of o If the Status field indicates=20 > that the BRI was processed > successfully, the local mobility anchor deletes the=20 > current timer > [Ahmad] Ok. =20 > Page 29, 31: > =3D> I suggest to stick to a single expression throughout the=20 > draft: either Acknowledge (A) bit or Acknowledgement (A) bit [Ahmad] Agree. This is a typo. Will use Acknowledge throughout the doc. >=20 > Page 30: > When the local mobility anchor receive_s a valid Binding Revocation >=20 > o In the case that one of the bindings identified in the received > Binding Revocation Indication message has already been released > before receiving the it, > =3D> delete _the_ after _receiving_ [Ahmad] Ok. >=20 > age 32: > access gateway use_s the mobility ... [Ahmad] Ok. >=20 > Include (Binding Update List) after using acronym BUL (that's=20 > what it stands for, right?) [Ahmad] It should be mentioned the first time BUL appears in the document. Will = make sure that is the case. >=20 > Page 33: > When the mobile access gateway receive_s_ a valid [Ahmad] Ok. >=20 > Page 34: >=20 > o The Acknowledge (A) bit MUST be set in the to request=20 > the local =3D> deleter either _in the_ or add _messsage_ after _in = the_ >=20 [Ahmad] Ok. > The Alternate Care-of=20 > Address option(s) > contain the proxy Care-of address(es) which their bindings are > being impacted by this Binding Revocation Indication message. >=20 > =3D> Do you mean ... the proxy Care-of address(es) the bindings=20 > of which are ... ? [Ahmad] Yeh. That is probably clearer. Thanks again! Ahmad >=20 >=20 > Best regards > Dirk > -----Urspr=FCngliche Nachricht----- > Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im=20 > Auftrag von Xiangsong Cui > Gesendet: Freitag, 14. August 2009 05:04 > An: Ahmad Muhanna > Cc: mext@ietf.org > Betreff: Re: [MEXT] Last Call:=20 > draft-ietf-mext-binding-revocation (BindingRevocation for=20 > IPv6 Mobility) to Proposed Standard >=20 > Hi, >=20 > There is an editorial issue in the author list, both the head=20 > and the end. > I think "Startent Networks"should be "Starent Networks", right? >=20 > Regards > Xiangsong >=20 >=20 > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Xiangsong Cui" > Cc: > Sent: Thursday, August 13, 2009 2:57 PM > Subject: RE: [MEXT] Last Call: draft-ietf-mext-binding-revocation > (BindingRevocation for IPv6 Mobility) to Proposed Standard >=20 >=20 > Hi, > Sure, we will clarify the text for the HA in the next revision. >=20 > Thanks. >=20 > Regards, > Ahmad >=20 >=20 > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]=20 > On Behalf=20 > > Of Xiangsong Cui > > Sent: Wednesday, August 12, 2009 11:03 PM > > To: ietf@ietf.org; IETF-Announce > > Cc: mext@ietf.org > > Subject: Re: [MEXT] Last Call: > > draft-ietf-mext-binding-revocation (BindingRevocation for > > IPv6 Mobility) to Proposed Standard > > > > Hi all, > > > > Thank the authors for the good job and I have a minor comment. > > > > In section 8.2 (the last paragraph), > > > > o If the Status field indicates any value other than=20 > success, the > > home agent SHOULD examine any mobility options included in the > > Binding Revocation Acknowledgement. The home agent=20 > MAY log the > > appropriate event to reflect the received status. > > > > I think it is not very clear how should the home agent=20 > handle the BCE=20 > > (e.g. the resource and revocation in progress flag) and the=20 > revocation=20 > > timer (if there is some timer is running). > > > > The corresponding part from LMA is better, I think. > > > > It is based on the local mobility anchor local policy how to > > handle the mobile node BCE(s) that the mobile access gateway > > indicated it failed the revocation procedure,=20 > however, the LMA=20 > > MAY > > log the event. > > > > Regards > > > > Xiangsong > > > > > > ----- Original Message ----- > > From: "The IESG" > > To: "IETF-Announce" > > Cc: > > Sent: Wednesday, August 12, 2009 11:59 PM > > Subject: [MEXT] Last Call: draft-ietf-mext-binding-revocation > > (BindingRevocation for IPv6 Mobility) to Proposed Standard > > > > > > > The IESG has received a request from the Mobility > > EXTensions for IPv6 > > > WG > > > (mext) to consider the following document: > > > > > > - 'Binding Revocation for IPv6 Mobility ' > > > as a=20 > Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, > > and solicits > > > final comments on this action. Please send substantive=20 > comments to=20 > > > the ietf@ietf.org mailing lists by 2009-08-26. > > Exceptionally, comments > > > may be sent to iesg@ietf.org instead. In either case,=20 > please retain=20 > > > the beginning of the Subject line to allow automated sorting. > > > > > > The file can be obtained via > > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation > > > -08.txt > > > > > > > > > IESG discussion can be tracked via > > > > >=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > > > g=3D17614&rfc_flag=3D0 > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From vijay@wichorus.com Fri Aug 14 11:57:20 2009 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 ACB8E28C1BE for ; Fri, 14 Aug 2009 11:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, 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 6obpqE3CK23t for ; Fri, 14 Aug 2009 11:57:19 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id B9BF83A6D27 for ; Fri, 14 Aug 2009 11:57:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Aug 2009 14:57:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis Thread-Index: AcoV4C/MITZ832VfQMeSZMhEKAB5+QHL5X4A References: From: "Vijay Devarapalli" To: "Laganier, Julien" , Cc: "Charles E. Perkins" Subject: Re: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis 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, 14 Aug 2009 18:57:20 -0000 I reviewed the document. It is ready to be sent to the IESG.=20 I have a couple of minor comments. There are a few instances of "Section Section" in the document. I saw them in sections 10.3.2, 11.3.6 and 11.5.2. The following needs a re-write.=20 Binding Error The Binding Error is used by the correspondent node or the home agent to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding, or when an unrecognized Mobility Header is received. The HA sends a binding error to the mobile node only when it sees an unrecognized Mobility Header Type. So I suggest re-writing it as Binding Error The Binding Error is used by the correspondent node to signal an=20 error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding.=20 The Binding Error message is also used by the Home Agent to signal an error to the mobile node, when it receives an unrecognized=20 Mobility Header Message Type from the mobile node. Vijay > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Laganier, Julien > Sent: Wednesday, August 05, 2009 8:20 AM > To: mext@ietf.org > Subject: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis >=20 > Folks, >=20 > As discussed during the MEXT session in IETF-75 we're issuing=20 > a two weeks WGLC on RFC 3775 bis=20 > =20 > that will follow the two rules below: >=20 > - this WGLC is NOT intended for re-opening discussions on=20 > issues that were resolved during the revision process neither=20 > for bringing up new issues.=20 >=20 > - this WGLC is intended to be sanity check to see whether the=20 > various changes we agreed to made fit together. Editorial=20 > corrections are also welcome. >=20 > Please review the specification and post a message to the=20 > mailing list if you think the document is ready to be=20 > forwarded to IESG before 2009-08-15 6:00PM PST. >=20 > Thank you for your support. >=20 > --julien & Marcelo, MEXT chairs >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From root@core3.amsl.com Fri Aug 14 23:30:02 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 22A533A68F3; Fri, 14 Aug 2009 23: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: <20090815063002.22A533A68F3@core3.amsl.com> Date: Fri, 14 Aug 2009 23:30:02 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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: Sat, 15 Aug 2009 06:30: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 : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-09.txt Pages : 42 Date : 2009-08-14 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-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-binding-revocation-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-14232523.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Aug 15 00:15:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 524943A6855; Sat, 15 Aug 2009 00:15: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: <20090815071501.524943A6855@core3.amsl.com> Date: Sat, 15 Aug 2009 00:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-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: Sat, 15 Aug 2009 07:15:01 -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 : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-10.txt Pages : 42 Date : 2009-08-15 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-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-binding-revocation-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-15000317.I-D@ietf.org> --NextPart-- From AMUHANNA@nortel.com Sun Aug 16 22:00:21 2009 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 4393C3A685D for ; Sun, 16 Aug 2009 22:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, 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 CBVvKGUYDLXS for ; Sun, 16 Aug 2009 22:00:20 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C4FF53A6910 for ; Sun, 16 Aug 2009 22:00:19 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7H50I525778; Mon, 17 Aug 2009 05:00:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA1EF7.9BAC68DD" Date: Mon, 17 Aug 2009 00:00:14 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-mext-binding-revocation-10.txt Thread-Index: AcodeDrGMFpUw9WCQ36JOqfjVV61bwBfxZ5Q From: "Ahmad Muhanna" To: Cc: Jari Arkko Subject: [MEXT] FW: I-D Action:draft-ietf-mext-binding-revocation-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: Mon, 17 Aug 2009 05:00:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1EF7.9BAC68DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello Folks, Revision 10 addresses all the comments that we have received thus far. Please let us know if we missed anything.=20 Thanks. Regards, Ahmad -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Saturday, August 15, 2009 2:15 AM To: i-d-announce@ietf.org Cc: mext@ietf.org Subject: I-D Action:draft-ietf-mext-binding-revocation-10.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. Title : Binding Revocation for IPv6 Mobility Author(s) : A. Muhanna, et al. Filename : draft-ietf-mext-binding-revocation-10.txt Pages : 42 Date : 2009-08-15 This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1 0.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_001_01CA1EF7.9BAC68DD Content-Type: application/octet-stream; name="draft-ietf-mext-binding-revocation-10.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-mext-binding-revocation-10.URL Content-Disposition: attachment; filename="draft-ietf-mext-binding-revocation-10.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW1leHQtYmluZGluZy1yZXZvY2F0aW9uLTEwLnR4dA0K ------_=_NextPart_001_01CA1EF7.9BAC68DD Content-Type: text/plain; name="ATT1306797.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1306797.txt Content-Disposition: attachment; filename="ATT1306797.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CA1EF7.9BAC68DD-- From AMUHANNA@nortel.com Wed Aug 19 01:40:32 2009 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 31C7028C0EE; Wed, 19 Aug 2009 01:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TiV6wx0Vkbmp; Wed, 19 Aug 2009 01:40:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4663328C0E7; Wed, 19 Aug 2009 01:40:29 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7J83T112298; Wed, 19 Aug 2009 08:03:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA20A3.70BD2B6C" Date: Wed, 19 Aug 2009 03:02:46 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-mext-binding-revocation-08 Thread-Index: AcogdR0xJy2LCQ5HS+uE7oGHz4adKgAI+0vgAAB5pUA= From: "Ahmad Muhanna" To: , Subject: [MEXT] FW: Comments on draft-ietf-mext-binding-revocation-08 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, 19 Aug 2009 08:40:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA20A3.70BD2B6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable copying the lists. Regards,=20 Ahmad=20 ________________________________ From: Muhanna, Ahmad (RICH1:2H10)=20 Sent: Wednesday, August 19, 2009 1:57 AM To: Tina TSOU; ops-dir@ietf.org Cc: draft-ietf-mext-binding-revocation@tools.ietf.org Subject: RE: Comments on draft-ietf-mext-binding-revocation-08 Hello Tina, =20 Initially the NEMO case was part of the Binding Revocation presentations that were made in, at least, two IETF meetings. However, based on further discussion on the MEXT/Netlmm mailing lists, the wg failed to find a use for Binding Revocation in the case of NEMO for the following reasons: =20 1. The MNP is allocated via a mechanism other than the BU/BA signaling. In other words, DHCP could be an option. Therefore, the argument was made that there is no justification for the home agent to send a Binding Revocation Indication message in order to revoke a specific MNP. =20 2. On the other hand, at any time the MR would like to revoke a specific MNP binding to its home address, the MR can send a BU with the remaining MNPs that still valid and the home agent will update the MR BCE accordingly. In addition, the MR can send a de-registration to de-register all MNPs is a single message. =20 3. In the case that BU/BA is used for allocating MNP(s) to a specific MR with a specific HoA, then Binding Revocation makes sense, but, at the time of discussing this issue that mechanism for MNP allocation was NOT available or standardized. =20 I hope this addresses your concern. Regards,=20 Ahmad=20 =20 ________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Tuesday, August 18, 2009 9:31 PM To: ops-dir@ietf.org Cc: draft-ietf-mext-binding-revocation@tools.ietf.org Subject: Comments on draft-ietf-mext-binding-revocation-08 =09 =09 Hi, I think it is good shaped and can be moved forward except the NEMO case.=20 =20 As the draft describes "These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. ..." =20 As we know, the NEMO can be one of Mobile IPv6 extensions. However, I don't see any note about it. Therefore, I wonder if the draft is also applied for the NEMO case (RFC3963).=20 =09 =20 =20 B. R. Tina http://tinatsou.weebly.com/contact.html =09 =20 ------_=_NextPart_001_01CA20A3.70BD2B6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
copying the lists.

Regards, =
Ahmad=20

From: Muhanna, Ahmad (RICH1:2H10)=20
Sent: Wednesday, August 19, 2009 1:57 AM
To: Tina = TSOU;=20 ops-dir@ietf.org
Cc:=20 draft-ietf-mext-binding-revocation@tools.ietf.org
Subject: RE: = Comments on draft-ietf-mext-binding-revocation-08

Hello Tina,
 
Initially the NEMO case was part of the Binding = Revocation=20 presentations that were made in, at least, two IETF meetings. However, = based on=20 further discussion on the MEXT/Netlmm mailing lists, the wg failed to = find a use=20 for Binding Revocation in the case of NEMO for the following=20 reasons:
 
1. The MNP is allocated via a mechanism other = than the=20 BU/BA signaling. In other words, DHCP could be an option. Therefore, the = argument was made that there is no justification for the home agent to = send a=20 Binding Revocation Indication message in order to revoke a specific=20 MNP.
 
2. On the other hand, at any time the MR would = like to=20 revoke a specific MNP binding to its home address, the MR can send a BU = with the=20 remaining MNPs that still valid and the home agent will update the MR = BCE=20 accordingly. In addition, the MR can send a de-registration to = de-register all=20 MNPs is a single message.
 
3. In the case that BU/BA is used for = allocating MNP(s) to=20 a specific MR with a specific HoA, then Binding Revocation makes sense, = but, at=20 the time of discussing this issue that mechanism for MNP allocation was = NOT=20 available or standardized.
 
I hope this addresses your = concern.

Regards, =
Ahmad

 

From: Tina TSOU = [mailto:tena@huawei.com]=20
Sent: Tuesday, August 18, 2009 9:31 PM
To:=20 ops-dir@ietf.org
Cc:=20 draft-ietf-mext-binding-revocation@tools.ietf.org
Subject: = Comments=20 on draft-ietf-mext-binding-revocation-08

Hi,
I think it is good shaped and = can be moved=20 forward except the NEMO case.
 
As the draft describes "These = semantics are=20 generic enough and can be used by mobility entities in the case of = Mobile IPv6=20 and its extensions. ..."
 
As we know, the NEMO can be one of = Mobile IPv6=20 extensions. However, I don't see any note about it. Therefore, I = wonder=20 if the draft is also applied for the NEMO case (RFC3963). =
 
 
B. R.
Tina
http://tinatsou.weebly.c= om/contact.html

 
------_=_NextPart_001_01CA20A3.70BD2B6C-- From AMUHANNA@nortel.com Wed Aug 19 02:50:34 2009 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 B69C13A6C8F; Wed, 19 Aug 2009 02:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k0wFAUiWezfB; Wed, 19 Aug 2009 02:50:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0F72A3A6889; Wed, 19 Aug 2009 02:50:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7J9oB104932; Wed, 19 Aug 2009 09:50:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA20B1.45154FFE" Date: Wed, 19 Aug 2009 04:41:46 -0500 Message-ID: In-Reply-To: <01f001ca20ac$baa0e210$8e27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEMO support in Binding Revocation draft Thread-Index: AcogrTJ+Ju2Ohc/sTtu6mJ65btzIFAAAgTCg References: <017501ca1fd7$fccd1990$8e27460a@china.huawei.com> <61A1D127-DE20-4A4B-9F84-74E0851B6BB7@cisco.com> <00bc01ca2075$0e9bbb70$8e27460a@china.huawei.com> <01f001ca20ac$baa0e210$8e27460a@china.huawei.com> From: "Ahmad Muhanna" To: "Tina TSOU" , Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] NEMO support in Binding Revocation 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: Wed, 19 Aug 2009 09:50:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA20B1.45154FFE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tina, =20 I am not sure if we need to say that it is NOT supported in the abstract.=20 Binding revocation is a generic mechanism that can be supported in all IPv6 mobility cases. However, for the current NEMO, there is no usecase to use Binding Revocation.=20 =20 So, I am not certain if we need to mention this in the abstract of the draft.=20 May be we can get some feedback from the wgs. =20 Comments please? =20 I changed the subject to be issue specific. Regards,=20 Ahmad=20 =20 ________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Wednesday, August 19, 2009 4:09 AM To: ops-dir@ietf.org; Muhanna, Ahmad (RICH1:2H10) Cc: draft-ietf-mext-binding-revocation@tools.ietf.org Subject: Re: Comments on draft-ietf-mext-binding-revocation-08 =09 =09 Hi Ahmad, I know the history of it. The NEMO MNP is carried by DHCP option, and the way BU/BU carrying MNP was out. Therefore it is not in the Binding Revocation. =20 I just wanna comment that since NEMO is not included, should it be spelled out in the draft that the MIP6 extension in the Abstract does not include NEMO? Though I'm wondering there is no deployment for the time being, even no running code. There might be deployment in the future. I don't have strong opinion whether excluding the NEMO in the draft. =20 =20 B. R. Tina http://tinatsou.weebly.com/contact.html =09 ----- Original Message -----=20 From: Ahmad Muhanna =20 To: Tina TSOU ; ops-dir@ietf.org=20 Cc: draft-ietf-mext-binding-revocation@tools.ietf.org=20 Sent: Wednesday, August 19, 2009 2:57 PM Subject: RE: Comments on draft-ietf-mext-binding-revocation-08 Hello Tina, =20 Initially the NEMO case was part of the Binding Revocation presentations that were made in, at least, two IETF meetings. However, based on further discussion on the MEXT/Netlmm mailing lists, the wg failed to find a use for Binding Revocation in the case of NEMO for the following reasons: =20 1. The MNP is allocated via a mechanism other than the BU/BA signaling. In other words, DHCP could be an option. Therefore, the argument was made that there is no justification for the home agent to send a Binding Revocation Indication message in order to revoke a specific MNP. =20 2. On the other hand, at any time the MR would like to revoke a specific MNP binding to its home address, the MR can send a BU with the remaining MNPs that still valid and the home agent will update the MR BCE accordingly. In addition, the MR can send a de-registration to de-register all MNPs is a single message. =20 3. In the case that BU/BA is used for allocating MNP(s) to a specific MR with a specific HoA, then Binding Revocation makes sense, but, at the time of discussing this issue that mechanism for MNP allocation was NOT available or standardized. =20 I hope this addresses your concern. Regards,=20 Ahmad=20 =20 ________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Tuesday, August 18, 2009 9:31 PM To: ops-dir@ietf.org Cc: draft-ietf-mext-binding-revocation@tools.ietf.org Subject: Comments on draft-ietf-mext-binding-revocation-08 =09 =09 Hi, I think it is good shaped and can be moved forward except the NEMO case.=20 =20 As the draft describes "These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. ..." =20 As we know, the NEMO can be one of Mobile IPv6 extensions. However, I don't see any note about it. Therefore, I wonder if the draft is also applied for the NEMO case (RFC3963).=20 =09 =20 =20 B. R. Tina http://tinatsou.weebly.com/contact.html =09 =20 ------_=_NextPart_001_01CA20B1.45154FFE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Tina,
 
I am not sure if we need to say that it is NOT = supported in=20 the abstract.
Binding revocation is a generic mechanism that = can be=20 supported in all IPv6 mobility cases. However, for the current NEMO, = there is no=20 usecase to use Binding Revocation.
 
So, I am not certain if we need to mention this = in the=20 abstract of the draft.
May be we can get some feedback from the=20 wgs.
 
Comments please?
 
I changed the subject to be issue=20 specific.

Regards, =
Ahmad

 

From: Tina TSOU = [mailto:tena@huawei.com]=20
Sent: Wednesday, August 19, 2009 4:09 AM
To:=20 ops-dir@ietf.org; Muhanna, Ahmad (RICH1:2H10)
Cc:=20 draft-ietf-mext-binding-revocation@tools.ietf.org
Subject: = Re:=20 Comments on draft-ietf-mext-binding-revocation-08

Hi Ahmad,

I know the history of it. The NEMO MNP is carried by DHCP = option,=20 and the way BU/BU carrying MNP was out. Therefore it is not in the = Binding=20 Revocation.

 

I just wanna comment that since NEMO is not included, = should it be=20 spelled out in the draft that the MIP6 extension in the Abstract does = not=20 include NEMO?

Though I’m wondering there is no deployment for the = time being,=20 even no running code. There might be deployment in the=20 future.

I don’t have strong opinion whether excluding the = NEMO in the=20 draft.

 

 

B. = R.
Tina
http://tinatsou.weebly.c= om/contact.html
----- Original Message -----
From:=20 Ahmad=20 Muhanna
Cc: draft-i= etf-mext-binding-revocation@tools.ietf.org=20
Sent: Wednesday, August 19, = 2009 2:57=20 PM
Subject: RE: Comments on=20 draft-ietf-mext-binding-revocation-08

Hello Tina,
 
Initially the NEMO case was part of the = Binding=20 Revocation presentations that were made in, at least, two IETF = meetings.=20 However, based on further discussion on the MEXT/Netlmm mailing = lists, the=20 wg failed to find a use for Binding Revocation in the case = of NEMO=20 for the following reasons:
 
1. The MNP is allocated via a mechanism = other than the=20 BU/BA signaling. In other words, DHCP could be an option. Therefore, = the=20 argument was made that there is no justification for the home agent = to send=20 a Binding Revocation Indication message in order to revoke a = specific=20 MNP.
 
2. On the other hand, at any time the MR = would like to=20 revoke a specific MNP binding to its home address, the MR can send a = BU with=20 the remaining MNPs that still valid and the home agent will update = the MR=20 BCE accordingly. In addition, the MR can send a de-registration to=20 de-register all MNPs is a single message.
 
3. In the case that BU/BA is used for = allocating MNP(s)=20 to a specific MR with a specific HoA, then Binding Revocation makes = sense,=20 but, at the time of discussing this issue that mechanism for MNP = allocation=20 was NOT available or standardized.
 
I hope this addresses your = concern.

Regards,
Ahmad

 

From: Tina TSOU = [mailto:tena@huawei.com]=20
Sent: Tuesday, August 18, 2009 9:31 PM
To:=20 ops-dir@ietf.org
Cc:=20 = draft-ietf-mext-binding-revocation@tools.ietf.org
Subject:=20 Comments on = draft-ietf-mext-binding-revocation-08

Hi,
I think it is good shaped = and can be=20 moved forward except the NEMO case.
 
As the draft describes "These = semantics are=20 generic enough and can be used by mobility entities in the case of = Mobile=20 IPv6 and its extensions. ..."
 
As we know, the NEMO can be one = of Mobile=20 IPv6 extensions. However, I don't see any note about = it. Therefore, I=20 wonder if the draft is also applied for the NEMO case (RFC3963).=20
 
 
B. R.
Tina
http://tinatsou.weebly.c= om/contact.html

 
------_=_NextPart_001_01CA20B1.45154FFE-- From alexandru.petrescu@gmail.com Wed Aug 19 03:54:24 2009 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 D27443A6876; Wed, 19 Aug 2009 03:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.289, 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 s-E2FlTAaulP; Wed, 19 Aug 2009 03:54:23 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id E7AC03A6C86; Wed, 19 Aug 2009 03:54:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n7JAqXrY016057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Aug 2009 12:52:33 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n7JAqWvx016331; Wed, 19 Aug 2009 12:52:32 +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 n7JAqWfP010926; Wed, 19 Aug 2009 12:52:32 +0200 Message-ID: <4A8BD96F.6030902@gmail.com> Date: Wed, 19 Aug 2009 12:52:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ahmad Muhanna References: <017501ca1fd7$fccd1990$8e27460a@china.huawei.com> <61A1D127-DE20-4A4B-9F84-74E0851B6BB7@cisco.com> <00bc01ca2075$0e9bbb70$8e27460a@china.huawei.com> <01f001ca20ac$baa0e210$8e27460a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ops-dir@ietf.org, mext@ietf.org, draft-ietf-mext-binding-revocation@tools.ietf.org, Tina TSOU Subject: Re: [MEXT] NEMO support in Binding Revocation 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: Wed, 19 Aug 2009 10:54:24 -0000 Maybe we can say something in the abstract about the fact that this revocation works ok when HA revokes the revoked thing (HoA?) from the Mobile Host and also works if it revokes if from a Mobile Router. This is somehow suggested already when the abstract says: "terminate a mobile node's mobility session" because a MN could be by definition an MH or a MR. TO be more explicit, we could probably say instead of: "This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries." New: "This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one (a Mobile Host, a Mobile Router or a MAG) to terminate either one, multiple or all specified binding cache entries." As two side notes: (1) there is a problem with the last part of the phrase, because an MN doesn't hold a binding cache but a binding update list (does a MAG hold a BC?); (2) the use of the word "corresponding" may lead to think to CN - it's not. Or we could add some NEMO phrase in the section 11 "Mobile Node Operation" to say "Mobile Node (Mobile Host or Mobile Router)". I still disagree to allocate and transmit/delegate the MNP from HA to MR with a BU (and thus still oppose to revoke it with the Binding Revocation Indication.) Yours, Alex Ahmad Muhanna a écrit : > Hi Tina, > > I am not sure if we need to say that it is NOT supported in the > abstract. Binding revocation is a generic mechanism that can be > supported in all IPv6 mobility cases. However, for the current NEMO, > there is no usecase to use Binding Revocation. > > So, I am not certain if we need to mention this in the abstract of > the draft. May be we can get some feedback from the wgs. > > Comments please? > > I changed the subject to be issue specific. > > Regards, Ahmad > > > > ------------------------------------------------------------------------ > *From:* Tina TSOU [mailto:tena@huawei.com] *Sent:* Wednesday, August > 19, 2009 4:09 AM *To:* ops-dir@ietf.org; Muhanna, Ahmad (RICH1:2H10) > *Cc:* draft-ietf-mext-binding-revocation@tools.ietf.org *Subject:* > Re: Comments on draft-ietf-mext-binding-revocation-08 > > Hi Ahmad, > > I know the history of it. The NEMO MNP is carried by DHCP option, and > the way BU/BU carrying MNP was out. Therefore it is not in the > Binding Revocation. > > > > I just wanna comment that since NEMO is not included, should it be > spelled out in the draft that the MIP6 extension in the Abstract does > not include NEMO? > > Though I’m wondering there is no deployment for the time being, even > no running code. There might be deployment in the future. > > I don’t have strong opinion whether excluding the NEMO in the draft. > > > > > > B. R. Tina http://tinatsou.weebly.com/contact.html > > ----- Original Message ----- *From:* Ahmad Muhanna > *To:* Tina TSOU > ; ops-dir@ietf.org *Cc:* > draft-ietf-mext-binding-revocation@tools.ietf.org > *Sent:* > Wednesday, August 19, 2009 2:57 PM *Subject:* RE: Comments on > draft-ietf-mext-binding-revocation-08 > > Hello Tina, > > Initially the NEMO case was part of the Binding Revocation > presentations that were made in, at least, two IETF meetings. > However, based on further discussion on the MEXT/Netlmm mailing > lists, the wg failed to find a use for Binding Revocation in the case > of NEMO for the following reasons: > > 1. The MNP is allocated via a mechanism other than the BU/BA > signaling. In other words, DHCP could be an option. Therefore, the > argument was made that there is no justification for the home agent > to send a Binding Revocation Indication message in order to revoke a > specific MNP. > > 2. On the other hand, at any time the MR would like to revoke a > specific MNP binding to its home address, the MR can send a BU with > the remaining MNPs that still valid and the home agent will update > the MR BCE accordingly. In addition, the MR can send a > de-registration to de-register all MNPs is a single message. > > 3. In the case that BU/BA is used for allocating MNP(s) to a specific > MR with a specific HoA, then Binding Revocation makes sense, but, at > the time of discussing this issue that mechanism for MNP allocation > was NOT available or standardized. > > I hope this addresses your concern. > > Regards, Ahmad > > > > ------------------------------------------------------------------------ > *From:* Tina TSOU [mailto:tena@huawei.com] *Sent:* Tuesday, August > 18, 2009 9:31 PM *To:* ops-dir@ietf.org *Cc:* > draft-ietf-mext-binding-revocation@tools.ietf.org *Subject:* Comments > on draft-ietf-mext-binding-revocation-08 > > Hi, I think it is good shaped and can be moved forward except the > NEMO case. > > As the draft describes "These semantics are generic enough and can be > used by mobility entities in the case of Mobile IPv6 and its > extensions. ..." > > As we know, the NEMO can be one of Mobile IPv6 extensions. However, I > don't see any note about it. Therefore, I wonder if the draft is > also applied for the NEMO case (RFC3963). > > > B. R. Tina http://tinatsou.weebly.com/contact.html > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From AMUHANNA@nortel.com Wed Aug 19 07:16:51 2009 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 8DC233A6EA9 for ; Wed, 19 Aug 2009 07:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, 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 uODiaIXk0hCq for ; Wed, 19 Aug 2009 07:16:50 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 109FD3A6A82 for ; Wed, 19 Aug 2009 07:16:49 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7JEGW115269; Wed, 19 Aug 2009 14:16:32 GMT 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: Wed, 19 Aug 2009 09:15:28 -0500 Message-ID: In-Reply-To: <4A8BD96F.6030902@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] NEMO support in Binding Revocation draft Thread-Index: Acogu21MiNZPvUZaStqB0W/N13QNlgADTWhA References: <017501ca1fd7$fccd1990$8e27460a@china.huawei.com> <61A1D127-DE20-4A4B-9F84-74E0851B6BB7@cisco.com> <00bc01ca2075$0e9bbb70$8e27460a@china.huawei.com> <01f001ca20ac$baa0e210$8e27460a@china.huawei.com> <4A8BD96F.6030902@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext@ietf.org, Tina TSOU Subject: Re: [MEXT] NEMO support in Binding Revocation 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: Wed, 19 Aug 2009 14:16:51 -0000 Hi Alex, Thanks for the feedback. Please see more inline. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, August 19, 2009 5:53 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Tina TSOU; ops-dir@ietf.org;=20 > draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org > Subject: Re: [MEXT] NEMO support in Binding Revocation draft >=20 > Maybe we can say something in the abstract about the fact=20 > that this revocation works ok when HA revokes the revoked=20 > thing (HoA?) from the Mobile Host and also works if it=20 > revokes if from a Mobile Router. >=20 > This is somehow suggested already when the abstract says:=20 > "terminate a mobile node's mobility session" because a MN=20 > could be by definition an MH or a MR. >=20 > TO be more explicit, we could probably say instead of: > "This mechanism allows > the mobility entity which initiates the revocation procedure to > request its corresponding one to terminate either one, multiple or > all specified binding cache entries." >=20 > New: > "This mechanism allows > the mobility entity which initiates the revocation procedure to > request its corresponding one (a Mobile Host, a Mobile Router or a > MAG) to terminate either one, multiple or > all specified binding cache entries." >=20 > As two side notes: (1) there is a problem with the last part=20 > of the phrase, because an MN doesn't hold a binding cache but=20 > a binding update list (does a MAG hold a BC?);=20 [Ahmad] Good point. What about if we use the generic term binding(s) only, as = the following: " .............................................. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding(s). " This way we are referring to the binding(s) generically. Because, = sometime, especially when the MAG sends a BRI with the (G) bit set, the = recipient is the LMA which maintains Binding cache entries. > (2) the use of=20 > the word "corresponding" > may lead to think to CN - it's not. [Ahmad] I am not sure about this one, especially, we avoided on purpose the use = of "node" and used "the corresponding one" to avoid any confusion. >=20 > Or we could add some NEMO phrase in the section 11 "Mobile=20 > Node Operation" to say "Mobile Node (Mobile Host or Mobile Router)". [Ahmad] Le me understand this one. Are you saying that the HA should still be = able to send a BRI message to revoke the MR HoA binding, for any reason, = e.g., administrative. ? BUT for sure Not to include a specific MNP. Is my understanding correct? >=20 > I still disagree to allocate and transmit/delegate the MNP=20 > from HA to MR with a BU (and thus still oppose to revoke it=20 > with the Binding Revocation Indication.) [Ahmad] No problem.=20 Sure. We are not trying to change that. Just to make sure that the = wording in Binding Revocation is accurate if applied to NEMO. >=20 > Yours, >=20 > Alex >=20 >=20 > Ahmad Muhanna a =E9crit : > > Hi Tina, > >=20 > > I am not sure if we need to say that it is NOT supported in the=20 > > abstract. Binding revocation is a generic mechanism that can be=20 > > supported in all IPv6 mobility cases. However, for the=20 > current NEMO, =20 > > there is no usecase to use Binding Revocation. > >=20 > > So, I am not certain if we need to mention this in the=20 > abstract of the=20 > > draft. May be we can get some feedback from the wgs. > >=20 > > Comments please? > >=20 > > I changed the subject to be issue specific. > >=20 > > Regards, Ahmad > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > *From:* Tina TSOU [mailto:tena@huawei.com] *Sent:*=20 > Wednesday, August =20 > > 19, 2009 4:09 AM *To:* ops-dir@ietf.org; Muhanna, Ahmad (RICH1:2H10) > > *Cc:* draft-ietf-mext-binding-revocation@tools.ietf.org *Subject:* > > Re: Comments on draft-ietf-mext-binding-revocation-08 > >=20 > > Hi Ahmad, > >=20 > > I know the history of it. The NEMO MNP is carried by DHCP=20 > option, and =20 > > the way BU/BU carrying MNP was out. Therefore it is not in=20 > the Binding=20 > > Revocation. > >=20 > >=20 > >=20 > > I just wanna comment that since NEMO is not included, should it be=20 > > spelled out in the draft that the MIP6 extension in the=20 > Abstract does =20 > > not include NEMO? > >=20 > > Though I'm wondering there is no deployment for the time=20 > being, even=20 > > no running code. There might be deployment in the future. > >=20 > > I don't have strong opinion whether excluding the NEMO in the draft. > >=20 > >=20 > >=20 > >=20 > >=20 > > B. R. Tina http://tinatsou.weebly.com/contact.html > >=20 > > ----- Original Message ----- *From:* Ahmad Muhanna=20 > > *To:* Tina TSOU=20 > =20 > > ; ops-dir@ietf.org *Cc:*=20 > > draft-ietf-mext-binding-revocation@tools.ietf.org > > *Sent:*=20 > > Wednesday, August 19, 2009 2:57 PM *Subject:* RE: Comments on > > draft-ietf-mext-binding-revocation-08 > >=20 > > Hello Tina, > >=20 > > Initially the NEMO case was part of the Binding Revocation=20 > > presentations that were made in, at least, two IETF meetings. > > However, based on further discussion on the MEXT/Netlmm=20 > mailing lists,=20 > > the wg failed to find a use for Binding Revocation in the case of=20 > > NEMO for the following reasons: > >=20 > > 1. The MNP is allocated via a mechanism other than the BU/BA=20 > > signaling. In other words, DHCP could be an option. Therefore, the=20 > > argument was made that there is no justification for the=20 > home agent to=20 > > send a Binding Revocation Indication message in order to revoke a =20 > > specific MNP. > >=20 > > 2. On the other hand, at any time the MR would like to revoke a=20 > > specific MNP binding to its home address, the MR can send a BU with=20 > > the remaining MNPs that still valid and the home agent will=20 > update the=20 > > MR BCE accordingly. In addition, the MR can send a=20 > de-registration to=20 > > de-register all MNPs is a single message. > >=20 > > 3. In the case that BU/BA is used for allocating MNP(s) to=20 > a specific =20 > > MR with a specific HoA, then Binding Revocation makes=20 > sense, but, at =20 > > the time of discussing this issue that mechanism for MNP=20 > allocation =20 > > was NOT available or standardized. > >=20 > > I hope this addresses your concern. > >=20 > > Regards, Ahmad > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > *From:* Tina TSOU [mailto:tena@huawei.com] *Sent:* Tuesday, August=20 > > 18, 2009 9:31 PM *To:* ops-dir@ietf.org *Cc:*=20 > > draft-ietf-mext-binding-revocation@tools.ietf.org=20 > *Subject:* Comments =20 > > on draft-ietf-mext-binding-revocation-08 > >=20 > > Hi, I think it is good shaped and can be moved forward=20 > except the NEMO=20 > > case. > >=20 > > As the draft describes "These semantics are generic enough=20 > and can be =20 > > used by mobility entities in the case of Mobile IPv6 and its=20 > > extensions. ..." > >=20 > > As we know, the NEMO can be one of Mobile IPv6 extensions.=20 > However, I =20 > > don't see any note about it. Therefore, I wonder if the=20 > draft is also=20 > > applied for the NEMO case (RFC3963). > >=20 > >=20 > > B. R. Tina http://tinatsou.weebly.com/contact.html > >=20 > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ MEXT mailing list=20 > > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 From julienl@qualcomm.com Thu Aug 20 16:26:03 2009 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 2BD793A6B95 for ; Thu, 20 Aug 2009 16:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.741 X-Spam-Level: X-Spam-Status: No, score=-103.741 tagged_above=-999 required=5 tests=[AWL=-1.142, 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 gnqKOYOdeV5T for ; Thu, 20 Aug 2009 16:26:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2D7C63A6C16 for ; Thu, 20 Aug 2009 16:26: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=1250810768; x=1282346768; h=from:to: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: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"mext@ietf.org"=20|Date:=20Thu,=202 0=20Aug=202009=2016:26:04=20-0700|Subject:=20DRAFT=20MEXT =20WG=20minutes=20@=20IETF=2075|Thread-Topic:=20DRAFT=20M EXT=20WG=20minutes=20@=20IETF=2075|Thread-Index:=20Acoh7Z ZRv18BUtXaQNqpqhiGyEyaKQ=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-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5715"=3B=20a=3D"22431283"; bh=/zdqd+LR93XHMbMEsHrQuGquPbWEAGs6V8kKBrWok1c=; b=iIKAb0burEa45AQuaRDFsXIcDGeqABgnBXHCCax9wQ7du0iaW/fFU2wC D0hkDsquA6ZNL1aq9YKlQhzofxXM//AxaQW3LxveiwBGt6gTKhGKBhXC/ FG+Y1Lq9qRim8nt73UWnPJJVMNedijHuNXcI1WH0CTPoZLh+E6kZS74EN Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5715"; a="22431283" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2009 16:26:07 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7KNQ75a029700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Aug 2009 16:26:07 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7KNQ6Mq001650 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Aug 2009 16:26:07 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Thu, 20 Aug 2009 16:26:06 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 20 Aug 2009 16:26:06 -0700 From: "Laganier, Julien" To: "mext@ietf.org" Date: Thu, 20 Aug 2009 16:26:04 -0700 Thread-Topic: DRAFT MEXT WG minutes @ IETF 75 Thread-Index: Acoh7ZZRv18BUtXaQNqpqhiGyEyaKQ== 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 MEXT WG minutes @ IETF 75 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, 20 Aug 2009 23:26:03 -0000 Folks, DRAFT minutes of the Stockholm meeting based (entirely) on notes taken by W= illiam Ivancic & George Tsirtsis are available there: Please review the minutes and send additions and/or corrections ASAP. Thank you for your support, --julien & Marcelo, MEXT chairs From julienl@qualcomm.com Fri Aug 21 11:30:05 2009 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 8421F28C1E8 for ; Fri, 21 Aug 2009 11:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.731 X-Spam-Level: X-Spam-Status: No, score=-103.731 tagged_above=-999 required=5 tests=[AWL=-1.132, 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 hZRPWf7+8bGK for ; Fri, 21 Aug 2009 11:30:04 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 63DC928C1D7 for ; Fri, 21 Aug 2009 11:30:04 -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=1250879410; x=1282415410; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"Laganier,=20Julien"=20,=20" mext@ietf.org"=20|Date:=20Fri,=2021=20Aug =202009=2011:30:06=20-0700|Subject:=20EXTENDED=20[MEXT] =20[WGLC]=20RFC=203775=20bis=20/=20draft-ietf-mext-rfc377 5bis|Thread-Topic:=20EXTENDED=20[MEXT]=20[WGLC]=20RFC=203 775=20bis=20/=0D=0A=20draft-ietf-mext-rfc3775bis |Thread-Index:=20AcoV4C/MITZ832VfQMeSZMhEKAB5+QMrKR0w |Message-ID:=20|References:=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|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5716"=3B=20a=3D"22471280"; bh=N7RaegaJWABiSAMutCYka8q8EDBuogf4qgmlSMoZFxk=; b=JSp8hf3UOUywDW96E9dWGfJnRsfk0WGuJN4+2gOelIaunco/wStdmS2Y p40qF+0K38I8Urngn0OOkb1I2YMsVJsaI4tctlrRuPvjLhKs2qch1m/yX 3YySXgGRNisx73gr5ZEdrbjgNO0HGfFjlQO39zHrV1ua4a5Ayvs7J6dXn A=; X-IronPort-AV: E=McAfee;i="5300,2777,5716"; a="22471280" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Aug 2009 11:30:09 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7LIU9j7002182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Aug 2009 11:30:09 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7LIU8dh027392 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Aug 2009 11:30:08 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 21 Aug 2009 11:30:08 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Fri, 21 Aug 2009 11:30:08 -0700 From: "Laganier, Julien" To: "Laganier, Julien" , "mext@ietf.org" Date: Fri, 21 Aug 2009 11:30:06 -0700 Thread-Topic: EXTENDED [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis Thread-Index: AcoV4C/MITZ832VfQMeSZMhEKAB5+QMrKR0w Message-ID: References: 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 Subject: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis 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, 21 Aug 2009 18:30:05 -0000 Greetings, There was only one review of the draft RFC3775bis so far and we need more t= o send this document to IESG thus we decided to extend the WGLC. Please review the specification and post a message to the mailing list if y= ou think the document is ready to be forwarded to IESG before 2009-09-11 6:= 00PM EST. --julien & marcelo, MEXT chairs > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Laganier, Julien > Sent: Wednesday, August 05, 2009 8:20 AM > To: mext@ietf.org > Subject: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis >=20 > Folks, >=20 > As discussed during the MEXT session in IETF-75 we're issuing a two > weeks WGLC on RFC 3775 bis rfc3775bis-04> that will follow the two rules below: >=20 > - this WGLC is NOT intended for re-opening discussions on issues that > were resolved during the revision process neither for bringing up new > issues. >=20 > - this WGLC is intended to be sanity check to see whether the various > changes we agreed to made fit together. Editorial corrections are also > welcome. >=20 > Please review the specification and post a message to the mailing list > if you think the document is ready to be forwarded to IESG before 2009- > 08-15 6:00PM PST. >=20 > Thank you for your support. >=20 > --julien & Marcelo, MEXT chairs >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Fri Aug 21 11:36:00 2009 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 8FEE828C21E for ; Fri, 21 Aug 2009 11:36:00 -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 gnYKQCz-hQe1 for ; Fri, 21 Aug 2009 11:35:59 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id B4A983A6B92 for ; Fri, 21 Aug 2009 11:35:59 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so294456rvb.49 for ; Fri, 21 Aug 2009 11:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=joQZopuF5Hq4MXDCWQdRHWw9Ns5jSIqrvDelLhP3Jdw=; b=MwDjaTsCxRLuSQOmb4o0Ee0NDc7aAY/AcO/4sdBfixjH1opdDAMlkrhBbIxA+D/G+K Fq+a5HI/jRHobTnR6gtegO38w3376ikql/70tZTKH/cjbLhCs/8Nd8NdEk3cV3lAPn2k wfrMh+yr67+3MEwbYcmUWQFFPJuc4GaLEGDV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=MyDA6ILg8a5J7uNEXMTCx9Ur06VxkF4MhSokOlgsyfUYDrtgWSooX25RKuJP8AfhsZ tDJ+n2Qj9Z00k/2KrUJj/DJthsK6Tc8UILtLNZmvN48sqNFqQM0IdRabX2HRmLpUk7S/ RAciEw1G/ltqD+P7TLETUfVViNzki0xveRQmQ= Received: by 10.141.37.13 with SMTP id p13mr797383rvj.193.1250879752524; Fri, 21 Aug 2009 11:35:52 -0700 (PDT) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id g22sm2554634rvb.45.2009.08.21.11.35.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 21 Aug 2009 11:35:50 -0700 (PDT) From: Ryuji Wakikawa To: "Laganier, Julien" In-Reply-To: References: Message-Id: <0C5D7BDC-83FD-4C8F-A118-25AB41AA0272@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 21 Aug 2009 11:35:48 -0700 X-Mailer: Apple Mail (2.936) Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis 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, 21 Aug 2009 18:36:00 -0000 Hi Charlie and all I reviewed this document and support the current version. It's ready to be sent to IESG. I have two minor comments. - Section 6.4.1 in Page 59 We should remove the following sentence, since type 0 is deprecated RFC5095. "If both a type 0 and a type 2 routing header are present, the type 2 routing header should follow the other routing header. A packet containing such nested encapsulation should be created as if the inner (type 2) routing header was constructed first and then treated as an original packet by the outer (type 0) routing header construction process." - In Appendix A, A4 and A5 are outdated future things, they were solved by bootstraping RFCs!? The next two comments have low priority, but they are just for better readability. - Although there is the reference entry of RFC4225, it is not cited anywhere in the text body. Should we refer to it somewhere in the text body? Maybe in section 5.2? - 3.2 Mobile IPv6 Terms There is RFC 3753 defining the same terms. home address, home subnet prefix, mobile node, L2 handover, foreign subnet prefix, care-of address, home agent are defined in RFC3753 It's OK to me to keep the same terms here, but adding reference of rfc3753 may help readers. regards, ryuji On 2009/08/05, at 8:19, Laganier, Julien wrote: > Folks, > > As discussed during the MEXT session in IETF-75 we're issuing a two > weeks WGLC on RFC 3775 bis > that will follow the two rules below: > > - this WGLC is NOT intended for re-opening discussions on issues > that were resolved during the revision process neither for bringing > up new issues. > > - this WGLC is intended to be sanity check to see whether the > various changes we agreed to made fit together. Editorial > corrections are also welcome. > > Please review the specification and post a message to the mailing > list if you think the document is ready to be forwarded to IESG > before 2009-08-15 6:00PM PST. > > Thank you for your support. > > --julien & Marcelo, MEXT chairs > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Mon Aug 24 02:27:42 2009 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 7928A3A6DEA for ; Mon, 24 Aug 2009 02:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.272, 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 a8Pin71Zj7-H for ; Mon, 24 Aug 2009 02:27:41 -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 335043A6DF3 for ; Mon, 24 Aug 2009 02:27:39 -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 n7O9RYm3012769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Aug 2009 11:27:34 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n7O9RYYi001903; Mon, 24 Aug 2009 11:27:34 +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 n7O9RX74028653; Mon, 24 Aug 2009 11:27:33 +0200 Message-ID: <4A925D04.20201@gmail.com> Date: Mon, 24 Aug 2009 11:27:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ahmad Muhanna References: <017501ca1fd7$fccd1990$8e27460a@china.huawei.com> <61A1D127-DE20-4A4B-9F84-74E0851B6BB7@cisco.com> <00bc01ca2075$0e9bbb70$8e27460a@china.huawei.com> <01f001ca20ac$baa0e210$8e27460a@china.huawei.com> <4A8BD96F.6030902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, mext@ietf.org, Tina TSOU Subject: Re: [MEXT] NEMO support in Binding Revocation 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: Mon, 24 Aug 2009 09:27:42 -0000 Ahmad Muhanna a écrit : > Hi Alex, Thanks for the feedback. > > Please see more inline. > > Regards, Ahmad > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, August 19, >> 2009 5:53 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Tina TSOU; >> ops-dir@ietf.org; >> draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org >> Subject: Re: [MEXT] NEMO support in Binding Revocation draft >> >> Maybe we can say something in the abstract about the fact that this >> revocation works ok when HA revokes the revoked thing (HoA?) from >> the Mobile Host and also works if it revokes if from a Mobile >> Router. >> >> This is somehow suggested already when the abstract says: >> "terminate a mobile node's mobility session" because a MN could be >> by definition an MH or a MR. >> >> TO be more explicit, we could probably say instead of: "This >> mechanism allows the mobility entity which initiates the revocation >> procedure to request its corresponding one to terminate either >> one, multiple or all specified binding cache entries." >> >> New: "This mechanism allows the mobility entity which initiates the >> revocation procedure to request its corresponding one (a Mobile >> Host, a Mobile Router or a MAG) to terminate either one, multiple >> or all specified binding cache entries." >> >> As two side notes: (1) there is a problem with the last part of >> the phrase, because an MN doesn't hold a binding cache but a >> binding update list (does a MAG hold a BC?); > > [Ahmad] Good point. What about if we use the generic term binding(s) > only, as the following: " > .............................................. This mechanism allows > the mobility entity which initiates the revocation procedure to > request its corresponding one to terminate either one, multiple or > all specified binding(s). " > > This way we are referring to the binding(s) generically. Because, > sometime, especially when the MAG sends a BRI with the (G) bit set, > the recipient is the LMA which maintains Binding cache entries. I agree with the intention to talk bindings (instead of binding cache entry), it's clearer in this case. But to say "request its corresponding one" doesn't sound very ok to my non-native English reading. "request a node"? Anyways, this is final editing stuff... I trust the Editor is very good at these things. >> (2) the use of the word "corresponding" may lead to think to CN - >> it's not. > > [Ahmad] I am not sure about this one, especially, we avoided on > purpose the use of "node" and used "the corresponding one" to avoid > any confusion. IT's as you wish, but "corresponding node" is too similar to "Correspondent Node". >> Or we could add some NEMO phrase in the section 11 "Mobile Node >> Operation" to say "Mobile Node (Mobile Host or Mobile Router)". > [Ahmad] Le me understand this one. Are you saying that the HA should > still be able to send a BRI message to revoke the MR HoA binding, for > any reason, e.g., administrative. ? BUT for sure Not to include a > specific MNP. Is my understanding correct? > >> I still disagree to allocate and transmit/delegate the MNP from HA >> to MR with a BU (and thus still oppose to revoke it with the >> Binding Revocation Indication.) > [Ahmad] No problem. Sure. We are not trying to change that. Just to > make sure that the wording in Binding Revocation is accurate if > applied to NEMO. Ok. Alex From alexandru.petrescu@gmail.com Mon Aug 24 02:30:36 2009 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 04D0F3A6B03 for ; Mon, 24 Aug 2009 02:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.267, 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 G-oqi7kuCvBp for ; Mon, 24 Aug 2009 02:30:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 1072A3A695A for ; Mon, 24 Aug 2009 02:30:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n7O9Udfx020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Aug 2009 11:30:39 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n7O9Uc6g002633; Mon, 24 Aug 2009 11:30:39 +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 n7O9Ubvq004035; Mon, 24 Aug 2009 11:30:38 +0200 Message-ID: <4A925DBD.3050003@gmail.com> Date: Mon, 24 Aug 2009 11:30:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Laganier, Julien" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis 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, 24 Aug 2009 09:30:36 -0000 I suggest the draft-3775bis to refer to RFC3963 in some way. Alex Laganier, Julien a écrit : > Greetings, > > There was only one review of the draft RFC3775bis so far and we need > more to send this document to IESG thus we decided to extend the > WGLC. > > Please review the specification and post a message to the mailing > list if you think the document is ready to be forwarded to IESG > before 2009-09-11 6:00PM EST. > > --julien & marcelo, MEXT chairs > >> -----Original Message----- From: mext-bounces@ietf.org >> [mailto:mext-bounces@ietf.org] On Behalf Of Laganier, Julien Sent: >> Wednesday, August 05, 2009 8:20 AM To: mext@ietf.org Subject: >> [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis >> >> Folks, >> >> As discussed during the MEXT session in IETF-75 we're issuing a two >> weeks WGLC on RFC 3775 bis >> that >> will follow the two rules below: >> >> - this WGLC is NOT intended for re-opening discussions on issues >> that were resolved during the revision process neither for bringing >> up new issues. >> >> - this WGLC is intended to be sanity check to see whether the >> various changes we agreed to made fit together. Editorial >> corrections are also welcome. >> >> Please review the specification and post a message to the mailing >> list if you think the document is ready to be forwarded to IESG >> before 2009- 08-15 6:00PM PST. >> >> Thank you for your support. >> >> --julien & Marcelo, MEXT chairs >> >> _______________________________________________ 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 julienl@qualcomm.com Mon Aug 24 08:07:46 2009 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 841963A6E0F for ; Mon, 24 Aug 2009 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.692 X-Spam-Level: X-Spam-Status: No, score=-103.692 tagged_above=-999 required=5 tests=[AWL=-1.093, 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 p4n05mtZ76x2 for ; Mon, 24 Aug 2009 08:07:45 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 639533A6BF0 for ; Mon, 24 Aug 2009 08:07:45 -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=1251126471; x=1282662471; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Alexandru=20Petrescu=20,=0D=0A=20=20=20=20=20=20=20=20Ahmad=20Muhanna=0D=0A =09|CC:=20"draft-ietf-mext-binding-r evocation@tools.ietf.org"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20 =20"mext@ietf.org"=0D=0A=09,=20Tina=20TSOU =20|Date:=20Mon,=2024=20Aug=202009=2008: 07:42=20-0700|Subject:=20RE:=20[MEXT]=20NEMO=20support=20 in=20Binding=20Revocation=20draft|Thread-Topic:=20[MEXT] =20NEMO=20support=20in=20Binding=20Revocation=20draft |Thread-Index:=20AcoknS1wj3xHmV3TSKys/I7GJ9qc2QALzujg |Message-ID:=20|References:=20<017501ca1fd 7$fccd1990$8e27460a@china.huawei.com>=0D=0A=09<61A1D127-D E20-4A4B-9F84-74E0851B6BB7@cisco.com>=0D=0A=09<00bc01ca20 75$0e9bbb70$8e27460a@china.huawei.com>=0D=0A=09 =0D=0A=09<01f001ca20ac$baa0e210$8e27460a@china.huawei.com >=0D=0A=09=0D=0A=09<4A8BD96F.6030902@gmail.com> =0D=0A=09=0D=0A=20<4A925D04.20201@gmail.com> |In-Reply-To:=20<4A925D04.20201@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|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5719"=3B=20a=3D"22563613"; bh=mTdEIYV7XRLhj2rkjuJ1DxmN8xlWIMsd7UVJ6SkEoXI=; b=L//rA5aenCidXunw1v549VZZJLhtbuX4t71uv5RNDMCdN3qENxYyfxWC 5H60nJ4HtBS3Wll9BZ3fd0qQpS7irDYoEAb8zg2aSgo6L4ZYa8C5YtR/1 9kK3opS0KyOO1daqyE8rmFG6cDsY7sQ4ZfrT6v3+n9Lc9DfvzmSL1mZgA E=; X-IronPort-AV: E=McAfee;i="5300,2777,5719"; a="22563613" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Aug 2009 08:07:51 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7OF7pXu005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2009 08:07:51 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7OF7k1v016041 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 Aug 2009 08:07:46 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 24 Aug 2009 08:07:46 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Mon, 24 Aug 2009 08:07:46 -0700 From: "Laganier, Julien" To: Alexandru Petrescu , Ahmad Muhanna Date: Mon, 24 Aug 2009 08:07:42 -0700 Thread-Topic: [MEXT] NEMO support in Binding Revocation draft Thread-Index: AcoknS1wj3xHmV3TSKys/I7GJ9qc2QALzujg Message-ID: References: <017501ca1fd7$fccd1990$8e27460a@china.huawei.com> <61A1D127-DE20-4A4B-9F84-74E0851B6BB7@cisco.com> <00bc01ca2075$0e9bbb70$8e27460a@china.huawei.com> <01f001ca20ac$baa0e210$8e27460a@china.huawei.com> <4A8BD96F.6030902@gmail.com> <4A925D04.20201@gmail.com> In-Reply-To: <4A925D04.20201@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: "draft-ietf-mext-binding-revocation@tools.ietf.org" , Tina TSOU , "mext@ietf.org" Subject: Re: [MEXT] NEMO support in Binding Revocation 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: Mon, 24 Aug 2009 15:07:46 -0000 FWIW, Alexandru Petrescu wrote: >=20 > Ahmad Muhanna a =E9crit : > > Hi Alex, Thanks for the feedback. > > > > Please see more inline. > > > > Regards, Ahmad > > > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, August 19, > >> 2009 5:53 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Tina TSOU; > >> ops-dir@ietf.org; > >> draft-ietf-mext-binding-revocation@tools.ietf.org; mext@ietf.org > >> Subject: Re: [MEXT] NEMO support in Binding Revocation draft > >> > >> Maybe we can say something in the abstract about the fact that this > >> revocation works ok when HA revokes the revoked thing (HoA?) from > >> the Mobile Host and also works if it revokes if from a Mobile > >> Router. > >> > >> This is somehow suggested already when the abstract says: > >> "terminate a mobile node's mobility session" because a MN could be > >> by definition an MH or a MR. > >> > >> TO be more explicit, we could probably say instead of: "This > >> mechanism allows the mobility entity which initiates the revocation > >> procedure to request its corresponding one to terminate either > >> one, multiple or all specified binding cache entries." > >> > >> New: "This mechanism allows the mobility entity which initiates the > >> revocation procedure to request its corresponding one (a Mobile > >> Host, a Mobile Router or a MAG) to terminate either one, multiple > >> or all specified binding cache entries." > >> > >> As two side notes: (1) there is a problem with the last part of > >> the phrase, because an MN doesn't hold a binding cache but a > >> binding update list (does a MAG hold a BC?); > > > > [Ahmad] Good point. What about if we use the generic term binding(s) > > only, as the following: " > > .............................................. This mechanism allows > > the mobility entity which initiates the revocation procedure to > > request its corresponding one to terminate either one, multiple or > > all specified binding(s). " > > > > This way we are referring to the binding(s) generically. Because, > > sometime, especially when the MAG sends a BRI with the (G) bit set, > > the recipient is the LMA which maintains Binding cache entries. >=20 > I agree with the intention to talk bindings (instead of binding cache > entry), it's clearer in this case. >=20 > But to say "request its corresponding one" doesn't sound very ok to my > non-native English reading. "request a node"? s/corresponding one/peer =20 --julien From charles.perkins@earthlink.net Mon Aug 24 09:20:34 2009 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 771F228C217 for ; Mon, 24 Aug 2009 09:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 X3QQCVTy0lyN for ; Mon, 24 Aug 2009 09:20:33 -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 BBB0B28C292 for ; Mon, 24 Aug 2009 09:20:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HTiMDRnevPwh5+uGYTTXrAG6v7SkR5iCtzfoEB/NEKe23+vCcuaq3zIKJ1eg+wik; 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.254.16]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MfcHV-0003SA-Tn; Mon, 24 Aug 2009 12:20:30 -0400 Message-ID: <4A92BDCB.5050002@earthlink.net> Date: Mon, 24 Aug 2009 09:20:27 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <4A925DBD.3050003@gmail.com> In-Reply-To: <4A925DBD.3050003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f524972b509e42e5baba939acebc7c8211d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "mext@ietf.org" Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis 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, 24 Aug 2009 16:20:34 -0000 Hello Alex, I took a look. The only logical place would be in the Introduction. We could replace: > o Mobile routers. > by > o Mobile routers. But see RFC 3963. > I don't think this is a very good idea. We don't do that for the other topics which aren't covered in RFC 3775. Regards, Charlie P. Alexandru Petrescu wrote: > I suggest the draft-3775bis to refer to RFC3963 in some way. > > Alex > > Laganier, Julien a écrit : >> Greetings, >> >> There was only one review of the draft RFC3775bis so far and we need >> more to send this document to IESG thus we decided to extend the >> WGLC. >> >> Please review the specification and post a message to the mailing >> list if you think the document is ready to be forwarded to IESG >> before 2009-09-11 6:00PM EST. >> >> --julien & marcelo, MEXT chairs >> From vijay@wichorus.com Mon Aug 24 10:59:55 2009 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 B6FD428C2ED for ; Mon, 24 Aug 2009 10:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.236 X-Spam-Level: X-Spam-Status: No, score=-0.236 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] 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 U6U7jB+r7h67 for ; Mon, 24 Aug 2009 10:59:55 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id BAAF128C2FB for ; Mon, 24 Aug 2009 10:59:15 -0700 (PDT) Received: from 12.204.153.98 ([12.204.153.98]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Mon, 24 Aug 2009 17:59:09 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 24 Aug 2009 10:59:20 -0700 From: Vijay Devarapalli To: Ryuji Wakikawa , "Laganier, Julien" Message-ID: Thread-Topic: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis Thread-Index: Acok5JqyPRL2NACw4kmRqT2A0jV5nA== In-Reply-To: <0C5D7BDC-83FD-4C8F-A118-25AB41AA0272@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis 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, 24 Aug 2009 17:59:55 -0000 On 8/21/09 11:35 AM, "Ryuji Wakikawa" wrote: > - In Appendix A, A4 and A5 are outdated future things, they were > solved by bootstraping RFCs!? I agree. We should remove A4 and A5. Vijay From AMUHANNA@nortel.com Mon Aug 24 22:48:16 2009 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 3E0DC3A6E0A for ; Mon, 24 Aug 2009 22:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, 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 95iORuA7xscP for ; Mon, 24 Aug 2009 22:48:15 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E0C383A6E94 for ; Mon, 24 Aug 2009 22:48:14 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7P5m2X10442; Tue, 25 Aug 2009 05:48:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Aug 2009 00:47:38 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] NEMO support in Binding Revocation draft Thread-Index: AcoknS1wj3xHmV3TSKys/I7GJ9qc2QALzujgAB6rfBA= References: <017501ca1fd7$fccd1990$8e27460a@china.huawei.com><61A1D127-DE20-4A4B-9F84-74E0851B6BB7@cisco.com><00bc01ca2075$0e9bbb70$8e27460a@china.huawei.com><01f001ca20ac$baa0e210$8e27460a@china.huawei.com><4A8BD96F.6030902@gmail.com> <4A925D04.20201@gmail.com> From: "Ahmad Muhanna" To: "Laganier, Julien" , "Alexandru Petrescu" Cc: draft-ietf-mext-binding-revocation@tools.ietf.org, Tina TSOU , mext@ietf.org Subject: Re: [MEXT] NEMO support in Binding Revocation 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, 25 Aug 2009 05:48:16 -0000 > Subject: RE: [MEXT] NEMO support in Binding Revocation draft >=20 > >=20 > > I agree with the intention to talk bindings (instead of=20 > binding cache=20 > > entry), it's clearer in this case. > >=20 > > But to say "request its corresponding one" doesn't sound=20 > very ok to my=20 > > non-native English reading. "request a node"? >=20 > s/corresponding one/peer [Ahmad] Thanks Julien. This is a good choice assuming that the MN qualifies to be an HA peer. All, So basically we have a couple of minor wording to update; I guess we can wait for the next revision to include these two minor changes. Regards, Ahmad > =20 > --julien >=20 >=20 From behcetsarikaya@yahoo.com Tue Aug 25 08:06:24 2009 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 46CA83A6F79 for ; Tue, 25 Aug 2009 08:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.189, 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 8JkTJIRQlTXh for ; Tue, 25 Aug 2009 08:06:23 -0700 (PDT) Received: from web111413.mail.gq1.yahoo.com (web111413.mail.gq1.yahoo.com [67.195.15.204]) by core3.amsl.com (Postfix) with SMTP id 892DB3A6ED8 for ; Tue, 25 Aug 2009 08:06:23 -0700 (PDT) Received: (qmail 95565 invoked by uid 60001); 25 Aug 2009 15:06:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251212784; bh=fu4E3Xzg5tFG4iN5RrVsMTdpyFTzhvqshVsvltxk4GI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NVQF4uMQNQwYKenWgAJ8Z0szRmKBhKdxmkXKAB/DLpITDAhHucBezIwfsebyseiGY+dtqJdgmNvl47zwu3wG33q4Wc425HaDG2BIrKoVev6REWayG1wBpJljNsaHvTO7AI/0FoLREtNp3VcC2WuyTmqXnaQ76PG78aFHl/taPhE= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HMIzyxvpBHvmdMLH4/TaGK0Vi8LuZSQds9QL2ihhjB6v00Klf4tHYrzbPJc89tWoyyBYPkf+xtMJj3Az9jlgYd6jvT2tIueF1QuMVJPhP0Bub7kKr1tMdEG0d3BZSkOv/CVvHP3zF+j1Q7eMYtmAuo1SHOXnxSUDjKD9YpvreQM=; Message-ID: <35199.91902.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: 3AOSiwkVM1nTPZhcqZRKWQY1mix.hO3J1E5dZLdWIk08Nuf.Wk4U5dcKVRmGZ6JX2DxGA_mRerBh7z3U9g7M6ptIjFQjJKvn141eI3Rh9CH3J0NKnm8jdAVQLjVdJIRvMYoLm5EBNvuoSpBKXnbbjMYKvaJH_.cW5HWuo9uIqpETnHFykurhMryGlbJa.67Ny19rNuezElswL8Qkstj9UV6CWqJ3CQ5basOSOqTKZhvrH4LVIJtr0Waj78YKLkensbLGo2EHFQKXweiR98uLR7mi3SJ15lKF3aSCQw_9nFnvgtjDa3tCfcEPBAjnLQWouKWbZC5daWmfoylzoPNtllAiDll7l_YechkU Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Tue, 25 Aug 2009 08:06:23 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: Date: Tue, 25 Aug 2009 08:06:23 -0700 (PDT) From: Behcet Sarikaya To: "Laganier, Julien" , "mext@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 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: Tue, 25 Aug 2009 15:06:24 -0000 Hi Julien,=0A=A0 Regarding =0A3. Use cases for flow bindings in the HA->MN = direction=0A=0Athe text you have there doesn't match my memory of what happ= ened.=0AWhat I remember is that Scenario 1 (binding revocation) was OK and = most of the discussions by the people (Patil, George, Marcelo, Ryuji, Kent)= happened on Scenarios 2 & 3. Some people argued for and some argued agains= t.=0A=0AI don't have time to go to the audio=A0file and give you a precise = transcript. =0AMy suggestion is to replace current Section 3 with a summary= like the above.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Original Message -= ---=0A> From: "Laganier, Julien" =0A> To: "mext@ietf.= org" =0A> Sent: Thursday, August 20, 2009 6:26:04 PM=0A> Sub= ject: [MEXT] DRAFT MEXT WG minutes @ IETF 75=0A> =0A> Folks,=0A> =0A> DRAFT= minutes of the Stockholm meeting based (entirely) on notes taken by =0A> W= illiam Ivancic & George Tsirtsis are available there:=0A> =0A> =0A> =0A> Pl= ease review the minutes and send additions and/or corrections ASAP.=0A> =0A= > Thank you for your support,=0A> =0A> --julien & Marcelo, MEXT chairs=0A> = =0A> =0A> _______________________________________________=0A> MEXT mailing = list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mext=0A=0A= =0A=0A From julienl@qualcomm.com Tue Aug 25 09:12:58 2009 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 B43DB3A67EA for ; Tue, 25 Aug 2009 09:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.656 X-Spam-Level: X-Spam-Status: No, score=-103.656 tagged_above=-999 required=5 tests=[AWL=-1.057, 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 nEaKYo0SaBup for ; Tue, 25 Aug 2009 09:12:57 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id A863F3A6863 for ; Tue, 25 Aug 2009 09:12:57 -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=1251216784; x=1282752784; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Behcet=20Sarikaya=20,=20"mext@i etf.org"=20|Date:=20Tue,=2025=20Aug=202009 =2009:12:38=20-0700|Subject:=20RE:=20[MEXT]=20DRAFT=20MEX T=20WG=20minutes=20@=20IETF=2075|Thread-Topic:=20[MEXT] =20DRAFT=20MEXT=20WG=20minutes=20@=20IETF=2075 |Thread-Index:=20AcollZ8nSX/W6UC0SkGYXyiaMaDHjAACOq9Q |Message-ID:=20|References:=20=0D=0A=20<35199.91902.qm@web111413.mail.gq1.yahoo.com> |In-Reply-To:=20<35199.91902.qm@web111413.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"iso-8 859-1"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5720"=3B=20a=3D"22627108"; bh=Fr1i+G3AI2GxQz7YRuAFpQYciSeqYzI9XJle4fcbNws=; b=Di0w57SOxYHkDuRHQVdRUyMV9JVSrT7zhs9GA+8DWYs3Jo0LDbiJ/ubx YehzjZMs9epgLlPFV08nDOpHCTwmJCO1DPXqFiydq+xJHIz7op7703Jj/ +AEUD/5zKLVmh7zWb9p4SNxORorVP7s+9/vRezhawexJ4d8iEvxETremo Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5720"; a="22627108" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Aug 2009 09:12:41 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7PGCfQ7004744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2009 09:12:41 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n7PGCejP012438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Aug 2009 09:12:41 -0700 (PDT) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Aug 2009 09:12:40 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 25 Aug 2009 09:12:40 -0700 From: "Laganier, Julien" To: Behcet Sarikaya , "mext@ietf.org" Date: Tue, 25 Aug 2009 09:12:38 -0700 Thread-Topic: [MEXT] DRAFT MEXT WG minutes @ IETF 75 Thread-Index: AcollZ8nSX/W6UC0SkGYXyiaMaDHjAACOq9Q Message-ID: References: <35199.91902.qm@web111413.mail.gq1.yahoo.com> In-Reply-To: <35199.91902.qm@web111413.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 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, 25 Aug 2009 16:12:58 -0000 Hi Behcet, I think I'm going to add one line after the existing transcript to describe= what I think was the consensus at the end: Conclusion: Scenario 2 & 3 do not make sense. Scenario 1 might make sense, = let's have interested people write a draft describing the use case in detai= ls and the required extensions to binding revocation. Does that sounds good? --julien > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Tuesday, August 25, 2009 8:06 AM > To: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 >=20 > Hi Julien, > =A0 Regarding > 3. Use cases for flow bindings in the HA->MN direction >=20 > the text you have there doesn't match my memory of what happened. > What I remember is that Scenario 1 (binding revocation) was OK and most > of the discussions by the people (Patil, George, Marcelo, Ryuji, Kent) > happened on Scenarios 2 & 3. Some people argued for and some argued > against. >=20 > I don't have time to go to the audio=A0file and give you a precise > transcript. > My suggestion is to replace current Section 3 with a summary like the > above. >=20 > Regards, >=20 > Behcet >=20 >=20 > ----- Original Message ---- > > From: "Laganier, Julien" > > To: "mext@ietf.org" > > Sent: Thursday, August 20, 2009 6:26:04 PM > > Subject: [MEXT] DRAFT MEXT WG minutes @ IETF 75 > > > > Folks, > > > > DRAFT minutes of the Stockholm meeting based (entirely) on notes > taken by > > William Ivancic & George Tsirtsis are available there: > > > > > > > > Please review the minutes and send additions and/or corrections ASAP. > > > > Thank you for your support, > > > > --julien & Marcelo, MEXT chairs > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 >=20 From behcetsarikaya@yahoo.com Tue Aug 25 09:44:56 2009 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 06DFF3A6C46 for ; Tue, 25 Aug 2009 09:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.162, 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 FBkFZVu7jYL8 for ; Tue, 25 Aug 2009 09:44:55 -0700 (PDT) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id 5B8AB28C112 for ; Tue, 25 Aug 2009 09:44:48 -0700 (PDT) Received: (qmail 49069 invoked by uid 60001); 25 Aug 2009 16:44:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251218689; bh=1QkSTPNI81SqF+jgOf+uZijYB6V5YpUIRemfsDnJoFQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YHdpPvy4r3t0UHWOfdUxzrJqFSSD3UhQVnQqFH65GPIeKXXpbLm2PoEkMt5KW2gpwP0ccspxU3MAkVeQrNwxIQlxr5xMZgqWHCTPV8m671jnrn6LS3xhXWRuHKu1h9QxXi4unc3N1FF8I/qQumhPAxYWWqgdV01qjZARz1viOWg= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5eC0X/7yoWKf7AhE0tKR2eHOCuIiCQvNxLCNVVwYu+qGuCVe4Zr9MYFL77V4GET9ZD6lS/rEru98cgoJYhcnPorVg2HdKhyD+YIKjMhcApBFgBUMd8l7VJjIQQtbplUkcARgBCVx8g+zrAXDW0lMCgmGiYiiSky947CYeJ49e6k=; Message-ID: <922661.46009.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: 3lYNgN8VM1n9T5AexL9pJwkKdT.qD8L5jaNZl4eQWhhTn6oYiXPPWEnnAGRmypx4g_AM58_lSZOG7U4utobrxW4YlrVIu77_iQLWkg.4iQLuNW8ujQnYm9ScVrlmIkB6HzMFiShZf1tEhpqOeR4owsTWntmYg1UCujeMJ.S2cvy3kl7yBPL7iFpl2aGZfeLc1l1IuiPh0g6adHyDvrPvXS2qPaDo7Ujmz8wNPZisL7BXf4a4HabbREdwS4yiKYT8OpHMlogD1KRDWcHG1moCRUO82zpithRggnMnV6qQtwsk8XknDquuZsAde4qv8b0ZwWs2VR5sz_aN.abqGx_AJbSuGWAcJp5Y6u2q Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 25 Aug 2009 09:44:49 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: <35199.91902.qm@web111413.mail.gq1.yahoo.com> Date: Tue, 25 Aug 2009 09:44:49 -0700 (PDT) From: Behcet Sarikaya To: "Laganier, Julien" , "mext@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 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: Tue, 25 Aug 2009 16:44:56 -0000 Hi Julien,=0A=A0 You may wish to add the following text:=0A=0A> Conclusion:= There were argumens both for and against Scenario 2 & 3 so no consensus ca= n be reached. There was a consensus on Scenario 1.=0A> =0A=0ARegards,=0A=0A= Behcet=0A=0A> > -----Original Message-----=0A> > From: Behcet Sarikaya [mai= lto:behcetsarikaya@yahoo.com]=0A> > Sent: Tuesday, August 25, 2009 8:06 AM= =0A> > To: Laganier, Julien; mext@ietf.org=0A> > Subject: Re: [MEXT] DRAFT = MEXT WG minutes @ IETF 75=0A> > =0A> > Hi Julien,=0A> > =A0 Regarding=0A> >= 3. Use cases for flow bindings in the HA->MN direction=0A> > =0A> > the te= xt you have there doesn't match my memory of what happened.=0A> > What I re= member is that Scenario 1 (binding revocation) was OK and most=0A> > of the= discussions by the people (Patil, George, Marcelo, Ryuji, Kent)=0A> > happ= ened on Scenarios 2 & 3. Some people argued for and some argued=0A> > again= st.=0A> > =0A> > I don't have time to go to the audio=A0file and give you a= precise=0A> > transcript.=0A> > My suggestion is to replace current Sectio= n 3 with a summary like the=0A> > above.=0A> > =0A> > Regards,=0A> > =0A> >= Behcet=0A> > =0A> > =0A> > ----- Original Message ----=0A> > > From: "Laga= nier, Julien" =0A> > > To: "mext@ietf.org" =0A> > > Sent: Thursday, August = 20, 2009 6:26:04 PM=0A> > > Subject: [MEXT] DRAFT MEXT WG minutes @ IETF 75= =0A> > >=0A> > > Folks,=0A> > >=0A> > > DRAFT minutes of the Stockholm meet= ing based (entirely) on notes=0A> > taken by=0A> > > William Ivancic & Geor= ge Tsirtsis are available there:=0A> > >=0A> > >=0A> > >=0A> > > Please rev= iew the minutes and send additions and/or corrections ASAP.=0A> > >=0A> > >= Thank you for your support,=0A> > >=0A> > > --julien & Marcelo, MEXT chair= s=0A> > >=0A> > >=0A> > > _______________________________________________= =0A> > > MEXT mailing list=0A> > > MEXT@ietf.org=0A> > > https://www.ietf.o= rg/mailman/listinfo/mext=0A> > =0A> > =0A> > =0A> > =0A=0A=0A=0A From behcetsarikaya@yahoo.com Tue Aug 25 10:02:30 2009 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 39CA83A6B61 for ; Tue, 25 Aug 2009 10:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.142, 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 dUd4s-oPruZr for ; Tue, 25 Aug 2009 10:02:29 -0700 (PDT) Received: from web111401.mail.gq1.yahoo.com (web111401.mail.gq1.yahoo.com [67.195.15.132]) by core3.amsl.com (Postfix) with SMTP id 746183A684F for ; Tue, 25 Aug 2009 10:02:29 -0700 (PDT) Received: (qmail 81972 invoked by uid 60001); 25 Aug 2009 17:02:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251219755; bh=WAKYdffdyzCdJ6JC3vbLcbxi8jcpOFIUFL+H6WV/mxo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rs1yOAuZWgmd5IXV8p64fUqra78N/c8qp/lRnB6AsH55uUQcefUCWmsrVEY8h7+81+hMsQ5DJCtlpQIdbmliEc9lkmPsxG5NFTl3NCQkUYNkox7HTJOShPUyVdMoaRIVKt236/1Sa9jvWTY+PzhZtDp3nnqmv/DSEsz9k/qyJHg= 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:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WUpp+GX+CO1hV2LdBs3Nla7G4ppPOzgoj/LCYqv3ylroQQ7+mfKG0FwK/Xw07/9F+Cj9AXhORacUdzQ2DQxuvj35iNTZlBW1Jo82aFiT5q71fLQZftAAeyr8ajH9AMJ8mn9mQTcDuEgiUmJHN3TisaGuVgtiWJb2oAsl7D/P3Jg=; Message-ID: <189739.80138.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: mydGPeAVM1ng05DPGKaU_tM5dCCmIUzTF1P13ihH0C8zv_yAxfRqQpeQ8nvpmS3jlN_IovYdrwSlkuJReQj2kcULbjmjgl_QvGfMbY5f9YwiDRGRijDjhhEQydQ6k5K.JjVttti7FbW9IYMhZuARUcFKbQrnGf2k0y12X2_Xie.u.CcwG9bndVed3k8yoXqxxe4eZVnQbLaNR1WuBkz5jU0XxvkaZFbxau6.g9dXtvtzR2sg3nUBFX58yYiQse.UQRZm4SEEUipXBihmEQu3aa7nVYPwv5glV.tru_7Jk7dnBu8azaK2MgMpQTB8ptrEXSO15LXvWoKzDx08IprvJGU- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Tue, 25 Aug 2009 10:02:35 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: <35199.91902.qm@web111413.mail.gq1.yahoo.com> <922661.46009.qm@web111406.mail.gq1.yahoo.com> Date: Tue, 25 Aug 2009 10:02:35 -0700 (PDT) From: Behcet Sarikaya To: "Laganier, Julien" , "mext@ietf.org" In-Reply-To: <922661.46009.qm@web111406.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 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: Tue, 25 Aug 2009 17:02:30 -0000 Hi Julien,=0A=A0 Sorry, I need to back up.=0A=0AThere was no consensus call= or hums, etc. during the presentation on this item. Your minutes also do n= ot mention such a consensus call.=0A=0AIMHO it will be too strong to add su= ch sentences to the minutes. So we should not add anything related to the c= onsensus call which did not happen.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A--= --- Original Message ----=0A> From: Behcet Sarikaya =0A> To: "Laganier, Julien" ; "mext@ietf.org" =0A> Sent: Tuesday, August 25, 2009 11:44:49 AM=0A> Subject: Re:= [MEXT] DRAFT MEXT WG minutes @ IETF 75=0A> =0A> Hi Julien,=0A> =A0 You may= wish to add the following text:=0A> =0A> > Conclusion: There were argumens= both for and against Scenario 2 & 3 so no =0A> consensus can be reached. T= here was a consensus on Scenario 1.=0A> > =0A> =0A> Regards,=0A> =0A> Behce= t=0A> =0A> > > -----Original Message-----=0A> > > From: Behcet Sarikaya [ma= ilto:behcetsarikaya@yahoo.com]=0A> > > Sent: Tuesday, August 25, 2009 8:06 = AM=0A> > > To: Laganier, Julien; mext@ietf.org=0A> > > Subject: Re: [MEXT] = DRAFT MEXT WG minutes @ IETF 75=0A> > > =0A> > > Hi Julien,=0A> > > =A0 Reg= arding=0A> > > 3. Use cases for flow bindings in the HA->MN direction=0A> >= > =0A> > > the text you have there doesn't match my memory of what happene= d.=0A> > > What I remember is that Scenario 1 (binding revocation) was OK a= nd most=0A> > > of the discussions by the people (Patil, George, Marcelo, R= yuji, Kent)=0A> > > happened on Scenarios 2 & 3. Some people argued for and= some argued=0A> > > against.=0A> > > =0A> > > I don't have time to go to t= he audio=A0file and give you a precise=0A> > > transcript.=0A> > > My sugge= stion is to replace current Section 3 with a summary like the=0A> > > above= .=0A> > > =0A> > > Regards,=0A> > > =0A> > > Behcet=0A> > > =0A> > > =0A> >= > ----- Original Message ----=0A> > > > From: "Laganier, Julien" =0A> > > = > To: "mext@ietf.org" =0A> > > > Sent: Thursday, August 20, 2009 6:26:04 PM= =0A> > > > Subject: [MEXT] DRAFT MEXT WG minutes @ IETF 75=0A> > > >=0A> > = > > Folks,=0A> > > >=0A> > > > DRAFT minutes of the Stockholm meeting based= (entirely) on notes=0A> > > taken by=0A> > > > William Ivancic & George Ts= irtsis are available there:=0A> > > >=0A> > > >=0A> > > >=0A> > > > Please = review the minutes and send additions and/or corrections ASAP.=0A> > > >=0A= > > > > Thank you for your support,=0A> > > >=0A> > > > --julien & Marcelo,= MEXT chairs=0A> > > >=0A> > > >=0A> > > > ________________________________= _______________=0A> > > > MEXT mailing list=0A> > > > MEXT@ietf.org=0A> > >= > https://www.ietf.org/mailman/listinfo/mext=0A> > > =0A> > > =0A> > > =0A= > > > =0A> =0A> =0A> =0A> =A0 =A0 =A0 =0A> ________________________________= _______________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.iet= f.org/mailman/listinfo/mext=0A=0A=0A=0A From xiayangsong@huawei.com Tue Aug 25 10:18:23 2009 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 DEDD028C4D4 for ; Tue, 25 Aug 2009 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_63=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=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 nWzG3QCu8oYy for ; Tue, 25 Aug 2009 10:18:23 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DF30E28C4E4 for ; Tue, 25 Aug 2009 10:18:22 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOY00KDK02IRK@szxga01-in.huawei.com> for mext@ietf.org; Wed, 26 Aug 2009 01:18:18 +0800 (CST) Received: from X24512z ([10.124.12.62]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOY00HK002ENX@szxga01-in.huawei.com> for mext@ietf.org; Wed, 26 Aug 2009 01:18:18 +0800 (CST) Date: Tue, 25 Aug 2009 12:18:13 -0500 From: Frank Xia To: "Laganier, Julien" , Behcet Sarikaya , mext@ietf.org Message-id: <001b01ca25a8$09b43960$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <35199.91902.qm@web111413.mail.gq1.yahoo.com> Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 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, 25 Aug 2009 17:18:24 -0000 Hi Julien IMHO, it is not proper to have such conclusion given intensive discussion in the mailing, and my offlist discussion with Marcelo in preparing the slides(you were also cc'd, please check.). There WAS concensus on scenario 1, IMO. As for scenario 2, further discussion was encouraged. IMHO, the follow-up is supposed to clarify the charter, not just say "let's have interested people write a draft". This discussion has consumed a lot of energy of the community, and it is time to settle down. BR Frank ----- Original Message ----- From: "Laganier, Julien" To: "Behcet Sarikaya" ; Sent: Tuesday, August 25, 2009 11:12 AM Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 Hi Behcet, I think I'm going to add one line after the existing transcript to describe what I think was the consensus at the end: Conclusion: Scenario 2 & 3 do not make sense. Scenario 1 might make sense, let's have interested people write a draft describing the use case in details and the required extensions to binding revocation. Does that sounds good? --julien > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Tuesday, August 25, 2009 8:06 AM > To: Laganier, Julien; mext@ietf.org > Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 > > Hi Julien, > Regarding > 3. Use cases for flow bindings in the HA->MN direction > > the text you have there doesn't match my memory of what happened. > What I remember is that Scenario 1 (binding revocation) was OK and most > of the discussions by the people (Patil, George, Marcelo, Ryuji, Kent) > happened on Scenarios 2 & 3. Some people argued for and some argued > against. > > I don't have time to go to the audio file and give you a precise > transcript. > My suggestion is to replace current Section 3 with a summary like the > above. > > Regards, > > Behcet > > > ----- Original Message ---- > > From: "Laganier, Julien" > > To: "mext@ietf.org" > > Sent: Thursday, August 20, 2009 6:26:04 PM > > Subject: [MEXT] DRAFT MEXT WG minutes @ IETF 75 > > > > Folks, > > > > DRAFT minutes of the Stockholm meeting based (entirely) on notes > taken by > > William Ivancic & George Tsirtsis are available there: > > > > > > > > Please review the minutes and send additions and/or corrections ASAP. > > > > Thank you for your support, > > > > --julien & Marcelo, MEXT chairs > > > > > > _______________________________________________ > > 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 conny.larsson@ericsson.com Tue Aug 25 22:59:59 2009 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 9CFDA3A703B for ; Tue, 25 Aug 2009 22:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=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 FXGs6KMWjCfD for ; Tue, 25 Aug 2009 22:59:58 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 06C6D3A6920 for ; Tue, 25 Aug 2009 22:59:57 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-50-4a94cf62e295 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 5F.55.18827.26FC49A4; Wed, 26 Aug 2009 08:00:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 07:59:38 +0200 Received: from [127.0.0.1] ([153.88.50.221]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 07:59:38 +0200 Message-ID: <4A94CF47.5030804@ericsson.com> Date: Wed, 26 Aug 2009 07:59:35 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A634580.7090908@it.uc3m.es> In-Reply-To: <4A634580.7090908@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2009 05:59:38.0137 (UTC) FILETIME=[65206890:01CA2612] X-Brightmail-Tracker: AAAAAA== Cc: mext Subject: Re: [MEXT] About flow binding directionality 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, 26 Aug 2009 05:59:59 -0000 Hi Marcelo, I believe the two alternatives that you describe below makes sense. I read the mail thread between you and Hesham and as Hesham I also believe that the MN is the natural point to take decisions on where to send specific data flows. However, there may be cases when the network has information and would like to influence which access a data flow should use. Regards Conny marcelo bagnulo braun wrote: > Hi, > > I have read the long discussion about this. > It seems that in order for the HA to be able to send > meaningful/useful information to the MN about a flow binding, > either: > > 1- the HA knows something relevant that is not available to the > MN about the path conditions between the HA and the different CoAs, > or, > > 2- The HA has enough information to make a clue-full decision and > we want to support a model where the network side influences the MN > choices. > > Let me try to take a stab on those, and i am confident you will let > me know what i am missing. > > Let's start by the first case i.e. > 1- the HA knows something relevant that is not available to the > MN about the path conditions between the HA and the different CoAs, > > Suppose the following scenario. > > +-----+ > | CN | > +-----+ > | > +------------------+ > | ISP3 | > | | > +------------------+ > | > +----------------------------------------+ > | Home Network | > | +----+ | > | | HA | | > | +----+ | > | | | | > | +--------+ +---------+ | > | | | | > +--------|---------------------|---------+ > | | > | | > +------------+ +---------------+ > | ISP1 | | ISP2 | > | | | | > +------------+ +---------------+ > | | > | +----+ | > +--------| MN |----+ > CoA1 +----+ CoA2 > > > So, in case it is not obvious, i describe it a bit > more in detail. > Assume that the home network has 3 providers. > ISP1 that is the same that it is providing one access to the MN ISP1 > that is the same that it is providing the other access to the MN > And ISP3, that is connected to the CN > > (i know this is a somehow forced example, but it is easily generalizable > to more complex scenarios, where the HA could play a useful role in > traffic engineering for the home network) > > So, for obvious reasons, the traffic flowing from the MN to the HA > through > CoA1 will flow through ISP1 and the traffic flowing from the MN to the > HA through CoA2 will flow through ISP2. > > Now, suppose that the link between the ISP1 and the home network is > becoming > congested, or is about to reach the expected quota or whatever traffic > management issue that is perfectly known to the home network. > > Since the HA, as it is located in the home network, it would make sense > that the HA can have easy access to that circumstance and it would > make sense that the HA asks the MN to move the traffic from the CoA1 > to the > CoA2. > > Of course, this is not all the information that is needed to actually > decide > what is the best CoA, but i think that the point is that this is relevant > information for the MN to have. Of course, the problem is that what if > the MN > actually believes that the other CoA is the right one to use? > I believe that this is up to the MN policy and internal heuristics, > about > how to make a reasonable decision considering all the input it has. > At this point, the point that i am trying to make is that the HA may have > access to information that the MN has not and if anything, if the MN > has no preference, it can follow the HA suggestions. > > Does this makes sense to you? > > Let me try the second case i.e. > > The HA has enough information to make a clue-full decision and > we want to support a model where the network side influences the MN > choices. > > Now, in order for this work, we need to assume a bunch of things, > which will certainly not be true in the general case, but may be > true in some specific cases. > > First of all, we need to agree whether there is some value in allowing > the HA (i.e. the network side) to micro manage the MN. > If not, then, this case has no value. > If yes, then i guess that under a set of assumptions, this can be done. > I understand that the assumptions basically comes down to the things > that are needed for the HA to have the information. > > So these assumptions include: > - The HA knows what access is associated to each CoA > - The HA knows the situation of the visited network, including > the radio access link with the MN. This essentially > implies that the HA and the visited network are the same admin domain. > - The HA also knows the situation of the rest of the network, in order > to have a full picture of the different paths. > - The HA knows something about the flows. This can be achieved cause > the apps running in the MN are managed by the network, or cause they > usually use the well known ports in a reasonable way or because they > the late binding approach (i.e. the HA moves the existent flows once > it is aware of their characteristics e.g. the rate fo the flow) > > So, maybe the assumptions can be relaxed, but i think that the point is > that under a set of assumptions that may match to a viable scenario, > it is possible for the HA to manage the MN. > > So, does people agree that this is a viable scenario? > And does people see any value in having the network side managing the MN? > > Fire up. > > We should try to wrap this up for ietf75.... > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Wed Aug 26 05:06:09 2009 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 472893A68C6 for ; Wed, 26 Aug 2009 05:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 R-asIBnRIlze for ; Wed, 26 Aug 2009 05:06:08 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1075C3A683D for ; Wed, 26 Aug 2009 05:06:07 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (218.Red-79-154-162.dynamicIP.rima-tde.net [79.154.162.218]) by smtp01.uc3m.es (Postfix) with ESMTP id 9CD01BA7F56; Wed, 26 Aug 2009 13:36:54 +0200 (CEST) Message-ID: <4A951E58.1010408@it.uc3m.es> Date: Wed, 26 Aug 2009 13:36:56 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Frank Xia References: <35199.91902.qm@web111413.mail.gq1.yahoo.com> <001b01ca25a8$09b43960$3e0c7c0a@china.huawei.com> In-Reply-To: <001b01ca25a8$09b43960$3e0c7c0a@china.huawei.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-5.6.0.1016-16848.003 Cc: "Laganier, Julien" , mext@ietf.org Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 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, 26 Aug 2009 12:06:09 -0000 My recollection is that: - people didn't find any problem with case 1. We are however not chartered to do this at this point and we should handle this through a recharter process ,where this item will be considered by the wg along with all the other potential items we could do work on (need to talk to the AD about how/when to start this recharter process) - for the scenario 2, people didn't find a clear use case, so more disucssion is needed. Regards, marcelo Frank Xia escribió: > Hi Julien > > IMHO, it is not proper to have such conclusion given > intensive discussion in the mailing, and my offlist discussion > with Marcelo in preparing the slides(you were also cc'd, > please check.). > > There WAS concensus on scenario 1, IMO. As for scenario 2, > further discussion was encouraged. > > IMHO, the follow-up is supposed to clarify the charter, > not just say "let's have interested people write a draft". > This discussion has consumed a lot of energy of the > community, and it is time to settle down. > > BR > Frank > > ----- Original Message ----- From: "Laganier, Julien" > > To: "Behcet Sarikaya" ; > Sent: Tuesday, August 25, 2009 11:12 AM > Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 > > > Hi Behcet, > > I think I'm going to add one line after the existing transcript to > describe what I think was the consensus at the end: > > Conclusion: Scenario 2 & 3 do not make sense. Scenario 1 might make > sense, let's have interested people write a draft describing the use > case in details and the required extensions to binding revocation. > > Does that sounds good? > > --julien > >> -----Original Message----- >> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >> Sent: Tuesday, August 25, 2009 8:06 AM >> To: Laganier, Julien; mext@ietf.org >> Subject: Re: [MEXT] DRAFT MEXT WG minutes @ IETF 75 >> >> Hi Julien, >> Regarding >> 3. Use cases for flow bindings in the HA->MN direction >> >> the text you have there doesn't match my memory of what happened. >> What I remember is that Scenario 1 (binding revocation) was OK and most >> of the discussions by the people (Patil, George, Marcelo, Ryuji, Kent) >> happened on Scenarios 2 & 3. Some people argued for and some argued >> against. >> >> I don't have time to go to the audio file and give you a precise >> transcript. >> My suggestion is to replace current Section 3 with a summary like the >> above. >> >> Regards, >> >> Behcet >> >> >> ----- Original Message ---- >> > From: "Laganier, Julien" >> > To: "mext@ietf.org" >> > Sent: Thursday, August 20, 2009 6:26:04 PM >> > Subject: [MEXT] DRAFT MEXT WG minutes @ IETF 75 >> > >> > Folks, >> > >> > DRAFT minutes of the Stockholm meeting based (entirely) on notes >> taken by >> > William Ivancic & George Tsirtsis are available there: >> > >> > >> > >> > Please review the minutes and send additions and/or corrections ASAP. >> > >> > Thank you for your support, >> > >> > --julien & Marcelo, MEXT chairs >> > >> > >> > _______________________________________________ >> > 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 > From wwwrun@core3.amsl.com Mon Aug 31 10:35:34 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E233B28C2AC; Mon, 31 Aug 2009 10:35:34 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090831173534.E233B28C2AC@core3.amsl.com> Date: Mon, 31 Aug 2009 10:35:34 -0700 (PDT) Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Document Action: 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks' to Informational 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: Mon, 31 Aug 2009 17:35:35 -0000 The IESG has approved the following document: - 'Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks ' as an Informational RFC 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: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-04.txt Technical Summary This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. Working Group Summary This is product of the MEXT WG. Document Quality Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies. Personnel The Document Shepherd is Marcelo Braun, and the responsible Area Director is Jari Arkko. RFC Editor Note Please change the following: OLD: (e.g. the Gatelink system) NEW: (e.g. local networks available while on a gate) OLD: (currently on the surface when connected to a wired Gatelink system) NEW: (currently on the surface when connected to a wired link at a gate) OLD: (link technologies and acronyms are briefly defined in Appendix A. NEW: (link technologies and acronyms are briefly defined in Appendix A). OLD: rouge NEW rogue