Subject: [Gen-art] Gen-ART LC review of draft-ietf-shim6-failure-detection-09

From: "Eric Gray" <[email-masked]>
Date: Fri, 9 Nov 2007 15:03:26 -0600

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Nov 2007 16:39:01 +1300

Eric,

> Since there are no IANA considerations, where is the Keep-Alive
See below- already fixed in the tracker!

    Brian

-------- Original Message --------
Subject: Re: Last Call: draft-ietf-shim6-failure-detection (Failure Detection and Locator Pair Exploration Protocol for IPv6 
Multihoming) to Proposed Standard
Date: Thu, 01 Nov 2007 11:14:29 +0200
From: Jari Arkko <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: IESG <[email-masked]>, Iljitsch van Beijnum <[email-masked]>,  Geoff Huston <[email-masked]>
References: <[email-masked]> <[email-masked]>

Yes. Thanks.

Mark, can you place this to the RFC Editor notes window
in the tracker:

    Please change the contents of Section 9 as follows:

    OLD:
    No IANA actions are required.
    NEW:
    The relevant Shim6 message types and their registries are
    defined in [draft-ietf-shim6-proto]. This document has no
    additional IANA considerations.

Jari

Brian E Carpenter kirjoitti:
 > Minor editorial:
 >
 > I think the IANA Considerations should state that the
 > relevant shim6 message types and their registry are
 > defined in draft-ietf-shim6-proto.
 >
 >    Brian

---

From: "Eric Gray" <[email-masked]>
Date: Sat, 10 Nov 2007 06:25:16 -0600

Brian,

	Great, thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Friday, November 09, 2007 10:39 PM
> To: Eric Gray
> Cc: Jari Arkko; Iljitsch van Beijnum; Mark Townsley; [email-masked]
> Subject: Re: [Gen-art] Gen-ART LC review of 
> Importance: High
> Subject: Re: Last Call: draft-ietf-shim6-failure-detection 
> (Failure Detection and Locator Pair Exploration Protocol for IPv6 
> CC: IESG <[email-masked]>, Iljitsch van Beijnum 
> <[email-masked]>,  Geoff Huston <[email-masked]>