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.