Chris, > Yup, and someone/no-one noted this as a real concern with ipv6 RH0, > everyone focused on the least interesting problem and decided to > shutdown RHO and excise it from the protocol... a blatant knee jerk > reaction. It's interesting to me that this blatant knee jerk reaction > is getting a base protocol level change
The RH0 case is not one of the big issues facing the Internet. As bugs and changes go, its a very small one. This does not imply that we can forget it and do nothing. The IETF is responsible for its specifications much the same way as vendors are responsible for their products. When there's a bug or a security vulnerability in our specifications, it is our duty to take notice and take appropriate. Perhaps we can debate what that action should be, but it most certainly should include documentation of the issue, and in some cases modification of the spec in question. I realize that in many cases what has happened is that the RFC stays unchanged, and a body of knowledge is developed outside the RFCs (code in common implementations; papers in conferences; discussions on lists; word of mouth) about what should be done. I do not think this mode of operation is appropriate, or at least not appropriate in all cases. We owe it to the consumers of our specifications -- implementors, for instance -- that we keep them up to date and that they contain all the information required to implement and use the feature in question. I respect your opinion that this is a knee jerk reaction, but disagree with that characterization, and so did most of the people who were involved in the discussion. On a personal note, I find it amusing that a couple of months ago we had to calm people down and assure that this is just another bug and we'd deal with it the way we deal any other issues. Now we're using same words to argue that we're not giving in to hysteria... > yet locator/id split isn't. > It's interesting that folks feel in this instance ipv6 is 'less used > and less critical' and thus able to be changed where in the locator/id > split discussion that argument was not acceptable. > I share your frustration, there is nothing that I would like better than getting an identifier-locator separation in our stack. (Or having one there already, but then you have to lend your time machine to us.) However, the way to get there is to not block bug fixes or other ongoing work. What we need instead is (a) work towards identifier-locator solutions that are far enough in the design that we can actually adopt them and (b) people who start to use these things in their networks. As you know, there is ongoing work in the IETF, e.g., in HIP WG/RG and the RRG. The former has more issues in class b, the latter has more issues in category a. I'm very hopeful that we'll get a positive end result, but we are not there yet. The criteria for adopting either a bug fix or a new feature is the same that it has always been: - We have a solution ready for adoption (no missing parts, does not cause major security issues) - We understand how it can be deployed and how it affects backwards compatibility. - We have agreement on adopting it. So - I would suggest that we get to work on this, too. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
