What Thomas says below is valid. We need to know what problem or purpose we are building a new safe RHx for. Once that is known, we can evaluate if your design meets the goals, ensure that the problem is of general interest for the Internet community that it makes sense to recommend it be implemented, etc.
Jari Thomas Narten wrote: > Sorry to interrupt, but I'd suggest that working on a new RH design is > mostly a waste of time at this point. > > Can we please _first_ identify a user/customer for a proposed RH, so > we are sure we actually design something useful? And at the same time > be sure we have a transition strategy for getting it > implemented/deployed that makes sense (i.e., doesn't require upgrading > parts of the infrastructure outside of the control of those wanting to > take advantage of the RH?) > > I.e., exactly what _real_ problem are we trying to solve here? > > The idea that we can define something (with no clear expected use) and > get it actually implemented and deployed is mostly naive. (My guess is > this would be an _optional_ standard, and vendors mostly wouldn't > bother to implement it -- if no one actually needs it). > > One can argue that the whole RH0 debacle results from designing > functionality for which there was no clear customer/use. Time and time > again, this sort of protocol design results in (at best) wasted > effort. > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
