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

Michael Welzl <michael.welzl@uibk.ac.at> Mon, 19 May 2008 19:11 UTC

Return-Path: <mobopts-bounces@ietf.org>
X-Original-To: mobopts-archive@megatron.ietf.org
Delivered-To: ietfarch-mobopts-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770383A6B46; Mon, 19 May 2008 12:11:10 -0700 (PDT)
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FA93A6D29 for <mobopts@core3.amsl.com>; Mon, 19 May 2008 01:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.269
X-Spam-Level:
X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MANGLED_LIST=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 pgFG7psMThh0 for <mobopts@core3.amsl.com>; Mon, 19 May 2008 01:00:59 -0700 (PDT)
Received: from smtp.uibk.ac.at (lmr1.uibk.ac.at [138.232.1.142]) by core3.amsl.com (Postfix) with ESMTP id C1F693A685E for <mobopts@irtf.org>; Mon, 19 May 2008 01:00:58 -0700 (PDT)
Received: from [138.232.65.105] (pc105-c703.uibk.ac.at [138.232.65.105] michael.welzl@uibk.ac.at) (authenticated bits=0) by smtp.uibk.ac.at (8.13.8/8.13.8/F1) with ESMTP id m4J80qON021681 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 19 May 2008 10:00:52 +0200
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: rajeev_koodli@yahoo.com
In-Reply-To: <424070.62934.qm@web50302.mail.re2.yahoo.com>
References: <424070.62934.qm@web50302.mail.re2.yahoo.com>
Organization: University of Innsbruck
Date: Mon, 19 May 2008 10:00:52 +0200
Message-Id: <1211184052.3652.55.camel@pc105-c703.uibk.ac.at>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
X-Scanned-By: MIMEDefang 2.61 at uibk.ac.at on 138.232.1.140
X-Mailman-Approved-At: Mon, 19 May 2008 12:11:07 -0700
Cc: irsg@ISI.EDU, basavaraj.patil@nsn.com, mobopts@irtf.org
Subject: [Mobopts] IRSG review of draft-irtf-mobopts-location-privacy-solutions-08.txt
X-BeenThere: mobopts@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mobopts>
List-Post: <mailto:mobopts@ietf.org>
List-Help: <mailto:mobopts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mobopts-bounces@ietf.org
Errors-To: mobopts-bounces@ietf.org

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)



_______________________________________________
Mobopts mailing list
Mobopts@ietf.org
https://www.ietf.org/mailman/listinfo/mobopts