On 2004-11-06, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > > I'm very sorry for delaying the response...I could not have time to > respond before you left for vacation, and have kept this thread > sleeping in my mail box since then. I hope my silence was not a major > showstoppper.
G'day Jinmei, no worries, I just hope I can remember what on earth I was talking about! I'd better check my list archive: On 2004-09-25, Nick 'Sharkey' Moore wrote: >> >> So far, it's mostly editorial issues, which I suppose >> can be fixed post-LC, [...] There have been a couple of bigger >> issues raised [...] >> >> 1: Interoperability with SEND >> >> The draft points out rather uselessly: >> >> Further work will be required to integrate Optimistic >> DAD with Secure Neighbor Discovery [SEND]. >> >> ... but now SEND is complete. It would be good to address >> any SEND issues in OptiDAD. I think all that is required is >> for someone who understands SEND better than I do to think >> it through and give it a big rubber stamp so I can change the >> text to: >> >> Optimistic DAD is interoperable with Secure Neighbour >> Discovery [SEND] because ... >> >> The question is, fundamentally, "does SEND require sending >> any signals during address configuration which would >> disadvantage a collidee". If someone expert in SEND could >> answer this question, I'll change the text! This stands ... please, are there any SEND experts with a half an hour to check this out for me? OptiDAD has hardly changed in several revisions, so there's unlikely to be nasty surprises, but ... Actually, let me rephrase that: as I understand it, OptiDAD is compatible with SEND. Can anyone here demonstrate otherwise? >> 2: Unsolicited NAs >> >> OptiDAD does not disallow the unsolicited NAs mentioned in >> RFC 2461 7.2.6. It no longer mentions sending them either. >> >> The only text which does mention them in passing is 4.2, >> which explains: >> >> In the course of establishing connections, the ON may >> send NAs either spontaneously or in response to received >> NSs. Since these NAs will have O=0, they will not >> override existing NC entries, although they may result >> in a colliding entry being changed to state STALE. >> >> ... note that that's not MAY, it's just may. This is in a >> section explaining the behaviour (4. Protocol Operation), >> not the section listing the rules of OptiDAD (3. Modifications >> to RFC-mandated behaviour). It's meant to be explaining >> why sending NA O=0 is mostly harmless. >> >> Perhaps this would be clearer if I changed 'may send' to >> 'might have sent' (and corresponding tense changes throughout). > > > Hmm, I simply don't understand why we cannot remove "spontaneously". > In fact, no existing RFCs or this particular document describes such a > behavior, right? So, IMO, leaving it here would just confuse the > reader about in which case the "spontaneous" NA can happen. In light of a long, relaxing holiday I've decided I don't care much about it either, so here's some proposed replacement text: NEW> In the course of establishing connections, the ON might NEW> have sent NAs in response to received NSs. Since NAs NEW> sent from Optimistic Addresses have O=0, they will not NEW> have overridden existing NC entries, although they may have NEW> resulted in a colliding entry being changed to state STALE. I think we'll both be happy with that, yes? Hope you're all having fun in DC! -----sharks -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
