Subject: [Mobopts] IRSG review of draft-irtf-mobopts-location-privacy-solutions-08.txt

From: Rajeev Koodli <[email-masked]>
Date: Fri, 2 May 2008 11:23:28 -0700 (PDT)

Dear IRSG,

following is the information captured in the tracker regarding the review. Michael Welzl has agreed to review the doc; thanks Michael!

Raj Patil (MIP6 chair) will be the document shepherd.

Regards,

-Rajeev

URL to the draft:

http://www.ietf.org/internet-drafts/draft-irtf-mobopts-location-privacy-solutions-08.txt

Document shepherd name and contact information: Raj Patil, [email-masked]

Type of RFC: Informational

IRSG member performing editorial review: Michael Welzl

Scheduled date for IRSG poll: May 30, 2008

IRSG poll results: TBA

Pointers to RG reviews: (URLs below and subsequent follow ups. NOTE: The RG conducted review on version 06. The current draft version is 08)

http://www.ietf.org/mail-archive/web/mobopts/current/msg00886.html

http://www.ietf.org/mail-archive/web/mobopts/current/msg00889.html

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
Mobopts mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mobopts

---

From: Michael Welzl <[email-masked]>
Date: Mon, 19 May 2008 10:00:52 +0200

Dear Rajeev, dear IRSG, dear MOBOPTS group,

Here is my review of
draft-irtf-mobops-location-privacy-solutions-08.txt.

I hope it's useful!

Cheers,
Michael

=======================================================================

According to:
http://www3.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#ResearchGroupPreparation
there must be a statement in the abstract identifying it as the product
of the RG.
This statement is missing.

These rules also state that it must be very clear throughout the
document that
it is not an IETF product and is not a standard. I'm not sure if this is
really so clear in this case.

Furthermore, the abstract should IMO be understandable without having to
dig
through references. Since the two references in the abstracts are RFCs,
I would prefer if the authors would mention the RFC numbers instead of
pointing to a reference.

On page 12, in para 1, you state that "the actual position of 'P'
bit is waiting for IANA approval" (btw, it should be "_the_ 'P' bit",
and this sentence is an example of the "following" problem - see below).
I don't know if this kind of statement is acceptable, should this
document become an RFC.

On the whole, the presentation is quite poor; while I have no expertise
in
this field (which, by the way, makes it very hard for me to comment on
technical issues), the document should be easier to read even for
someone like me than it is in its current form.

General presentation issues:
-----------------------------

The terminology is incomplete. Several abbreviations are never
introduced,
e.g. pHoA (although it's clear that this is the pseudo home address).
Not being an expert on Mobile IPv6, I have no idea what the HoTI, HoT,
CoTI and CoT messages are - the abbreviations should be listed in the
terminology, and a reference should be added together with a brief
explanation of what these messages are. RR refers to the Return
Routability Procedure, put this abbreviation in the terminology list.
In the text, it should be *the* RR procedure. In the context of this
document I'm also not sure what exactly "MAC" refers to. What is "BU"?
(used on page 25)

Speaking of abbreviations, I think that you should not omit articles
in front of them - e.g., instead of saying something like "MH talks
to CN", you should probably say "The MH talks to the CN".

Several sentences end with "and with home network prefix." or "one of
home
network prefixes." This is broken English, especially in a context like
this
one, on page 28: "The pseudo home address also has the feature of
routability
and with home network prefix."

I think you should avoid starting sentences with "And"; at least the
ones that
start that way seem odd.

I think that the phrase "similar with" doesn't exist, and should be
replaced
with "similar to" throughout the document.

Several sentences containing the word "following" are broken, usually
with a missing article or some other odd construction - e.g. pg 10
para above figure: "...HoTI message showed as following figure to...",
and sentences starting with "Following". I suggest to search for the
word "following" and fix these sentences. 

Presentation details:
---------------------

Page 5, para 3: "The other approach to generate _the_ pseudo home
address..."
further down same para: "...would securely generate _a_ pseudo home
address..."

Page 6 para 2: "...mechanisms where _the_ pseudo home address is
generated..."

Para 6 1st sentence: remove "of" in "the term of Pseudo..."
Next sentence: "In the following, we will propose..."
Next: "...during _the_ RR procedure..."  "... to _the_ CN during _the_
RR procedure."
Next: remove "later"

Page 8 para 5: I suggest to change "In the meanwhile, IPsec tunnel
enables..."
to "At the same time, using an IPsec tunnel enables...". End of this
para: remove
space before "."

Page 13: "launch the attack" -> "launch an attack"

pg 15 par 2: "either _a_ stateful or..."; par 4: "choose the prefix" ->
"choose a prefix"

pg 16 par 3 "may be not longer than IPsec" -> "may not be longer than
the IPsec..."
(and are you sure that this is shouldn'T be "must not"?)
par 4 has one of these "And .." sentences, where ", and ..." would be a
lot better.

pg 18: "pseduo" -> "pseudo"

pg 20: last par "showed" -> "shown", "...to indicate _THAT_ it uses..."

pg 21 par 1 "...using _the_ pseudo home... ... one of _the_ selectors"
last par "Upon (remove 'the') reception, the home..."

pg 22 last par: "ensure_s_ that..."

pg 23 par 1 1st sentence should be "... when the session was
established."
("Following" problem immediately after that)

pg 24 sentence "The pseudo HoA is routability and with home network
prefix."
is broken, I have no idea what you want to say here.

pg 25 sentence "So the BU processing in _the_ CN is little difference"
is broken,
and I don't understand what you want to say here.

table: weird mixture of things in left column: rules ("...option MUST be
present"),
facts ("Sequence Number field.. is greater than...") and todo-style
comments ("create/update
the BU entry...")

pg 26: par 1: "Ours" sounds too vague, and weird for an RFC - suggest to
write
"the new mechanism with the additional option" or something like that.
Same
sentence "need" is grammatically broken, and so is "then based on the
identity_address"
in that sentence - it seems a verb is missing here.

par 3: 1st sentence is broken. 3rd sentence "identity_addrees" ->
"..address".
4th sentence: just remove "Meantime"

par 4 1st and 2nd sentence broken ("When MN in foreign.." and "When MN
moving to.." misses "is";
also, in 2nd sentence,: "address become_s_ pHoAj.").

par 5 "...when set up a communication session" -> "when a communication
session is established."
next sentence should probably be "..is not to change ... a packet to the
upper layer".

par 6 "same as _the_ RR procedure"

par 7 "care _about_ the session..."

pg 27 par 1 "Before (remove "to") decrypting ...". sentence 2 "bring new
flood attack" is broken.

par 2 "If need much stronger..." and "...check if _the_ pHoA _is_ equal
to ..."

par 3 "...is just _a_ has value... CN _does_ not know the seq#, ..."

par 6 "for _the_ pseudo HoA..."

pg 28 bullet list last two items should start with "The" or "A"
par below: "multi-home_d_ addresses,..."
last par "...the mobile node _to_ use different..."

pg 29 par 2 "an old pseudo home _address_ should be withdrawn..."
par 3 "code as" -> "node is"; last sentence "update message to _the_
correspondent..."

pg 33 par 1 "_The_ pseudo home address provides...". sentence 2: "The
more information
is collected, the higher _the_ probability.... becomes, which in
return..."

par 2 remove ", but not limited to, "

pg 34 heading 6.2.2. should be "Hoe often should these invariants be
updated?"
par below "and also the higher _the_ costs _will be_ in terms of
communication..."

pg 35 par 1 "...number _to_ wrap (not "wrapping") around quickly ...
hash function
output _are_ used"

next par "MN-HA path _from_ correlating ..."

pg 36 par 2 "Eavesdroppers _are_ unable to derive..." last sentence
"prevent eavesdroppers _from_
linking the..."

par 4 remove "either" in last sentence
last line: should be  "node, and ..."

pg 37 par 1 last sentence "Note _that_ the same analysis..."

last par "focused on _the_ IP layer". last sentence: remove "which"

pg 38 par 1: 1st sentence "works" -> "work".
par 3 1st sentence "discussed" -> "discusses"
par 6 remove "instead"
par 7 remove isolated "." at the end

pg 39 par 2 "intend" -> "intended", "we presented the thorough" -> "we
presented thorough"

(btw weird to say that what you did was thorough in a draft - this is
not
a research paper)

---

From: "Rajeev Koodli" <[email-masked]>
Date: Tue, 20 May 2008 11:23:45 -0700

Hello Michael,
thank you for your detailed review. The authors will take a look and
respond.

In the meanwhile, couple of quick replies below.

> really so clear in this case.

This is a boilerplate issue for an IRTF RFC. The RFC coming from the IRTF
stream makes it evident that it is not an IETF product or a standard. The
boilerplate in the eventual RFC will capture that (it's hard to mention this
throughout the document)

> someone like me than it is in its current form.

I understand. However, the document is fairly involved, and does assume
familiarity with the nits and grits of IP mobility.
We will try to address your input below. However, I am afraid we cannot
simplify it further technically.

Thanks again.

-Rajeev

---

From: Michael Welzl <[email-masked]>
Date: Wed, 28 May 2008 14:06:30 +0200

On Tue, 2008-05-20 at 11:23 -0700, Rajeev Koodli wrote:
> On Mon, May 19, 2008 at 1:00 AM, Michael Welzl
> <[email-masked]> wrote:
>         
> This is a boilerplate issue for an IRTF RFC. The RFC coming from the
> IRTF stream makes it evident that it is not an IETF product or a
> standard. The boilerplate in the eventual RFC will capture that (it's
> hard to mention this throughout the document)

fine, i think

> I understand. However, the document is fairly involved, and does
> assume familiarity with the nits and grits of IP mobility. 
> We will try to address your input below. However, I am afraid we
> cannot simplify it further technically.

i understand that - but it will automatically be simplified by
fixing the presentation, e.g. the missing terms at the beginning
make it especially hard to read. with this document, it was
hard for me to even concentrate on the actual technical content
because the presentation is so broken. once that's fixed, everything
will be easier to understand

cheers
michael