Hugo,
While I find it a pity that the consensus seems to be that just
including the serial instead of the entire SOA is the best way forward,
I don't strongly object, since it can indeed be useful for debugging as
proposed.
Sorry if I missed earlier discussion, but if a query to a resolver
Tim,
On 28/05/2021 16.26, Tim Wicinski wrote:
>
> We had a lot of good discussion of this draft when it first came out,
> and the chairs want to put up a call for adoption.
I support adoption of the draft, and am willing to contribute text and
review.
Cheers,
--
Shane
OpenPGP_0x3732979CF9
On Tue, 2021-06-01 at 08:59 +0200, Shane Kerr wrote:
> And maybe cache the value if desired?
I'm already looking forward to having serials in resolver cache dumps!
> At the very least, maybe the draft should be agnostic towards
> non-authoritative servers?
>
> So instead of:
>
> This EDNS
On 13:20 01/06, Peter van Dijk wrote:
> On Tue, 2021-06-01 at 08:59 +0200, Shane Kerr wrote:
> > And maybe cache the value if desired?
>
> I'm already looking forward to having serials in resolver cache dumps!
>
> > At the very least, maybe the draft should be agnostic towards
> > non-authoritat
Hi Peter. Just wanted to comment on one issue below:
On 21:27 28/05, Peter Thomassen wrote:
> 2.) NSID option
> ---
> The draft says, RRSERIAL helps "recognize the origin of an answer"
> (supposedly when secondaries are out of sync).
>
> There already is a way to do that, using the N
Hi Hugo,
On 6/1/21 4:19 PM, Hugo Salgado wrote:
2.) NSID option
---
The draft says, RRSERIAL helps "recognize the origin of an answer" (supposedly
when secondaries are out of sync).
There already is a way to do that, using the NSID option (RFC 5001). It works
as a part of another
Hi Hugo,
On 1 Jun 2021, at 10:05, Hugo Salgado wrote:
> On 13:20 01/06, Peter van Dijk wrote:
>
>> I like this. I suspect defining it well for answers from resolvers to
>> clients would open up a big can of worms that could kill the draft,
>> like many other drafts that have been crushed under
