Subject: RE: 2461bis update

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 26 May 2005 00:45:18 -0400

No problem, I don't think you're trying to block anything. Please continue to 
provide comments on the doc, I appreciate it. I think what happened was that I 
assumed you were ok with the change since Peter said he was fine and I interpreted your last
response on that thread to be that you mainly wanted to see Peter's comment addressed. 

The new version will be submitted on Friday so if there are more comments please let me know.

thx,
Hesham

 > -----Original Message-----
 > From: [email-masked] 
 > [mailto:[email-masked]]
 > Sent: Thursday, May 26, 2005 12:17 AM
 > To: Soliman, Hesham
 > Cc: [email-masked]
 > Subject: Re: 2461bis update
 > 
 > 
 > >>>>> On Wed, 25 May 2005 23:31:24 -0400, 
 > >>>>> "Soliman, Hesham" <[email-masked]> said:
 > 
 > > => Yes this is clearly wrong. I'll update this. As for the 
 > rest, you still don't say
 > > what's wrong with it, you just ask for it to be changed 
 > back. I don't agree
 > > with your suggestion because there is no basis for it, but 
 > to save cycles I'll
 > > change it back...
 > 
 > Sorry if I've been keeping unclear, but regarding the 
 > "rest", my point
 > is that the current text (of the first part of Section 7.2.5) in
 > 2461bis is more confusing than RFC2461, and I actually didn't see any
 > problem in the original text of RFC2461 (and, for that matter, no one
 > knows the rationale of the changes in 2461bis).  That's why I
 > suggested to change it back.  Assuming (the first part of) 2461bis is
 > more confusing than RFC2461, I believe this is a reasonable 
 > suggestion
 > (isn't it?).
 > 
 > Regarding whether (the first part of) 2461bis is more confusing than
 > RFC2461, I admit "confusing" is a subjective word and opinions may
 > vary.  However, as I pointed out in this thread, at least the
 > duplicate description in 2461bis is clearly confusing to me. 
 >  That is,
 > 
 >    If the target's Neighbor Cache entry is in the INCOMPLETE 
 > state when
 >    the advertisement is received, one of two things happen: If the
 >    advertisement were solicited, the state is changed to REACHABLE.
 >    Otherwise, the state is set to STALE. Note that the 
 > Override flag is
 >    ignored if the entry is in the
 >    INCOMPLETE state.
 > 
 >    If the Neighbor Cache entry is in INCOMPLETE state, the receiving
 >    node performs the following steps:
 > 
 >      (...)
 > 
 >     - If the advertisement's Solicited flag is set, the state of the
 >       entry is set to REACHABLE, otherwise it is set to STALE.
 > 
 > (The bullet is actually already covered in the paragraph 
 > starting with
 > "If the target's...")
 > 
 > Is it so unclear to say it's confusing to have the duplicate
 > description?  Is it strange to wonder whether we can unify the
 > duplicate part, and, e.g., remove the redundant paragraph 
 > (with moving
 > the "Note" sentence into the bullet if necessary)?
 > 
 > I'm sorry if I just look behaving in a stubborn way, blocking the
 > document...but please believe me, I just want 2461bis to be clearer.
 > 
 > I hope this message expresses my point clearly.
 > 
 > 					JINMEI, Tatuya
 > 					Communication Platform Lab.
 > 					Corporate R&D Center, 
 > Toshiba Corp.
 > 					[email-masked]
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 May 2005 17:04:19 +0900

>>>>> On Thu, 26 May 2005 00:45:18 -0400, 

> response on that thread to be that you mainly wanted to see Peter's comment addressed. 

Thanks for your patience.  Hoping that you can still accept this
one:-), here is one more related thing:

2461bis-03 (more accurately since 2461bis-01) has a new paragraph in
Section 7.2.5:

   In any state, if the link layer has addresses and an unsolicited
   Neighbor Advertisement is received with the O flag cleared, with no
   Target Link-Layer address option included, the receiving node SHOULD
   silently discard the received advertisement.
(the 3rd paragraph of this section)

The corresponding part of original RFC2462 should be the following
line:

   [If the target's Neighbor Cache entry is in the INCOMPLETE state when
   the advertisement is received, one of two things happens.]  If the
   link layer has addresses and no Target Link-Layer address option is
   included, the receiving node SHOULD silently discard the received
   advertisement.

As far as I can see, the new text is more than just a "clarification".
In the new text,

  - the rule is applied to all neighbor cache states.  (in original
    RFC2461, it was limited to the INCOMPLETE state)
  - a new condition about the O flag is added

So I guess there should have been a clear reason for the new text.  If
it was, what was that?  Or, if there was actually no special reason
(or we cannot even remember that), it would be another reason for
changing it back (for "safety").

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]