Subject: [Gen-art] Gen-ART LC review of draft-ietf-mipshop-fmipv6-rfc4068bis-06

From: Ben Campbell <[email-masked]>
Date: Sat, 15 Mar 2008 16:08:56 -0400

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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Mar 2008 10:36:41 +0200

Thanks for your very in-depth review, Ben!

> scope of our changes" is perfectly reasonable for most of my comments.

This is a the first PS RFC on this topic, and the intent is to have
sufficient quality for a PS. The previous RFC was Experimental.

In short, I think we want to fix issues where we see them.

> losses would, unfortunately, require more time than I can commit to

Ah. Probably authors started from their own source, not the RFC.
Authors, please do a diff and back-port the RFC Editor editorial (and
possibly other) changes.

Jari

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Mar 2008 14:30:37 -0500

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:
> 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.
>
> 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.
>
> 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:
>
> 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:
>
> Is SHOULD strong enough for this requirement? What happens if the  
> PAR does not forward the inner packet?
>
> paragraph 7:
>
> 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"
>
> 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:
>
> Can you move figures 2 and 3 closer to the first reference? (At  
> least in the same section?)
>
> Section 3.3, Figure 2:
>
> 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
> avoid collisions, unless there is little chance of collision in  
> which case it may turn DAD off. That  seems self-contradictory.
>
> 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)
>
> 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  
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>