I think this discussion is getting way too deep into the weeds of policy. That isn't a concern IETF has generally taken a definitive stand on. If it had there would not have been the need to set up CABForum outside IETF.
As I see it the specification should allow: * A mechanism for the client to indicate the proof(s) of DNS control it can provide. * A mechanism for the service to indicate the proof(s) of DNS control it will accept. Who offers and who chooses is something the protocol can make a decision on but it is probably best if a 'no' from the service is accompanied by a list of what is acceptable. It is useful for IETF to provide security considerations on particular proofs but IETF cannot and should not choose. That is ultimately up to the people who write the path validation code and the data it consumes (including root lists). They bear the liability, unless they can figure out how to hand the hot potato to someone else. Another reason to not make the choice in IETF is that this is not a once and for all decision. It is a decision that should be under constant review. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
