Subject: [mobile-ip] Editorial comments on Draft 16 - Sections 1-5

From: Robert Chalmers <[email-masked]>
Date: Wed, 17 Apr 2002 16:02:38 -0700

Comments on draft 16. I realize that this is an interim draft, but I
wanted to ensure that these issues were addressed in draft 17.

Note: These are mainly editorial nits, but I wasn't sure if Charlie
was the only one still editing the document. I've broken up the comments
into two parts to ensure that they will fit within the e-mail size
limit.

First off, I think that the current version of the draft is hard to
read and very repetitious.  We need to limit explaining things in more
than one place. This usually leads to inconsistencies when changes are
made (as will soon be seen).  In particular, Section 4 should really
only be an overview. It should contain just the high-level view of the
protocol necessary for the reader to understand how it works.  Details
(SHOULDs and MUSTs) should occur in later sections describing the
requirements and operations (7-10).

Another general problem throughout the document is the inconsistent
use of capitalization.  At times home agent, binding update, etc. are
capitalized, and other times not.  If something is a major term
defined in the document then I think it should be capitalized
everywhere.

Now on to the specifics (most of you will probably want to hit Del at
this point).  I'll use the notation C1P1S1 to mean chapter (section)
1, paragraph 1, sentence 1.  Negative numbers count from the end;
e.g., C1P1S-1 would be the last sentence of the first paragraph.  If
not clear, I'll indicate the context of the comment with 
/pertinent text/, and I'll indicate possible word (phrase) substitution
 with s/hapy/happy/.

C2P3S-1: s/nor stationary/or stationary/

C2P9S-1: /due to the ability to not be concerned with/ 
This could be made more concise in terms of 'decoupling'.

C2P11S1: s/used IPv4/uses IPv4/ s/and returned a/and returns a/

C2P11S-1:
Odd sentence and actually somewhat questionable.  Do you really think
that a "huge" number of home agents would respond causing implosion and
severe packet loss?  I think you're more likely to simply lose a
packet in the network.

C2P12S1: s/option on/option for/

C3.1P11: /Security Association/ This term, SPD, Binding Key and BSA
are capitalized while the other terms are not. Also the first word, a,
is not capitalized for three of the four.  Finally, the last sentence
mentions a key defined above where no key had been previously defined.

C3.2P1: /home address/
The definition is somewhat circular with respect to 'home link'.

C3.2P10: /care-of address/
This should be moved before the definition of 'home agent' since that
definition refers to the CoA.

C3.2P10S2: s/at a time/any given time/

C4: 
This section is the most inconsistent in its level of detail.
Moreover, the ordering is odd.  The basic operation should probably be
first, and should probably subsume Section 4.8.  All new protocols,
destination options, ICMP messages, etc. should be presented in order.
Currently they are separated by too much description - it gets
confusing.

C4.1P1S1:
I'd lose the pre-reference to Section 4.2.  It doesn't help.

C4.1P2S1:
Return Routability needs to be defined as a term in Section 3.2.

C4.1P2S2: s/subsequence/subsequent/

C4.1P6S-2: s/Section 4.5/Section 4.5.5/

C4.1P7S-2: s/Section 4.5/Section 4.5.5/

C4.1P8S1: s/request a mobile node to send/request that a mobile node
send/

C4.1P10,11:
This is not really overview material. It should be pushed to Section
5.1.1.

C4.2P4S2: 
s/This binding registration is done by the mobile node/
  The mobile node performs this binding registration by/

C4.2P4S3: 
s/address in this binding registered with its home agent/
  address associated with this binding registration/

C4.2P5S1: s/node's care-of/node's new care-of/

C4.2P5S2: /it is specified to be used/
Odd sentence structure.

C4.2P6S-1: /care-of addresses/
Why multiple addresses?  The section talks about only one home address
- multiple home addresses are introduced much later.

C4.2P8S1: s/destination option/message/

C4.2P9:
Refers to piggybacking, and should be removed.

C4.2P10: 
No mention is made of HAO being legal only when route optimization is
being used, i.e., a binding cache entry exists at CN.  Too much detail
is not necessary, but it should be stated in the overview that reverse
tunneling is now the 'basic' mode.

C4.2P10S4: /yet ingress filtering/ 
Odd sentence.  Why is 'yet' used here? The second clause does not
contradict the first.  What does the second clause actually add to the
sentence?

C4.3P1S1: /As mentioned in/
The reference doesn't really help here.

C4.3P2S3: /transparent to the correspondent node/
We should be careful here.  It is only transparent to upper layers.

C4.3P2S-2: s/sections 10.2 and 5.3/Sections 5.3 and 10.2/

C4.4:
This is not really overview material. It should be pushed to Section
5.3.

C4.5:
This should really be the last sub-section of the overview section,
and it should only contain overview material pertinent to security
such as the threats, features and rationale. The actual operations
should be moved to the operational sections (8-10).

C4.5.1:
This section needs to be rewritten to sound less colloquial.  Words
like 'lie' and 'trick' should be replaced with more formal terms.
Plus, capitalization is inconsistent with previous sections: 
s/binding update/Binding Update/

C4.5.1P2S2: s/a attacker/An attacker/

C4.5.1P2S-1: s/didn't/did not/

C4.5.1P4S3: s/node accepted this/node accepts this/

C4.5.1P4S3,4:
s/mobile/mobile node/
s/correspondent/correspondent node/

C4.5.1P7S1:
s/is used to/is leveraged to/
s/other parties/a third party:/

C4.5.1P7S2:
s/traffic against a/traffic toward a/
s/without giving a possibility for/without allowing/

C4.5.1P8:
Rather thin description.

C4.5.1P9S1: 
s/where IPv6/where the IPv6/
s/from other nodes./from other nodes:/

C4.5.1P9S2:
s/allows the kind/allows this kind/
s/MIPV6 needs/MIPv6 requires/

C4.5.1P11:
Should be included with the intro paragraph for this sub-section.

C4.5.2P2S2: s/can thus have/thus have/

C4.5.2P2S-1: s/4.5.5/4.5.4/

C4.5.2P3S2: s/belonging under/belonging to/
This sentence is the a conclusion and should be stated at the end of
the paragraph, or stated first and then defended.

C4.5.2P4S1: /A different approach/
Different from what, an infrastructure-less approach?  The difference
between infrastructured versus infrastructure-less was made in the
previous paragraph.

C4.5.2P4S2: /with the addresses/
You don't really perform an exchange with addresses.
s/sent cookies/exchanged cookies/

C4.5.2P5S1: s/as follows./as follows:/

C4.5.3:
The title doesn't really fit the content.  The text pertains only to
reverse tunneling.

C4.5.4P2S2: s/used to for/used for/

C4.5.5P1S3: /receive traffic on them/
Do you really receive traffic on an address?

C4.5.5P1S5: s/exchanges were responses/exchanges where responses/

C4.5.5P1S6: s/receive the a binding/receive a binding/

C4.5.5P3S-1: s/will can be/will be/

C4.5.5P5:
Here 'l' is used as one of the nonce subscripts when later 'i' is
used.  In fact, if 'i' and 'j' are used they should be used in order.
In later text, 'j' is used before 'i' and it seems odd.

C4.5.5: /HoTI (Home Test Init) Message/
s/This message tells/This message imparts/ or /This message conveys/

C4.5.5: /CoT (Care-of Test) Message/
s/sent directly the mobile node./sent directly to the mobile node at its
CoA/
s/used for distinguishing home/used to distinguish between home/
s/from each other//

C4.5.6P3S1: s/situations it is/situations in which it is/

C4.5.6P3S2: s/treat/consider/

C4.5.6P4S4: s/by stopping/by not/

C4.5.7:
Should probably be the first security sub-section.

C4.6P6:
Need a period at end of last sentence.  Plus, should add 'This message
is specified in Section 5.9' for consistency.

C4.7P9:
Sequence number is back to 16-bits.  There's actually an old reference
to "int" data type which should have been changed to "char", but is
now correct.

C4.7P10S-1: s/lifetime on/lifetime of/

C4.7P13: /SHOULD NOT be deleted/ /MUST NOT be changed/
Seems a bit heavy for an overview of the conceptual data structures.,
and it's probably all repeated later anyway.

C4.7P16: /The home address for which/
s/home addresses/home address/
The second bullet is a bit confusing.

C4.7P20:
Sequence number is back to 16-bits.

C4.8P3S-1: s/4.5/4.5.5./

C4.8P5:
This is a repeat from what was already said in the Basic Operation
sub-section.

C5.1P1S3: s/5.1.2 to 5.1.9/5.1.2 through 5.1.9/

C5.1P1S4:
This seems like an odd place for this requirement.  I'd leave it for
specific sections pertaining to MN operations.

C5.1.1P6S2: /MH Type/
s/5.1.2 to 5.1.8/5.1.2 through 5.1.9/

C5.1.1P7S3: /Checksum/
s/section 8.1/Section 8.1/

C5.1.2P1S-1: s/NOT respond Binding/NOT respond to Binding/

C5.1.2P4S1: /Parameters/
Lose the comma after 'Variable-length field'. This is repeated for
all message descriptions.

C5.1.2P4: 
The sentence from paragraph 6, 'The encoding and format ... in Section
5.2', should be moved up to this paragraph to provide a pre-reference
for the Authentication Data parameter. 
This also occurs in Sections 5.1.7 and 5.1.8.

C5.1.2P5S-1: /The actual authenticator calculation/
s/over sequence/over a sequence/
The reference to the description in Section 4.5 doesn't seem to exist.
This also occurs in Sections 5.1.7 and 5.1.8.

C5.1.3P1S1:
Should specifically mention that the procedure is to test the validity
of the home address.

C5.1.3P3: /Flags/
This should simply be a reserved field. There shouldn't be any specific 
purpose designated for the bits.

C5.1.3P5: /If no actual parameters/
No padding required.

C5.1.4P1S1:
Should specifically mention that the procedure is to test the validity
of the care-of address.

C5.1.4P3: /Reserved/
This should simply be a reserved field. There shouldn't be any specific 
purpose designated for the bits.

C5.1.5P1S1: s/is an answer/is a response/

C5.1.5:
The home cookie is a 128-bit field aligned on a 32-bit boundary.  I do
believe it should be on a 64-bit boundary.

C5.1.5P3: /Reserved/
This should be a contiguous 32-bit field.  Otherwise, it has to be
separated into two separate 16-bit reserved fields.  Again, it should
not be specifically reserved for use by future flags.

C5.1.5P9S-1:
s/prevent attackets e.g. on the same link as the MN to/
  prevent attackers, possibly on the same link as the MN, to/

C5.1.6P1S1: s/is an answer/is a response/

C5.1.6:
The care-of cookie is a 128-bit field aligned on a 32-bit boundary.  I
do believe it should be on a 64-bit boundary.

C5.1.6P3: /Reserved/
This should be a contiguous 32-bit field.  Otherwise, it has to be
separated into two separate 16-bit reserved fields.  Again, it should
not be specifically reserved for use by future flags.

C5.1.7P4S-1: /Home Registration/
The last part in parentheses, 'given by the ...', is confusing at this
point in the document.  Since the HoA is provided in the BU, nothing
should be said here.  Later, it is stated that the HAO is necessary
and that both addresses must match.

C5.1.7P6S1:
s/request the receiving/request that the receiving/
s/to perform Duplicate/perform Duplicate/

C5.1.7P8S-1: /Sequence Number/
The last sentence no longer applies.  Error code 141 should probably
mention here for consistency.

C5.1.7P10S1: /Home Address/
Replace the existing sentence with something like:
'The home address of the mobile node associated with this Binding
Update.'

C5.1.7P16S1: 
s/message to the correspondent/message to a correspondent/
s/include the Home/include a Home/
s/avoid reflection/avoid the reflection/

C5.1.7P16S2: s/A Binding Update/However, a Binding Update/

C5.1.7P17S2: s/check for the equal/check for equal/

C5.1.7P18:
This paragraph is unnecessary and confusing with respect to previous
paragraphs.

C5.1.7P20S1: s/, if present,//

C5.1.7P22S1: s/Binding parameter/Binding Update/

C5.1.7P20,22:
Seems like a bit too much detail for this section.

C5.1.8P1S2: s/Binding Parameter carried in the//

C5.1.8P1S3: s/an answer/in response/ 
The sentence should actually be reworded to avoid ending that clause
in 'to'.

C5.1.8P4: /144/ and /145/
s/Too old/Expired/

C5.1.8P6S1: /Lifetime/
s/node will SHOULD/node SHOULD/

C5.1.8P7S1: 
s/keep on using/continue to use/
s/of outgoing/on outgoing/

C5.1.8P8S-1: /Refresh/
The last sentence no longer applies.

C5.1.8P14S-1: s/inserted to the message/added to the message/

C5.1.8P15S-1: s/Binding Ack Parameter/Binding Acknowledgement/

C5.1.9P1S2: s/Option i.e./Option, i.e.,/

C5.1.9P2-5:
These belong in the MN operations section.

C5.1.9P3S2: s/loss of resources spent on the/a waste of resources on/

C5.1.9P7: /Reserved/
This should simply be a reserved field. There shouldn't be any specific 
purpose designated for the bits.

C5.1.9P8S-1: /Home Address/
s/if there mobile/in cases where the mobile/

C5.2.1P5S-1: /Parameter Type/
s/sub-options in the option/
s/parameters in the message/

C5.2.1P6S2: /Parameter Length/
s/the Parameter Data field//

C5.2.1P6S3: /Parameter Length/
Why is this different from the way destination sub-options were used -
length excludes first two fields?  Is there a precedent we are
following?

C5.2.1P7: /Parameter Data/
Replace existing text with something like:
'A variable length field that contains data specific to the parameter.'

C5.2.1P8:
An odd question - if all parameters must start on 8-byte boundaries,
why don't we make all message end on 8-byte boundaries.  Is is to
simply make those message without a parameter take up minimum space.
When considering those that require a parameter, though, does it make
any since to 'require' padding.  Wouldn't that space be better spent
as reserved space.

C5.2.2-5.2.7:
A new format has been introduced here.  The name of the parameter is
repeated, and the alignment requirement are in parentheses.  It should
be kept consistent with the other packet formats.

C5.2.2P3S-1: s/used, rather/used rather/

C5.2.3P2S1: s/into the Parameters area of some/in the Parameter of a/

C5.2.4P1S1: s/Identifier parameter/Identifier Parameter/

C5.2.4P2:
The HoTI and CoTI messages mention this parameter as legal, but here
it says only BU and BR can have it.

C5.2.5P1S1: s/Address parameter/Address Parameter/

C5.2.6P1S1: s/8n+6/8n+2/

C5.2.7P1S1: s/8n+6/8n+2/

C5.3P1S-2:
Again, we should be careful about the use of the word transparent.

C5.3:
This sub-section should be rearranged a little. The last paragraph
(P14) should immediately follow P7, 'The alignment requirement...'.
P13 should follow P14. P8, 'The inclusion of...', should be moved to
the end of the sub-section.

C5.4P1S1: s/node which the/node. The/

C5.4P2:
Reword the paragraph to something like:
'This uses a different routing header type than defined for "regular"
IPv6 source routing, enabling firewalls to apply different rules to
source routed packets than to MIPv6. This routing header type (Type 2)
is restricted to carry only one IPv6 address.  All IPv6 nodes which
process this routing header MUST verify that the address contained
within is the node's own home address in order to prevent packets from
being forwarded outside the node.'

C5.4.1P4: /Routing Type/
A full sentence would be more clear.

C5.4.1P5: /Segments Left/
s/remaining, i.e., number/remaining; i.e., the number/
The last sentence is not quite true.  Segments left can be decremented
within the node and resubmitted to the IP stack. On the second pass,
the field will be zero, and this is still a valid header.

C5.4.1P6: /Reserved/
s/transmission; ignored/transmission, and ignore/

C5.4.2:
This should be moved to the CN operations section.

C5.4.2P1S2: 
s/cache and if/cache. If/
s/then the IP/, then the IP/
s/of type 2/with type 2/
s/rules below and moves the Home Address to/
  rules below. The Home Address is copied into/
s/RH and places the Care of Address in/
  RH, and the Care-of Address is placed in/

C5.4.2P2S1: s/conceptually/conceptual/

C5.4.3P1S2: s/routing header of type 2/Type 2 Routing header/

C5.4.3P1:
All bullets need final periods.

C5.4.3P2:
If you follow these steps, the packet would then fail the tests in the
previous paragraph.

C5.4.3P2S1:
This is a sentence fragment.

C5.4.3P2S2: s/RFC 2460 i.e. swap/RFC 2460; i.e., swap/

C5.4.3P3:
The paragraph is not very clear. It depends on a previous explanation
of how t he original AH was calculated. It may be helpful to repeat
that part here.

C5.4.3P3S1: s/Header any/Header, any/

C5.4.3P3S-1:
Replace the sentence with something like:
'Thus, the AH calculations at the sender and receiver will have an
identical view of the packet.'

C5.4.4P1:
The paragraph is oddly presented. It could be made clearer with
something like:
'The ordering rules for extension headers in an IPv6 packet are
described in Section 4.1 of RFC 2460. The new Routing header (Type 2)
defined for Mobile IPv6 follows the same ordering as other routing
headers. If more than one routing header (e.g., both a Type 0 and a
Type 2 Routing header are present), the Type 2 Routing header should
follow all other Routing headers.'

C5.4.5P1S-1: s/done to type 2 routing headers/done for Type 2 Routing
headers/

C5.5:
I believe this section will be removed. If not, however, it should be
made a sub-section of Section 5.3.

C5.6P1S-1:
s/agents there responds/agents responds/
s/message giving/message, providing/

C5.6P7S2: s/then MUST return/MUST then return/

C5.6P7S-1: s/node not registered/node is not registered/

C5.1P1S-1:
s/agents there responds/agents responds/
s/message giving/message, providing/

C5.9P1S-1:
This section refers to itself. Should this be Section 9.7?

C5.9P2: /Source Address/
s/i.e. same prefix/i.e., same network prefix/

C5.9P4: /Authentication Header/
Replace description with something like:
'An AH header MUST be included unless the mobile node has yet to
configure a home address.'

C5.9P8S1: /Prefix Information/
s/options,/options./
s/which contain/Each option carries/
s/the mobile node should/that the mobile node should use to/
s/address(es) with./address(es)./

C5.9P11S2: /Home Agents MUST ignore/
Should this be 'Mobile nodes MUST ignore'?

enjoy,
Bob

-- 
/****************************************************************

 Robert Chalmers
 UCSB Computer Science Doctoral Candidate
 Network and Multimedia Systems Lab (NMSL)

 "My heart is in the code, but my soul lies in the process"
 
 | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

---

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Apr 2002 02:02:39 +0300

> believe it should be on a 64-bit boundary.

There's a tradeoff on making the cookie aligned on a 64 bit boundary
vs. spending 8 reserved bytes vs. not saving any bits for flags (though
flags can be simulated with options). I'm thinking we should spend the 8
bytes. Comments?

> any since to 'require' padding.  Wouldn't that space be better spent

Yes. If we do this, it might make sense to mandate that all parameters
are also multiple of 8 bytes, making pad1 and padn unnecessary. Comments?

Jari