Subject: [mobile-ip] Editorial comments on Draft 16 - Section 6-13

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

This is the second half of the editorial comments, covering Sections 6
through 13.

C6.4P9: /Home Agents MAY include/
What happens when a router splits its advertisement due to it being
too large?  If this option is included in only the first 'portion',
then later 'portions' will force the lifetime to be reset to the
Router Lifetime. Does this option have to be included in all
'portions'?

C7:
What happened to the sub-section describing the requirements for all
hosts and routers? Are there no longer any requirements on CNs? What
about handling route optimization messages?

C7.1P5:
Reword the paragraph to something like:
'Filtering routers SHOULD support different rules for Type 0 and Type
2 Routing headers so that filtering of source routed packets (Type 0)
will not necessarily limit MIPv6 traffic via Type 2 Routing headers.'

C7.3P3: s/options/messages/

C7.3P6: s/option/message/

C7.3P7:
The paragraph is not completely clear that the packets with the HAO
are sent with the CoA as the source address.  It also seems to
preclude the use of reverse tunneling.  Actually, shouldn't reverse
tunneling be a requirement? Decapsulation is, but encapsulation is
not.

C8:
The discussion of CN RR processing is missing.

C8.1P1:
There's no note about requiring a valid BCE to accept the HAO.

C8.2P1S1: s/option/message/

C8.2P1S3: /packet MUST contain/
This actually contradicts Section 5.1.7.

C8.2P1S4: 
s/Option Length/Header Len/
None of the MIPv6 messages state the required minimum value of Header
Len.

C8.2P1S5:
16-bit sequence numbers.

C8.2P3S1:
s/any other reason (than/any reason other than/
s/Number) MUST/Number MUST/

C8.3P2S1:
s/node (or/node, or/
s/exists)./exists./

C8.3P2S2: s/new Binding/Binding/

C8.3P2S-1: s/this lifetime in the Binding Cache entry/its lifetime/

C8.5P1S1: s/option/message/

C8.5P1S2: s/and the 'A' bit was set in the Binding Update,//

C8.5P1S-2: s/was not sent/was not set/

C8.5P6: /In response to/
Isn't this actually an error that would require a reply by the rules
in the first paragraph. This paragraph should just be removed.

C8.6:
May need to state that the BR meet certain security requirements if
that is so decided.

C8.6P2S1,-1: s/option/message/

C8.6P2S2:
This sentence should be removed, it refers to piggy-backing.

C8.7P2S3: s/in addition//

C8.7P3S1: /SHOULD return/
This is a MUST in Section 8.5.

C8.7P3S-1: s/a "home registration"/"home registrations"/

C8.7P4S-1: s/to add an entry again/to again add an entry/

C8.8P4S2:
This is just a nit, but here we state a MUST in terms of a weakly
defined concept of 'persistent' ICMP messages. Should there be
something more concrete?

C8.9:
This sub-section should actually follow Section 8.7.

C8.9P1S3: s/Type 0/Type 2/

C8.9P2S1: s/Type 0/Type 2/

C8.9P4: /It is possible that/
This paragraph no longer applies.

C9.1P2:
Missing a couple of tests:
1) require the presence of an HAO
2) require that HoA in HAO and BU match.
Plus, the final test about DAD is rather rough.

C9.1P2S2-4: /SHOULD return a Binding Ack/
This is a MUST in Section 8.5.

C9.1P3S2: 
s/node (or update its/node, or update an/
s/for this mobile node,//

C9.1P6S1: s/possible/possibly/

C9.1P6S5:
Are the lifetime of all BCEs actually limited to the minimum of all
prefix lifetimes? I don't think that this is mandated in later text.

C9.1P7S3: /The only currently defined/
This is repetitive and not very informative.

C9.1P8:
What about the other things that the HA must do for the MN, such as
reverse tunneling and prefix propagation?

C9.2P2S2:
s/entry in/entry marked as a "home registration" in/
s/that is marked as a "home registration"//

C9.2P4S3: /The only currently defined/
Again a repeat and not very informative.

C9.2P5S1: s/link addressed/link that are addressed/

C9.3P1S1: 
s/link addressed/link that are addressed/
s/using using/using/

C9.3P2: /The Router (R) bit/
This no longer applies.

C9.3P4S-1: /This check MUST include/
What if the 'S' bit was set, do we still check all possible
combinations.
Prefix Length is no longer applicable.

C9.4P2S1: /Prefix Length field was nonzero/
Prefix Length is no longer applicable.

C9.5P1S1: /sent to it from a mobile node's home address/
What does this mean exactly?  I think it should be made more clear.
It should also be mentioned that this is the default behavior until
route optimization has been setup.

C9.6P2S1:
s/need protection/require protection/
Are BUs and BAs ever tunneled?

C9.7:
The section reads a bit odd.

C9.7P3: /receive Mobile Prefix/
This seems to be talking about normal IPv6 renumbering. If that's the
case then nodes receive just normal Prefix Adverts.  If this is
actually about sending Mobile Prefix Adverts then the paragraph is not
at all clear.

C9.8P1S-1:
s/each other home agent/other home agents/
This is an extremely long sentence.

C9.8P2S2: /If the Home Agent (H) bit...skip all/
This will skip the next step which fits the same criteria.

C9.9.1P4S1: /possibly including ... destination options/
This clause is obsolete. It refers to piggy-backing.

C9.9.2P1S2: s/home address changes/home address./

C9.9.2P1S3: s/Router Solicitation/Mobile Prefix Solicitation/

C9.9.2P1S4,5:
Add periods to end of bullets.

C9.9.2P2S4: /ensure that a transmission is scheduled/
It may help to add a '(as described below) here to make it clear that
scheduling is a separate issue.

C9.9.2P2S5: /are any unacknowledged/
It's not mentioned until much later how to acknowledge an advert.  In
fact, the mechanism doesn't quite work since it depended on the fact
that a BR would be piggy-backed on the advert.

C9.9.2P2S6: /SHOULD have the Binding Request/
This won't work without piggy-backing.

C9.9.2P3S1:
s/Router Advertisement/Prefix Advertisement/
This is an extremely long sentence.

C9.9.2P5: /The mobile will get the revised information/
Not quite true anymore.

C9.9.2P6: /RAND_ADV_DELAY is/
This paragraph should maybe come a little earlier.

C9.9.3P1S5: /the advertisement MUST include/
This won't work without piggy-backing.

C9.9.3P2:
This won't work without piggy-backing.

C9.9.3P2S1: s/Sequence Number/Unique Identifier/

C9.9.3P2-4:
These are really scheduling issues and should appear in the previous
sub-section.

C9.9.4P1-2:
These are not HA operations.  They belong in the MN operations section.

C10.1P1S1: s/address as well as/address, as well as/

C10.1P1S6: s/address in this way./address./

C10.1P1S7: /When sending such packets/
This is only true for route optimization.

C10.1P3:
This paragraph ignores reverse tunneling, nor does it mention that the
CN must have a valid BCE prior to using the HAO.

C10.1P3S3: s/e.g., to TCP/e.g., TCP/

C10.2P1S4: s/e.g., by TCP/e.g., TCP/

C10.2P1S9: 
s/through through/through/
May also note that further IPSec processing may occur on outer header
according to normal IPSec rules.

C10.2P1S-1: s/remain the same/remains the same/

C10.2P2S1: s/any new SA/a new SA/

C10.4P8S1: s/link-level address to it/addressed to it at the link-level/

C10.7P1S2: s/option/message/

C10.7P1S6:
s/sub-option/parameter/
s/option/message/

C10.7P3: /The Prefix Length/
The first sentence no longer applies.
The rest of the paragraph should be in reference to the value of the
'S' bit.

C10.7P5S2: /These additional/
This assumes the existence of piggy-backing.

C10.7P5S3: /Each care-of address/
I don't understand this sentence!

C10.7P7S4: s/showing Status 138/containing a Status of 138/

C10.7P7S-1: s/appendix B/Appendix B/

C10.8P2S1: s/discovery/discover/

C10.8P2S-1: s/Request message/request message/

C10.9P1S2: s/See for example/See, for example,/

C10.9P1S-1: s/Sub-Option/Parameter/

C10.9P3S1: s/Cache to record/Cache in order to record/

C10.9P3S-1: /SHOULD be less than or equal to/
Previously, I think that the lifetime was supposed to be less than the
remaining lifetime of the home registration binding which may be less
than the lifetime of either the HoA or CoA.

C10.9P4S-1: /A mobile node MAY set/
This sentence has no relation to the rest of the paragraph.  It should
actually go at the end of the first paragraph.

C10.9P8: /The mobile node, however, need not send/
This is about piggy-backing and should be removed.

C10.10P1S3: /The Source Address/
This sentence seems a bit redundant with respect to the next sentence.

C10.10P1S5: s/agenet/agent/

C10.10P3S2: s/5.1.5/5.1.6/

C10.10P3S3: /The Source Address/
Again this seems a bit redundant.

C10.11P2S5:
s/sub-option/parameter/
s/option/message/

C10.11P5S-1: s/4.5/4.5.4/

C10.13P1S1: s/about the same/for the same/

C10.14P1S3:
s/Option Length/Header Len/
s/option/message/

C10.14P2: /Any Binding Acknowledgement/
This paragraph assumes the presence of piggy-backing.

C10.15P1S2: /except that this lifetime MUST NOT exceed/
The maximum lifetime differs from time in Section 10.9.

C10.15P3: s/Sub-Option/Parameter/

C10.16:
This is a repeat of Section 10.17.

C10.17P1: 
This is incorrect for new MIPv6 messages. Instead the Code 0 solution
as discussed recently on the mailing list should be presented.

C10.17P2S1: /although ALL IPv6 nodes/
This is actually no longer stipulated in the requirements.

C10.17P2S-1: /this error message indicates/
It should also be noted that the mobile node should not attempt route
optimization with this CN.

C10.18P3S1:
s/address (but/address, but/
s/authenticated)./authenticated./

C10.19P2S5,6: /The packet MUST be protected by IPSec/
This precludes the MN from soliciting an advert prior to configuring
its HoA which is said to be acceptable in Section 9.9.3

C10.19P5: /If the advertisement contains/
Specific to piggy-backed solution for acknowledging adverts.

C10.21P2: /In order to receive/
This paragraph is confusing.  It starts out by talking about receiving
multicast, but finishes with adding HAO to sent packets.  It should be
split up and clarified. 
Also, in the last paragraph of the section, an alternative to adding
the HAO is provided through reverse tunneling.  Question, will HAOs
work now with multicast since CNs won't have a matching BCE?

C12:
This section should be an appendix.

C12.2P1S1:
s/opening up/opening/
s/cache i.e. there/
s/cache; i.e., there/

C12.3P1S1: s/level of security/levels of security/

C12.3P1S-1: /This isn't/
There seems to be a dangling sentence here.

C13P1S4: s/5.1.2 to 5.1.9/5.1.2 through 5.1.9/

C13P3S2: s/5.2.2 to 5.2.5/5.2.2 through 5.2.5/

C13P3:
Need to add entries for Nonce Indices and Authentication Data
parameters.

C13P5:
The destination sub-options will probably disappear.

C13P6S1: s/IPv6 Routing Header type, 2/IPv6 Type 2 Routing header/

C13P6S2: /The value 2 is/
The tense of 'is' seems odd, but I don't know if it's correct for this
type of section.

C14.1P1S1: /The use of IPSec/
This is a sentence fragment.
s/protects/protect/

C14.2P1S-1: /Replay protection is provided/
I don't think that this sentence applies any longer.

C14.3P2S2: s/in order to perform e.g./e.g., in order to perform/

C14.3P2S-1: /maximum of five minutes/
I'm not sure that a maximum was defined anywhere in the document.

C14.3P3:
This paragraph is very colloquial and rather loose.

C14.3P3S1: s/node is when/node occur when/

C14.3P3S2: s/path as well but/path, as well, but/

C14.3P3S3: s/security as well in/security, as well as in/

C14.4P1S3: s/the answers/replies/

C14.4P1S-2: /the home address has agreed/
I'm not sure what it means for the home address to agree to anything.

C14.4P3: /A node receiving/
This paragraph is not about security and should be removed.

C14.5P2S-1: s/inside as well as/inside, as well as/

C14.5P3S1:
s/that device which implement/that a device which implements/
s/distinguish routing header type 2 from other routing/
s/distinguish between a Type 2 Routing header and other Routing/

C14.5P3S-1: s/use of routing/uses of Routing/

Acknowledgements: 
s/University of California at Santa Barbara/
  University of California, Santa Barbara/

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/ |

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