Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Sat, 06 November 2004 03:31 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18371 for <ipv6-web-archive@ietf.org>; Fri, 5 Nov 2004 22:31:12 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQHIL-0004ad-B0 for ipv6-web-archive@ietf.org; Fri, 05 Nov 2004 22:31:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQHC0-0003FK-1P; Fri, 05 Nov 2004 22:24:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQH8g-0002OA-23 for ipv6@megatron.ietf.org; Fri, 05 Nov 2004 22:21:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17893 for <ipv6@ietf.org>; Fri, 5 Nov 2004 22:21:15 -0500 (EST)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQH8h-0004QC-Pg for ipv6@ietf.org; Fri, 05 Nov 2004 22:21:21 -0500
Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AC94E15210; Sat, 6 Nov 2004 12:21:13 +0900 (JST)
Date: Sat, 06 Nov 2004 12:21:15 +0900
Message-ID: <y7vbrebek7o.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: Nick 'Sharkey' Moore <sharkey@zoic.org>
In-Reply-To: <20040924221639.GA24646@zoic.org>
References: <29AC4C04-0C9E-11D9-81FA-000D93330CAA@innovationslab.net> <20040924221639.GA24646@zoic.org>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: Brian Haberman <brian@innovationslab.net>, IPv6 WG <ipv6@ietf.org>, Pekka Savola <pekkas@netcore.fi>
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-02.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe

Hello,

>>>>> On Sat, 25 Sep 2004 08:16:39 +1000, 
>>>>> "Nick 'Sharkey' Moore" <sharkey@zoic.org> said:

> 	well, it's bad timing on the Last Call, unfortunately,
> because I'm off on vacation for five weeks starting today!
> Rhonda and I will be backpacking around in Scotland, Ireland
> and Italy, so I won't be reading email much if at all in this
> time.  I'm looking forward to the break!

I'm very sorry for delaying the response...I could not have time to
respond before you left for vacation, and have kept this thread
sleeping in my mail box since then.  I hope my silence was not a major
showstoppper.

> 2: Unsolicited NAs 

> 	OptiDAD does not disallow the unsolicited NAs mentioned in
> 	RFC 2461 7.2.6.  It no longer mentions sending them either.

> 	The only text which does mention them in passing is 4.2,
> 	which explains:

> 		In the course of establishing connections, the ON may
> 		send NAs either spontaneously or in response to received
> 		NSs.  Since these NAs will have O=0, they will not
> 		override existing NC entries, although they may result
> 		in a colliding entry being changed to state STALE.

> 	... note that that's not MAY, it's just may.  This is in a 
> 	section explaining the behaviour (4. Protocol Operation),
> 	not the section listing the rules of OptiDAD (3. Modifications
> 	to RFC-mandated behaviour).  It's meant to be explaining 
> 	why sending NA O=0 is mostly harmless.

> 	Perhaps this would be clearer if I changed 'may send' to 
> 	'might have sent' (and corresponding tense changes throughout).
	
> 	Would that be okay, Jinmei?  Does anyone else hold strong
> 	opinions on this?

Hmm, I simply don't understand why we cannot remove "spontaneously".
In fact, no existing RFCs or this particular document describes such a
behavior, right?  So, IMO, leaving it here would just confuse the
reader about in which case the "spontaneous" NA can happen.

Is there any reason for keeping this wording?  If not, I'd simply
remove it not to confuse the reader.

Perhaps this is just a minor nitpicking, so I won't insist on this
point, whether to removed or leave it, though.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------