On 2011-11-18 09:04, Ted Lemon wrote: > On Nov 17, 2011, at 9:57 PM, "Tomek Mrugalski" > <[email protected]> wrote: >> To have this list more organized, please assign a number to >> your support voice. It will make it easier to explain if >> comments are made about already mentioned use cases or new >> cases. If you have any specific concerns, there's separate >> thread for that. >> >> My understanding is that it helps if you are representing a >> large ISP, a vendor or someone else who has non-trivial >> impact on the industry. Voice of people, who express their >> personal opinions still count, but to a lesser degree.
In terms of IETF process, that is not OK. We are individuals here, expressing individual engineering arguments. Nevertheless it is important to hear from practitioners and, excuse me for saying it, they are not here because they are fed up with waiting for the IETF. > To be clear, a use case is not "I want it because I think it > would be nice." It's "Router Advertisements don't work for > me for the following specific reason in my actual > deployment." > > The fact that it is the most requested feature isn't the > point. The question is, *why* is it the most requested > feature? Is it because people have zero operational > experience with IPv6, and are just trying to do the same > thing they did in IPv4, and once you explain RAs to them they > say "oh, okay" and stop asking for it? Or is it the case > that there is some genuine deployment problem that RAs don't > properly address? The people on the *real* IPv6 ops list who are asking for this are not beginners. But they *are* trying to do the same thing they did for IPv4, for a reason... <snip> > I'm also pragmatic. If we have to make this problem a > little bit worse to solve some real world problem, fine, > let's make the problem a little bit worse. But if we're > doing it because people think they have to have feature > parity with DHCPv4, that's just not a good enough reason. Tomek didn't define a way of assigning use case numbers, so I'll call this use case #42: Operators say that they want (approximate) feature parity so that they can have (approximate) alignment between their operational procedures for v4 and v6, especially in a dual stack network. I assert that this is a very good engineering reason, and it isn't for the IETF to get on its high horse and say that experienced operators don't know how to manage OPEX. I don't know whether my final comment belongs on this thread or the drawbacks thread, but it's clear that a strong constraint on any DHCPv6 option that overlaps in functionality with RA is that it must convey exactly the same semantics or a proper superset of the same semantics. If we do that, DHCPv6 will not undercut RA and a special algorithm for RA vs DHCPv6 conflict resolution will not be needed. Brian _______________________________________________ mif mailing list [email protected] https://www.ietf.org/mailman/listinfo/mif
