[apps-discuss] AppsDir reivew of draft-ietf-6man-impatient-nud

"Murray S. Kucherawy" <superuser@gmail.com> Wed, 08 May 2013 21:58 UTC

Return-Path: <msk@blackops.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 56B6421F8BB7; Wed, 8 May 2013 14:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7U2R5HJO66oS; Wed, 8 May 2013 14:58:52 -0700 (PDT)
Received: from medusa.blackops.org (medusa.blackops.org []) by ietfa.amsl.com (Postfix) with ESMTP id 5A83821F86C1; Wed, 8 May 2013 14:58:52 -0700 (PDT)
Received: from medusa.blackops.org (msk@localhost.blackops.org []) by medusa.blackops.org (8.14.5/8.14.5) with ESMTP id r48LwlPj051484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 14:58:48 -0700 (PDT) (envelope-from msk@medusa.blackops.org)
DKIM-Filter: OpenDKIM Filter v2.8.3 medusa.blackops.org r48LwlPj051484
X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org r48LwlPj051484
Authentication-Results: medusa.blackops.org; sender-id=permerror header.from=superuser@gmail.com; spf=none smtp.mfrom=msk@medusa.blackops.org
Received: (from msk@localhost) by medusa.blackops.org (8.14.5/8.14.5/Submit) id r48LwkGe051483; Wed, 8 May 2013 14:58:46 -0700 (PDT) (envelope-from msk)
Date: Wed, 08 May 2013 14:58:46 -0700
Message-Id: <201305082158.r48LwkGe051483@medusa.blackops.org>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: apps-discuss@ietf.org, draft-ietf-6man-impatient-nud.all@tools.ietf.org
Cc: iesg@ietf.org
Subject: [apps-discuss] AppsDir reivew of draft-ietf-6man-impatient-nud
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2013 21:58:58 -0000

I have been selected as the Applications Area Directorate (appsdir) reviewer
for this draft.  (For background on appsdir, please see

Please resolve these comments along with any other Last Call comments you may
receive.  Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-6man-impatient-nud
Title: Neighbor Unreachability Detection is too impatient
Reviewer: Murray S. Kucherawy
Review Date: May 8, 2013
IETF Last Call Date: ends May 9, 2013
IESG Telechat Date: May 9, 2013

Summary: This document is almost ready for publication on the Standards
Track.  The technology described in it seems sound overall.  However, the
document is in some need of an editorial pass as I found myself tripping
over several expressions and such.  So, rather than providing a technical
review (which doesn't seem to be needed), my comments below are entirely
stylistic or grammatical in the hopes that you'll get to AUTH48 a little


These are all editorial concerns that caused me to stumble while reading.
I think they're more important to fix, to help future readers, than the ones
I listed under "NITS".

Section 1, Introduction:

"These short can be appropriate" should be "This short timeout can be
appropriate" or some such.

The "For example... " sentence is a fragment.  Suggest adding to the end:
", then a short timeout functions well."

"alternative neighbor;" should be "alternative neighbor,"

The second and third paragraphs don't need to be separate.  I suggest merging

Add a comma right after "As a result" and "For IPv4".

Section 3, Protocol Updates:

For the expression MAX_UNICAST_SOLICIT/MAX_MULTICAST_SOLICIT, is that "or" or
"division"?  I suggest not using the slash but rather using text to say what
you mean there.

Change "it SHOULD" to "they SHOULD" since you're talking about a plural

Fourth paragraph, add a comma after "above".

I suggest a section reference for the conceptual model mentioned in paragraph
five, not just a document reference.

Change "But in the UNREACHABLE state" to "However, in the UNREACHABLE state,"

In the sixth paragraph you talk about "we" for the first time.  The style
should be consistent, so use "implementations" instead of "we".

In paragraph 7, add a comma after "Thus".

In paragraph 10, change the second sentence to:

	UNREACHABLE is added to the current list of STALE, PROBE, or

Change "That needs to be replaced by" to "The following table replaces the
State table at Section [xxx] of RFC4861." and remove the original table.

Change "clamped at" to "limited to".

Change "then it makes sense to stop" to "then implementations MAY discontinue".

In the last paragraph, please be more specific than "sooner or later".

Section 4, Example Algorithm:

Change "that allows it" to "that allow it" (you're talking about multiple
configuration values this time).

In the second paragraph, please express the equation using a figure or other
illustration rather than making it part of the prose.

Third paragraph, add a comma after "transmissions".
of course.  Same in the following two paragraphs.

Add a comma after "With the above recommended values".

Add a comma after "In the language of the state machine in [RFC4861]", and
another after "Thus".

In "in a link-layer address i.e., the case when", add a comma after "address".

Change "you would get the same behavior as in [RFC4861]" to "the same
behavior as in [RFC4861] would be produced".

Use a figure or illustration for the equation in the last paragraph as well.

Section 7, IANA Considerations:

Include an RFC Editor note to remove the section prior to publication.

These are all minor things, pet peeves and the like.  The RFC Editor will
probably make them too, but I won't complain if you don't fix them.  :-)

Title should be "Neighbor Unreachability Detection Is Too Impatient" (note

In the abstract, "3" should be "three".  Also, "whether or not" should be just

In paragraph four of Section 1, s/which/that/.

In paragraph five of Section 1, s/it means that/it means/

In Section 3, change "A node MAY garbage collect" to "A node MAY perform
garbage collection".

In Section 4, first sentence, s/which/that/.

Also in Section 4, in the fourth paragraph: For numbers lower than ten,
use the English word rather than the numeral (e.g. "five attempts",
"one second", "three seconds", etc.).  You don't need to do this for your
configuration settings, however.