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

["Murray S. Kucherawy" <[e-mail]>]

On Thu, May 9, 2013 at 1:40 AM, Barry Leiba <[e-mail]> 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?:
> OLD
> After MAX_UNICAST_SOLICIT the implementation
> NEW
> 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.

-MSK