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

"Murray S. Kucherawy" <> Thu, 09 May 2013 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0730C21F92F4; Thu, 9 May 2013 10:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hy2m20QMsLXG; Thu, 9 May 2013 10:49:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22f]) by (Postfix) with ESMTP id 2FC8121F9227; Thu, 9 May 2013 10:49:30 -0700 (PDT)
Received: by with SMTP id uo1so2150010pbc.20 for <multiple recipients>; Thu, 09 May 2013 10:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GDBBRtvHe+oq9E7pmvnQDYl6cPtveCVj9G6z1pW7Iko=; b=0otGXtMUPXVFmzW/URNKOYWhMYijBOdM4Oiq6i0TnXcRRcd/WTKLvUtrA4C9p21FKn NE4eQ2DZvzGZoiCHuwCDhVATrqmtqNPrJg2YJE+4X8btyKkYwhZiCSrzJN1q13JFJR/j 6IsgKr2wf938Js7KnTDQK/HGYKr5OGtFI0u0+92v0Tm/1zb6Z7mxeoorDOS+sY354xfo 6g/NAgWYPBjVyb0MEsTi1mtpB3s6QFx7gReEeOyVuwSv4F8Hps+0x/o/CbcDgWwRJFSa EZQQeDhjX3QCv/YtXYMLKJLQMnsStXeNjwXWQJMkRZcRQQ+7qTmADh2BviJRbwtDG8KE kPpA==
MIME-Version: 1.0
X-Received: by with SMTP id qq10mr13618503pbc.57.1368121769860; Thu, 09 May 2013 10:49:29 -0700 (PDT)
Received: by with HTTP; Thu, 9 May 2013 10:49:29 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 09 May 2013 10:49:29 -0700
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: Barry Leiba <>
Content-Type: multipart/alternative; boundary="047d7b2e09df1a24d304dc4cacdd"
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 17:49:31 -0000

On Thu, May 9, 2013 at 1:40 AM, Barry Leiba <> wrote:

> > Change "But in the UNREACHABLE state" to "However, in the UNREACHABLE
> state,"
> Why?  What's wrong with it as it's written?

It's technically fine the way it is, but I find the way I suggested to be
more palatable.  It otherwise seems almost like a run-on sentence.

> > 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.

I find "it makes sense to do X" to be a little too colloquial.  I realize
we're not writing the Code of Federal Regulations here, but when the
language is also overly informal, I find the effect to be that it's too
mushy and provides little real guidance at all.  At that point I wonder why
it's there in the first place.

A different option might be to do something like  "then it is best to do X
because..." or "then doing X is advisable because..."

Could well be personal preference.

> > 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?

Right, that's also my point.  In fact the language is so soft that I'm left
wondering if I could get away with not doing it at all.  Some better
guidance about how to decide when to do it, or what the penalties are of
doing it too soon or too late, would help to provide better guidance.

> > 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
> change?:
> After MAX_UNICAST_SOLICIT the implementation
> After MAX_UNICAST_SOLICIT transmissions, the implementation

Again, technically correct without, but I think it's better with.  Same
deal (to me) as your "Please, no" objection above, but you went the other
way on this one.

> > 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).

I think those are equivalent fixes to the same problem, so fine with me.