At Mon, 20 Aug 2007 13:43:19 -0700, Bob Hinden <[EMAIL PROTECTED]> wrote:
> We would like to get your comments on the following two choices: > > 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>. > > 2) Revising the draft to restrict the usage of RH0. This would If I were to choose one I support choice #1, but I can live with choice #2 (but in that case just turning it off by default seems sufficient to me). The most important point for me is to make the consensus as quick as possible rather than sticking to a super-perfect solution and wasting more time. So, if there are still a non-negligible number of people who object to the deprecation while the vast majority *can live with* off-by-default, I think we should go for it. Some detailed comments: I prefer choice #1 because it looks cleaner resolution. Also, since (as far as I know) not so many people are heavily relying on RH0 right now, I believe they can generally wait for new types of RH for their specific purposes. But at the same time, I guess getting new RHx deployed will take pretty long time (e.g., one-year) realistically, especially due to the infamous time-consuming standardization process at the IETF (I'm afraid we're not even sure where to discuss the spec - apparently 6MAN is not the place). So it's understandable to me for those who prefer choice #2 to oppose to the idea of hasty deprecation. Thus I can also live with choice #2. I've heard an argument that off-by-default is not sufficient, but I personally do not necessarily agree with that. I stated my personal opinion on this somewhere else before: http://mail-index.netbsd.org/tech-net/2007/05/20/0003.html The argument that if the node is controlled by a remote attacker the feature may be re-enabled is not convincing to me either because in that case the attacker can do any other evil things including even replacing the kernel implementation or running a user-space bouncer application that has the same effect of RH0. I'm not arguing I prefer choice #2 by saying this, but choice #2 certainly works for me as a compromise if that makes a quicker decision. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
