I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mipshop-fmipv6-rfc4068bis-06
Reviewer: Ben Campbell
Review Date: 2008-3-15
IETF LC End Date: 2008-3-15
Summary: This document is on the right track, but needs work.
Comments:
Disclaimer: I do not have much background in Mobile IPv6. I assume
others have reviewed this for technical correctness.
--General Comments
This is a difficult review, as the document is an update to a previous
RFC. It is almost certain that some of my comments apply to the
original RFC, and I realize that the goal of this revision is probably
not to fix _every_ issue in that RFC. Therefore, a response to the
effect of "That issue was in the original RFC, and was beyond the
scope of our changes" is perfectly reasonable for most of my comments.
That being said, there are a large number of editorial nits that have
clearly been introduced in this draft that were not in the original
RFC. The omission of articles and incorrect use of "an" vs "a" occur
throughout. A diff shows that there are several paragraphs where the
introduction of such errors are the _only_ changes from the RFC, which
I suspect they may be the result of regression errors. Is it possible
that the author started from the original test for RFC 4068 _before_
the RFC editor edits? If so, I am concerned that if there were any
substantive changes introduced to RFC 4068 during the RFC Editor or
author's 48 process, they may have been lost. Checking for such
losses would, unfortunately, require more time than I can commit to
this review.
I find the general organization of this document hard to follow. The
general operation of the protocol is described no less than 3 times.
Section 3.1 gives a high level overview. 3.2 gives the same
description in more detail with some more normative language. Section
4 describes it in even more detail with more normative language. It is
common to have an overview section and a detailed operation section,
but I am confused by the presence of the "middle" description.
Normative language is spread across the sections, which increases the
odds of implementation errors.
I read through all three descriptions, and still found myself
wondering about basic questions such as "what transport do these
messages use?" It wasn't until section 6 that I learned that some of
the messages are ICMPv6 extensions, and that some of Mobile IPv6
extensions.
Finally, there is a great deal of imprecise language that I think
could impact interoperability. There are a number of statements of the
form "an XXX message is sent" or "XXX/YYY messages are exchanged" that
left me digging to figure out what device sends the message and what
device consumes it. I will address some of these in the detailed
comments, but I'm sure there are a number that I missed.
-- Detailed Comments:
Section 2, RFC 2119 boilerplate:
IDNITS does not like the 2119 boilerplate. I don't think 2119 defines
"silently ignore".
Section 2, Figure 1:
Do you intend Figure 1 to be part of the terminology section? It might
make more sense to put it nearer the first reference.
3.1, paragraph 4:
"The information provided in the PrRtAdv message can be used even when
DHCP [rfc3315] is used to configure an NCoA on the NAR's link. In
this case, the protocol supports forwarding using PCoA, and the MN
performs DHCP once it attaches to the NAR's link. The MN still
formulates an NCoA for FBU processing; however, it MUST NOT send
packets using this NCoA."
The "this NCoA" in the last sentence is assumed to be different than
the one received via DHCP, right?
paragraph 5. last sentence:
"Otherwise, it should send it immediately
after detecting attachment to NAR."
I found the multiple use of "it" to cause pronoun confusion.
"And,
PAR SHOULD forward the inner packet in the tunnel to its destination
(i.e., to the MN's correspondent)."
Is SHOULD strong enough for this requirement? What happens if the PAR
does not forward the inner packet?
paragraph 7:
"In addition, buffering for handover traffic may be
desirable."
Buffering by which device? (NAR or PAR?)
last paragraph"
"The
access routers MUST have necessary security association established
by means outside the scope of this document."
The document should at least describe the security characteristics
expected for such security associations, if it is not going to specify
the mechanisms. (Does this conflict with statements about IPSec in the
security considerations section?)
3.2, paragraph 1"
"The protocol begins when a MN sends RtSolPr to its access router..."
Which access router? PAR or NAR? Please be specific.
paragraph 2:
" With the information provided in the PrRtAdv message, the MN
formulates a prospective NCoA and sends an FBU message."
To where? Please be specific.
paragraph 3:
" Depending on whether an FBack is received or not on the previous
link, which clearly depends on whether FBU was sent in the first
place, there are two modes of operation."
I found this confusing, as there are clearly other reasons for not
receiving an FBack than having simply not sent an FBU.
numbered item 1:
"...PAR can determine whether NCoA is
acceptable to NAR through the exchange of HI and HAck messages.
When assigned addressing (i.e., addresses are assigned by the
router) is used, the proposed NCoA in FBU is carried in HI, and
NAR MAY assign the proposed NCoA.Z"
Please be specific about which devices sends the and receives the HI.
Same for the HAck. I can infer the answers, but don't just assume the
answers are obvious.
numbered item 2:
'Hence, the MN (re)sends FBU
immediately after sending the UNA message."
Does the MN resend to the PAR or to the NAR?
paragraph 8:
Can you move figures 2 and 3 closer to the first reference? (At least
in the same section?)
Section 3.3, Figure 2:
Does the PAR really send the FBack to both the MN and the NAR?
Figure 3:
Combining the HI and HAck on same line obfuscates which device is the
sender and recipient for each message.
Section 4, paragraph 2:
"...the MN sends
RtSolPr in order to resolve access point identifiers to subnet
router
information."
Sends it where? Yes, the figure shows this--but it's clearer if the
text says it too.
"Implementations SHOULD make use of such
triggers whenever available."
Is SHOULD strong enough here? If the MN does not have some mechanism
to detect access point changes, how could it use this protocol at all?
paragraph 5 (list item 1)
"...it responds indicating that the new access point is
unknown."
How is this indicated? That is, what code, option, etc?
paragraph 6 (list item 2)
"PAR responds with a Code
value indicating that the new access point is connected to the
current interface..."
What is the specific code value?
Paragraph 7 (list item 3)
"...then PAR responds indicating that the new access point
is known..."
How is this indicated?
paragraph 15 (list item 3)
"MAY create a host route entry for PCoA..."
Is MAY strong enough? Are there negative consequences of not doing it?
paragraph 16 (list item 4)
"provides the status of handover request in Handover Acknowledge
(HAck) message."
To where does it send the HAck?
"However, it SHOULD be prepared to process any other options which may
be defined in the future."
What does that mean? How can it process an option that has not yet
been defined? The wording seems to imply more than simply ignoring
unknown options.
paragraph 25 (list item 1):
"updates
the state to STALE"
This is the first mention of a formal state--can you reference where
it is defined?
Paragraph 26 (list item 2)
Same as previous comment for "INCOMPLETE" state.
Paragraph 29 (list item 1)
Numbered list with just one item.
Section 5.4, last paragraph
"... it SHOULD also provide
its own support for buffering."
Can you provide guidance on how much buffering is needed?
Section 5.5, first paragraph:
I'm confused. You seem to say that this protocol (I assume "this"
means the protocol being defined) SHOULD only be deployed when there
is little chance of collision--but it also must use DAD to try to
avoid collisions, unless there is little chance of collision in which
case it may turn DAD off. That seems self-contradictory.
Section 6, first paragraph:
This is the first mention of ICMP I find in the document. It would be
helpful to mention that the messages defined in this document are ICMP
extensions early in the draft. (Same comment for Mobility Header
messages in section 6.3)
6.1.2, 3rd paragraph from the end of page 23:
"If a New CoA option is present following the New
Router Prefix Information option, the MN SHOULD use the supplied
NCoA
and send FBU immediately or else stand to lose service."
Why is this not a MUST? Loosing service is a drastic result for
ignoring a SHOULD.
6.5, paragraphs 1-2:
You state that all options are of the form described in Figure 10, but
that's not necessarily true for Mobility Header LLA. I suggest
treating ICMPv6 and Mobility Header options separately.
9, paragraph 2:
What security properties are required of the security mechanism?
section 9, 2nd to last paragraph:
"IPsec ESP [rfc4303] in transport mode with
mandatory integrity protection SHOULD be used for protecting the
signaling messages. "
Why is this a SHOULD and not a MUST?
Appendix B:
Do you expect the change log to be published in the final RFC? A list
of changes from RFC4068, rather than a list of changes for each draft
revision, would be more helpful for implementors.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
