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

Peter Thomassen <peter@desec.io> Tue, 01 June 2021 14:28 UTC

Return-Path: <peter@desec.io>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804063A1A01 for <dnsop@ietfa.amsl.com>; Tue, 1 Jun 2021 07:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUPsSXTKlw3l for <dnsop@ietfa.amsl.com>; Tue, 1 Jun 2021 07:28:22 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5423A1A03 for <dnsop@ietf.org>; Tue, 1 Jun 2021 07:28:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2iUJ+CSgBuqmQShulcNK7qKEsXDqKjXOSlp60FgbYnI=; b=QF4caOT6DrWQ00HpR9OM55Ooyr evvmdRfPdFcZfaMiIC6zYvL5PurFW+CBr5mj4zm4BwnIssL/3YZk+T1jaCS/rWr5Jhk56X1SDnmn5 tWKbjUJTY2MMrKKkgipIRcyVBleEmeu7VdbRqoKotRuWj6C/Ogxj0dZTSNprXW9TbOvD39yZc8U+e xRIjaf+dfDw+GeTMgOzwaAv8O+TXxI2/TGbBZS6slcJcDykCp/UymPRB09g+b1DoS7SuDo8+7unvl 7wiIOpyta0ITaREJeGrLueTYhQu3f7XuyZFv+uDkImHc9LhavUOa6w5c7kk8F7Asl9IV7CipC/9cW IWxW/NAA==;
Received: from ip5f5aea57.dynamic.kabel-deutschland.de ([95.90.234.87] helo=[192.168.1.171]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1lo5NS-0006PI-Nh for dnsop@ietf.org; Tue, 01 Jun 2021 16:28:18 +0200
To: dnsop@ietf.org
References: <162221199604.5432.8913611760873877465@ietfa.amsl.com> <c8beea2f-90b6-f005-f137-df47b8dead4d@desec.io> <20210601141922.GB68051@pepino>
From: Peter Thomassen <peter@desec.io>
Message-ID: <187aee91-2978-81fb-c10a-e47e9f982de3@desec.io>
Date: Tue, 01 Jun 2021 16:28:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <20210601141922.GB68051@pepino>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="rpOrFXyeFjBG4khEyRjYF9P2UoYVrzAO2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kwCeJLMVU8QcS9QzA5k56U1gDRo>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-salgado-dnsop-rrserial in state "Call For Adoption By WG Issued"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2021 14:28:28 -0000

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 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.

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