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>du>; <basavaraj.patil@nokia.com>om>; <mobopts@irtf.org>rg>;
> <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