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 PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 26, 2005 12:17 AM
> To: Soliman, Hesham
> Cc: ipv6@ietf.org
> Subject: Re: 2461bis update
>
>
> >>>>> On Wed, 25 May 2005 23:31:24 -0400,
> >>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> 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 PROTECTED]
>
===========================================================
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
