> 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. The real question is, are there situations where revising an RFC is necessary, where the result of the RFC *doesn't* require that a new functionality or change in functionality be built? The answer here is yes, and is directly on-topic. The reason the RFC needs to be changed, is that the *default* behaviour, not the supported kinds of behaviour, is being changed. The RFCs specify all kinds of things, with language like MUST and MAY. 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. > 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. > I think that dismissing concerns about coherence and direction in the > RFCs because of a desire to rush publication is short-sighted at best. I agree. I also believe that well-thought out and coherent RFC proposals, whose timely publication are needed to address actual concerns, should be given appropriately timely consideration. I also believe that only the technical content of the RFC should really be what we're talking about, in any RFC discussion, rather than delaying action on it because of abstract meta-issues which do not bear on the RFC. (There can well be situations where the meta-issues *do* bear on the RFC and/or other RFCs, especially when convicted monopolists are attempting to modify RFCs to their own ends. But when no such issue exists, we should avoid dragging those kinds of questions into the discussion.) Do you agree that the proposal, as written, has very narrow scope? Do you agree that adoption of the RFC may require vendors to change code to support the RFC? 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? If so, I would suggest the appropriate response is to express any concerns you have, but to also support the proposal. And if you happen to represent a vendor of IPv6 code, that you either do the code fix unilaterally, or support the proposal, since the general consensus is that this needs to be fixed. Or even abstain, if you feel conflicted. But I don't think opposing this proposal, on any of the grounds you have suggested, is entirely appropriate -- IMHO. Brian Dickson Afilias -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
