Re: [Mobopts] MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Michael,

Are you okay with the revisions, so that I can go ahead with the next
step in publication?

Thanks,

-Rajeev
 

> -----Original Message-----
> From: mobopts-bounces at irtf.org 
> [mailto:mobopts-bounces at irtf.org] On Behalf Of fan zhao
> Sent: Tuesday, January 27, 2009 7:46 PM
> To: Michael Welzl
> Cc: rajeev_koodli at yahoo.com; IRSG at isi.edu; 
> basavaraj.patil at nokia.com; mobopts at irtf.org
> Subject: Re: [Mobopts] 
> MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt
> 
> 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-privac
> > y-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
> 
_______________________________________________
Mobopts mailing list
Mobopts at irtf.org
http://www.irtf.org/mailman/listinfo/mobopts

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.