Hi Paul, > > I would expect there to be some people pushing to have this be a capability > > negotiation that honors the client's preference, not the server's; the > > scenario you describe is one where the server's preference is used. > > (To be fair, I'm not following ADD much at all, though, so I could be > > wrong.) > > 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 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. Regards, Valery. > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
