Hi, Benjamin, On Fri, Jul 27, 2018 at 12:33 PM Benjamin Kaduk <ka...@mit.edu> wrote:
> On Thu, Jul 26, 2018 at 09:33:20PM -0700, Spencer Dawkins wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > [snip] > > > > This next one is well within the "Spencer wouldn't have done it this > way, but > > Spencer's not the working group, or the IETF" range, but > > > > However, in the typical case a server will not know in advance > > whether a client supports DSO, so in general, unless it is known in > > advance by other means that a client does support DSO, a server MUST > > NOT initiate DSO request messages or DSO unacknowledged messages > > until a DSO Session has been mutually established by at least one > > successful DSO request/response exchange initiated by the client, as > > described below. Similarly, unless it is known in advance by other > > means that a server does support DSO, a client MUST NOT initiate DSO > > unacknowledged messages until after a DSO Session has been mutually > > established. > > > > seems fragile, especially in environments where clients can come and go, > and > > servers may be addressed using anycast (so I knew in advance that the > four > > servers at that anycast address supported DSO, but somebody installed a > fifth > > server that does not). Is that unlikely to be a problem? > > Note that the client is only prohibted from using "unacknowledged" > (one-shot) messages -- it can send always normal requests and use the > presence of a reply to determine server support, on this connection. > So this seems like a pretty vanilla "client initiates" thing, if I > understand correctly. > Ah - that helps me understand. Thank you for that. Spencer > -Benjamin > > [snip] >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
