From fu@cs.uni-goettingen.de Wed Mar 4 16:41:54 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA01C3A67A8 for ; Wed, 4 Mar 2009 16:41:54 -0800 (PST) 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_DE=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 xNEKUGfXosBJ for ; Wed, 4 Mar 2009 16:41:53 -0800 (PST) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id 519B03A6954 for ; Wed, 4 Mar 2009 16:41:53 -0800 (PST) Received: from p548aab9d.dip0.t-ipconnect.de ([84.138.171.157] helo=[192.168.1.95]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Lf1fI-0007Py-NU for mobopts@irtf.org; Thu, 05 Mar 2009 01:42:21 +0100 Message-ID: <49AF2127.7090805@cs.uni-goettingen.de> Date: Thu, 05 Mar 2009 01:47:35 +0100 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie Subject: [Mobopts] CFP: IEEE ICNP 2009 (submission deadline in 6 weeks: April 17, 2009 -- HARD!) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:41:54 -0000 [Sincere apologies if you receive multiple copies of this CFP.] CALL FOR PAPERS ICNP 2009 17th IEEE International Conference on Network Protocols October 13-16, 2009 Princeton, New Jersey, USA http://www.ieee-icnp.org/2009 ICNP, the IEEE International Conference on Network Protocols is the premier conference covering all aspects of network protocols. ICNP will be held in its seventeenth year at Princeton, New Jersey from October 13-16th, 2009. Papers with significant research contributions on network protocols are solicited for submission. Papers related to all aspects of network protocols including design, implementation, analysis, performance and specification are relevant. Papers must not be previously published nor under review in any other conference or journal. Only original papers that have not been published previously or submitted for publication and under review by another conference or journal elsewhere can be submitted. Papers containing plagiarized material will be subject to the IEEE Plagiarism policy and will be rejected without review. Topics of interest include, but are not limited to: • Protocol design, implementation, testing and analysis. • Measurement studies of protocol performance. • Protocols for wireless ad hoc and sensor networks. • Protocols for peer-to-peer networks. • Protocols for specific functions such as routing, flow/congestion control, network management. • Protocols for security, survivability and fault-tolerance. Papers must be directly relevant to protocols. Papers on general networking where protocols are only a secondary focus will be considered only if they are of exceptionally high quality. Papers will be subject to a double-blind review process. The identity of authors and referees will not be revealed to each other. To ensure blind reviewing, the authors' names and affiliations should not appear in the paper. Bibliographic references should protect the authors' anonymity. Papers should adhere to the IEEE format and should not be more than 10 pages. The font size should not be smaller than 10pt. Further instructions will be posted on the ICNP website (http://www.ieee-icnp.org/2009). Authors of accepted papers will be expected to register for the conference and the paper must be presented at the conference in order for the paper to appear in the conference proceedings. Important Dates: Abstract Submission: April 10, 2009 8:59 P.M. EDT Paper Submission: April 17, 2009 8:59 P.M. EDT (Hard Deadline) Notification of Acceptance: July 28, 2009 Camera Ready Version Due: September 4, 2009 Steering Committee: David Lee (Chair) Ohio State University, USA Ken Calvert (Vice Chair) University of Kentucky, USA Kevin Almeroth University of California, Santa Barbara, USA Mostafa Ammar Georgia Tech, USA Sonia Fahmy Purdue University, USA Mohamed Gouda University of Texas, Austin, USA Teruo Higashino Osaka University, Japan Krishan Sabnani Bell Labs Research, USA Advisory Board: Simon Lam University of Texas, Austin, USA Mike T. Liu Ohio State University, USA Raymond Miller University of Maryland, USA General Chairs: K.K. Ramakrishnan AT & T Labs Research, USA Henning Schulzrinne Columbia University, USA Program Chairs: Timothy Griffin University of Cambridge, UK Srikanth V. Krishnamurthy University of California, Riverside, USA For more details, visit the conference webpage: http://www.ieee-icnp.org/2009 Regards, Xiaoming Fu IEEE ICNP'09 Publicity Chair From rajeev_koodli@yahoo.com Fri Mar 6 16:37:43 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991D728C165 for ; Fri, 6 Mar 2009 16:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799] 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 GUwuOejXmROJ for ; Fri, 6 Mar 2009 16:37:43 -0800 (PST) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id E7A6228C161 for ; Fri, 6 Mar 2009 16:37:42 -0800 (PST) Received: (qmail 68742 invoked by uid 60001); 7 Mar 2009 00:38:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236386293; bh=g4lfcX2kwQV16vNjRWXHn1LjBsUvRaJmRr2LWeELNpE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=eHkxFFxAfc6X5u+KLMJXkdvrQQ6OM+XEaO+W/5SxCwcKsoaQbPRUW9Q4MwgUDKPKVG7tBLHKR4dwZln/gTjaWvoNk4b6WkM9OuFg9QD7pl7l2xxAQyKb+71mza++SVcbytHdMS2utaNXtYOMRAo7oFhQpx9QJsGo1i8REJ18XDI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=mbmoRbedWz0lQUVfleAFSHJEmT1yBTu3vxUHXo6pbUwr526ZyfYVF/VBUN6SlZEgpv5xeNSzdpJp7vfXCcJGPuQQCLprJHntVbVofMKXW9tB5HsRhXDDnWHJgQ7Bc9qEiLzluMQ12xzwwz+DRmwxhPP16Q4Uxw1KT9oU4I6Tc3Y=; Message-ID: <742598.65589.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: KwDIY3oVM1mkaT2tPmm25ZWrOAXXsv1eUTZBkrCNkQhKjH7sGURzNj63Yf9.n6k4tFzCJlYbJIA96ZqIYUA5iyreKz.KRguT6sAXjcoumkL24gz3JOKzsoM_MgshfhsygW0FEDCzGzEO1dP5M1DZAiUpNYiUXr96fK4Iwwv0G.ceOODlPN3gnteFXoWyw.UqELPtvJlD0P2irAp6mIsIyhkWsCJO2Q79DzgF4HHqW2QtXT0MA7gN5CNXY0_KeQu1qfb95T3OOVjDBGp92QUMjJwZRELa Received: from [70.231.128.74] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 06 Mar 2009 16:38:13 PST X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1 Date: Fri, 6 Mar 2009 16:38:13 -0800 (PST) From: Rajeev Koodli To: mobopts@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1428476705-1236386293=:65589" Subject: [Mobopts] Fw: draft-irtf-mobopts-mpa-framework-05 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 00:37:43 -0000 --0-1428476705-1236386293=:65589 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Fri, 3/6/09, Rajeev Koodli wrote: From: Rajeev Koodli Subject: draft-irtf-mobopts-mpa-framework-05 To: falk@bbn.com Cc: irsg@isi.edu, rajeev_koodli@yahoo.com Date: Friday, March 6, 2009, 4:37 PM Hi Aaron, This is another MobOpts RG document needs IRSG review. I have=A0captured=A0= the details on the tracker: http://trac.tools.ietf.org/group/irtf/trac/ticket/27 Could you please assign a reviewer so that we can=A0progress the document? Thank you. -Rajeev=A0=A0 =A0=A0=A0 =0A=0A=0A --0-1428476705-1236386293=:65589 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


--- On Fri, 3/6/09, Rajeev Koodli = <rajeev_koodli@yahoo.com> wrote:
=
From: Rajeev Koodli <rajeev_koodli@yahoo.com>
Subject: draft-irtf= -mobopts-mpa-framework-05
To: falk@bbn.com
Cc: irsg@isi.edu, rajeev_k= oodli@yahoo.com
Date: Friday, March 6, 2009, 4:37 PM



Hi Aaron,
This is another MobOpts RG document needs IRSG review. I have= =A0captured=A0the details on the tracker:

http://trac.tools.= ietf.org/group/irtf/trac/ticket/27

Could you please assign a review= er so that we can=A0progress
the document?

Thank you.

-Rajeev=A0=A0 =A0=A0=A0

=0A=0A --0-1428476705-1236386293=:65589-- From Basavaraj.Patil@nokia.com Tue Mar 10 20:40:19 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942F63A6833 for ; Tue, 10 Mar 2009 20:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.781 X-Spam-Level: X-Spam-Status: No, score=-4.781 tagged_above=-999 required=5 tests=[AWL=-1.281, BAYES_00=-2.599, MANGLED_SOLTNS=2.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 nu4+r8mKmnxb for ; Tue, 10 Mar 2009 20:40:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 33EE13A681D for ; Tue, 10 Mar 2009 20:40:17 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2B3eSLq006603; Tue, 10 Mar 2009 22:40:51 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 05:40:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Mar 2009 05:40:33 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 11 Mar 2009 04:40:33 +0100 From: To: Date: Wed, 11 Mar 2009 04:40:32 +0100 Thread-Topic: [Mobopts] IRSG Poll for I-D:draft-irtf-mobopts-location-privacy-solutions Thread-Index: AcmMoAJrECRqzS1pjkyOYuqkhWO/NwMhdCAQAW723rAAxi0cVw== Message-ID: References: <4D35478224365146822AE9E3AD4A266606FBB312@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266606FBB312@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2009 03:40:33.0287 (UTC) FILETIME=[21CF5970:01C9A1FB] X-Nokia-AV: Clean Cc: basavarj.patil@nokia.com, mobopts@irtf.org Subject: Re: [Mobopts] IRSG Poll for I-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:40:19 -0000 Hello, The deadline for the IRSG poll for I-D: draft-irtf-mobopts-location-privacy= -solutions expired on Feb 26th. So far we have received one no objection vote. Would like to hear from a fe= w other people. I am extending the deadline to March 15th. Please respond to the poll. Again the choices are: o 'Ready to publish' -- requires a thorough read and reasonably detailed review o 'Not ready to publish' -- requires a thorough read, reasonably detailed review, and actionable comments. o 'No objection' -- I don't object if this document goes forward; I've read the document (perhaps quickly); I have some small comments which are not show stoppers; I don't have great expertise in the area. o 'Request more time to review' -- a commitment to provide a thorough review in a specified period of time. Rgds, -Basavaraj > > -----Original Message----- > > From: mobopts-bounces@irtf.org > > [mailto:mobopts-bounces@irtf.org] On Behalf Of > > Basavaraj.Patil@nokia.com > > Sent: Wednesday, February 11, 2009 3:25 PM > > To: irsg@isi.edu > > Cc: Basavaraj.Patil@nokia.com; mobopts@irtf.org > > Subject: [Mobopts] IRSG Poll for > > I-D:draft-irtf-mobopts-location-privacy-solutions > > > > > > Hello, > > > > The Mobopts RG I-D: > > draft-irtf-mobopts-location-privacy-solutions has completed IRSG > > review. > > The revised version of the I-D (Rev 12) which incorporates the > > comments is now available at: > > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-locatio > > n-privacy-solu > > tions-12.txt. > > > > Michael Welzl who has performed the IRSG review and the Mobopts RG > > have approved the revised I-D to be progressed for publication. > > > > The IRSG review is available from the IRTF tracker web page at: > > http://trac.tools.ietf.org/group/irtf/trac/ticket/24 > > > > Please consider this email as the start of a two week IRSG > poll. The > > deadline for this poll is : Feb 26th, 2009. > > > > Please use one of the poll responses defined below. > > The possible poll responses are: > > > > o 'Ready to publish' -- requires a thorough read and reasonably > > detailed review > > > > o 'Not ready to publish' -- requires a thorough read, > reasonably > > detailed review, and actionable comments. > > > > o 'No objection' -- I don't object if this document > goes forward; > > I've read the document (perhaps quickly); I have some small > > comments which are not show stoppers; I don't have great > > expertise in the area. > > > > o 'Request more time to review' -- a commitment to provide a > > thorough review in a specified period of time. > > > > The most relevant rule is that "At least two other IRSG members > > (besides the one sponsoring the document) need to vote 'ready to > > publish' for the document to move forward." > > > > Please review and submit your vote. > > > > -Basavaraj > > Document Shepherd for the I-D > > > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > http://www.irtf.org/mailman/listinfo/mobopts > > This email and any attachments may contain legally privileged and/or confid= ential information of Starent Networks, Corp. and is intended only for the = individual or entity named in the message. The information transmitted may= not be used to create or change any contractual obligations of Starent Net= works, Corp. Any review, retransmission, dissemination or other use of, or= taking of any action in reliance upon this e-mail and its attachments by p= ersons or entities other than the intended recipient is prohibited. If you = are not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to postmaster@starentnetwor= ks.com -- and destroy all copies of this message and any attachments withou= t reading or disclosing their contents. Thank you. From rajeev.koodli@gmail.com Sat Mar 14 08:51:02 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581003A69B7 for ; Sat, 14 Mar 2009 08:51:02 -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 kP0sFz7dUCTk for ; Sat, 14 Mar 2009 08:51:01 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 4F35A3A6B02 for ; Sat, 14 Mar 2009 08:51:01 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2174909rvf.7 for ; Sat, 14 Mar 2009 08:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=1KT13t8X9BSUkfMGDzZ0mZ0uKwujyNI+PHiglXlQgTc=; b=EkQI17/tIrllOJeiRKlg9OQ69H5E9H7LCYAr/vUpixYCmkEhqBdCjEl14MHCJ0CPvE v93tDvahtmmIv/M8sMRgI6mh7M634YJ+wI7TYUWwE7VJXffjRiVMLudBWI1WyBXMaVuq ivBkKZf4uehmqNM1D2+zPubRK3TNC2c1ACFIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=sXhlhGgGLW8kR22QrFmVS2WhR6GaIRfmhGdfcG4b9JgvdoiPmpNFC1OCHW7BL95pqv n72KLxdsfz7RLdR3szTt156r1Hgp5dtwrRMVn9EYjGW4cZNsDZmg9i4Qi+YgI10c66uA XoAJAg9KTjcPoY6KQaRohOLboL1MUNXEXl15U= MIME-Version: 1.0 Received: by 10.140.174.11 with SMTP id w11mr1252460rve.83.1237045901128; Sat, 14 Mar 2009 08:51:41 -0700 (PDT) Date: Sat, 14 Mar 2009 08:51:41 -0700 Message-ID: <3d57679a0903140851s6da8a28ufb168d6cd32993ec@mail.gmail.com> From: Rajeev Koodli To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Mobopts] Mobiarch X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 15:51:02 -0000 Hello folks, many of you may be interested in this.. http://user.informatik.uni-goettingen.de/~mobiarch/2009/ Regards, -Rajeev From wesley.m.eddy@nasa.gov Wed Mar 11 08:22:07 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416C828C1FC for ; Wed, 11 Mar 2009 08:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 p0-KWuWq3DJR for ; Wed, 11 Mar 2009 08:22:02 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 9748E28C1E4 for ; Wed, 11 Mar 2009 08:22:02 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id A86E196E4; Wed, 11 Mar 2009 10:22:37 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n2BFMho7008519; Wed, 11 Mar 2009 10:22:43 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Wed, 11 Mar 2009 10:22:37 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: "Basavaraj.Patil@nokia.com" , "irsg@ISI.EDU" Date: Wed, 11 Mar 2009 10:22:37 -0500 Thread-Topic: [Mobopts] IRSG Poll forI-D:draft-irtf-mobopts-location-privacy-solutions Thread-Index: AcmMoAJrECRqzS1pjkyOYuqkhWO/NwMhdCAQAW723rAAxi0cVwAYORGw Message-ID: References: <4D35478224365146822AE9E3AD4A266606FBB312@exchtewks3.starentnetw orks.com> 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 X-Mailman-Approved-At: Sat, 14 Mar 2009 08:53:38 -0700 Cc: "mobopts@irtf.org" Subject: Re: [Mobopts] IRSG Poll forI-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:22:07 -0000 You can record a vote for "ready to publish" from me. The document is well laid out and the relationships between it and the many pieces of existing work are well described within the document. One substance nit is that the requirements listed in section 3 lack any associated "rationale" statements. Including some rationale alongside each requirement is general practice in formal requirements management. Another nit is that the document generally phrases the problem as being to hide the mapping between "the home address and the care-of address". I believe it should really be between "the home address and an in-use care-of address", in order to ease later understanding of the applicability to monami6, dsmip, or other extensions that the conclusions say may be in-scope in the future for clarification. The problem of location privacy is very complex, and the document does a good job of tracking each concern and clearly explaining what appears in each relevant header and option field in the stack so that the impact can be readily assessed. I appreciated this. There are some editorial nits, but I believe they're minor enough that the RFC Editor will fix them. --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- =20 >-----Original Message----- >From: mobopts-bounces@irtf.org=20 >[mailto:mobopts-bounces@irtf.org] On Behalf Of=20 >Basavaraj.Patil@nokia.com >Sent: Tuesday, March 10, 2009 11:41 PM >To: irsg@ISI.EDU >Cc: basavarj.patil@nokia.com; mobopts@irtf.org >Subject: Re: [Mobopts] IRSG Poll=20 >forI-D:draft-irtf-mobopts-location-privacy-solutions > > >Hello, > >The deadline for the IRSG poll for I-D:=20 >draft-irtf-mobopts-location-privacy-solutions expired on Feb 26th. > >So far we have received one no objection vote. Would like to=20 >hear from a few other people. >I am extending the deadline to March 15th. Please respond to the poll. > >Again the choices are: > > o 'Ready to publish' -- requires a thorough read and reasonably > detailed review > > o 'Not ready to publish' -- requires a thorough read, > reasonably detailed review, and actionable comments. > > o 'No objection' -- I don't object if this document > goes forward; > I've read the document (perhaps quickly); I have some small > comments which are not show stoppers; I don't have great > expertise in the area. > > o 'Request more time to review' -- a commitment to provide a > thorough review in a specified period of time. > >Rgds, >-Basavaraj > >> > -----Original Message----- >> > From: mobopts-bounces@irtf.org >> > [mailto:mobopts-bounces@irtf.org] On Behalf Of >> > Basavaraj.Patil@nokia.com >> > Sent: Wednesday, February 11, 2009 3:25 PM >> > To: irsg@isi.edu >> > Cc: Basavaraj.Patil@nokia.com; mobopts@irtf.org >> > Subject: [Mobopts] IRSG Poll for >> > I-D:draft-irtf-mobopts-location-privacy-solutions >> > >> > >> > Hello, >> > >> > The Mobopts RG I-D: >> > draft-irtf-mobopts-location-privacy-solutions has completed IRSG >> > review. >> > The revised version of the I-D (Rev 12) which incorporates the >> > comments is now available at: >> > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-locatio >> > n-privacy-solu >> > tions-12.txt. >> > >> > Michael Welzl who has performed the IRSG review and the Mobopts RG >> > have approved the revised I-D to be progressed for publication. >> > >> > The IRSG review is available from the IRTF tracker web page at: >> > http://trac.tools.ietf.org/group/irtf/trac/ticket/24 >> > >> > Please consider this email as the start of a two week IRSG >> poll. The >> > deadline for this poll is : Feb 26th, 2009. >> > >> > Please use one of the poll responses defined below. >> > The possible poll responses are: >> > >> > o 'Ready to publish' -- requires a thorough read and=20 >reasonably >> > detailed review >> > >> > o 'Not ready to publish' -- requires a thorough read, >> reasonably >> > detailed review, and actionable comments. >> > >> > o 'No objection' -- I don't object if this document >> goes forward; >> > I've read the document (perhaps quickly); I have some small >> > comments which are not show stoppers; I don't have great >> > expertise in the area. >> > >> > o 'Request more time to review' -- a commitment to provide a >> > thorough review in a specified period of time. >> > >> > The most relevant rule is that "At least two other IRSG members >> > (besides the one sponsoring the document) need to vote 'ready to >> > publish' for the document to move forward." >> > >> > Please review and submit your vote. >> > >> > -Basavaraj >> > Document Shepherd for the I-D >> > >> > _______________________________________________ >> > Mobopts mailing list >> > Mobopts@irtf.org >> > http://www.irtf.org/mailman/listinfo/mobopts >> > > > >This email and any attachments may contain legally privileged=20 >and/or confidential information of Starent Networks, Corp. and=20 >is intended only for the individual or entity named in the=20 >message. The information transmitted may not be used to=20 >create or change any contractual obligations of Starent=20 >Networks, Corp. Any review, retransmission, dissemination or=20 >other use of, or taking of any action in reliance upon this=20 >e-mail and its attachments by persons or entities other than=20 >the intended recipient is prohibited. If you are not the=20 >intended recipient, please notify the sender immediately -- by=20 >replying to this message or by sending an email to=20 >postmaster@starentnetworks.com -- and destroy all copies of=20 >this message and any attachments without reading or disclosing=20 >their contents. Thank you. >_______________________________________________ >Mobopts mailing list >Mobopts@irtf.org >http://www.irtf.org/mailman/listinfo/mobopts >= From stephen.farrell@cs.tcd.ie Wed Mar 11 09:11:09 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B451828C17C for ; Wed, 11 Mar 2009 09:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.256 X-Spam-Level: * X-Spam-Status: No, score=1.256 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3, RDNS_DYNAMIC=0.1, SARE_SUB_RAND_LETTRS4=0.799] 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 iC0J7n+TjtF1 for ; Wed, 11 Mar 2009 09:11:08 -0700 (PDT) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 6987C28C177 for ; Wed, 11 Mar 2009 09:11:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 331ED1003F4DA; Wed, 11 Mar 2009 16:11:43 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 552uXBc0QqSR; Wed, 11 Mar 2009 16:11:42 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 25C5F1003F4D8; Wed, 11 Mar 2009 16:11:41 +0000 (GMT) Message-ID: <49B7E2D3.3050605@cs.tcd.ie> Date: Wed, 11 Mar 2009 16:12:03 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" References: <4D35478224365146822AE9E3AD4A266606FBB312@exchtewks3.starentnetw orks.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 14 Mar 2009 08:53:38 -0700 Cc: "irsg@ISI.EDU" , "mobopts@irtf.org" , "Basavaraj.Patil@nokia.com" Subject: Re: [Mobopts] [IRSG] IRSG Poll forI-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 16:11:09 -0000 Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote: > You can record a vote for "ready to publish" from me. Same here. My non-blocking comments are below. Feel free to take 'em on board or not, as you see fit. Stephen. #1 Its a bit surprising that active attackers aren't considered. Maybe adding a justification for that would be good? I guess the danger is that someone goes and implements all of this and claims to have produced a "secure" solution, but in fact has only produced something good against passive attacks. #2 section 5.1, what mode of operation is used for the generation of the encrypted home address? For AES I think ECB is ok, but if a block cipher with a smaller block (e.g. 3DES) is used, then you should probably not use ECB as that'd expose some information if Kpm is re-used and if the home address structure is sensitive. I've no idea if that's significant or not, but specifying CBC mode for shorter-block ciphers would I think remove the potential vulnerability. (3DES with ECB mode might also allow some non-obvious cut'n'paste attacks if Kpm is re-used, though those'd be active attacks and so presumably out of scope.) Nits: #1 1st sentence of section 1 is missing a word, maybe "problem" #2, p12: s/If such/If so/ From qiuying@i2r.a-star.edu.sg Mon Mar 16 03:37:12 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E96628C111 for ; Mon, 16 Mar 2009 03:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=-1.954, BAYES_40=-0.185, MANGLED_LIST=2.3, SARE_SUB_RAND_LETTRS4=0.799, 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 skkx650zCnKL for ; Mon, 16 Mar 2009 03:37:11 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id 08AB33A6936 for ; Mon, 16 Mar 2009 03:37:10 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2GAbjAc014552; Mon, 16 Mar 2009 18:37:45 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 18:38:50 +0800 Message-ID: <65C0B939696D45A68AF8962E358A19DE@t3400> From: "QIU Ying" To: "Stephen Farrell" , "Eddy, Wesley M. \(GRC-RCN0\)[Verizon]" References: <4D35478224365146822AE9E3AD4A266606FBB312@exchtewks3.starentnetw orks.com> <49B7E2D3.3050605@cs.tcd.ie> Date: Mon, 16 Mar 2009 18:37:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 16 Mar 2009 10:38:50.0122 (UTC) FILETIME=[64C136A0:01C9A623] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-16_02:2009-03-13, 2009-03-16, 2009-03-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903160035 Cc: irsg@ISI.EDU, Basavaraj.Patil@nokia.com, mobopts@irtf.org Subject: Re: [Mobopts] [IRSG] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 10:37:12 -0000 Hi, Stephen Thanks for your review and support. For the #1 comment regarding to active attacks: we discussed this issue before, but it is too difficult to enumerate all of active attacks. In fact, if an attacker launches an active attack signaling, the mobile node has 2 choices: 1) simply drop the signaling message according to its own access policy, hence it is not much for further discussion. 2) accept the signaling messages, then the MN must response the signaling. Hence the attacker is treated as a correspondent node and the correspondent node is still not able to map the real home address and the in-use care-of-address according to our solution. For the #2 comment regarding to using ECB in DES: since KM is derived from Kbm: Kpm = HMAC_SHA1(Kbm, 0), and Kbm is always changed by every RR process, a Kpm can not be re-used during the communication. By the way, the example you describe here, I prefer to call it as passive attack because it does not tempt messages from MN or HA directly. Please correct me if I am wrong. Regards and Thanks Qiu Ying ----- Original Message ----- From: "Stephen Farrell" To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" Cc: ; ; Sent: Thursday, March 12, 2009 12:12 AM Subject: Re: [Mobopts] [IRSG] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions > > Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote: >> You can record a vote for "ready to publish" from me. > > Same here. > > My non-blocking comments are below. Feel free to take 'em > on board or not, as you see fit. > > Stephen. > > #1 Its a bit surprising that active attackers aren't considered. > Maybe adding a justification for that would be good? I guess the > danger is that someone goes and implements all of this and claims > to have produced a "secure" solution, but in fact has only produced > something good against passive attacks. > > #2 section 5.1, what mode of operation is used for the generation > of the encrypted home address? For AES I think ECB is ok, but if > a block cipher with a smaller block (e.g. 3DES) is used, then you > should probably not use ECB as that'd expose some information if > Kpm is re-used and if the home address structure is sensitive. > I've no idea if that's significant or not, but specifying CBC mode > for shorter-block ciphers would I think remove the potential > vulnerability. (3DES with ECB mode might also allow some non-obvious > cut'n'paste attacks if Kpm is re-used, though those'd be active > attacks and so presumably out of scope.) > > Nits: > > #1 1st sentence of section 1 is missing a word, maybe "problem" > > #2, p12: s/If such/If so/ > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From qiuying@i2r.a-star.edu.sg Mon Mar 16 03:49:52 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7C128C12D for ; Mon, 16 Mar 2009 03:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 S7vJTD-nrBDE for ; Mon, 16 Mar 2009 03:49:51 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id 0C4363A6407 for ; Mon, 16 Mar 2009 03:49:50 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n2GAoS5H027433; Mon, 16 Mar 2009 18:50:31 +0800 Received: from t3400 ([10.217.141.175]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 18:51:34 +0800 Message-ID: <1B28D7280C5949B093FD86BC71D8D61D@t3400> From: "QIU Ying" To: "Eddy, Wesley M. \(GRC-RCN0\)[Verizon]" , , References: <4D35478224365146822AE9E3AD4A266606FBB312@exchtewks3.starentnetworks.com> Date: Mon, 16 Mar 2009 18:50:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 16 Mar 2009 10:51:34.0748 (UTC) FILETIME=[2C81E1C0:01C9A625] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-03-16_02:2009-03-13, 2009-03-16, 2009-03-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0903160038 Cc: mobopts@irtf.org Subject: Re: [Mobopts] IRSG Poll forI-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 10:49:52 -0000 Hi, Wesley Thanks for your review and support. My response inline > You can record a vote for "ready to publish" from me. > > The document is well laid out and the relationships between it > and the many pieces of existing work are well described within > the document. > > One substance nit is that the requirements listed in section > 3 lack any associated "rationale" statements. Including some > rationale alongside each requirement is general practice in > formal requirements management. Do you mean we should brief the home/correspondent binding update and the RR procedure? OK, we will add it. > Another nit is that the document generally phrases the > problem as being to hide the mapping between "the home > address and the care-of address". I believe it should > really be between "the home address and an in-use > care-of address", in order to ease later understanding > of the applicability to monami6, dsmip, or other > extensions that the conclusions say may be in-scope in > the future for clarification. OK. Thanks for your observation. Regards and Thanks Qiu Ying > > The problem of location privacy is very complex, and the > document does a good job of tracking each concern and > clearly explaining what appears in each relevant header > and option field in the stack so that the impact can be > readily assessed. I appreciated this. > > There are some editorial nits, but I believe they're minor > enough that the RFC Editor will fix them. > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > >>-----Original Message----- >>From: mobopts-bounces@irtf.org >>[mailto:mobopts-bounces@irtf.org] On Behalf Of >>Basavaraj.Patil@nokia.com >>Sent: Tuesday, March 10, 2009 11:41 PM >>To: irsg@ISI.EDU >>Cc: basavarj.patil@nokia.com; mobopts@irtf.org >>Subject: Re: [Mobopts] IRSG Poll >>forI-D:draft-irtf-mobopts-location-privacy-solutions >> >> >>Hello, >> >>The deadline for the IRSG poll for I-D: >>draft-irtf-mobopts-location-privacy-solutions expired on Feb 26th. >> >>So far we have received one no objection vote. Would like to >>hear from a few other people. >>I am extending the deadline to March 15th. Please respond to the poll. >> >>Again the choices are: >> >> o 'Ready to publish' -- requires a thorough read and reasonably >> detailed review >> >> o 'Not ready to publish' -- requires a thorough read, >> reasonably detailed review, and actionable comments. >> >> o 'No objection' -- I don't object if this document >> goes forward; >> I've read the document (perhaps quickly); I have some small >> comments which are not show stoppers; I don't have great >> expertise in the area. >> >> o 'Request more time to review' -- a commitment to provide a >> thorough review in a specified period of time. >> >>Rgds, >>-Basavaraj >> >>> > -----Original Message----- >>> > From: mobopts-bounces@irtf.org >>> > [mailto:mobopts-bounces@irtf.org] On Behalf Of >>> > Basavaraj.Patil@nokia.com >>> > Sent: Wednesday, February 11, 2009 3:25 PM >>> > To: irsg@isi.edu >>> > Cc: Basavaraj.Patil@nokia.com; mobopts@irtf.org >>> > Subject: [Mobopts] IRSG Poll for >>> > I-D:draft-irtf-mobopts-location-privacy-solutions >>> > >>> > >>> > Hello, >>> > >>> > The Mobopts RG I-D: >>> > draft-irtf-mobopts-location-privacy-solutions has completed IRSG >>> > review. >>> > The revised version of the I-D (Rev 12) which incorporates the >>> > comments is now available at: >>> > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-locatio >>> > n-privacy-solu >>> > tions-12.txt. >>> > >>> > Michael Welzl who has performed the IRSG review and the Mobopts RG >>> > have approved the revised I-D to be progressed for publication. >>> > >>> > The IRSG review is available from the IRTF tracker web page at: >>> > http://trac.tools.ietf.org/group/irtf/trac/ticket/24 >>> > >>> > Please consider this email as the start of a two week IRSG >>> poll. The >>> > deadline for this poll is : Feb 26th, 2009. >>> > >>> > Please use one of the poll responses defined below. >>> > The possible poll responses are: >>> > >>> > o 'Ready to publish' -- requires a thorough read and >>reasonably >>> > detailed review >>> > >>> > o 'Not ready to publish' -- requires a thorough read, >>> reasonably >>> > detailed review, and actionable comments. >>> > >>> > o 'No objection' -- I don't object if this document >>> goes forward; >>> > I've read the document (perhaps quickly); I have some small >>> > comments which are not show stoppers; I don't have great >>> > expertise in the area. >>> > >>> > o 'Request more time to review' -- a commitment to provide a >>> > thorough review in a specified period of time. >>> > >>> > The most relevant rule is that "At least two other IRSG members >>> > (besides the one sponsoring the document) need to vote 'ready to >>> > publish' for the document to move forward." >>> > >>> > Please review and submit your vote. >>> > >>> > -Basavaraj >>> > Document Shepherd for the I-D >>> > >>> > _______________________________________________ >>> > Mobopts mailing list >>> > Mobopts@irtf.org >>> > http://www.irtf.org/mailman/listinfo/mobopts >>> > >> >> >>This email and any attachments may contain legally privileged >>and/or confidential information of Starent Networks, Corp. and >>is intended only for the individual or entity named in the >>message. The information transmitted may not be used to >>create or change any contractual obligations of Starent >>Networks, Corp. Any review, retransmission, dissemination or >>other use of, or taking of any action in reliance upon this >>e-mail and its attachments by persons or entities other than >>the intended recipient is prohibited. If you are not the >>intended recipient, please notify the sender immediately -- by >>replying to this message or by sending an email to >>postmaster@starentnetworks.com -- and destroy all copies of >>this message and any attachments without reading or disclosing >>their contents. Thank you. >>_______________________________________________ >>Mobopts mailing list >>Mobopts@irtf.org >>http://www.irtf.org/mailman/listinfo/mobopts >> > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From cmjr@iol.pt Mon Mar 16 15:20:52 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A4A3A68ED for ; Mon, 16 Mar 2009 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.224 X-Spam-Level: **** X-Spam-Status: No, score=4.224 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, 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 wzvA43o-6PWo for ; Mon, 16 Mar 2009 15:20:51 -0700 (PDT) Received: from bld10.srv.portugalmail.net (bld10.srv.portugalmail.net [195.170.168.137]) by core3.amsl.com (Postfix) with ESMTP id DDDCE3A6902 for ; Mon, 16 Mar 2009 15:20:50 -0700 (PDT) Received: from localhost (unknown [10.1.0.10]) by bld10.srv.portugalmail.net (Postfix) with ESMTP id 310FB239292 for ; Mon, 16 Mar 2009 22:21:18 +0000 (WET) X-Virus-Scanned: amavisd-new at srv.portugalmail.net Received: from bld6.srv.portugalmail.net ([10.1.0.6]) by localhost (bld10.srv.portugalmail.net [10.1.0.10]) (amavisd-new, port 10024) with ESMTP id SkWYwfwilJSw for ; Mon, 16 Mar 2009 22:21:17 +0000 (WET) Received: by bld6.srv.portugalmail.net (Postfix, from userid 30) id A1EBD2E1CB8; Mon, 16 Mar 2009 22:21:17 +0000 (WET) Received: from 193.137.239.11 (193.137.239.11 [193.137.239.11]) by webmail.iol.pt (Horde MIME library) with HTTP; Mon, 16 Mar 2009 22:21:16 +0000 Message-ID: <20090316222116.b30g5iidwkog8css@webmail.iol.pt> X-Priority: 3 (Normal) Date: Mon, 16 Mar 2009 22:21:16 +0000 From: Carlos Rodrigues To: mobopts@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs) Subject: [Mobopts] IMS with 802.21 and MPA X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 22:20:52 -0000 Hi! I'm studying some aspects handover over heterogeneous networks, in =20 particularly 802.21 and IMS "working" together. Like 802.21 can work =20 as an application server connected to the S-CSCF, a MPA server can be =20 attached to S-CSCF? Or that must be "attached" to P-CSCF, the nearest point of access =20 networks? (Or any of the previous solutions?) Another question is about MIH-MPA on a dual mode terminal. The MPA =20 only communicates with MIH or "links" too a higher layer (like IP) =20 transport unit? http://img27.imageshack.us/img27/1927/mobileagentexample.jpg http://img10.imageshack.us/img10/6874/mihimsmpa.jpg All help or support will be very helpful. Cheers, Carlos Rodrigues (Computer Science BSc student) ESTG - IPL Leiria, Portugal ____________________________________________________________________________= ____ An=C3=BAncios gr=C3=A1tis: Venda o que quiser sem custos. Saiba mais em http://www.iol.pt/correio/rodape.php?dst=3D0902091 From rkoodli@starentnetworks.com Tue Mar 17 15:24:13 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113693A6B23 for ; Tue, 17 Mar 2009 15:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 eY6C4a6-8JvJ for ; Tue, 17 Mar 2009 15:24:12 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 10DF13A67D2 for ; Tue, 17 Mar 2009 15:24:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 50CC790051 for ; Tue, 17 Mar 2009 17:24:48 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18538-04 for ; Tue, 17 Mar 2009 17:24:47 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 17 Mar 2009 17:24:47 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Mar 2009 18:22:27 -0400 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, 17 Mar 2009 18:22:26 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660741C348@exchtewks3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] IRSG Poll forI-D:draft-irtf-mobopts-location-privacy-solutions Thread-Index: AcmMoAJrECRqzS1pjkyOYuqkhWO/NwMhdCAQAW723rAAxi0cVwAYORGwATzXH+A= From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 17 Mar 2009 22:22:27.0032 (UTC) FILETIME=[DA683580:01C9A74E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Mobopts] IRSG Poll forI-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 22:24:13 -0000 Hi Wes, Thanks for your review, and vote. Please some comments inline: =20 > One substance nit is that the requirements listed in section > 3 lack any associated "rationale" statements. Including some=20 > rationale alongside each requirement is general practice in=20 > formal requirements management. This is just a very basic set of requirements (such as use MIP6 framework, do not alter IPsec etc.) set forth for the solutions. We feel it is fairly self-explanatory, and prefer to refer the reader to a basic understanding of MIP6.=20 =20 >=20 > Another nit is that the document generally phrases the=20 > problem as being to hide the mapping between "the home=20 > address and the care-of address". I believe it should really=20 > be between "the home address and an in-use care-of address",=20 > in order to ease later understanding of the applicability to=20 > monami6, dsmip, or other extensions that the conclusions say=20 > may be in-scope in the future for clarification. >=20 Multiple CoAs may be in-use (in the future), right? If so, the document is equally applicable. > The problem of location privacy is very complex, and the=20 > document does a good job of tracking each concern and clearly=20 > explaining what appears in each relevant header and option=20 > field in the stack so that the impact can be readily=20 > assessed. I appreciated this. Thanks. >=20 > There are some editorial nits, but I believe they're minor=20 > enough that the RFC Editor will fix them. Okay. Regards, -Rajeev >=20 > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > =20 >=20 > >-----Original Message----- > >From: mobopts-bounces@irtf.org > >[mailto:mobopts-bounces@irtf.org] On Behalf Of=20 > >Basavaraj.Patil@nokia.com > >Sent: Tuesday, March 10, 2009 11:41 PM > >To: irsg@ISI.EDU > >Cc: basavarj.patil@nokia.com; mobopts@irtf.org > >Subject: Re: [Mobopts] IRSG Poll > >forI-D:draft-irtf-mobopts-location-privacy-solutions > > > > > >Hello, > > > >The deadline for the IRSG poll for I-D:=20 > >draft-irtf-mobopts-location-privacy-solutions expired on Feb 26th. > > > >So far we have received one no objection vote. Would like to=20 > >hear from a few other people. > >I am extending the deadline to March 15th. Please respond to=20 > the poll. > > > >Again the choices are: > > > > o 'Ready to publish' -- requires a thorough read and reasonably > > detailed review > > > > o 'Not ready to publish' -- requires a thorough read, > > reasonably detailed review, and actionable comments. > > > > o 'No objection' -- I don't object if this document > > goes forward; > > I've read the document (perhaps quickly); I have some small > > comments which are not show stoppers; I don't have great > > expertise in the area. > > > > o 'Request more time to review' -- a commitment to provide a > > thorough review in a specified period of time. > > > >Rgds, > >-Basavaraj > > > >> > -----Original Message----- > >> > From: mobopts-bounces@irtf.org > >> > [mailto:mobopts-bounces@irtf.org] On Behalf Of > >> > Basavaraj.Patil@nokia.com > >> > Sent: Wednesday, February 11, 2009 3:25 PM > >> > To: irsg@isi.edu > >> > Cc: Basavaraj.Patil@nokia.com; mobopts@irtf.org > >> > Subject: [Mobopts] IRSG Poll for > >> > I-D:draft-irtf-mobopts-location-privacy-solutions > >> > > >> > > >> > Hello, > >> > > >> > The Mobopts RG I-D: > >> > draft-irtf-mobopts-location-privacy-solutions has completed IRSG > >> > review. > >> > The revised version of the I-D (Rev 12) which incorporates the > >> > comments is now available at: > >> > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-locatio > >> > n-privacy-solu > >> > tions-12.txt. > >> > > >> > Michael Welzl who has performed the IRSG review and the=20 > Mobopts RG > >> > have approved the revised I-D to be progressed for publication. > >> > > >> > The IRSG review is available from the IRTF tracker web page at: > >> > http://trac.tools.ietf.org/group/irtf/trac/ticket/24 > >> > > >> > Please consider this email as the start of a two week IRSG > >> poll. The > >> > deadline for this poll is : Feb 26th, 2009. > >> > > >> > Please use one of the poll responses defined below. > >> > The possible poll responses are: > >> > > >> > o 'Ready to publish' -- requires a thorough read and=20 > >reasonably > >> > detailed review > >> > > >> > o 'Not ready to publish' -- requires a thorough read, > >> reasonably > >> > detailed review, and actionable comments. > >> > > >> > o 'No objection' -- I don't object if this document > >> goes forward; > >> > I've read the document (perhaps quickly); I have=20 > some small > >> > comments which are not show stoppers; I don't have great > >> > expertise in the area. > >> > > >> > o 'Request more time to review' -- a commitment to provide a > >> > thorough review in a specified period of time. > >> > > >> > The most relevant rule is that "At least two other IRSG members > >> > (besides the one sponsoring the document) need to vote 'ready to > >> > publish' for the document to move forward." > >> > > >> > Please review and submit your vote. > >> > > >> > -Basavaraj > >> > Document Shepherd for the I-D > >> > > >> > _______________________________________________ > >> > Mobopts mailing list > >> > Mobopts@irtf.org > >> > http://www.irtf.org/mailman/listinfo/mobopts > >> > > > > > > >This email and any attachments may contain legally privileged=20 > >and/or confidential information of Starent Networks, Corp. and=20 > >is intended only for the individual or entity named in the=20 > >message. The information transmitted may not be used to=20 > >create or change any contractual obligations of Starent=20 > >Networks, Corp. Any review, retransmission, dissemination or=20 > >other use of, or taking of any action in reliance upon this=20 > >e-mail and its attachments by persons or entities other than=20 > >the intended recipient is prohibited. If you are not the=20 > >intended recipient, please notify the sender immediately -- by=20 > >replying to this message or by sending an email to=20 > >postmaster@starentnetworks.com -- and destroy all copies of=20 > >this message and any attachments without reading or disclosing=20 > >their contents. Thank you. > >_______________________________________________ > >Mobopts mailing list > >Mobopts@irtf.org > >http://www.irtf.org/mailman/listinfo/mobopts > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts >=20 From wesley.m.eddy@nasa.gov Tue Mar 17 18:37:27 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A843A6A80 for ; Tue, 17 Mar 2009 18:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] 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 wDkA4gujGdpp for ; Tue, 17 Mar 2009 18:37:25 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id EBE043A68F4 for ; Tue, 17 Mar 2009 18:37:24 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 0BEF1B1D3; Tue, 17 Mar 2009 20:38:07 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n2I1cCqO030706; Tue, 17 Mar 2009 20:38:12 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Tue, 17 Mar 2009 20:38:06 -0500 From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" To: "Koodli, Rajeev" , "mobopts@irtf.org" Date: Tue, 17 Mar 2009 20:38:06 -0500 Thread-Topic: [Mobopts] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions Thread-Index: AcmMoAJrECRqzS1pjkyOYuqkhWO/NwMhdCAQAW723rAAxi0cVwAYORGwATzXH+AABlLbyQ== Message-ID: References: , <4D35478224365146822AE9E3AD4A26660741C348@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660741C348@exchtewks3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Mobopts] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 01:37:27 -0000 All of my comments are non-blocking, and I trust the authors/editors to just take them as suggestions, and nothing more serious. Your logic makes sense to me with the explanations below. ________________________________________ From: mobopts-bounces@irtf.org [mobopts-bounces@irtf.org] On Behalf Of Kood= li, Rajeev [rkoodli@starentnetworks.com] Sent: Tuesday, March 17, 2009 6:22 PM To: mobopts@irtf.org Subject: Re: [Mobopts] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-= solutions Hi Wes, Thanks for your review, and vote. Please some comments inline: > One substance nit is that the requirements listed in section > 3 lack any associated "rationale" statements. Including some > rationale alongside each requirement is general practice in > formal requirements management. This is just a very basic set of requirements (such as use MIP6 framework, do not alter IPsec etc.) set forth for the solutions. We feel it is fairly self-explanatory, and prefer to refer the reader to a basic understanding of MIP6. > > Another nit is that the document generally phrases the > problem as being to hide the mapping between "the home > address and the care-of address". I believe it should really > be between "the home address and an in-use care-of address", > in order to ease later understanding of the applicability to > monami6, dsmip, or other extensions that the conclusions say > may be in-scope in the future for clarification. > Multiple CoAs may be in-use (in the future), right? If so, the document is equally applicable. > The problem of location privacy is very complex, and the > document does a good job of tracking each concern and clearly > explaining what appears in each relevant header and option > field in the stack so that the impact can be readily > assessed. I appreciated this. Thanks. > > There are some editorial nits, but I believe they're minor > enough that the RFC Editor will fix them. Okay. Regards, -Rajeev > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > > > >-----Original Message----- > >From: mobopts-bounces@irtf.org > >[mailto:mobopts-bounces@irtf.org] On Behalf Of > >Basavaraj.Patil@nokia.com > >Sent: Tuesday, March 10, 2009 11:41 PM > >To: irsg@ISI.EDU > >Cc: basavarj.patil@nokia.com; mobopts@irtf.org > >Subject: Re: [Mobopts] IRSG Poll > >forI-D:draft-irtf-mobopts-location-privacy-solutions > > > > > >Hello, > > > >The deadline for the IRSG poll for I-D: > >draft-irtf-mobopts-location-privacy-solutions expired on Feb 26th. > > > >So far we have received one no objection vote. Would like to > >hear from a few other people. > >I am extending the deadline to March 15th. Please respond to > the poll. > > > >Again the choices are: > > > > o 'Ready to publish' -- requires a thorough read and reasonably > > detailed review > > > > o 'Not ready to publish' -- requires a thorough read, > > reasonably detailed review, and actionable comments. > > > > o 'No objection' -- I don't object if this document > > goes forward; > > I've read the document (perhaps quickly); I have some small > > comments which are not show stoppers; I don't have great > > expertise in the area. > > > > o 'Request more time to review' -- a commitment to provide a > > thorough review in a specified period of time. > > > >Rgds, > >-Basavaraj > > > >> > -----Original Message----- > >> > From: mobopts-bounces@irtf.org > >> > [mailto:mobopts-bounces@irtf.org] On Behalf Of > >> > Basavaraj.Patil@nokia.com > >> > Sent: Wednesday, February 11, 2009 3:25 PM > >> > To: irsg@isi.edu > >> > Cc: Basavaraj.Patil@nokia.com; mobopts@irtf.org > >> > Subject: [Mobopts] IRSG Poll for > >> > I-D:draft-irtf-mobopts-location-privacy-solutions > >> > > >> > > >> > Hello, > >> > > >> > The Mobopts RG I-D: > >> > draft-irtf-mobopts-location-privacy-solutions has completed IRSG > >> > review. > >> > The revised version of the I-D (Rev 12) which incorporates the > >> > comments is now available at: > >> > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-locatio > >> > n-privacy-solu > >> > tions-12.txt. > >> > > >> > Michael Welzl who has performed the IRSG review and the > Mobopts RG > >> > have approved the revised I-D to be progressed for publication. > >> > > >> > The IRSG review is available from the IRTF tracker web page at: > >> > http://trac.tools.ietf.org/group/irtf/trac/ticket/24 > >> > > >> > Please consider this email as the start of a two week IRSG > >> poll. The > >> > deadline for this poll is : Feb 26th, 2009. > >> > > >> > Please use one of the poll responses defined below. > >> > The possible poll responses are: > >> > > >> > o 'Ready to publish' -- requires a thorough read and > >reasonably > >> > detailed review > >> > > >> > o 'Not ready to publish' -- requires a thorough read, > >> reasonably > >> > detailed review, and actionable comments. > >> > > >> > o 'No objection' -- I don't object if this document > >> goes forward; > >> > I've read the document (perhaps quickly); I have > some small > >> > comments which are not show stoppers; I don't have great > >> > expertise in the area. > >> > > >> > o 'Request more time to review' -- a commitment to provide a > >> > thorough review in a specified period of time. > >> > > >> > The most relevant rule is that "At least two other IRSG members > >> > (besides the one sponsoring the document) need to vote 'ready to > >> > publish' for the document to move forward." > >> > > >> > Please review and submit your vote. > >> > > >> > -Basavaraj > >> > Document Shepherd for the I-D > >> > > >> > _______________________________________________ > >> > Mobopts mailing list > >> > Mobopts@irtf.org > >> > http://www.irtf.org/mailman/listinfo/mobopts > >> > > > > > > >This email and any attachments may contain legally privileged > >and/or confidential information of Starent Networks, Corp. and > >is intended only for the individual or entity named in the > >message. The information transmitted may not be used to > >create or change any contractual obligations of Starent > >Networks, Corp. Any review, retransmission, dissemination or > >other use of, or taking of any action in reliance upon this > >e-mail and its attachments by persons or entities other than > >the intended recipient is prohibited. If you are not the > >intended recipient, please notify the sender immediately -- by > >replying to this message or by sending an email to > >postmaster@starentnetworks.com -- and destroy all copies of > >this message and any attachments without reading or disclosing > >their contents. Thank you. > >_______________________________________________ > >Mobopts mailing list > >Mobopts@irtf.org > >http://www.irtf.org/mailman/listinfo/mobopts > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org http://www.irtf.org/mailman/listinfo/mobopts= From rajeev.koodli@gmail.com Tue Mar 17 22:00:08 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B523A6B41 for ; Tue, 17 Mar 2009 22:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_00=-2.599, MANGLED_LIST=2.3, SARE_SUB_RAND_LETTRS4=0.799] 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 5H527G4W8NPu for ; Tue, 17 Mar 2009 22:00:07 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 16CC23A6AA2 for ; Tue, 17 Mar 2009 22:00:06 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so347372wfg.7 for ; Tue, 17 Mar 2009 22:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=1/m7IdL6VRHUTG4cM8IdpVKInlx9stfZ5ytB63RMBgA=; b=E+YUK4qe+K6gWTRrUI+h11fnIV8nuIQ0e1cMulWEC5qV2scQdwfyfyfcK7w4kIRNT8 0HnMOR5wBiz/LdSVWOZUrSKXTHy2AKGqEBCwjBYqehvk+LaPGxxkLtuPmlElGQsRjP1k DTM9Y9EpvDVyMz2O9UVwuXNd3gRkRJX6lNuXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qGMwQNgQkCS7fTQ47ZR203TvODQX5aO6EoUaaAtL5xUoPN2g/VybG2PoZx7a0xl686 vgnFVfF0uxdI2KPUNRPAu2q77kZ6DrcFTJ32kHFgntG7Hz+9U+3WF8K8h8Yl4PVgBzJ2 DPBObI4Xw14bV+L9bWd6qmm1nO1sLqGygRPL4= MIME-Version: 1.0 Received: by 10.141.146.4 with SMTP id y4mr155658rvn.88.1237352450729; Tue, 17 Mar 2009 22:00:50 -0700 (PDT) In-Reply-To: <65C0B939696D45A68AF8962E358A19DE@t3400> References: <49B7E2D3.3050605@cs.tcd.ie> <65C0B939696D45A68AF8962E358A19DE@t3400> Date: Tue, 17 Mar 2009 22:00:50 -0700 Message-ID: <3d57679a0903172200m394665e7q8629a3df31c6a18a@mail.gmail.com> From: Rajeev Koodli To: QIU Ying Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: irsg@isi.edu, Basavaraj.Patil@nokia.com, mobopts@irtf.org, "Eddy, Wesley M. \(GRC-RCN0\)\[Verizon\]" , Stephen Farrell Subject: Re: [Mobopts] [IRSG] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 05:00:08 -0000 Hi Stephen, I agree with Qiu Ying's reply. We can address the nits as part of RFC Editor revisions. So, I request that the ID be progressed forward. Thanks for your review. Regards, -Rajeev On Mon, Mar 16, 2009 at 3:37 AM, QIU Ying wrote= : > Hi, Stephen > > Thanks for your review and support. > > For the #1 comment regarding to active attacks: we discussed this issue > before, but it is too difficult to enumerate all of active attacks. In fa= ct, > if an attacker launches an active attack signaling, =A0the mobile node ha= s 2 > choices: 1) simply drop the signaling message according to its own access > policy, hence it is not much for further discussion. 2) accept the signal= ing > messages, then the MN must response the signaling. Hence the attacker is > treated as a correspondent node and the correspondent node is still not a= ble > to map the real home address and the in-use care-of-address according to = our > solution. > > For the #2 comment regarding to using ECB in DES: since KM is derived fro= m > Kbm: Kpm =3D HMAC_SHA1(Kbm, 0), and Kbm is always changed by every RR pro= cess, > a Kpm can not be re-used during the communication. By the way, the exampl= e > you describe here, I prefer to call it as passive attack because it does = not > tempt messages from MN or HA directly. > > Please correct me if I am wrong. > > Regards and Thanks > Qiu Ying > > > ----- Original Message ----- From: "Stephen Farrell" > > To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" > Cc: ; ; > Sent: Thursday, March 12, 2009 12:12 AM > Subject: Re: [Mobopts] [IRSG] IRSG > PollforI-D:draft-irtf-mobopts-location-privacy-solutions > > >> >> Eddy, Wesley M. (GRC-RCN0)[Verizon] wrote: >>> >>> You can record a vote for "ready to publish" from me. >> >> Same here. >> >> My non-blocking comments are below. Feel free to take 'em >> on board or not, as you see fit. >> >> Stephen. >> >> #1 Its a bit surprising that active attackers aren't considered. >> Maybe adding a justification for that would be good? I guess the >> danger is that someone goes and implements all of this and claims >> to have produced a "secure" solution, but in fact has only produced >> something good against passive attacks. >> >> #2 section 5.1, what mode of operation is used for the generation >> of the encrypted home address? For AES I think ECB is ok, but if >> a block cipher with a smaller block (e.g. =A03DES) is used, then you >> should probably not use ECB as that'd expose some information if >> Kpm is re-used and if the home address structure is sensitive. >> I've no idea if that's significant or not, but specifying CBC mode >> for shorter-block ciphers would I think remove the potential >> vulnerability. (3DES with ECB mode might also allow some non-obvious >> cut'n'paste attacks if Kpm is re-used, though those'd be active >> attacks and so presumably out of scope.) >> >> Nits: >> >> #1 1st sentence of section 1 is missing a word, maybe "problem" >> >> #2, p12: s/If such/If so/ >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> http://www.irtf.org/mailman/listinfo/mobopts > > Institute for Infocomm Research disclaimer: =A0"This email is confidentia= l and > may be privileged. If you are not the intended recipient, please delete i= t > and notify us immediately. Please do not copy or use it for any purpose, = or > disclose its contents to any other person. Thank you." > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts > From cmjr@iol.pt Mon Mar 23 10:52:47 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC793A68AF for ; Mon, 23 Mar 2009 10:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.039 X-Spam-Level: *** X-Spam-Status: No, score=3.039 tagged_above=-999 required=5 tests=[AWL=1.642, BAYES_50=0.001, MIME_QP_LONG_LINE=1.396] 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 xtivgJC+YfxW for ; Mon, 23 Mar 2009 10:52:46 -0700 (PDT) Received: from bld10.srv.portugalmail.net (bld10.srv.portugalmail.net [195.170.168.137]) by core3.amsl.com (Postfix) with ESMTP id 0BA733A67E2 for ; Mon, 23 Mar 2009 10:52:45 -0700 (PDT) Received: from localhost (unknown [10.1.0.10]) by bld10.srv.portugalmail.net (Postfix) with ESMTP id E829923A2B4 for ; Mon, 23 Mar 2009 17:53:21 +0000 (WET) X-Virus-Scanned: amavisd-new at srv.portugalmail.net Received: from bld6.srv.portugalmail.net ([10.1.0.6]) by localhost (bld10.srv.portugalmail.net [10.1.0.10]) (amavisd-new, port 10024) with ESMTP id 2VY3b6VwvgU6 for ; Mon, 23 Mar 2009 17:53:21 +0000 (WET) Received: by bld6.srv.portugalmail.net (Postfix, from userid 30) id A61BD2E964E; Mon, 23 Mar 2009 17:53:19 +0000 (WET) Received: from warrior1.ipleiria.pt (warrior1.ipleiria.pt [193.137.239.251]) by webmail.iol.pt (Horde MIME library) with HTTP; Mon, 23 Mar 2009 17:53:19 +0000 Message-ID: <20090323175319.ljqtzw568sowws4s@webmail.iol.pt> X-Priority: 3 (Normal) Date: Mon, 23 Mar 2009 17:53:19 +0000 From: Carlos Rodrigues To: mobopts@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs) Subject: [Mobopts] SIP protocol and MPA X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:52:47 -0000 I have question about the integration of MPA in IMS Core. Makes sense integrate MPA, with the main goal (re)negotiate security =20 parameters between networks (vertical handover!) and reduce handover =20 latency, or SIP protocol does that effectively? I think not but is a =20 question that won't leave my head... Carlos Rodrigues (Computer Science BSc student) ESTG - IPL Leiria, Portugal ____________________________________________________________________________= ____ Descubra as Solu=C3=A7=C3=B5es de Financiamento Cetelem. Saiba mais em: http://www.iol.pt/correio/rodape.php?dst=3D0901272 From adutta@research.telcordia.com Mon Mar 23 10:57:13 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1C03A68AF for ; Mon, 23 Mar 2009 10:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 SYc3kLF6f1Jr for ; Mon, 23 Mar 2009 10:57:12 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 47BDA3A6BB5 for ; Mon, 23 Mar 2009 10:57:12 -0700 (PDT) Received: from [192.4.8.228] (ar8-228.research.telcordia.com [192.4.8.228]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n2NHvx1L017811; Mon, 23 Mar 2009 13:58:00 -0400 (EDT) Message-ID: <49C7CDA7.4080700@research.telcordia.com> Date: Mon, 23 Mar 2009 13:57:59 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Carlos Rodrigues References: <20090323175319.ljqtzw568sowws4s@webmail.iol.pt> In-Reply-To: <20090323175319.ljqtzw568sowws4s@webmail.iol.pt> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mobopts@irtf.org Subject: Re: [Mobopts] SIP protocol and MPA X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 17:57:13 -0000 Carlos, I think I did answer to your question in 802.21 mailing list. What is the additional question you have? Please let me know. Also, since this is MPA deployment related question (MPA's use in IMS), it is probably better to discuss offline, unless Chair allows us to discuss it in the mailing list. Regards Ashutosh Carlos Rodrigues wrote: > I have question about the integration of MPA in IMS Core. > Makes sense integrate MPA, with the main goal (re)negotiate security > parameters between networks (vertical handover!) and reduce handover > latency, or SIP protocol does that effectively? I think not but is a > question that won't leave my head... > > Carlos Rodrigues (Computer Science BSc student) > ESTG - IPL > Leiria, Portugal > > ________________________________________________________________________________ > > Descubra as Soluções de Financiamento Cetelem. > Saiba mais em: http://www.iol.pt/correio/rodape.php?dst=0901272 > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts From rajeev_koodli@yahoo.com Fri Mar 27 11:14:23 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B0428C1E7 for ; Fri, 27 Mar 2009 11:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 jY83Uvel9Pg4 for ; Fri, 27 Mar 2009 11:14:22 -0700 (PDT) Received: from n62.bullet.mail.sp1.yahoo.com (n62.bullet.mail.sp1.yahoo.com [98.136.44.35]) by core3.amsl.com (Postfix) with SMTP id 6051228C1CC for ; Fri, 27 Mar 2009 11:14:22 -0700 (PDT) Received: from [216.252.122.218] by n62.bullet.mail.sp1.yahoo.com with NNFMP; 27 Mar 2009 18:15:17 -0000 Received: from [67.195.9.82] by t3.bullet.sp1.yahoo.com with NNFMP; 27 Mar 2009 18:15:17 -0000 Received: from [67.195.9.104] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 27 Mar 2009 18:15:16 -0000 Received: from [127.0.0.1] by omp108.mail.gq1.yahoo.com with NNFMP; 27 Mar 2009 18:14:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 613273.7668.bm@omp108.mail.gq1.yahoo.com Received: (qmail 33115 invoked by uid 60001); 27 Mar 2009 18:15:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238177716; bh=PXwwsk9SmUkTfyNUO6mjYakB7cod3/5KsMFiOw9uGRU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=LuxwQZQivIWqUF9n+mXvFdkjQisCrXF6n4yd1DSdDFKAGcDsHhq7XQkU+vwQ9TXsHwDfvycau2GpvHsDDh4AS3EufVYB7FWZNHW9uWbSnEwp34CfFk27G4X25TqyxZ4D8MmdsoPYsFVxXeN0SRuuuB7/dykdMUodRCFAVXEYNgk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=wBLd4D9bymrPmELs0DdPcUzDPDV56E0uoWScij5H7+ex7pqHWQIYYZzct/Rnw0nA+BTUrsGtvlJru8Sm00odULusN8i7/rGciSfYQfSCeWq0EipkbaZLcBVreWxrCoPOWq58BuFfTN6gcl0YgHnIVp6kksgIdb3AjliqYwMCOuo=; Message-ID: <174229.33108.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: z4FYYxQVM1mxfRaG97eMnWi8Aq996nTEi58QWxAXrOmi_QOZsHt_qYEbWe0110WYesuCAMPrt.MZ5jhnRNzlCIAva.p0DwauWhQdpwP4sQlmGhcm7koxe__iMgKU66ujLcz0JQgjSa4ixCkaBTdTcsZQ2tw7sPtWCEt3DnoI4Te.GJz.Mosjl5Er.WAgiON3mNXXWgJcgx24RpEYlvukDEMHz2o- Received: from [70.212.185.240] by web111401.mail.gq1.yahoo.com via HTTP; Fri, 27 Mar 2009 11:15:15 PDT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Fri, 27 Mar 2009 11:15:15 -0700 (PDT) From: Rajeev Koodli To: irsg@ISI.EDU, Craig Partridge MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-973456675-1238177715=:33108" Cc: mobopts@irtf.org Subject: Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 18:14:23 -0000 --0-973456675-1238177715=:33108 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Craig, many thanks for your thoughtful review. I am sure the authors and the RG fi= nd this useful. Regards, -Rajeev --- On Tue, 3/24/09, Craig Partridge wrote: From: Craig Partridge Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt To: irsg@ISI.EDU Date: Tuesday, March 24, 2009, 9:22 AM I had two almost contradictory views after reviewing the document. The first view is that it is very well-informed and presents a lot of complex information well.=A0 The second view is that it seems lost -- that it doesn't know what it is trying to do and where it is going. So, I'm comfortable seeing it published -- I think some folks will find it useful, but have some suggestions for how it could be improved to work as a roadmap for research/thinking about the problem of multicast mobility in wireless (which I think is what it aspires to be). Comments: =A0 =A0 * First, the draft should be more explicit that its focus is =A0 =A0 =A0 on multicast IPv6 mobility in WIRELESS environments.=A0 You can= read =A0 =A0 =A0 the early part of the draft and think you might be involved =A0 =A0 =A0 in worrying about someone unplugging from one wired network and= plugging =A0 =A0 =A0 into wired network.=A0 Particular odd is that Figure 1 clearly =A0 =A0 =A0 envisions wireless edge networks (single and multihop) yet neve= r =A0 =A0 =A0 says wireless anywhere in the text around it. =A0 =A0 =A0 (Example -- "wireless" appears in the abstract but then not =A0 =A0 =A0 again until page 8...) =A0 =A0 * The document appears to be seeking to define a set of constraints =A0 =A0 =A0 within which a solution must appear.=A0 I took the step of capi= talizing =A0 =A0 =A0 every MUST/MUST NOT and SHOULD/SHOULD NOT in the document and w= hen you =A0 =A0 =A0 do that the document is clearly a half-thought-out requirements =A0 =A0 =A0 document.=A0 I suspect the authors would be surprised at themse= lves if =A0 =A0 =A0 they undertook the experiment. =A0 =A0 =A0 I mention it because I often reacted that the document was sett= ing =A0 =A0 =A0 requirements in one spot but not another and I wondered why. =A0 =A0 * in section 2.1, "jointly support unicast and multicast" -- why =A0 =A0 =A0 not broadcast and anycast as well? (esp. as broadcast is =A0 =A0 =A0 near universal in wireless and anycast apparently matters) =A0 =A0 * in section 2.2.1, 2nd bullet, why would we enable multicast in =A0 =A0 =A0 a network but ban a particular multicast group from circulation= ? =A0 =A0 =A0 (Needs some more explanation here about why this happens -- it = is =A0 =A0 =A0 a surprising restriction not mentioned earlier). =A0 =A0 * 2.2.2 uses the word "n-casting" in a context where it is clear =A0 =A0 =A0 the draft things n-casting is evil, but n-casting is never defi= ned =A0 =A0 =A0 anywhere in the document. =A0 =A0 * 2.4 "Facing deployment complexity, it is desirable that any solut= ion for =A0 =A0 =A0 mobile multicast SHOULD leave routing protocosl unchanged". [No= te =A0 =A0 =A0 I capitalized SHOULD to point out the restriction here].=A0 Why= is this =A0 =A0 =A0 desired?=A0 If we found a routing approach that worked better f= or all =A0 =A0 =A0 environments and supported multicast, wouldn't we prefer that? =A0 =A0 * 4.1 -- never mentions that wireless is inherently a broadcast med= ium =A0 =A0 =A0 and that there may be opportunities to exploit this feature. =A0 =A0 =A0 Especially for receivers, an inherently multicast medium makes = it =A0 =A0 =A0 easier to rejoin groups (if the group is already live, you can =A0 =A0 =A0 immediately listen in). Craig _______________________________________________ IRSG mailing list IRSG@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/irsg =0A=0A=0A --0-973456675-1238177715=:33108 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A=0A --0-973456675-1238177715=:33108-- From schmidt@informatik.haw-hamburg.de Fri Mar 27 12:11:32 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28A13A6A6E for ; Fri, 27 Mar 2009 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799] 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 ene70RT0cKOj for ; Fri, 27 Mar 2009 12:11:32 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id D8C803A6996 for ; Fri, 27 Mar 2009 12:11:31 -0700 (PDT) Envelope-to: mobopts@irtf.org Received: from dhcp-30fd.meeting.ietf.org ([130.129.48.253]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1LnHTd-000JTu-7P; Fri, 27 Mar 2009 20:12:25 +0100 Message-ID: <49CD24FD.9080704@informatik.haw-hamburg.de> Date: Fri, 27 Mar 2009 12:11:57 -0700 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Rajeev Koodli References: <174229.33108.qm@web111401.mail.gq1.yahoo.com> In-Reply-To: <174229.33108.qm@web111401.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: irsg@ISI.EDU, Craig Partridge , mobopts@irtf.org Subject: Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 19:11:33 -0000 Hi Craig, many thanks for your fast and highly reflective review: this will certainly trigger many reflections on our side, as well. So we will take a bit of time to think things over again ... and then respond in detail. Thanks again! Kind regards, Thomas Rajeev Koodli wrote: > > Hi Craig, > > many thanks for your thoughtful review. I am sure the authors and the RG > find this useful. > > Regards, > > -Rajeev > > > --- On *Tue, 3/24/09, Craig Partridge //* wrote: > > > From: Craig Partridge > Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt > To: irsg@ISI.EDU > Date: Tuesday, March 24, 2009, 9:22 AM > > > I had two almost contradictory views after reviewing the document. > > The first view is that it is very well-informed and presents a lot of > complex information well. The second view is that it seems lost -- that > it doesn't know what it is trying to do and where it is going. > > So, I'm comfortable seeing it published -- I think some folks will find > it useful, but have some suggestions for how it could be improved to > work > as a roadmap for research/thinking about the problem of multicast > mobility in wireless (which I think is what it aspires to be). > > Comments: > > * First, the draft should be more explicit that its focus is > on multicast IPv6 mobility in WIRELESS environments. You can read > the early part of the draft and think you might be involved > in worrying about someone unplugging from one wired network > and plugging > into wired network. Particular odd is that Figure 1 clearly > envisions wireless edge networks (single and multihop) yet never > says wireless anywhere in the text around it.. > > (Example -- "wireless" appears in the abstract but then not > again until page 8...) > > * The document appears to be seeking to define a set of constraints > within which a solution must appear. I took the step of > capitalizing > every MUST/MUST NOT and SHOULD/SHOULD NOT in the document and > when you > do that the document is clearly a half-thought-out requirements > document. I suspect the authors would be surprised at > themselves if > they undertook the experiment. > > I mention it because I often reacted that the document was setting > requirements in one spot but not another and I wondered why. > > * in section 2.1, "jointly support unicast and multicast" -- why > not broadcast and anycast as well? (esp. as broadcast is > near universal in wireless and anycast apparently matters) > > * in section 2.2.1, 2nd bullet, why would we enable multicast in > a network but ban a particular multicast group from circulation? > (Needs some more explanation here about why this happens -- it is > a surprising restriction not mentioned earlier). > > * 2.2.2 uses the word "n-casting" in a context where it is clear > the draft things n-casting is evil, but n-casting is never defined > anywhere in the document. > > * 2.4 "Facing deployment complexity, it is desirable that any > solution for > mobile multicast SHOULD leave routing protocosl unchanged". [Note > I capitalized SHOULD to point out the restriction here]. Why > is this > desired? If we found a routing approach that worked better > for all > environments and supported multicast, wouldn't we prefer that? > > * 4.1 -- never mentions that wireless is inherently a broadcast > medium > and that there may be opportunities to exploit this feature. > Especially for receivers, an inherently multicast medium makes it > easier to rejoin groups (if the group is already live, you can > immediately listen in). > > Craig > _______________________________________________ > IRSG mailing list > IRSG@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/irsg > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > http://www.irtf.org/mailman/listinfo/mobopts -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Sat Mar 28 01:31:55 2009 Return-Path: X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CD63A6AE6 for ; Sat, 28 Mar 2009 01:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799] 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 plKKUAR6Zq08 for ; Sat, 28 Mar 2009 01:31:54 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 4535F3A679C for ; Sat, 28 Mar 2009 01:31:53 -0700 (PDT) Envelope-to: mobopts@irtf.org Received: from adsl-76-231-184-62.dsl.pltn13.sbcglobal.net ([76.231.184.62] helo=[192.168.1.94]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1LnTyB-000Oip-Cz; Sat, 28 Mar 2009 09:32:47 +0100 Message-ID: <49CDE091.7070705@informatik.haw-hamburg.de> Date: Sat, 28 Mar 2009 01:32:17 -0700 From: "Thomas C. Schmidt" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Rajeev Koodli References: <174229.33108.qm@web111401.mail.gq1.yahoo.com> In-Reply-To: <174229.33108.qm@web111401.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: irsg@ISI.EDU, Craig Partridge , mobopts@irtf.org Subject: Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 08:31:56 -0000 Dear Craig, many thanks again for your review. We have now discussed and overlooked things, and are ready to answer: please see comments inline. > --- On *Tue, 3/24/09, Craig Partridge //* wrote: > > > From: Craig Partridge > Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt > To: irsg@ISI.EDU > Date: Tuesday, March 24, 2009, 9:22 AM > > > I had two almost contradictory views after reviewing the document. > > The first view is that it is very well-informed and presents a lot of > complex information well. The second view is that it seems lost -- that > it doesn't know what it is trying to do and where it is going. > This is in a sense quite right: We are trying to comprehensively explore the problem space and to present all relevant aspects of the somewhat intricate issues. The idea was to write a general reference document that summarizes 'all there is to think about' in its corresponding contexts. In this sense, the document is not going into a particular direction, that's right. > So, I'm comfortable seeing it published -- I think some folks will find > it useful, but have some suggestions for how it could be improved to > work > as a roadmap for research/thinking about the problem of multicast > mobility in wireless (which I think is what it aspires to be). > > Comments: > > * First, the draft should be more explicit that its focus is > on multicast IPv6 mobility in WIRELESS environments. You can read > the early part of the draft and think you might be involved > in worrying about someone unplugging from one wired network > and plugging > into wired network. Particular odd is that Figure 1 clearly > envisions wireless edge networks (single and multihop) yet never > says wireless anywhere in the text around it.. > > (Example -- "wireless" appears in the abstract but then not > again until page 8...) > Yes, you are right: one should not forget about the obvious. We added explicit statements in the introduction to link to the wireless domain. > * The document appears to be seeking to define a set of constraints > within which a solution must appear. I took the step of > capitalizing > every MUST/MUST NOT and SHOULD/SHOULD NOT in the document and > when you > do that the document is clearly a half-thought-out requirements > document. I suspect the authors would be surprised at > themselves if > they undertook the experiment. > We repeated your experiment and questioned all these occurrences. In quite a number of cases we reworded, in particular the "must/must not" terms. In general the document does not make use of normative terms in the sense of RFC 2119, so there are repeated occurrences where "should" is just used as an English word, in particular like "should preferably do ...". There are a couple of instances, where requirements drop out of other sources. Some originate for instance from normative aspects of existing standards (e.g., "must respect scoping restrictions"), some are just logical consequences of technical arguments given beforehand (e.g., "source must provide address transparency"). The latter are not meant as requirements for specific protocols, but as conclusions "if we want to achieve this, we have to do the other". > I mention it because I often reacted that the document was setting > requirements in one spot but not another and I wondered why. > Actually, we tried to keep the solution space as open as possible by avoiding any evitable constraint in argumentation. > * in section 2.1, "jointly support unicast and multicast" -- why > not broadcast and anycast as well? (esp. as broadcast is > near universal in wireless and anycast apparently matters) > :-) The issue we discuss is multicast and thereby assume, a unicast routing is present. Broadcast, I suspect, is not exactly an issue, as it may be viewed as a special case of multicast (can at least be emulated by multicast). Anycast matters, yes, but it is not required to implement multicast. So adding anycast mobility aspects to the document would probably just confuse the reader, or am I wrong? > * in section 2.2.1, 2nd bullet, why would we enable multicast in > a network but ban a particular multicast group from circulation? > (Needs some more explanation here about why this happens -- it is > a surprising restriction not mentioned earlier). > We added a clarifying remark. A limited group allowance is not rare these days for administrative reasons. A typical example are IPTV deployments, where providers offer (allow for) a certain collection of groups (TV channels) they (contractually) support. Other IPTV multicast groups they do not support (allow) in their networks. So by changing a provider on handover, one may enter a domain without the group previously under subscription. > * 2.2.2 uses the word "n-casting" in a context where it is clear > the draft things n-casting is evil, but n-casting is never defined > anywhere in the document. > We added an explanation. By the way: this is not meant to say n-casting is evil - the document just recalls known issues. > * 2.4 "Facing deployment complexity, it is desirable that any > solution for > mobile multicast SHOULD leave routing protocosl unchanged". [Note > I capitalized SHOULD to point out the restriction here]. Why > is this > desired? If we found a routing approach that worked better > for all > environments and supported multicast, wouldn't we prefer that? > From a technical and research perspective we completely agree: We would much rather design an elegant routing protocol than fiddle with proxy functions. However, this is a pure deployment argument. Given the experiences with slow, limited multicast deployment today, it appears much more promising to propose solutions that only require adding some 'boxes' at the wireless edges and leave the routing core untouched. Otherwise, we assume, a timely deployment is hardly to expect. > * 4.1 -- never mentions that wireless is inherently a broadcast > medium > and that there may be opportunities to exploit this feature. > Especially for receivers, an inherently multicast medium makes it > easier to rejoin groups (if the group is already live, you can > immediately listen in). > Yes, again this is one of the obvious to be mentioned in the beginning of section 4. We added this. I hope we got all your comments and hints right. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °

Hi Craig,

many thanks for your tho= ughtful review. I am sure the authors and the RG find this useful.

R= egards,

-Rajeev


--- On Tue, 3/24/09, Craig Partridge <= i><craig@aland.bbn.com> wrote:
From: Craig Partridge <craig@aland.bbn.com>
Subject: [IRSG] revi= ew of draft-irtf-mobopts-mmcastv6-ps-06.txt
To: irsg@ISI.EDU
Date: Tu= esday, March 24, 2009, 9:22 AM


I had tw= o almost contradictory views after reviewing the document.

The first= view is that it is very well-informed and presents a lot of
complex inf= ormation well.  The second view is that it seems lost -- that
it do= esn't know what it is trying to do and where it is going.

So, I'm comfortable seeing it published -- I think some folks will find
it usef= ul, but have some suggestions for how it could be improved to work
as a = roadmap for research/thinking about the problem of multicast
mobility in= wireless (which I think is what it aspires to be).

Comments:
    * First, the draft should be more explicit that its focus is=
      on multicast IPv6 mobility in WIRELESS environment= s.  You can read
      the early part of the draft a= nd think you might be involved
      in worrying about so= meone unplugging from one wired network and plugging
     = ; into wired network.  Particular odd is that Figure 1 clearly
&nbs= p;     envisions wireless edge networks (single and multihop) yet= never
      says wireless anywhere in the text around it= ..

      (Example -- "wireless" appears in the abstract but then not
      again until page 8...)
    * The document appears to be seeking to define a set of con= straints
      within which a solution must appear. = I took the step of capitalizing
      every MUST/MUST NO= T and SHOULD/SHOULD NOT in the document and when you
     = ; do that the document is clearly a half-thought-out requirements
 =     document.  I suspect the authors would be surprised at = themselves if
      they undertook the experiment.
      I mention it because I often reacted that the documen= t was setting
      requirements in one spot but not anot= her and I wondered why.

    * in section 2.1, "jointly sup= port unicast and multicast" -- why
      not broadcast an= d anycast as well? (esp. as broadcast is
      near universal in wireless and anycast apparently matters)

  &= nbsp; * in section 2.2.1, 2nd bullet, why would we enable multicast in
&= nbsp;     a network but ban a particular multicast group from cir= culation?
      (Needs some more explanation here about w= hy this happens -- it is
      a surprising restriction n= ot mentioned earlier).

    * 2.2.2 uses the word "n-castin= g" in a context where it is clear
      the draft things = n-casting is evil, but n-casting is never defined
      a= nywhere in the document.

    * 2.4 "Facing deployment comp= lexity, it is desirable that any solution for
      mobil= e multicast SHOULD leave routing protocosl unchanged". [Note
  &nbs= p;   I capitalized SHOULD to point out the restriction here].  Wh= y is this
      desired?  If we found a routing approach that worked better for all
      enviro= nments and supported multicast, wouldn't we prefer that?

  &nbs= p; * 4.1 -- never mentions that wireless is inherently a broadcast medium      and that there may be opportunities to exploit this = feature.
      Especially for receivers, an inherently mu= lticast medium makes it
      easier to rejoin groups (if= the group is already live, you can
      immediately lis= ten in).

Craig
_______________________________________________IRSG mailing list
IRSG@mailman.isi.edu
http://mai= lman.isi.edu/mailman/listinfo/irsg