[EMAIL PROTECTED] writes: > > Jun-ichiro itojun Hagino writes: > >> again, it is about rather serious security problem, which risked > >> the DNS root name servers. it's quite serious and really urgent. > >> the RFC publication should have finished way earlier. > > > > Of course security problems are important. However, fixing them in > > the field is _never_ dependent on publishing an RFC, because the RFCs > > themselves are not executable. > > While this is technically true, it is a red herring.
I don't think it's a red herring at all. The previous poster was conflating RFC publication with actual code change. The two are distinct. > And the impediment to fixing things in the field, is that vendors need > to maintain interopability. This requires RFCs. Vendors who ignore RFCs, > cause problem for everyone. So, even if some vendors are willing to make > the change, most would prefer, and some require, that the RFC be changed > *first*, so that they do the change to maintain RFC compliance, as compared > to making a change which, while the right thing, violates the RFCs. I think a vendor that prides itself on specmanship rather than security and demonstrated interoperability is probably a lost cause anyway. In this case, what you're saying is effectively (also?) a red herring. It's not the case that vendors who shut down RH0 long ago were somehow causing "interoperability" problems, or that having the RFC published somehow makes any such problems go away. It may well be the case that (with _other_ changes), a flag day is necessary. This clearly isn't one of those cases. > > If there really are vendors that are failing to fix security problems > > because they want to see an RFC published first, then I'd suggest > > either taking that up directly with those vendors or simply choosing > > not to buy their products. > > The risk of RH0 requires that *all* vendors fix the issue, since it has > bearing on even those parties that have to some degree disabled processing > RH0 packets directed at their gear. Thinking that publishing the RFC will actually cause them to change seems like a different sort of risk to me. > Do you agree that the proposal, as written, has very narrow scope? Yes. > Do you agree that adoption of the RFC may require vendors to change code > to support the RFC? No. The IETF has no police and can't really force anyone to do anything. > And do you agree that if code is changed, to be universally supporting > the RFC, and deployed everywhere, that the RH0 security issue goes away? Yes. > If so, I would suggest the appropriate response is to express any concerns > you have, but to also support the proposal. I wasn't expressing any lack of support for the proposal. I was expressing support for Jason Schiller's on-topic discussion of the options. I don't think that Jun-ichiro itojun Hagino's response to him was helpful. It's alarmist and incorrect to say that delaying RFC publication in order to get the wording right means that people can't deploy _today_ based on the draft. Don't most people intentionally deploy implementations based on drafts anyway? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
