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

[Rajeev Koodli <rajeev.koodli at gmail.com>]

Hi Aaron,

this RG doc has completed the IRSG review. I have made the updates to
the tracker (ticket #24) at
http://trac.tools.ietf.org/group/irtf/trac/ticket/24

Could you please initiate the IRSG poll so that we can move this forward?

Many thanks,

-Rajeev



---------- Forwarded message ----------
From: Michael Welzl <Michael.Welzl at uibk.ac.at>
Date: Tue, Feb 3, 2009 at 2:05 PM
Subject: Re: [Mobopts]
MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt
To: "Koodli, Rajeev" <rkoodli at starentnetworks.com>
Cc: rajeev_koodli at yahoo.com, IRSG at isi.edu, mobopts at irtf.org,
basavaraj.patil at nokia.com


Hi,

Sorry! It wasn't clear to me that I was supposed
to answer this email and say so:

yes, I am, yes you can go ahead as far as I'm concerned!

Cheers,
Michael


Zitat von "Koodli, Rajeev" <rkoodli at starentnetworks.com>:

>
> 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
> >
>
>
> This email and any attachments may contain legally privileged and/or
> confidential information of Starent Networks, Corp. and is intended only for
> the individual or entity named in the message.  The information transmitted
> may not be used to create or change any contractual obligations of Starent
> Networks, Corp.  Any review, retransmission, dissemination or other use of,
> or taking of any action in reliance upon this e-mail and its attachments by
> persons or entities other than the intended recipient is prohibited. If you
> are not the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> postmaster at starentnetworks.com -- and destroy all copies of this message and
> any attachments without reading or disclosing their contents. Thank you.
>
>



_______________________________________________
Mobopts mailing list
Mobopts at irtf.org
http://www.irtf.org/mailman/listinfo/mobopts