Hi Ben,
Thank you for your detailed review. See my replies inline. From: Ben Campbell <[EMAIL PROTECTED]> Date: Sat, Mar 15, 2008 at 4:08 PM Subject: Gen-ART LC review of draft-ietf-mipshop-fmipv6-rfc4068bis-06 To: [email protected] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] 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. Rajeev:> I will check. 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. Section 3 is Protocol Overview and Section 4 is Protocol Details. Section 3 is split into two subsections - Addressing Handover Latency, which provides a high-level description of where the delays are and what the protocol does about, and Protocol Operation subsection, which describes the high-level operation. 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. Right, the Message Format section defines the transport types. 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. Hmm.. I will look for them below. -- Detailed Comments: Section 2, RFC 2119 boilerplate: IDNITS does not like the 2119 boilerplate. I don't think 2119 defines "silently ignore". Ok. 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. Ok, I will consider. 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? Yes. 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. Ah, I can rephrase to "Otherwise it should the FBU immediately.." "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? If it doesn't, the packet does not reach the CN. I am okay for a stronger requirement even though I think PAR will almost certainly forward it (in this case to provide the fast handover support) paragraph 7: "In addition, buffering for handover traffic may be desirable." Buffering by which device? (NAR or PAR?) This is in the context of discussing NAR's functions. I can make it explicit. 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?) The document does not specify how SA is established. That's for a companion document - draft-ietf-mipshop-handover-key-03.txt. Yes, this document does describe in details what is expected, SPD/SAD entries etc in Section 9. 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. Whichever happens to be the access router. I think we refrained from using PAR/NAR everywhere because we had considered handovers in tandem where a MN can go from PAR to NAR to another AR. So, it could do RtSolPr with NAR when NAR happens to be its access router. 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. Ok. To PAR. 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. Sure, FBack itself may be lost. But the MN cannot receive an FBack unless it has 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. This sender and receiver for these messages are clear for someone with background in this space. Nevertheless, this comes along fairly early in the document. So, I will revise it. 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? FBU is always sent to the PAR. paragraph 8: Can you move figures 2 and 3 closer to the first reference? (At least in the same section?) Okay. Section 3.3, Figure 2: Does the PAR really send the FBack to both the MN and the NAR? Yes. Figure 3: Combining the HI and HAck on same line obfuscates which device is the sender and recipient for each message. I see. Will revise. 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. This should also be fairly evident. Will mention at the first reference. "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? It can respond when it gets a Router Advertisement. 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? This is specified under each message format (see Section 6.1.2). IMO this is a matter of style. 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? See Section 6.1.2 Paragraph 7 (list item 3) "...then PAR responds indicating that the new access point is known..." How is this indicated? Code values, section 6.1.2 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? It is an option. Hence the MAY. paragraph 16 (list item 4) "provides the status of handover request in Handover Acknowledge (HAck) message." To where does it send the HAck? to PAR. "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. I think this sentence should be deleted. 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? Okay. Paragraph 26 (list item 2) Same as previous comment for "INCOMPLETE" state. Okay. 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? Depends on the implementation. We discussed this and arrived at not specifying a number. 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. Where there is an extremely small chance of collision, use DAD. Where this is not a concern, set DupAddrDetectTransmits to zero. I don't see a contradiction :-) 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) I will consider it. 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. Good point. Okay with MUST. 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. Ah, good catch. BADF does not have Option-Code. 9, paragraph 2: What security properties are required of the security mechanism? These are described in detail in draft-ietf-mipshop-handover-key-03.txt 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? I guess you could use ESP in tunnel mode too. We are recommending using transport mode integrity protection. 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. This is in the tracker www.mip4.org/issues/tracker/mipshop Thanks again, -Rajeev
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
