From mobopts-bounces@irtf.org Wed Dec 10 22:02:43 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70B6C3A693A; Wed, 10 Dec 2008 22:02:43 -0800 (PST) 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 AA61E3A679F; Mon, 8 Dec 2008 11:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA0WzulADXMC; Mon, 8 Dec 2008 11:15:57 -0800 (PST) Received: from relay2.mail.vrmd.de (relay2.mail.vrmd.de [81.28.224.28]) by core3.amsl.com (Postfix) with ESMTP id 2770A3A6A9D; Mon, 8 Dec 2008 11:15:57 -0800 (PST) Received: from [87.79.236.249] (helo=[192.168.1.102]) by relay2.mail.vrmd.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1L9la2-0007UE-9K; Mon, 08 Dec 2008 20:15:42 +0100 Message-Id: <0BB96D27-921B-4F6D-BFA5-32B657E7EEA7@let.de> From: Marc Manthey To: sam In-Reply-To: <4ce32a820812080607r7623e964i77ae3400faa9d39d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 20:15:40 +0100 References: <4ce32a820812080607r7623e964i77ae3400faa9d39d@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Relay-User: marc@let.de X-Mailman-Approved-At: Wed, 10 Dec 2008 22:02:42 -0800 Cc: mipshop , multimob@ietf.org, mobopts Subject: Re: [Mobopts] [SAM] XCAST at IETF 76 in Hiroshima 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: , Content-Type: multipart/mixed; boundary="===============0932659332==" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org --===============0932659332== Content-Type: multipart/alternative; boundary=Apple-Mail-333--799045718 --Apple-Mail-333--799045718 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Am 08.12.2008 um 15:07 schrieb John Buford: > Dear XCAST-team, > > Please comment to the RG mailing list regarding what > XCAST-related activities we could cover at a SAM RG > meeting if we scheduled it at IETF 76. > > Thanks, > John hello i am curious if some of them might read this too https://sourceforge.net/project/memberlist.php?group_id=3D30760 > As I wrote on the BBS in linux-xcast6 of sourceforge, we don't have > patches for Mac OS X. I heard some want to try but currently I think > nobody working on porting XCAST6 on Mac. > >> What does a universal P2P overlay protocol mean in detail? Is it =20 >> similar to the common API by Dabek et al. ("Towards a Common API =20 >> for Structured Peer-to-Peer Overlays", 2003)? > > Probably general p2p overlay protocol is not directly targeted =20 > within the RG, but p2p/overlay multicast issues may do. There are =20 > some current efforts within the P2PSIP WG, not sure what about =20 > P2PRG... > >> Btw: It makes sense to have an interface definition between ALM =20 >> 'stack' and application. But this should be a part of a common =20 >> group membership framework maybe borrowed from IGMP/MLD. That could =20= >> be also an outcome of SAM RG. > > Re: group member management seems a good item to work on, maybe we =20 > can work out something within the group... regards marc -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 K=F6ln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: marc@let.de PGP/GnuPG: 0x1ac02f3296b12b4d jabber :marc@kgraff.net IRC: #opencu freenode.net twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and =20= certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, =20 information on every electronic information exchange with me is =20 retained for a period of six months. --Apple-Mail-333--799045718 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Am 08.12.2008 um = 15:07 schrieb John Buford:

Dear XCAST-team,
 
=
Please comment to the RG mailing list regarding what
=
XCAST-related activities we could cover at a SAM RG
=
meeting if we scheduled it at IETF 76.
 
=
Thanks,
=
John

hello 

<= /div>i am curious if  some of them might read this = too


As = I wrote on the BBS in linux-xcast6 of sourceforge, we don't = have
patches for Mac OS X. I heard some want to = try but currently I think
nobody working on porting XCAST6 on = Mac.


 What does a universal = P2P overlay protocol mean in detail? Is it similar to the common API by = Dabek et al. ("Towards a Common API for Structured Peer-to-Peer = Overlays", 2003)?

Probably general p2p overlay = protocol is not directly targeted within the RG, but p2p/overlay = multicast issues may do. There are some current efforts within the = P2PSIP WG, not sure what about P2PRG...

 Btw: It makes sense to have an interface definition = between ALM 'stack' and application. But this should be a part of a = common group membership framework maybe borrowed from IGMP/MLD. That = could be also an outcome of SAM RG.

Re: group member = management seems a good item to work on, maybe we can work out something = within the = group...


re= gards

marc
--
Les Enfants Terribles - = WWW.LET.DE
Marc Manthey 50672 K=F6ln - = Germany
Hildeboldplatz = 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: marc@let.de
PGP/GnuPG: = 0x1ac02f3296b12b4d 
IRC: #o= pencu  freenode.net

=
Opinions expressed may not even be mine by the time = you read them, and certainly don't reflect those of any other = entity (legal or otherwise).

Please note that = according to the German law on data retention, information on every = electronic information exchange with me is retained for a period of = six months.
=
= --Apple-Mail-333--799045718-- --===============0932659332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts --===============0932659332==-- From mobopts-bounces@irtf.org Fri Dec 19 11:08:44 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477253A6822; Fri, 19 Dec 2008 11:08:44 -0800 (PST) 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 8064B3A67E5 for ; Fri, 19 Dec 2008 11:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 R462npv6uxV0 for ; Fri, 19 Dec 2008 11:08:41 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 941A33A6822 for ; Fri, 19 Dec 2008 11:08:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 27B691E065E for ; Fri, 19 Dec 2008 14:08:30 -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 16124-08 for ; Fri, 19 Dec 2008 14:08:29 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 19 Dec 2008 14:08:29 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 14:08:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 14:08:29 -0500 Message-ID: <4D35478224365146822AE9E3AD4A2666059D82E7@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-irtf-mobopts-location-privacy-solutions-11 Thread-Index: AcliDNPn6gFk+PVoToG0TzJxVImCCAAAQwRg From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 19 Dec 2008 19:08:29.0876 (UTC) FILETIME=[2DC51F40:01C9620D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Mobopts] FW: New Version Notification for draft-irtf-mobopts-location-privacy-solutions-11 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, December 19, 2008 11:06 AM > To: Koodli, Rajeev > Cc: qiuying@i2r.a-star.edu.sg; fanzhao@marvell.com > Subject: New Version Notification for draft-irtf-mobopts-location-privacy- > solutions-11 > > > A new version of I-D, draft-irtf-mobopts-location-privacy-solutions-11.txt > has been successfuly submitted by Rajeev Koodli and posted to the IETF > repository. > > Filename: draft-irtf-mobopts-location-privacy-solutions > Revision: 11 > Title: Mobile IPv6 Location Privacy Solutions > Creation_date: 2008-12-19 > WG ID: Independent Submission > Number_of_pages: 52 > > Abstract: > Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable > while it roams on the Internet. However, the location and movement > of the mobile node can be revealed by the IP addresses used in > signaling or data packets. In this document, we consider the Mobile > IPv6 location privacy problem described in RFC 4882, and propose > efficient and secure techniques to protect location privacy of the > mobile node. This document is a product of the IP Mobility > Optimizations (MobOpts) Research Group. > > > > The IETF Secretariat. > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Dec 19 11:57:00 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920B628C15C; Fri, 19 Dec 2008 11:57:00 -0800 (PST) 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 3DDD73A6A64 for ; Fri, 19 Dec 2008 11:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.393 X-Spam-Level: X-Spam-Status: No, score=0.393 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 NIsnJvAPU27F for ; Fri, 19 Dec 2008 11:54:32 -0800 (PST) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id 8E6AD3A6861 for ; Fri, 19 Dec 2008 11:54:32 -0800 (PST) Received: (qmail 90527 invoked by uid 60001); 19 Dec 2008 19:54:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=zL3JbRY+ykxTl87MZndgEFAm9RNF8iD//uWfP7XYH5/GBmq9xVKjuwpgalGuBR7onvCEPllnhaOX179IUTgRGHhyZEm/s2Qe4XsY9HhfnlQkrlLZ4L7aKIyzOXvE+dgzvFNTYbUYAcBWUzqnqJhNc7rB4GIeH6n3+iVoqlY+wr0=; X-YMail-OSG: HEhZnHQVM1lSNWH1fImZ6REjnMvac5G9vnEYgtNnSxQkNEaZAVhcOXYfxl65gPceOdmaYlfpmTH8XC1Wxkw9XHP78Eq6Fed6i_Gm7ksRp42nPYyjX0CDk_7NWWV7wukw1PrGiJjmUatwV8E.NcVjrKRv6gCGbGorIROGXZ43qlpwIQug3YTAkCVyYseOibpIVe3_gjltBD3_WSTqQDChDe6CuEQq Received: from [70.231.138.150] by web111409.mail.gq1.yahoo.com via HTTP; Fri, 19 Dec 2008 11:54:23 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Fri, 19 Dec 2008 11:54:23 -0800 (PST) From: Rajeev Koodli To: michael.welzl@uibk.ac.at MIME-Version: 1.0 Message-ID: <733028.90234.qm@web111409.mail.gq1.yahoo.com> X-Mailman-Approved-At: Fri, 19 Dec 2008 11:56:59 -0800 Cc: IRSG@isi.edu, mobopts@irtf.org, basavaraj.patil@nokia.com Subject: [Mobopts] MobOpts: draft-irtf-mobopts-location-privacy-solutions-11.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rajeev_koodli@yahoo.com List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Michael, you were the IRSG reviewer for this draft. The ID has gone through major revision and a subsequent RG LC. I believe that it is ready to move forward. Please have a look. http://www.ietf.org/internet-drafts/draft-irtf-mobopts-location-privacy-solutions-11.txt Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 22 08:32:39 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09F03A6A7C; Mon, 22 Dec 2008 08:32:39 -0800 (PST) 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 B35263A6A7B for ; Mon, 22 Dec 2008 08:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, 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 LJMGkW76oFUK for ; Mon, 22 Dec 2008 08:32:37 -0800 (PST) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id E1B433A6A7A for ; Mon, 22 Dec 2008 08:32:36 -0800 (PST) Received: (qmail 21917 invoked by uid 60001); 22 Dec 2008 16:32:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=fL0Z4Q0m36amcOs+EU1a6B42vUzmoGPk82ueoMw6Tx8BIt12iU/kVcTgbco0ornuLSwFC31pjesKC/2Mopngq1FlgnmFYlBcgZuCJpkfhApPd0C75ZmQJ8I+Nmf2/ysQnzogK/WceS8MnYWE1UsKp+VHb4SOTrYBZ14xSO1daZY=; X-YMail-OSG: O1fmorMVM1mwplXhICxXTZkUUFL.shic5t8zClm5tZDnZnA0.gF_N4_3ke4w75n7uDAI03RaNsGHzad.9TmUb7KElQ9pjEBrnf4i02fIW4qwjyZG_7CADYeKMK.DIi7K5_QAKtz6SRnpwEcLJMR9A5AHRdybCfRyt3YLQ3mky6XTNZaczhi0kQ9t8MFdGB.IQ3.dR.LW8V3_aMo- Received: from [70.231.141.119] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 22 Dec 2008 08:32:27 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Mon, 22 Dec 2008 08:32:27 -0800 (PST) From: Rajeev Koodli To: Michael Welzl In-Reply-To: <005101c96425$4fdb7600$0401a8c0@fun> MIME-Version: 1.0 Message-ID: <371425.20881.qm@web111407.mail.gq1.yahoo.com> Cc: IRSG@isi.edu, mobopts@irtf.org, basavaraj.patil@nokia.com Subject: Re: [Mobopts] MobOpts: draft-irtf-mobopts-location-privacy-solutions-11.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rajeev_koodli@yahoo.com List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi Michael, thanks for your prompt review. We will work on the suggested editorial changes. Please see my response to the following: --- On Mon, 12/22/08, Michael Welzl wrote: > Technically, the I-D is fine as far as I can tell - which > doesn't mean > much, though, as I'm not at all an expert on that > topic. >I must admit > that I didn't closely follow the recent discussion in > the IRSG about > what kind of specification an RG can write, but I remember > a note > from Sally saying that an RG I-D shouldn't specify a > standard protocol > behavior - could someone please take a quick look to check > whether > the kind of specification that this document constitutes is > appropriate > for an RG? This ID is not a specification for a standard, since it is an IRTF document. It does specify, in considerable detail, the location privacy behavior for Mobile IPv6. The use of "MAY", "SHOULD", and "MUST" are used for protocol behavior, just as we have done for other RG RFCs 4651, 5184, and that does not constitute "standard protocol specification", AFAIK. Regards, -Rajeev > > Cheers, > Michael > > > > ----- Original Message ----- > From: "Rajeev Koodli" > > To: > Cc: ; > ; ; > > Sent: Friday, December 19, 2008 8:54 PM > Subject: MobOpts: > draft-irtf-mobopts-location-privacy-solutions-11.txt > > > > > > Hi Michael, > > > > you were the IRSG reviewer for this draft. The ID has > gone through major > revision and a subsequent RG LC. I believe that it is ready > to move forward. > Please have a look. > > > > > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-location-privacy-solutions-11.txt > > > > > > Thanks, > > > > -Rajeev > > > > > > > > > > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 22 08:33:09 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E983A6A84; Mon, 22 Dec 2008 08:33:09 -0800 (PST) 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 713803A69B6 for ; Mon, 22 Dec 2008 03:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 dawr3b9uzlpi for ; Mon, 22 Dec 2008 03:04:11 -0800 (PST) Received: from viefep18-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id DE9EB3A687D for ; Mon, 22 Dec 2008 03:04:09 -0800 (PST) Received: from edge04.upc.biz ([192.168.13.239]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20081222110359.IOQX29431.viefep19-int.chello.at@edge04.upc.biz>; Mon, 22 Dec 2008 12:03:59 +0100 Received: from fun ([212.186.8.16]) by edge04.upc.biz with edge id uB3w1a00E0LlQKY04B3xNB; Mon, 22 Dec 2008 12:03:59 +0100 X-SourceIP: 212.186.8.16 Message-ID: <005101c96425$4fdb7600$0401a8c0@fun> From: "Michael Welzl" To: References: <733028.90234.qm@web111409.mail.gq1.yahoo.com> Date: Mon, 22 Dec 2008 12:06:13 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailman-Approved-At: Mon, 22 Dec 2008 08:33:09 -0800 Cc: IRSG@isi.edu, mobopts@irtf.org, basavaraj.patil@nokia.com Subject: Re: [Mobopts] MobOpts: draft-irtf-mobopts-location-privacy-solutions-11.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org Hi, I can see that the document has been thoroughly revised, and would say that it is now *almost* ready to move forward. I have a couple of suggested changes regarding the presentation, but these should not stop the process in my opinion. * Page 11: this sentence appears to be broken: One scenario is that the correspondent node may be able to or already know the real home address * Next sentence: "conceals" => "conceal" * Next par: missing "the" before "mobile node" in "With this solution, mobile node first obtains a home". Double "the" in the next sentence. * page 12: I'm no native speaker, so I might be wrong, but the repeated use of "such" without an article ("such Binding Update message", "such home agent") strikes me as odd. This appears again later on page 13 ("such message") and should be corrected throughout the document (just do a text search on "such") if it's wrong. But maybe it isn't. * next couple of pages: the (multiple) use of "... is shown as follows." before descriptions of packet headers seems odd to me, and should probably be replaced, e.g. with "is shown below" or (probably better) simply with "is:". I suggest to do a text search on "shown as follows" in this document to fix this problem everywhere (e.g. it also appears on page 25). * top of page 17: "is visible" => "are visible" * page 22: "setforth" => "set forth" * page 23: 6.1 par ends without ".". 2nd par of 6.1.1.1: should begin with "Using _the_ pseudo ...". Also, remove "And" 's starting the last two sentences of this par. * 6.1.1.2: first sentence of first par ends unexpectedly - missing noun. 2nd par: "The home agent do not have" => "The home agent does not have" * 6.1.2 first par: missing the "the" before "real" in "The de-registration of real home address" * page 25: "When receiving a Home Test Init message, the home agent performs operation as specified in Section 6.6.4." => "When receiving a Home Test Init message, the home agent performs the operation specified in Section 6.6.4. * page 26: "When the home agent intercepts such Home Test message using proxy Neighbor Discovery, it performs operation as specified in Section 6.6.5." => "When the home agent intercepts such Home Test message using proxy Neighbor Discovery, it performs the operation specified in Section 6.6.5." * In this part of the text (a few pages up and down), I think it would be good to generally replace "such operation" with "this operation" * end of 6.3.2: "in details" => "in detail" (or maybe just remove "in details" altogether) * end of 6.5.1.1: "There MUST be no" => "There MUST NOT be any" * 6.5.3 par 2: "mobile mode" => "mobile node" * 6.5.6 par 1: "Such packets SHOULD be sent encrypted in the Encrypted Home Address option." sounds as if the whole packet should be embedded in this option, which is surely not what you mean. Probably you mean "should contain an Encrypted ..." * 6.6.2 2nd bullet: "is set is 0" => "is set as 0" (btw I think that, generally, "is set to" would be better, and a text search for "is set as" and corresponding change could fix that problem) * 3rd bullet: fix sentences starting with "Or" => remove "Or" or fix this in some other way * 6.7 par 1: "The additional operations are same as specified in Section 5.5," => "The additional operations are the same as specified in Section 5.5," * end of 7.1 and 7.2: "MUST not" => "MUST NOT" * I think that the whole document might become a bit easier to read if you would move section 7 to the front! (i.e. introduce the mobile ipv6 extensions before describing their usage) * last par of 7.4: remove comma in "This field is not present, when the home" * sec 8 1st sentence: "one of _THE_ security...". further down: " we provide _AN_ in-depth analysis" * 8.1 first par first sentence: "strong security strength" seems odd, remove "strength" * 8.3: wrong use of "such as" (could be replaced with "e.g., ") in "For example, the Encrypted Home Address option may be used by attackers to launch reflection attacks, such as by indicating the IP address of a victim node in the Encrypted Home Address option." * A, par 2: "consideration When" => "consideration when" * A.3: remove "the" in ""To resist this kind of the profiling attack" * A.5: either missing "a" before "traffic" in "perform traffic analysis", or "analysis" => "analyses" * Throughout the document, the use of examples within lengthy sentences is disturbing. There is this prevalent style: "If the color of a fruit is bright, for example, apples can be green or red, then it can easily be seen." This seems to be bad to me, and should probably be fixed by splitting the sentence or occasionally changing the sequence to something like: "If the color of a fruit is bright -- apples, for example, can be green or red -- then it can easily be seen." A concrete example from A.6: "The algorithm to generate randomness is implementation specific, for example, it can be any random number generator." => "The algorithm to generate randomness is implementation specific. It can, for example, be an arbitrary random number generator." I strongly suggest to fix this everywhere, by searching for "for example" and accordingly updating the sentences one by one. * A.8 par 2: "Generally, the more frequently, the higher _THE_ probability that the profiling attack is resisted and" Finally, the document is partially (e.g. in the intro section) a bit hard to read because of lengthy sentences and forward references (stating that this terminology or this mechanism *will* be introduced in section whatever - couldn't sections be reordered to avoid this?). It wouldn't hurt to read and update the whole document again, just to try and make all sentences and descriptions a bit more concise. In some places, alternative ways of describing algorithms / protocol operation rather than plain text could be helpful. It also uses "paper language" in some places - cf. my comment about the 1st sentence of sec 8 above: why do you even need to say "in-depth" in an I-D? Similarly, mentioning future work at the end of the conclusion of is probably inappropriate. Technically, the I-D is fine as far as I can tell - which doesn't mean much, though, as I'm not at all an expert on that topic. I must admit that I didn't closely follow the recent discussion in the IRSG about what kind of specification an RG can write, but I remember a note from Sally saying that an RG I-D shouldn't specify a standard protocol behavior - could someone please take a quick look to check whether the kind of specification that this document constitutes is appropriate for an RG? Cheers, Michael ----- Original Message ----- From: "Rajeev Koodli" To: Cc: ; ; ; Sent: Friday, December 19, 2008 8:54 PM Subject: MobOpts: draft-irtf-mobopts-location-privacy-solutions-11.txt > > Hi Michael, > > you were the IRSG reviewer for this draft. The ID has gone through major revision and a subsequent RG LC. I believe that it is ready to move forward. Please have a look. > > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-location-privacy-solutions-11.txt > > > Thanks, > > -Rajeev > > > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 22 08:43:30 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883523A6A4C; Mon, 22 Dec 2008 08:43:30 -0800 (PST) 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 463503A68DC for ; Mon, 22 Dec 2008 08:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 i4puD4tYHTio for ; Mon, 22 Dec 2008 08:36:56 -0800 (PST) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 08A553A6819 for ; Mon, 22 Dec 2008 08:36:55 -0800 (PST) Received: from edge04.upc.biz ([192.168.13.239]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20081222163644.METV9925.viefep11-int.chello.at@edge04.upc.biz>; Mon, 22 Dec 2008 17:36:44 +0100 Received: from fun ([212.186.8.16]) by edge04.upc.biz with edge id uGcb1a03S0LlQKY04GccWh; Mon, 22 Dec 2008 17:36:44 +0100 X-SourceIP: 212.186.8.16 Message-ID: <000e01c96453$cbe0cba0$0401a8c0@fun> From: "Michael Welzl" To: References: <371425.20881.qm@web111407.mail.gq1.yahoo.com> Date: Mon, 22 Dec 2008 17:38:53 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Mailman-Approved-At: Mon, 22 Dec 2008 08:43:29 -0800 Cc: IRSG@ISI.EDU, basavaraj.patil@nokia.com, mobopts@irtf.org Subject: Re: [Mobopts] [IRSG] MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org > > Technically, the I-D is fine as far as I can tell - which > > doesn't mean > > much, though, as I'm not at all an expert on that > > topic. > >I must admit > > that I didn't closely follow the recent discussion in > > the IRSG about > > what kind of specification an RG can write, but I remember > > a note > > from Sally saying that an RG I-D shouldn't specify a > > standard protocol > > behavior - could someone please take a quick look to check > > whether > > the kind of specification that this document constitutes is > > appropriate > > for an RG? > > This ID is not a specification for a standard, since it is an IRTF document. It does specify, in considerable detail, the location privacy behavior for Mobile IPv6. The use of "MAY", "SHOULD", and "MUST" are used for protocol behavior, just as we have done for other RG RFCs 4651, 5184, and that does not constitute "standard protocol specification", AFAIK. ok, sounds ok for me then - just wanted to be sure cheers Michael _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www.irtf.org/mailman/listinfo/mobopts