On 21.7.2015 10:55, Michael StJohns wrote:
> On 7/21/2015 4:32 AM, David Conrad wrote:
>> On Jul 21, 2015, at 9:07 AM, Michael StJohns wrote:
>>> The decision with respect to "clients ... would see some benefit..." has
>>> to be based on what the servers know.
>> Yes, and the information provided
On 7/21/2015 4:32 AM, David Conrad wrote:
Mike,
On Jul 21, 2015, at 9:07 AM, Michael StJohns wrote:
The decision with respect to "clients ... would see some benefit..." has to be
based on what the servers know.
Yes, and the information provided by the mechanism described by Warren's draft
Mike,
On Jul 21, 2015, at 9:07 AM, Michael StJohns wrote:
> The decision with respect to "clients ... would see some benefit..." has to
> be based on what the servers know.
Yes, and the information provided by the mechanism described by Warren's draft
would provide at least some information t
On 7/20/2015 2:02 PM, David Conrad wrote:
Mike,
On Jul 20, 2015, at 6:02 PM, Michael StJohns wrote:
Basically, the major benefit from this is not to the clients who have to implement the
"query occasionally so the root knows what I know", but to the root operators
(or not even them maybe).
Mike,
On Jul 20, 2015, at 6:02 PM, Michael StJohns wrote:
> Basically, the major benefit from this is not to the clients who have to
> implement the "query occasionally so the root knows what I know", but to the
> root operators (or not even them maybe).
Presumably, the clients who have not ye
a long lived mechanism is in-band, not using labels in the DNS or query
payload.
bits in the EDNS space, indicating yes-no and where more than bits are
needed, explicit field:value definitions will get us further.
because they demand code change they can only inform us of the future.
warrens mec
