Re: [Mobopts] MobOpts: draft-irtf-mobopts-location-privacy-solutions-11.txt

[fan zhao <fanzhao828 at gmail.com>]

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 at 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 at yahoo.com>
> To: <michael.welzl at uibk.ac.at>
> Cc: <IRSG at isi.edu>; <basavaraj.patil at nokia.com>; <mobopts at irtf.org>;
> <rkoodli at 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 at irtf.org
> https://www.irtf.org/mailman/listinfo/mobopts
>
_______________________________________________
Mobopts mailing list
Mobopts at irtf.org
http://www.irtf.org/mailman/listinfo/mobopts