Re: [Mobopts] MobOpts: draft-irtf-mobopts-location-privacy-solutions-11.txt
fan zhao <fanzhao828@gmail.com> Wed, 28 January 2009 03:46 UTC
Return-Path: <mobopts-bounces@irtf.org>
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 <mobopts@core3.amsl.com>; 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 <mobopts@core3.amsl.com>; 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 <mobopts@irtf.org>; Tue, 27 Jan 2009 19:46:46 -0800 (PST)
Received: by qyk14 with SMTP id 14so10734517qyk.7 for <mobopts@irtf.org>; 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: <b6d6bbe00901271946l6bd665d5sf877c9ead13de906@mail.gmail.com>
From: fan zhao <fanzhao828@gmail.com>
To: Michael Welzl <michael.welzl@uibk.ac.at>
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 <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mailman/private/mobopts>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=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 <michael.welzl@uibk.ac.at> 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" <rajeev_koodli@yahoo.com> > To: <michael.welzl@uibk.ac.at> > Cc: <IRSG@isi.edu>; <basavaraj.patil@nokia.com>; <mobopts@irtf.org>; > <rkoodli@starentnetworks.com> > 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
- [Mobopts] MobOpts: draft-irtf-mobopts-location-pr… Rajeev Koodli
- Re: [Mobopts] MobOpts: draft-irtf-mobopts-locatio… Rajeev Koodli
- Re: [Mobopts] MobOpts: draft-irtf-mobopts-locatio… Michael Welzl
- Re: [Mobopts] [IRSG] MobOpts:draft-irtf-mobopts-l… Michael Welzl
- Re: [Mobopts] MobOpts: draft-irtf-mobopts-locatio… fan zhao
- Re: [Mobopts] MobOpts:draft-irtf-mobopts-location… Koodli, Rajeev