Hi, I see that this draft is on the agenda for this week's telechat. The gen-art assignment list indicates I reviewed version 05 at last call. In fact, I reviewed version 6, which is the same version on the telechat agenda.
I think the confusion originated from the fact I was assigned to review 05, but the document was revised to 06 before I got started with the review. Sorry for any confusion. Thanks! Ben. On Mar 15, 2008, at 3:08 PM, Ben Campbell wrote: > 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
