Hi Barbara, Thank you very much for your comment. I am glad to see that you agree with that it would be more logical to do all prefix-related configuration in RA. But yes, you are right that we need to prove what we have is insufficient or broken before we change the existing implementation. I once thought this was so obvious but it seems not. So I may need to spend some more time on this before I can get back on this topic.
Anyway, thanks to everyone that participated in this thread for the valuable comments. The original intent of this thread is to solve a puzzle about multiple prefix pools for different services. We finally came up with a well-recognized DHCPv6 approach and a potential but pending RA approach for the time being. So I am quite satisfied with this outcome for the time being and I really appreciate the active and quick responses on this thread. Thanks again! Best regards, Fortune -----Original Message----- From: STARK, BARBARA H (ATTLABS) [mailto:bs7...@att.com] Sent: Friday, June 18, 2010 10:49 PM To: Fortune HUANG Cc: ipv6@ietf.org Subject: RE: Question about SLAAC: how the host determines the prefixesallocated from different prefix pools > Do you think that the service type of > the prefix should be classified to the prefix related configuration or not? > If yes, do you agree that it should be carried in RA in the stateless > case? Nobody is disagreeing that *if* we could turn the clock back 10 years or so and have a greenfield discussion about creating brand new IPv6 standards that this might be something to consider. So, just to get past your question, let's say, for the sake of argument, that we all agree 100% that it would be more logical (a prettier way of doing things) to do all prefix-related configuration in RA. OK. Here is what we are saying: That is irrelevant. It is irrelevant that this would be a prettier way of doing things. Solutions exist. They have been coded and are being implemented. Hurdles for starting new standards work to change things that are already out in the field and being used are different than the hurdles for starting new standards where nothing exists. The hurdle when doing greenfield standards is indeed to convince others that what you propose is the most logical and efficient way of doing things. The hurdle when trying to convince others to go to the pain, effort, expense, suffering, and uncertainty of changing existing implementations and deployments, is to prove that the existing mechanisms are somehow insufficient or broken. So, to summarize... If you want to convince people to move forward with this proposal, you need to stop trying to convince us that your solution is more logical and inefficient. That's irrelevant, and we don't care. You need to convince us that what we have is insufficient or broken. Barbara -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
