Subject: RE: 2461bis update

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 25 May 2005 21:06:53 -0400

Jinmei, 

This comment was concerned with removing 
the "not" the preceded INCOMPLETE. Peter (who raised the comment)
said he's happy with just the removal, which was a typo. So what else 
needs to be done?

Hesham

 > -----Original Message-----
 > From: [email-masked] 
 > [mailto:[email-masked]]
 > Sent: Wednesday, May 25, 2005 3:01 PM
 > To: Soliman, Hesham
 > Cc: [email-masked]
 > Subject: Re: 2461bis update
 > 
 > 
 > >>>>> On Tue, 24 May 2005 10:04:25 -0400, 
 > >>>>> "Soliman, Hesham" <[email-masked]> said:
 > 
 > > Hi all,
 > > I submitted an updated revision of 2461bis which includes 
 > > the resolutions that were agreed on by the WG in the last meeting
 > > (the SLLAO thread). It also includes fixes for the comments Tatuya
 > > raised on the last version. 
 > 
 > > I think this draft is now ready for the IESG. 
 > 
 > I've not fully checked the entire new version, but from a 
 > quick glance
 > the following comment of mine does not seem to be addressed:
 > 
 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04811.html
 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html
 > 
 > At the very least, the 4th paragraph of Section 7.2.5 needs an
 > editorial fix for oddly short lines:
 > 
 >      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.
 > 
 > 					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 10:55:53 +0900

>>>>> On Wed, 25 May 2005 21:06:53 -0400, 

> said he's happy with just the removal, which was a typo. So what else 

I thought I had explained that in the previous message:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg04811.html

and made it clear that this is a separate issue of the original one
from Peter's:

  I don't know the background of this change, even if we removed the "not"...
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But, in case I was not clear enough, the point is that the relevant
change from RFC2461 to rfc2461bis makes the text rather unreadable.
So, I'd first like to know the intent of the change.

One specific point at the moment: Section 7.2.5 of
draft-ietf-ipv6-2461bis-03.txt reads:

   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.

From this paragraph, the "two things" would be:

  1. If the advertisement were solicited, the state is changed to
     REACHABLE.
  2. Otherwise, the state is set to STALE.

On the other hand, the corresponding part of RFC2461 was:

   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.  Otherwise, the receiving node performs the following
   steps:
       (....)

From this paragraph, the "two things" would be:

  1. If the link layer has addresses and no Target Link-Layer address
     option is included, the receiving node SHOULD silently discard
     the received advertisement.
  2. Otherwise, the receiving node performs the following steps:
       (....)

So, while the beginning part is exactly the same, the "two things"
seem to refer to completely different things.

The difference itself is not necessarily a problem.  However,
rfc2461bis-03 then repeats its "two things":

    - If the advertisement's Solicited flag is set, the state of the
      entry is set to REACHABLE, otherwise it is set to STALE.

Now this make me really confused...

Additionally, the relationship between the two parts beginning with
"If the (target's) Neighbor Cache entry is in the INCOMPLETE state" is
not very clear to me:

   If the target's Neighbor Cache entry is in the INCOMPLETE state when
   the advertisement is received, one of two things happen: (...)

   If the Neighbor Cache entry is in INCOMPLETE state, the receiving
   node performs the following steps:
      (...)

Note that the second part was one of the "two things" in original
RFC2461.

All of these things just confused me about what this part wanted to
convey.

So, again, I'd first like to know the intent of the change, and then
I'm willing to suggest explicit text according to the intent.

I hope this time I'm clear enough.  Thanks,

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