All,
In Berlin we had two presentations on different methods of returning
multiple responses:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
and a presentation in Buenos Aires:
https://datatracker.
Paul,
Thanks for the update... comment below:
On Aug 4, 2016, at 12:48 PM, Paul Hoffman
mailto:paul.hoff...@vpnc.org>> wrote:
Our intention for this month is to add a bunch of other terms from RFCs. I'll
also start some threads about terms that we should probably define but that are
not in RF
On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski wrote:
> All of these documents are attempting to solve a larger problem in different
> ways. The end result is "Return Associated Answer" to the client.
>
> The question is starting to coalesce around these two premises:
>
> - Do we want to Server t
On 16 Aug 2016, at 5:57, Tim Wicinski wrote:
- Do we want to Server to PUSH any or all Associated Answers, or
- Do we want the Client to PULL any or all Associated Answers, or
- Do we want the Status Quo?
Client pull, which is really just the client saying "if you have this,
send it to me i
my bad. I've been re-framed.
Contextually, PUSH means (to me at least) 'do this promiscuously' and
PULL means (to me at least) 'do this if asked' -which is not what I
previously understood.
In that case, I think PULL makes more sense: do this, if the client
signals its what it wants. Otherwise, d
