Authors, I am the General Area Review Team (Gen-ART) Last Call reviewer for this draft (for background on Gen-ART, please see:
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming draft-ietf-shim6-failure-detection-09 Reviewer: Eric Gray Review Date: 11/08/2007 IETF LC End Date: 11/09/2007 Summary: This draft is almost ready to publish as a Proposed Standard RFC. I have some minor questions about definitions and there are numerous NITs. I suggest another round to clean up minor editorial/grammar errors, prior to submission to the RFC Editor. Comments/Questions/NITs: ======================= The second paragraph of section 3.1 (Available Addresses) uses an interesting - if not unique - writing style. I suggest modifying it to something like - "Definition: Available Address - an address ..." This is a minor (stylistic) issue, but I have other questions about this definition, so I thought I may as well bring it up. This same comment applies to other definitions in the draft. This definition is very terse. I looked through RFC 2461 for some time and still am not sure I've discovered what "valid in the sense of RFC 2461" actually means. Is it valid if it has a valid prefix, if it is within its valid lifetime, both, neither? Could you summarize, please? I did note that "tentative in the sense of RFC 2462" is far easier to determine (the phrase "tentative address" is explicitly defined there). The definition also lacks formal structure. I get the impression that some combinations of the bullets are or'd while others are and'd - but this is not clear. One possible way to interpret the definition is that all of the bullets apply as if all conditions must be true. Is that the case, or are there examples of cases in which it is sufficient to satisfy only some conditions? _____________________________________________________________________ In section 3.5, first paragraph, last sentence - I suggest rewording as follows: "Efficient congestion control over multiple paths is considered an area for research at the time this specification is written." (as opposed to "... is a considered research ...") In addition, I also wonder if "effective" might not be a better word than "efficient" (as it is now). _____________________________________________________________________ In the same section, third paragraph, last sentence, I suggest: "Nevertheless, it makes sense to assume that the address pair that worked previously continues to be operational ..." ("previously" as opposed to "... in some time ago ...") Alternatively, there may be a specific time interval meant by "some time ago" - in which case, it might be better to say "within some specified time" instead of "in some time ago". ______________________________________________________________________ In section 4.1, third sentence (first paragraph), suggest rewording as: "Nodes SHOULD employ techniques listed in Section 3.1 and Section 3.2 to track the local situation." ("to track" as opposed to "to be track") Same paragraph, two sentences later, "a mechanism" (as opposed to just "mechanism"). Still in the same paragraph, I suspect you want to say "operational address pair" (opposed to "operational pair") in the last sentence. ______________________________________________________________________ In bullet number 1 (page 11), is assuming a maximum one-way delay of 2 seconds, reasonable? Are there not congestion and/or transient networking conditions in which this assumption will be invalid? ______________________________________________________________________ In the second line on page 12, "based on" (opposed to just "based"). ______________________________________________________________________ Middle of bullet 5, page 12, "to" (opposed to "to to"). ______________________________________________________________________ Also in bullet 5, it seems likely that a keep-alive would not be sent if data was sent within the keep-alive interval (as opposed to since the last data packet received). Is it the intention that keep-alives would be discontinued if data is no longer being received? ______________________________________________________________________ In the first line of section 4.2, "a previous section" or "previous sections" (as opposed to just "previous section"). ______________________________________________________________________ Fourth paragraph, page 13, "is unsatisfactory" (opposed to "in unsatisfactory"). ______________________________________________________________________ Is it intended to leave the "discussion note" on page 14, when this document is published? The same question applies to other such notes in the document. ______________________________________________________________________ Since there are no IANA considerations, where is the Keep-Alive message type defined? -- Eric Gray _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
