Subject: Re: [DNSOP] The DNSOP WG has placed draft-salgado-dnsop-rrserial in state "Call For Adoption By WG Issued"

From: Hugo Salgado <[email-masked]>
Date: Tue, 1 Jun 2021 10:19:22 -0400

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 NSID option (RFC 5001). It works as a part of another query, so no separate query is necessary (dig +nsid ...).
> 
> The question here would be why another method for discovering the origin should be introduced.
> 

The aim is to recognize the "origin" of a response in the sense of
"data source version". It's complementary to NSID because nsid allows
to recognize the origin in "transport", or "server". They work in
different scopes.

Hugo

---

From: Peter Thomassen <[email-masked]>
Date: Tue, 1 Jun 2021 16:28:17 +0200

Hi Hugo,

> to recognize the origin in "transport", or "server". They work in

Sure, understood. I'd like to propose to use another word, as "origin" belong to the lexical field of "source", "ancestor" etc. and is misleading.

A better word for the text may be "revision" or "version". Maybe even better, we could avoid the construct of helping "recognize the origin of an answer" altogether. For example, instead of

>    This "RRSERIAL" data allows to debug problems and diagnosis by
>    helping to recognize the origin of an answer, associating this answer
>    with a respective zone version.

we could just have

>    This "RRSERIAL" data allows to debug problems and diagnosis by
>    associating an answer with its respective zone version.

This affects the abstract and the introduction.

Best,
Peter

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525