On Tue, 22 Sep 2020, Valery Smyslov wrote:
That is not how the CP payloads work. The initiator sends a set it is okay with
and the responder picks what it
prefers from that set. Or an error if it deems all of it bad.
Exactly. However, with different attribute types the client can indicate its
capabilities too
and can prioritize them (by adding attributes to the request in the order of
client's preference).
I don't think the Configuration Payload order significies a preference
for anything? Does RFC 7296 really say that?
I would still prefer a single request for encrypted DNS and a reply with
servers with capabilities. Asking for all
these different types will be more complicated.
I don't think it's really more complicated. I agree, that current solution is
more bulky in case you want to
convey all possible types of encrypted DNS, all sharing the same IP-addresses
and authentication domain and
not counting non-standard ports. In other use cases it's roughly the same in
size.
The common case will be DNS servers that support the kitchen sink. Let's
make that use case the easiest.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
