Hi Jinmei, Greg, Hesham.
JINMEI Tatuya wrote:
Greg Daley said:
It has been a bit confusing with crossing e-mails and timezone differences.
Sorry, I actually noticed the possible confusion when I was writing the messages, but I simply let it go..
Actually, the guy who has been messung things up the most is me. There was no bad intention. I'm sorry... :)
I think that there's agreement for clarification.
Yes, I think so.
Same here. And not only that we agree on the need for clarification, the suggested text fragments are also very similar now.
I think that people agree what needs to be clarified.
Ditto.
Yes.
I'm not sure if it's decided where to put the clarification (but I don't care myself, so long as everyone else agrees)
Actually, I'm not sure, either.
I think that Jinmei's suggestion to have a general description about
unsolicited RS's and NS's without SLLAO is needed. This would be a good
place to explicitly mention in which cases NC state is NOT to be
created. In contrast, in sections 6.2.6 and 7.2.3/7.2.4, it's probably wise to say only what a node/router does rather than what it refrains from doing.
Given the separation in RD, ND, and Redirect (which Greg previously
mentioned), would you agree that we also amend sections 6.2.6 and 7.2.3/7.2.4? I'd be in favor of doing this. Both parts of the document specify NC-state creation and the decision of whether a multicast or unicast response ought to be used. And both of these subjects are relevant.
I'm not sure if there is a text which is agreed. (I've heard more harmonious responses in later text, but there were two or three fairly related pieces of text going round).
Again, I'm not sure, either. But I agreed on the Christian's second proposal **if we agree on the need for revising Section 6.2.6**.
See above. Yes, I do agree.
I don't have a strong preference on how to fix the issue, but if I were to ask, I'd
- at least add a general note about what the node should do when it receives an unsolicited ND message (NS, RS, RA, Redirect) without LLAO and does not have a corresponding neighbor cache. I don't care about the place, but I'd probably use Section 7.3.3, and
- updated APPENDIX C (state machine) accordingly, and
- (optionally) describe a bit more details of each case (e.g., add clarification 6.2.6 for the RS case)
Agreed. What would have to be added to (or modified in) section 6.2.6
is not too far from what is needed for section 7.2.3/7.2.4. So, we might be able to reuse some text, making the modifications consistent.
- Christian
-- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/
"No great genius has ever existed without some touch of madness." (Aristotle)
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
