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

Barry Leiba <> Thu, 09 May 2013 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C44721F8F07; Thu, 9 May 2013 01:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9xFKDjKjbDV3; Thu, 9 May 2013 01:40:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9D7AB21F84F9; Thu, 9 May 2013 01:40:30 -0700 (PDT)
Received: by with SMTP id 13so2737069lba.8 for <multiple recipients>; Thu, 09 May 2013 01:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HUgIwO6yNWvHwSNVcqjk8hfQr//k4yQ841+ALU4iWmQ=; b=I4WlEvUFR1qoPLCEZpwiojDxIMYnSrtmeZNYC7jMOVYRCz6cUUrInGwNzrRd8Sbo3g d1qblD5khI9H/MZp+W4MJgxgOyS07D3kmATdCJWMJr6W+4EdVmk2h3yXUunR6q1Mua+O YSe1B7HpMjouUhRE6l+zI0+/u/GACOdD6QErBZIz+fcgAYj7R6t5BpAJxBFDOtEe6W8d sT5jpKk6ukdCK5y3YOxHLNFPjWqDI6XqJw5KyGj0XS0xCbdpaqssYjx3qzENOSIbVAQF SFQP2Je61hhzbb9dLd4+5qJdVmf2/jwiV8ooXSYOEAvT60Ur17Zb6ZJIxJxFxk7MXTXR 1Z+Q==
MIME-Version: 1.0
X-Received: by with SMTP id 9mr4937462las.45.1368088829223; Thu, 09 May 2013 01:40:29 -0700 (PDT)
Received: by with HTTP; Thu, 9 May 2013 01:40:28 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 09 May 2013 04:40:28 -0400
X-Google-Sender-Auth: 9UJjN6TMoaqLF2B3zv4xg2mFJEQ
Message-ID: <>
From: Barry Leiba <>
To: "Murray S. Kucherawy" <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc:, IESG <>, "" <>
Subject: Re: [apps-discuss] AppsDir reivew of draft-ietf-6man-impatient-nud
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 May 2013 08:40:37 -0000

Thanks for the appsdir review, Murray.

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

Actually, it should be "alternative neighbor, try" in order to keep
the list parallel.  Also, "or discard the NCE which will also send
using a different router." should probably be rephrased.  Is it the
NCE that will send?  Or is it that discarding the NCE will cause the
use of a different router?

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

Why?  What's wrong with it as it's written?

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

Please, no.  As it's written, it says that it's a good idea to stop
the retransmits.  Changing it to "MAY" says that it's entirely
optional, losing the sense that this is a recommendation.  There's no
need for 2119 language here, and "discontinue" isn't better than
"stop".  I think this one is fine as written.

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

I agree, but to clarify why:
It might be reasonable to say "sooner or later", "eventually", or some
such if you weren't saying that it "MUST switch".  If there's a reason
to switch that involves interoperability of the protocol (and there
seems to be, as you explain in the next sentence), then you ought to
be able to say something better than this.  If I don't switch to
multicast until the very last NS I ever send, is that OK?

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

Ooh... yes, this is really hard to read this way.

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

Kind of a style issue here, really.  I would probably put in the
comma, yes.  More importantly, should the second sentence have this
After MAX_UNICAST_SOLICIT the implementation
After MAX_UNICAST_SOLICIT transmissions, the implementation

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

You mean in, "For IPv4 there is no mandatory time limit on the
retransmission behavior for ARP [RFC0826] which allows implementors to
pick more robust schemes." ?  No, that's the wrong fix (which is the
problem with which/that errors).  I think the correct fix here is to
put a comma before "which" (the following clause is a consequence, not
a restriction).

Barry, Applications AD