Re: [DNSOP] [Ext] Opsdir last call review of draft-ietf-dnsop-terminology-bis-11

Paul Hoffman <paul.hoffman@icann.org> Tue, 07 August 2018 01:09 UTC

Return-Path: <paul.hoffman@icann.org>
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 9EFCB130F08; Mon, 6 Aug 2018 18:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZAReTitfL-P1; Mon, 6 Aug 2018 18:09:27 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14121130ED1; Mon, 6 Aug 2018 18:09:27 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 6 Aug 2018 18:09:25 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Mon, 6 Aug 2018 18:09:25 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Dan Romascanu <dromasca@gmail.com>
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "draft-ietf-dnsop-terminology-bis.all@ietf.org" <draft-ietf-dnsop-terminology-bis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [Ext] Opsdir last call review of draft-ietf-dnsop-terminology-bis-11
Thread-Index: AQHULWNRWwh4sB3SlUiFZWFBIzj096Sz8SEA
Date: Tue, 07 Aug 2018 01:09:25 +0000
Message-ID: <0CD18946-1208-40C4-86B8-E0DFFBD96D03@icann.org>
References: <153354574511.26803.11164308130374229230@ietfa.amsl.com>
In-Reply-To: <153354574511.26803.11164308130374229230@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <ACB986A9EAD3324C914F28E2528A9A4F@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/D3JvaX49WZ8fyH8un6mNfF7mt1U>
Subject: Re: [DNSOP] [Ext] Opsdir last call review of draft-ietf-dnsop-terminology-bis-11
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, 07 Aug 2018 01:09:28 -0000

On Aug 6, 2018, at 1:55 AM, Dan Romascanu <dromasca@gmail.com> wrote:
> 1. One important difference between Informational RFC 7719 and the current
> document is its elevation to the status of BCP. There must be good reasons for
> this decision (like avoiding downrefs in new work, other), and I believe that
> it would be useful to include a short justification, maybe in the Introduction
> section, in case the document will be approved and published as a BCP.

This is covered in the shepherd report, and I can't really find a good place to put in in the document. As the shepherd says:

It's an effort to collect a large number of terms from a large number of sources, primarily RFCs but also common usage by practitioners. As such, it aims to improve interoperability among implementations and operational configuration of the DNS by giving implementers and practitioners a common reference vocabulary. Clearly the more people use it, the more useful it will be, so BCP seems right.

In addition, from the process perspective, the document's status is BCP because it updates RFC 2308, which is a Proposed Standard.

> 2. In section 2:
> 
> 'An ordered list of zero or more octets and which makes up a
>      portion of a domain name.'
> 
> This sentence seems to be broken, it is not clear what 'and' relates to.

Good catch. Will remove the "and".

> 3. In section 2:
> 
> ' At the time this
>      document is published, that operator is Public Technical
>      Identifiers (PTI).'
> 
> A reference would be useful.

Will add:

(See &lt;https://pti.icann.org/&gt: for more information about PTI operating the IANA Functions.)

> 4. In section 5:
> 
> I cannot find a definition of the term 'resource record' itself. I can see RR
> as acronym, then a discussion of RRset, etc., but not the term itself. Do I
> miss something?

No, you didn't. The definitions of resource records in RFC 1034 are:

>From Section 2.4:

   - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
     specifications for a tree structured name space and data
     associated with the names.

>From Section 3.6:

A domain name identifies a node.  Each node has a set of resource
information, which may be empty.  The set of resource information
associated with a particular name is composed of separate resource
records (RRs).  The order of RRs in a set is not significant, and need
not be preserved by name servers, resolvers, or other parts of the DNS.

Frankly, it doesn't feel like either ("data associated with names" or "set of resource information") are helpful enough to include in the terminology document. If you disagree, we're open to suggestions. 

> 5. I cannot find a definition or expansion of SOA. I can see 'SOA field names',
> 'SOA resource records', etc. but not just 'SOA'

Good call. Will add:

"SOA" stands for "start of a zone of authority".

> 6. Section 6:
> 'Master server:  See primary server.
> 
> Primary master: '
> 
> Is it 'Primary server' or 'Primary master'?

It is "primary server", which was defined just above. Will rearrange to make this clearer.

> 7. I cannot find a definition for 'NS records'

Will add:

An authoritative server is named in the NS ("name server") record in the parent zone.

> 8. I found the Index to be very useful, and I wish other documents of this size
> and complexity (or worse) include such a section.

Thanks, this is good to hear. (And I say that as the co-author who objected strenuously to adding the index because no one uses them...)

--Paul Hoffman