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

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 3 Feb 2009 13:50:51 -0500

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of fan zhao
> Sent: Tuesday, January 27, 2009 7:46 PM
> To: Michael Welzl
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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 
> <[email-masked]> 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" <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; 
> > <[email-masked]>
> > 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
> > [email-masked]
> > https://www.irtf.org/mailman/listinfo/mobopts
> >
> _______________________________________________
> Mobopts mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/mobopts
> 
_______________________________________________
Mobopts mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/mobopts

Date: Tue,  3 Feb 2009 23:05:47 +0100
From: Michael Welzl <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Mobopts] MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt

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" <[email-masked]>:

>
> 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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of fan zhao
> > Sent: Tuesday, January 27, 2009 7:46 PM
> > To: Michael Welzl
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > 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
> > <[email-masked]> 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" <[email-masked]>
> > > To: <[email-masked]>
> > > Cc: <[email-masked]>; <[email-masked]>;
> > <[email-masked]>;
> > > <[email-masked]>
> > > 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
> > > [email-masked]
> > > https://www.irtf.org/mailman/listinfo/mobopts
> > >
> > _______________________________________________
> > Mobopts mailing list
> > [email-masked]
> > 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
> [email-masked] -- and destroy all copies of this message and
> any attachments without reading or disclosing their contents. Thank you.
>
>

Date: Tue, 3 Feb 2009 16:05:34 -0800
From: Rajeev Koodli <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>, [email-masked]
Subject: [Mobopts] Fwd: MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt

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 <[email-masked]>
Date: Tue, Feb 3, 2009 at 2:05 PM
Subject: Re: [Mobopts]
MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt
To: "Koodli, Rajeev" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
[email-masked]

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" <[email-masked]>:

>
> 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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of fan zhao
> > Sent: Tuesday, January 27, 2009 7:46 PM
> > To: Michael Welzl
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > 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
> > <[email-masked]> 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" <[email-masked]>
> > > To: <[email-masked]>
> > > Cc: <[email-masked]>; <[email-masked]>;
> > <[email-masked]>;
> > > <[email-masked]>
> > > 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
> > > [email-masked]
> > > https://www.irtf.org/mailman/listinfo/mobopts
> > >
> > _______________________________________________
> > Mobopts mailing list
> > [email-masked]
> > 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
> [email-masked] -- and destroy all copies of this message and
> any attachments without reading or disclosing their contents. Thank you.
>
>

_______________________________________________
Mobopts mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/mobopts

Content-class: urn:content-classes:message
Date: Tue, 10 Feb 2009 17:46:09 -0500
From: "Koodli, Rajeev" <[email-masked]>
To: <[email-masked]>
Subject: [Mobopts] FW: draft-irtf-mobopts-mmcastv6-ps-06.txt

=20

> Subject: draft-irtf-mobopts-mmcastv6-ps-06.txt
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Date: Tuesday, February 10, 2009, 2:38 PM=20
>
> Hi Aaron,
>=20
> The MobOpts RG document needs IRSG review. I have captured the details

> on the tracker:
>=20
> http://trac.tools.ietf.org/group/irtf/trac/ticket/26
>=20
> Could you kindly assign a reviewer so that we can progress the=20
> document?
>=20
> Thank you.
>=20
> -Rajeev

     =20

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 12 Feb 2009 00:25:22 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked], [email-masked]
Subject: [Mobopts] IRSG Poll for I-D: draft-irtf-mobopts-location-privacy-solutions

Hello,

The Mobopts RG I-D: draft-irtf-mobopts-location-privacy-solutions has
completed IRSG review.
The revised version of the I-D (Rev 12) which incorporates the comments is
now available at:
http://www.ietf.org/internet-drafts/draft-irtf-mobopts-location-privacy-sol=
u
tions-12.txt.

Michael Welzl who has performed the IRSG review and the Mobopts RG have
approved the revised I-D to be progressed for publication.

The IRSG review is available from the IRTF tracker web page at:
http://trac.tools.ietf.org/group/irtf/trac/ticket/24

Please consider this email as the start of a two week IRSG poll. The
deadline for this poll is : Feb 26th, 2009.

Please use one of the poll responses defined below.
The possible poll responses are:

    o  'Ready to publish' -- requires a thorough read and reasonably
        detailed review

    o  'Not ready to publish' -- requires a thorough read, reasonably
       detailed review, and actionable comments.

    o  'No objection' -- I don't object if this document goes forward;
       I've read the document (perhaps quickly); I have some small
       comments which are not show stoppers; I don't have great
       expertise in the area.

    o  'Request more time to review' -- a commitment to provide a
       thorough review in a specified period of time.

The most relevant rule is that "At least two other IRSG members (besides th=
e
one sponsoring the document) need to vote 'ready to publish' for the
document to move forward."

Please review and submit your vote.

-Basavaraj
Document Shepherd for the I-D

Date: Tue, 17 Feb 2009 08:36:19 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [Mobopts] [IRSG] IRSG Poll for I-D:	draft-irtf-mobopts-location-privacy-solutions
Reply-To: [email-masked]

On Thu, Feb 12, 2009 at 12:25:22AM +0100, [email-masked] wrote:
 
> Please consider this email as the start of a two week IRSG poll. The
> deadline for this poll is : Feb 26th, 2009.

I vote 'no objection'. This seems to be solid, significant and
relevant work but I can't claim to understand all the details.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>