I'm glad to hear that RIRs can respond to users' concerns,
but that doesn't change the fact that they're second-guessing
an IETF decision and that other things in the IPv6
architecture are dependent on that design decision.
Given that the IETF has not released any documentation of the decisions
in question, other than one RFC that contains deprecated material, I
think that the RIRs have every right to second-guess the IETF. If anyone
thinks that the RIRs second-guessing results in the wrong decisions,
then perhaps they will take the time to write the missing RFC with
guidance for RIRs. It wouldn't hurt to issue another RFC with guidance
for network operators, even if it covers a lot of the same ground as the
RIR guidance.
That's why
IETF took too long to become aware of the inherent problems
associated with NATs and too long to speak out about those
problems, and has said too little about them.
It's that last point that I have a problem with. If supreme court judges
can't come to a consensus then at least they will explain why, by
writing a dissenting opinion. In my opinion, if there is a problem with
reaching consensus on important issues, then the IETF should pressure
both sides of the issue to write a draft explaining the problem area.
It's also why
it never has developed a viable transition path away from NAT
and toward native IPv6.
The IETF has effectively specified that IPv6 NAT devices are the right
way to do this by not defining a standard set of functionality for an
IPv6 gateway for connecting an IPv6 network to the IPv6 Internet. By not
specifying how it is to be done, the IETF is giving carte blanche for
anyone to solve the problem in any way that they please.
--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf