On Sep 19, 2020, at 01:09, Benjamin Kaduk wrote:
>
>
> 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 no
On Fri, Sep 18, 2020 at 03:51:11PM +0300, Valery Smyslov wrote:
> Hi Paul,
>
> > Why is this using a seperate CP payload type per encrypted DNS type?
> > This means that for a DNS server supporting DoT, DoH and DoQ, it needs
> > to send 3 separate payloads. Why not send 1 CP payload that contains
Hi Paul,
> Why is this using a seperate CP payload type per encrypted DNS type?
> This means that for a DNS server supporting DoT, DoH and DoQ, it needs
> to send 3 separate payloads. Why not send 1 CP payload that contains a
> bitmask specifying which services it supports?
Well, from my understa
etf.org
> Objet : Re: [IPsec] TR: New Version Notification for draft-btw-add-
> ipsecme-ike-01.txt
>
> On Thu, 10 Sep 2020, mohamed.boucad...@orange.com wrote:
>
> > We updated the draft to take into account the comments raised
> during the last IETF meeting. Instead of mult
On Thu, 10 Sep 2020, mohamed.boucad...@orange.com wrote:
We updated the draft to take into account the comments raised during the last
IETF meeting. Instead of multiplexing the attributes, we simplified the design
so that types are assigned to each encrypted DNS type (DoT, DoH, DoQ).
Why is
