Tim, >Given that there is a historical precedent for being able to do something via >more than one standardized IETF way, I'd suggest that IPv6 PD is another such >case where such an approach is warranted. >... >I'd like to repeat my/our contention that ICMPv6 PD is not meant to replace >DHCPv6 PD. The two are not mutually exclusive. > >In some cases, customers may wish to have an alternative to the existing >mechanism (WHY they wish to have it is a separate question, THAT they do is an >issue which helped inform the writing of our draft). > >Customer requirements are often what drive innovation (sometimes the other way >around). Over the past few years, more customers have expressed interest >in/requirement for an alternative to DHCPv6 PD. Our draft based upon ICMPv6 is >one such proposed solution. > >BTW, what would be your burden of proof in what you are asking?** I'd not want >to be chasing my technical tail. =^) > > As Brian pointed out there are some design principles that the IETF uses. We believe interoperability is very valuable. We do not create alternative ways to do the same thing, because doing so will burden implementors with additional complexity and reduces the likelihood that nodes can communicate successfully. Picking a common way to do something is the fundamental idea behind standards.
Of course, in some cases we actually do have to create alternative mechanisms when the situation calls for it. For instance, the requirements are very different, we have new needs that fundamentally cannot be met by the existing mechanisms, and so on. And we all want to enable the things that the customers want to do. So their requirements are important, but some engineering may be needed before we decide what solution should be employed. I would suggest that you focus on the WHY question and proceed with a rational analysis of whether existing mechanisms are or are not sufficient for your needs. This analysis should avoid arguments such as "Devices do not have X, therefore we must design Y". Such arguments do not provide any information on what the reasons for not having X were, whether designing Y will alleviate those concerns, and whether the benefits from Y are a good tradeoff with respect to the costs of supporting both X and Y in everyone's products over the next N years. And the burden of proof is on the side of those who want something new; you should convince the community that it is indeed necessary. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
