From mobopts-bounces@irtf.org Wed Jan 21 15:17:26 2009 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 840933A69EC; Wed, 21 Jan 2009 15:17:26 -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 A11D93A6998 for ; Wed, 21 Jan 2009 15:17:25 -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 HOK9uKZjc9j4 for ; Wed, 21 Jan 2009 15:17:24 -0800 (PST) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id 8634E28C104 for ; Wed, 21 Jan 2009 15:17:24 -0800 (PST) Received: from dsl54026089.pool.t-online.hu ([84.2.96.137] helo=[192.168.1.101]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LPmJm-0005Ey-TP for mobopts@irtf.org; Thu, 22 Jan 2009 00:17:07 +0100 Message-ID: <4977AE0E.2040302@cs.uni-goettingen.de> Date: Thu, 22 Jan 2009 00:21:50 +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 X-Authenticated: Id:xfu X-Virus-Scanned: (clean) by exiscan+sophie Subject: [Mobopts] Call for papers: ICNP 2009 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: mobopts-bounces@irtf.org Errors-To: mobopts-bounces@irtf.org [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: =95 Protocol design, implementation, testing and analysis. =95 Measurement studies of protocol performance. =95 Protocols for wireless ad hoc and sensor networks. =95 Protocols for peer-to-peer networks. =95 Protocols for specific functions such as routing, flow/congestion control, network management. =95 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 Organizing Committee: Executive Committee: David Lee Ohio State University, USA (Chair) Mostafa Ammar Georgia Tech. USA Ken Calvert University of Kentucky, USA Teruo Higashino Osaka University, Japan 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, U.K. 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 _______________________________________________ Mobopts mailing list Mobopts@irtf.org http://www.irtf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Jan 27 19:46:48 2009 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 2FAB828C135; Tue, 27 Jan 2009 19:46:48 -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 95DD828C135 for ; Tue, 27 Jan 2009 19:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=-0.384, 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 bN0lIzxo6HrS for ; Tue, 27 Jan 2009 19:46:46 -0800 (PST) Received: from mail-qy0-f21.google.com (mail-qy0-f21.google.com [209.85.221.21]) by core3.amsl.com (Postfix) with ESMTP id 1C2FE28C12D for ; Tue, 27 Jan 2009 19:46:46 -0800 (PST) Received: by qyk14 with SMTP id 14so10734517qyk.7 for ; Tue, 27 Jan 2009 19:46:27 -0800 (PST) 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=WWtoag5+S40hbvY0Ff5VBRXIHAYCt+WZfuoexy8SOZ8=; b=PBtNG/2kRfgUcnSXTCDffJK2O2PBTfF/T+19yEo/B17rxRX9pCnuhZTwNOC3jLsW58 5V9c7ill+V8/CG0H4HCEwTlLu9J5X1Ij1C7K2pt/gUoroGoBqxI5VntJJi1QE/4AbWEL Ocx6/KSHCjewlcgOS1h2bW6xizzAM1nidnbX4= 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=Z09iwxRJsVsrvmFpi0htzBEqv4LRnGNWDUKOOeuIf+jKVjhadyZLH9+8fscel/e2NT NylgxFmJFrjc+HzU/M+p2sqGsHteSSXngBAc2MY2YGJgiKwxCMGuKX2dumL9AzWxWdqH AxDiZKhro97wVFmVeBmAra5tvivBbWkVoFXM4= MIME-Version: 1.0 Received: by 10.214.130.4 with SMTP id c4mr3397173qad.282.1233114386586; Tue, 27 Jan 2009 19:46:26 -0800 (PST) In-Reply-To: <005101c96425$4fdb7600$0401a8c0@fun> References: <733028.90234.qm@web111409.mail.gq1.yahoo.com> <005101c96425$4fdb7600$0401a8c0@fun> Date: Tue, 27 Jan 2009 19:46:26 -0800 Message-ID: From: fan zhao To: Michael Welzl Cc: rajeev_koodli@yahoo.com, IRSG@isi.edu, basavaraj.patil@nokia.com, mobopts@irtf.org 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 Michael, Thanks a lot for your review. We revised the draft based on your review and a new version should be available soon in the IETF repository. In addition, please see my reply below. On Mon, Dec 22, 2008 at 3:06 AM, Michael Welzl wrote: > 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 Fixed. The new text is: "One scenario is that the correspondent node is able to obtain the mobile node's real home address and initiates communication with the mobile node by using the real home address." > > * Next sentence: "conceals" => "conceal" OK > > * Next par: missing "the" before "mobile node" in > "With this solution, mobile node first obtains a home". Double "the" > in the next sentence. Corrected. > > * 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. Fixed. > > * 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). ok, done. > > * top of page 17: "is visible" => "are visible" ok. > > * page 22: "setforth" => "set forth" ok. > > * 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. ok. > > * 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" ok. > > * 6.1.2 first par: missing the "the" before "real" in > "The de-registration of real home address" ok. > > * 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. ok. > > * 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." ok. > > * 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" done > > * end of 6.3.2: "in details" => "in detail" (or maybe just remove "in > details" altogether) ok. > > * end of 6.5.1.1: "There MUST be no" => "There MUST NOT be any" ok. > > * 6.5.3 par 2: "mobile mode" => "mobile node" ok. > > * 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 ..." Corrected. > > * 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) ok. > > * 3rd bullet: fix sentences starting with "Or" => remove "Or" or fix > this in some other way ok. > > * 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," ok. > > * end of 7.1 and 7.2: "MUST not" => "MUST NOT" ok. > > * 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" ok. > > * sec 8 1st sentence: "one of _THE_ security...". further down: > " we provide _AN_ in-depth analysis" ok. > > * 8.1 first par first sentence: "strong security strength" seems odd, remove > "strength" ok. > > * 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." fxied. > > * A, par 2: "consideration When" => "consideration when" ok > > * A.3: remove "the" in ""To resist this kind of the profiling attack" ok. > > * A.5: either missing "a" before "traffic" in "perform traffic analysis", > or "analysis" => "analyses" ok. > > * 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. done. > > * A.8 par 2: "Generally, the more frequently, the higher _THE_ probability > that the profiling attack is resisted and" ok. > > > 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. We also read through the draft and correct other typos. I am fine with removing the sentence on the future work, if other authors also agree. Thanks a lot for your review. We appreciate it. Sincerely, fan > > 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 > _______________________________________________ Mobopts mailing list Mobopts@irtf.org http://www.irtf.org/mailman/listinfo/mobopts