[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [208.69.40.157]) 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 [127.0.0.1]) 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 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). 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 faster. MAJOR ISSUES: None. MINOR ISSUES: 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 them. 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 ("implementations"). 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 DELAY. 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. NITS: 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 capitalization). In the abstract, "3" should be "three". Also, "whether or not" should be just "whether". 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.
- [apps-discuss] AppsDir reivew of draft-ietf-6man-… Murray S. Kucherawy
- Re: [apps-discuss] AppsDir reivew of draft-ietf-6… Barry Leiba
- Re: [apps-discuss] AppsDir reivew of draft-ietf-6… Murray S. Kucherawy