In my opinion, Thomas is correct. This is a technical choice, not a "policy" choice, and well within the IETF's competence.
(Speaking as co-drafter and co-signer of RFC 2860, among other things.) Brian Thomas Narten wrote: > > Alain Durand <[EMAIL PROTECTED]> writes: > > > On Feb 27, 2004, at 5:23 PM, Thomas Narten wrote: > > > > > > Let me ask you this then. If the word "permanent" is not appropriate, > > > what word is? To me, "not permanent" means that at some future time an > > > allocation that has been made to an endsite may be revoked. > > > The point I'm arguing is that it is not the IETF business to decide > > this. > > I respectfully disagree. Seems to me that whether or not assignment > should be permanent is a property of the type of address we are > defining and goes to heart of why we are defining unique local > addresses. My understanding is that end sites are supposed to be able > to use them however they see fit, and specifically will _not_ have to > worry about someone reclaiming them or taking them away. If an end > site has to worry that it may have to give up the address at some > future time, these addresses have just become a lot less attractive > (or useful). Thus, it is important that the assignments effectively > be permanent. > > > So not saying anything is probably the best option. Another one is > > saying that the entity in charge of the allocation is required to > > provide those allocation for the long term and not specify anything > > further. It is a policy decision made by the entity(ies) in charge > > to decide what long term means. > > Letting the entity that operates this service decide the terms of the > address (how long an assignment is good for, under what terms it > should be reclaimned, etc.) without any sort of guidance is a recipe > for creating a bad situation that we cannot fix. I.e., we get a > service that isn't what this WG intended and that we can't fix it > because we don't control it (e.g., in a worst case scenario, a newly > created monopoly accountable to nobody). > > > See the contract between the chosen entity and the customer. > > Again, this is policy, not protocol. i.e. this is not IETF business. > > Are you really suggesting that some third party (not under IETF > direction) define the policy, even if the result of the policy could > defeat the purpose of having such addresses? > > > > Is > > > there some future scenario we're worried about where it becomes > > > important to be able to reclaim these addresses? I.e., are they ever > > > going to become a scarce resource? > > > I'm worried about the scenario where IETF does policy and not protocols > > anymore. > > I believe you are confusing properties with policy. One can't > completely separate the two. If you look at CIDR, we've moved to > address leasing because we don't know (technically) how to do global > routing if all address assignments are permanent. In the case of > unique local addresses, there are no technical issues with making such > assignments permanent (or do you disagree?). Thus, there is no reason > why we can't make such assignments permanent. (Note: I'd agree with > you that the assignments shouldn't be permanent if there was a case to > be made that it may become necessary to reclaim them at some future > time. Is there?) > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
