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.
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 reason why the vendor option solution was proposed is that the only use cases that anybody could actually come up with in the meeting yesterday were use cases that were specific to particular ISP deployment models, and it seemed clear that these use cases could be adequately addressed with 3GPP- and BBF-specific extensions. There is genuine need in these two cases for this functionality. The reason why this isn't a no-brainer is that if it were added as a standard IETF solution, it would change what end nodes have to do to get routes, making end node software more complicated, and also more difficult to specify. As one of the authors of the MIF API document, I've had to think a lot about this problem, and I do not like having to have two different ways of configuring routes. The MIF problem is hard enough already; adding this to the problem seems to me to make it worse, not better. 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. _______________________________________________ mif mailing list [email protected] https://www.ietf.org/mailman/listinfo/mif
