Mans & Pekka, > > <snip> I guess the question is about whether we want to > > encourage adding that support, or documenting existing, well-known > > practice for new implementations. If we put EDNS0 as a SHOULD, we'd > > probably be doing the former .. which is OK by me as long as we're > > doing a conscious decision on that (but my personal take is that we > > should stick to "known good, implemented, works" -mantra in > a document > > like this). > > We know that EDNS0 works. Mark did a good description of the present > state. I see nothing to the contrary. It is A Good Thing to endorse > EDNS0 in a document like this, because it could speed up deployment.
I am not an expert with EDNS0, but reviewing this thread, it seems that the client support for EDNS0 is what is lacking, most servers support it already. What I think this means is that a SHOULD in the requirements shouldn't cause operational difficulties. If I am correct, then, what would be the problem with listing EDNS0 as a SHOULD? If we do this, we may get more clients to support EDNS0. John -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
