Re: [DNSOP] [Ext] Spencer Dawkins' Yes on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 28 August 2018 21:31 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 D2920130EF1; Tue, 28 Aug 2018 14:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.com
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 cvI_iAwo8Dgk; Tue, 28 Aug 2018 14:31:24 -0700 (PDT)
Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76D312D7F8; Tue, 28 Aug 2018 14:31:23 -0700 (PDT)
Received: by mail-yw1-xc34.google.com with SMTP id m62-v6so1189292ywd.6; Tue, 28 Aug 2018 14:31:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H4EPjm7nkCeoCQpVYBs7h85woiQfILZJomwiEyKrho0=; b=CwYGT+sK3PDgtqxFW1mj4jfKx3zK8ODfTMD85YMiBh9jDMZrjLU9oryghkjLZ7orja ImsHRPxIHzHzx2SeLfZW/mbWefodkZuzEKE+ITO4+s9SBGlei2Irkrj16POek3MC2UBW YulDFAaTLslvy3mVgW69MSBceV1I9C97F2dc3sHq/TSGyUBTtftuah23bJ1uHh7p8pku 0lmZwHZ0WZYBKE/DimC8vzLCRxJGixVxvx5FpWJ6AA0zzuonGuj5ahzF7NTa4zHPyhqk igkm3eyOaOtEkiPK2TJ3ky0cI4/LIoxUddcyZxAkQeCdurcc9YGFJKgqb+5n/YpedMJP ypdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H4EPjm7nkCeoCQpVYBs7h85woiQfILZJomwiEyKrho0=; b=ZKAEaTheR96DkWCdfy53DtNzw82Am9688pMG4GohPxZ1nX2RH3LY6bFLf254t+OQJi 0DhwQicaYsobCtq4TpG8Tz1tSYft7YEr9HRxYOUZOLlgl2Kuvzg3Lba3JjAg2mWJXlV3 rOQkd0HU67/M/9oaS89yp9Gf7JTwgttJuCblPErGR9Yx2fyIyNBv64ObuI6hX403hePy 64TNjbMhWNKMJOdC6Y4RPuhbNoWbdXWJ5O/FqezhdrmCWUUexanQo1YONtOIYpx47xOg d2LRIT2ZrruGWyCaSE7LGKnHH9FK5yRtQmoe0KTTMqqB9RxMcVToVrpOndPL4p3F11WV BF/w==
X-Gm-Message-State: APzg51A1gNJrwVG6ENV5vXkGTAsaM/mmPIRprwTZkf3UYEmsxUbu93Vm xAXYi/Rj3v9oQB71WdO6Ln+FRwMKuuMHbZcD8Vo=
X-Google-Smtp-Source: ANB0VdbmFRmAozJaS2rnpf5WzCJuHYlT95OXyEe2HyAngt3BhwqGBNowljhkdiT4rY7cakEPDCxj4iIrR9wceQ2wXQs=
X-Received: by 2002:a81:85c5:: with SMTP id v188-v6mr1874114ywf.126.1535491882830; Tue, 28 Aug 2018 14:31:22 -0700 (PDT)
MIME-Version: 1.0
References: <153542851332.29914.7675736622015606197.idtracker@ietfa.amsl.com> <035D4E56-9A03-48DB-B6C4-E23E61C91221@icann.org>
In-Reply-To: <035D4E56-9A03-48DB-B6C4-E23E61C91221@icann.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 28 Aug 2018 16:31:11 -0500
Message-ID: <CAKKJt-ef-J0fm0L+pBXen=w2UCazMTd9Y-4P8gS5LroGi6pKmA@mail.gmail.com>
To: paul.hoffman@icann.org
Cc: IESG <iesg@ietf.org>, draft-ietf-dnsop-terminology-bis@ietf.org, Suzanne Woolf <suzworldwide@gmail.com>, dnsop-chairs <dnsop-chairs@ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003b54620574859003"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/K6Y6P8LVNZ5EYo7zSpplgTVW7-o>
Subject: Re: [DNSOP] [Ext] Spencer Dawkins' Yes on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)
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 21:31:27 -0000

Hi, Paul,

On Tue, Aug 28, 2018 at 2:52 PM Paul Hoffman <paul.hoffman@icann.org>; wrote:

> On Aug 27, 2018, at 8:55 PM, Spencer Dawkins <
> spencerdawkins.ietf@gmail.com>; wrote:
> > In this text,
> >
> > 2.  Names
> >
> > ...
> >
> >      The common display format is used in applications and free text.
> >      It is the same as the presentation format, but showing the root
> >      label and the "." before it is optional and is rarely done.  For
> >      example, in common display format, a fully-qualified domain name
> >      with two non-root labels is usually shown as "example.tld" instead
> >      of "example.tld.".  Names in the common display format are
> >      normally written such that the directionality of the writing
> >      system presents labels by decreasing distance from the root (so,
> >      in both English and C the root or TLD label in the ordered list is
> >      right-most; but in Arabic it may be left-most, depending on local
> >      conventions).
> >
> > I bet I know what you mean by "C", but I'm guessing. Perhaps it's worth
> > providing a reference, for all the Javascript and Python programmers who
> > skipped over C?
>
> We can change this to "the C programming language". I don't think an
> actual reference is going to help anyone who doesn't recognize the language.
>

That's better than anything I was thinking about (I've been reviewing
drafts for too long. Sorry!)


> > I'm looking at
> >
> >     Administration of names -- Administration is specified by
> >      delegation (see the definition of "delegation" in Section 7).
> >      Policies for administration of the root zone in the global DNS are
> >      determined by the names operational community, which convenes
> >      itself in the Internet Corporation for Assigned Names and Numbers
> >      (ICANN).  The names operational community selects the IANA
> >      Functions Operator for the global DNS root zone.  At the time this
> >      document is published, that operator is Public Technical
> >      Identifiers (PTI).  (See <https://pti.icann.org/> for more
> >      information about PTI operating the IANA Functions.)  The name
> >      servers that serve the root zone are provided by independent root
> >      operators.  Other zones in the global DNS have their own policies
> >      for administration.
> >
> > and wondering what the stability of an ICANN URL that refers to the name
> of the
> > current IANA Functions Operator will be in 5-10 years. I'm not sure what
> else
> > you can do to make that more useful if a different operator is selected,
> but if
> > you can do something, maybe that would be useful.
>
> We already say "At the time this document is published". And it's not like
> documents like RFC 7868 are titled "Cisco's (or Whoever Purchases Them
> Later) Enhanced Interior Gateway Routing Protocol (EIGRP)". :-)
>

Right. Emphasizing that this may not be a solvable problem, my point was
that I can easily imagine that what was once "<https://pti.icann.org/> "
would disappear and something like "<https://tcifo.icann.org/>" would pop
up when The Competing IANA Functions Operator takes over, which is more
drastic, so you get 404 Not Found.

In a perfect world, ICANN would return 301 Moved Permanently, I suppose.
Mumble. Moving on.

> I'm looking at this text:
> >
> >  Passive DNS:  A mechanism to collect DNS data by storing DNS
> >      responses from name servers.  Some of these systems also collect
> >      the DNS queries associated with the responses, although doing so
> >      raises some privacy concerns.
> >
> > and thinking that the problem isn't collecting DNS queries associated
> with
> > responses, it's that it's possible to collect DNS queries associated with
> > responses (so, if one of these systems stops collecting DNS queries, you
> still
> > have an exposure; it's just not happening now). Is that wrong?
>
> Yes. Although this definition was well-discussed in the WG, I can see
> where you missed the salient bit. With RFC 7871, the query gives more
> information about the user making the request than the response does.
>

Yes, exactly. If you guys think you might have readers that don't realize
that, perhaps

 Passive DNS:  A mechanism to collect DNS data by storing DNS
      responses from name servers.  Some of these systems also collect
      the DNS queries associated with the responses, although doing so
      raises some privacy concerns, because the query reveals more
      information about the user making the request than the response does.

would be helpful. Do the right thing, of course.


> > I'm looking at this text:
> >
> >  Privacy-enabling DNS server:  "A DNS server that implements DNS over
> >      TLS [RFC7858] and may optionally implement DNS over DTLS
> >      [RFC8094]."  (Quoted from [RFC8310], Section 2)
> >
> > and seeing a race condition with
> > https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ (which
> isn't
> > news to the authors who contributed to both specifications). Is it worth
> a
> > mention here, given that the DOH draft is already in the RFC Editor
> queue?
>
> As I said earlier, we are hesitant to change direct quotations from other
> RFCs. Those same authors might update the definition in the future.
>

Sure. I wouldn't ask you to change the direct quotation. I noted that the
document does make some comments about how the quote maps onto current
practice.

Do the right thing, of course.


> > In this text,
> >
> >  Closest provable encloser:  "The longest ancestor of a name that can
> >      be proven to exist.  Note that this is only different from the
> >      closest encloser in an Opt-Out zone."  (Quoted from [RFC5155],
> >      Section 1.3)
> >
> > "Opt-Out zone" wasn't familiar to me, but it's defined later in the
> document.
> > Perhaps adding a pointer to Section 10 would be helpful to readers who
> lack
> > clue as I do.
>
> We will add that pointer.
>

Thanks for that, of course.

Spencer

>
> --Paul Hoffman