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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 May 2013 14:58:46 -0700 (PDT)

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.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 May 2013 04:40:28 -0400

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?

> illustration rather than making it part of the prose.

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

> 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?:
OLD
After MAX_UNICAST_SOLICIT the implementation
NEW
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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 May 2013 10:49:29 -0700

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

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

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

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

> put a comma before "which" (the following clause is a consequence, not

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

-MSK