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

["Koodli, Rajeev" <[e-mail]>]

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

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB5028C0DC for <[e-mail]>; Tue,  3 Feb 2009 14:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Level: 
X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTgXJ+uWFgQS for <[e-mail]>; Tue,  3 Feb 2009 14:06:14 -0800 (PST)
Received: from smtp.uibk.ac.at (lmr1.uibk.ac.at [138.232.1.142]) by core3.amsl.com (Postfix) with ESMTP id 5AB683A6A40 for <[e-mail]>; Tue,  3 Feb 2009 14:06:12 -0800 (PST)
Received: from localhost (lwm1.uibk.ac.at [138.232.1.160] [e-mail]) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id n13M5laa002777; Tue, 3 Feb 2009 23:05:47 +0100
Received: from proxy2.cc.swin.edu.au (proxy2.cc.swin.edu.au [136.186.1.188])  by web-mail1.uibk.ac.at (IMP) with HTTP  for <[e-mail]>; Tue,  3 Feb 2009 23:05:47 +0100
Message-ID: <[e-mail]>
Date: Tue,  3 Feb 2009 23:05:47 +0100
From: Michael Welzl <[e-mail]>
To: "Koodli, Rajeev" <[e-mail]>
References: <4D35478224365146822AE9E3AD4A266606543031$[e-mail]>
In-Reply-To: <4D35478224365146822AE9E3AD4A266606543031$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.8
X-Originating-IP: 136.186.1.188
X-Forwarded-For: 
X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Mobopts] MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mailman/private/mobopts>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 03 Feb 2009 22:06:15 -0000

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" <[e-mail]>:

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





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782D63A6C55 for <[e-mail]>; Tue,  3 Feb 2009 16:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level: 
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4O+IFCVZUvs for <[e-mail]>; Tue,  3 Feb 2009 16:05:54 -0800 (PST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id F08143A6C53 for <[e-mail]>; Tue,  3 Feb 2009 16:05:53 -0800 (PST)
Received: by wa-out-1112.google.com with SMTP id m33so1111358wag.23 for <[e-mail]>; Tue, 03 Feb 2009 16:05:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZfkxvsVf11pJIfeUJI41Nk7yCY9uHheZ4xhQ+KmwMkE=; b=FLwtWRp8IreNFg3MmJYNGvcGFbsTjFY6h6y7m18xtx9UBfWIFP/ZgagXtZWHKmyHbs 0VEiAO8waYXv7KjglWC0UK2OEJdP4vLGHw8WqD3+QIs/HVmukGvtcq/TuE7gNMWyDUHk Z0LTNnGjjgKj6Nfxw399fCeNk3kHfJ3Wh1mas=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CN5fha9RV1hPvocthuLXpFPtLFQ4ocpr3Hk1qGKyj+mkel6HcbRVZqVQWP1UwPPQHV AC8UCGaJdBHEo0X3R6eWJk94FmZ1Bu6MKohj+sFCgTpvqDYNxaSexhEx/qUPGvOTtaGQ m+9wpgfhpL4sOU9Z7B0F0bkjLqaNTYMP5h/sI=
MIME-Version: 1.0
Received: by 10.114.133.1 with SMTP id g1mr4017696wad.162.1233705934402; Tue,  03 Feb 2009 16:05:34 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <4D35478224365146822AE9E3AD4A266606543031$[e-mail]> <[e-mail]>
Date: Tue, 3 Feb 2009 16:05:34 -0800
Message-ID: <[e-mail]>
From: Rajeev Koodli <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "[e-mail]" <[e-mail]>, [e-mail]
Subject: [Mobopts] Fwd: MobOpts:draft-irtf-mobopts-location-privacy-solutions-11.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mailman/private/mobopts>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 00:05:55 -0000

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


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" <[e-mail]>:

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



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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8C13A6CFC for <[e-mail]>; Tue, 10 Feb 2009 14:47:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level: 
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.050,  BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIqyxprN3o7h for <[e-mail]>; Tue, 10 Feb 2009 14:47:55 -0800 (PST)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 023013A6D12 for <[e-mail]>; Tue, 10 Feb 2009 14:47:54 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0D6C49008F for <[e-mail]>; Tue, 10 Feb 2009 17:47:55 -0500 (EST)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27967-02 for <[e-mail]>; Tue, 10 Feb 2009 17:47:53 -0500 (EST)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for <[e-mail]>; Tue, 10 Feb 2009 17:47:53 -0500 (EST)
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Feb 2009 17:46:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Feb 2009 17:46:09 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-irtf-mobopts-mmcastv6-ps-06.txt
Thread-Index: AcmL0NtKVHFGpIy5S9u3sIP0LtpsjAAAUx7w
From: "Koodli, Rajeev" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2009 22:46:09.0466 (UTC) FILETIME=[5DC929A0:01C98BD1]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
Subject: [Mobopts] FW: draft-irtf-mobopts-mmcastv6-ps-06.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mailman/private/mobopts>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 22:47:55 -0000

=20

> Subject: draft-irtf-mobopts-mmcastv6-ps-06.txt
> To: [e-mail]
> Cc: [e-mail], [e-mail]
> 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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4030C3A6C36 for <[e-mail]>; Wed, 11 Feb 2009 15:25:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.5
X-Spam-Level: 
X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SOLTNS=2.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHC3NjAJrwyc for <[e-mail]>; Wed, 11 Feb 2009 15:25:25 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 70CF328C132 for <[e-mail]>; Wed, 11 Feb 2009 15:25:23 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1BNPNAB030729; Thu, 12 Feb 2009 01:25:24 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 12 Feb 2009 01:25:23 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 12 Feb 2009 01:25:18 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 12 Feb 2009 01:25:13 +0200
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 12 Feb 2009 00:25:12 +0100
From: <[e-mail]>
To: <[e-mail]>
Date: Thu, 12 Feb 2009 00:25:22 +0100
Thread-Topic: IRSG Poll for I-D: draft-irtf-mobopts-location-privacy-solutions
Thread-Index: AcmMoAJrECRqzS1pjkyOYuqkhWO/Nw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Feb 2009 23:25:13.0473 (UTC) FILETIME=[FD55FF10:01C98C9F]
X-Nokia-AV: Clean
X-Mailman-Approved-At: Wed, 11 Feb 2009 15:43:34 -0800
Cc: [e-mail], [e-mail]
Subject: [Mobopts] IRSG Poll for I-D: draft-irtf-mobopts-location-privacy-solutions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mailman/private/mobopts>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2009 23:25:26 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CD63A693B for <[e-mail]>; Mon, 16 Feb 2009 23:36:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3PiBdn7shhU for <[e-mail]>; Mon, 16 Feb 2009 23:36:18 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 21A593A684F for <[e-mail]>; Mon, 16 Feb 2009 23:36:17 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61202C0027; Tue, 17 Feb 2009 08:36:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rYcAtg0XYPgw; Tue, 17 Feb 2009 08:36:22 +0100 (CET)
Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B060FC0025; Tue, 17 Feb 2009 08:36:20 +0100 (CET)
Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id AA4739A3018; Tue, 17 Feb 2009 08:36:19 +0100 (CET)
Date: Tue, 17 Feb 2009 08:36:19 +0100
From: Juergen Schoenwaelder <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], [e-mail], [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.19 (2009-01-05)
X-Mailman-Approved-At: Fri, 20 Feb 2009 09:35:56 -0800
Cc: [e-mail], [e-mail]
Subject: Re: [Mobopts] [IRSG] IRSG Poll for I-D:	draft-irtf-mobopts-location-privacy-solutions
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mailman/private/mobopts>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 07:36:19 -0000

On Thu, Feb 12, 2009 at 12:25:22AM +0100, [e-mail] 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: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>