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

["Michael Welzl" <[e-mail]>]

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" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
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
[e-mail]
https://www.irtf.org/mailman/listinfo/mobopts