Hi Jinmei,
Sorry, but I seem to have failed to respond to this message...
At 5:26 AM +0900 11/5/04, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
I basically think we should publish 2461bis and 2462bis at the same timing with consistent changes. So, it would make sense to hold one of them until the other is done at some stage. I'm not really sure which point is the best, though. Perhaps just before the IETF last call (and the IESG evaluation)?
Send each of them to me when they are ready, and I will make sure that they go to the IESG together.
So, unless you have a strong demand to reorder the terminologies, I'd slightly prefer to keep the current ordering.
That's fine.
Okay, then I'll add a reference to the addressing architecture RFC (RFC3513) here. (I don't think the scope arch doc is an appropriate reference in this context.)
Sounds good.
At 5:26 AM +0900 11/5/04, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
What happens if the value of the "autonomous address-configuration flag" changes over time?
My understanding is that the change means nothing; if the "autonomous address-configuration (A) flag" is not set, the corresponding prefix simply isn't used for the address autoconfiguration protocol (creating a new address or updating an existing one). I think this point is pretty clear in Section 5.5.3, and I personally don't see the need for describing the details in the "overview" section. What do you think?
We discussed this in the WG, and I think that there is agreement regarding this now. I agree that this level of detail doesn't need to be in the overview.
I am not sure how the last sentence is consistent with the must in the first sentence. Change the must in the first sentence to a should?
I agree this is a bit confusing. Since it's not a RFC2119 keyword (i.e., not MUST), I believe this is just a wording issue. I'm fine with chaing "must" to "should", but I'd say "all addresses must basically be tested". Do you have any preference or other suggestions?
I'd prefer something like:
By default, all addresses should be tested for uniqueness prior to their assignment to an interface. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via DHCPv6. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag.
But, that's just a text editing suggestion... I think we are in agreement about what this means.
I think that we will be able to send this document to IETF LC very soon. Please let me know when a new version is submitted to the I-D archive.
You have done an excellent job of cleaning-up, updating and clarifying this document.
Thank you, Margaret
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
