Re: [DNSOP] [Ext] Mirja Kühlewind's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Tue, 28 August 2018 12:20 UTC

Return-Path: <ietf@kuehlewind.net>
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 74E8B130EA2 for <dnsop@ietfa.amsl.com>; Tue, 28 Aug 2018 05:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 DfZecG1DiaFb for <dnsop@ietfa.amsl.com>; Tue, 28 Aug 2018 05:20:21 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C972130DCC for <dnsop@ietf.org>; Tue, 28 Aug 2018 05:20:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=vL1u5TZUFJizLnT4GoHmZ7faQXYHM2Ag7rdR02Zr5kd6zIakwrvZ9G76KmV1+LY92yAFTnh8v/orD2l+PxK7fW6W7ze4wZG3SkgPvUJd2WHPhA37E3sSYIis4O3Frlk0hyBaGLnvLx2tt0uGTzeEpT0ZO8CrL9PU2Kk1FsF9qDw=; h=Received:Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 22066 invoked from network); 28 Aug 2018 14:19:19 +0200
Received: from nb-10688.ethz.ch (HELO ?82.130.103.20?) (82.130.103.20) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 28 Aug 2018 14:19:19 +0200
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: The IESG <iesg@ietf.org>, dnsop <dnsop@ietf.org>
References: <153512671800.23080.10672402309953864375.idtracker@ietfa.amsl.com> <9144207B-FAA7-41EC-A0B2-DC2443064727@icann.org>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <ietf@kuehlewind.net>
Message-ID: <6e70d395-bf33-4a3a-6cad-968912e84c59@kuehlewind.net>
Date: Tue, 28 Aug 2018 14:19:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <9144207B-FAA7-41EC-A0B2-DC2443064727@icann.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-PPP-Message-ID: <20180828121919.22060.62340@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZlgJ7ErwFlbs-oKw5lWuGD0oH98>
Subject: Re: [DNSOP] =?utf-8?q?=5BExt=5D_Mirja_K=C3=BChlewind=27s_No_Objectio?= =?utf-8?q?n_on_draft-ietf-dnsop-terminology-bis-13=3A_=28with_COMMENT=29?=
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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, 28 Aug 2018 12:20:25 -0000

Hi Paul,

I leave the decision about the update to the wg and responsible AD, 
however, if you decide to keep it, maybe you can just rephrase a bit to 
make sure that it is very clear the definition is this doc is the 
current one.

Mirja



On 26.08.2018 03:11, Paul Hoffman wrote:
> Thanks for the review!
>
> On Aug 24, 2018, at 9:05 AM, Mirja Kühlewind <ietf@kuehlewind.net>; wrote:
>> I'm actually not sure if this doc really updates RFC2308 because the two
>> definitions (Forwarder and QNAME) only say someting like "it is used
>> differently today" but seem not really to actually update the existing
>> definitions. I would recommend to either not use the "update" tag or clarify
>> these definitions.
> The WG thought that this is "updating 2308" and wanted that pointed out clearly, but if the IESG thinks it is not really updating, we can remove that designation at the top. Please let us know.
>
>> Thanks for the clarification added based on the TSV-ART review (and thanks
>> Allison!).
>>
>> (Potential) nits:
>> 1) OLD:
>> A set of resource records with the same label, class and
>>       type, but with different data.  (Definition from [RFC2181])
>> MAYBE use quotes here at least for the last part of the sentence:
>> A set of resource records "with the same label, class and
>>       type, but with different data."  (Definition from [RFC2181])
> Agree.
>
>> 2) s/Section 4.3.1 of of [RFC1034] /Section 4.3.1 of [RFC1034]/
> Of of course that is what we meant.
>
>> 3) Probably the first sentence should be removed:
>> "The idea of a primary master is only used by [RFC2136],
>>       and is considered archaic in other parts of the DNS.
>>
>>       The idea of a primary master is only used in [RFC1996] and
>>       [RFC2136]. "
> Agree.
>
>> 4) Why is there (a) and (b) for the definition of Origin?
> Because there are two different definitions for two different contexts. We'll make this clearer.
>
> --Paul Hoffman