>>>>> 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]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------