Re: [DNSOP] Updated cheese-shop.

神明達哉 <jinmei@wide.ad.jp> Mon, 29 February 2016 18:50 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402E21B39E6 for <dnsop@ietfa.amsl.com>; Mon, 29 Feb 2016 10:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level:
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 b6cf_9a8F5nU for <dnsop@ietfa.amsl.com>; Mon, 29 Feb 2016 10:50:03 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 BD2871B39EA for <dnsop@ietf.org>; Mon, 29 Feb 2016 10:50:03 -0800 (PST)
Received: by mail-ig0-x230.google.com with SMTP id g6so2353331igt.1 for <dnsop@ietf.org>; Mon, 29 Feb 2016 10:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=XN6pSCHpKfWYwxCJNMNeZd9Pl0Q+Y7VxaeCS7BoTyQE=; b=J3zIu5xd3JEMbLWm8Ybo+8GN89T7Tc3Q4K0wzHtpAdW6xh4N+K5rKT4Fd4v77Ka25X ra+ylJ/dhLhkRMwKJX+7XjgQMfdTQm3Ejo3SZ7IXVniAHley3mAwz+noll+m752l0r6e KHFaD56fvnj6LO3NcQSgJjXUIzczi7T8gicLJxUTlLrRCWXxqCszHFIdAyNE+++XNgtP Er3nwHg1mfJLCnn1jetdLnBtxYtuYQ9s/eE6sz8P0aqaiNq3iT1a42wNorHhVXsobfGf HkSJ47XynQCp82WPzncZDwDTtmnpfThK0KRrNm/fkTozEoRpyU7Vb6mRAFkAaZWMhM9k QtJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XN6pSCHpKfWYwxCJNMNeZd9Pl0Q+Y7VxaeCS7BoTyQE=; b=en12EWVZ64PaT26r4xy3fz8ySl9lB2eaBToaecQA9mucwvr6wMkjCTFAZuyVYq+8YW jgOwZSsInvKjTjXOie0Mko6CyJtMO+5f4RyVZC9zVFTxX+Kklm26aWZWrjp0fX8A/c30 t/tlHM1scsKCnxhZNu0a2enDMOsOP3hTXaXRJxXHK26gBSytcB2cck6KHf5WS2oN1rSw qz+bqEyzSptFTOg49w937g41fiL39CAgtyOwMYqXItsSG7IG0QrqIXPlXRd8KXudF4lb 1jcOAr0Cw7X1W4+95zMmpHi4B8buzpfS4Z/3UzU94tXVAH+0NVGYXjl+lrXkhWZek+Us vhaw==
X-Gm-Message-State: AD7BkJIrjQJNyRvhUk/gtXJSUU7foVl+dkIwQv1yng0mhxzkqBmM14dkCQwQCJsqB1kzb9IaMpaKN+BU+HaYog==
MIME-Version: 1.0
X-Received: by 10.50.97.71 with SMTP id dy7mr11782380igb.78.1456771803019; Mon, 29 Feb 2016 10:50:03 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.35 with HTTP; Mon, 29 Feb 2016 10:50:02 -0800 (PST)
In-Reply-To: <CAHw9_iJWRifZZh22LzbZSBXj9dEiZO=Qn-G24XFyd4gJ-8SBQQ@mail.gmail.com>
References: <CAHw9_i+qiU+rMcPHfv=EnogiwuMJzoaTi8a_KUWSepbLd7j6ug@mail.gmail.com> <CAJE_bqc2Uf+g9vV4a3jiMT03C7O7EJ+=PvQzQ7_3dnWRJdKD8Q@mail.gmail.com> <CAHw9_iJWRifZZh22LzbZSBXj9dEiZO=Qn-G24XFyd4gJ-8SBQQ@mail.gmail.com>
Date: Mon, 29 Feb 2016 10:50:02 -0800
X-Google-Sender-Auth: rl3MlGpUrr2MxMUeU1FbfB5z_gc
Message-ID: <CAJE_bqdy2Nw_g9BNX5KFfx3UnA+9SdQ19Kj9-pq7edeABn8Hgw@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Warren Kumari <warren@kumari.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/EAIuGVcaglYCYlRT6LkbapMsTs4>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Updated cheese-shop.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 29 Feb 2016 18:50:05 -0000

At Mon, 29 Feb 2016 16:54:28 +0000,
Warren Kumari <warren@kumari.net> wrote:

> > - Section 1
> >
> >    The title of this draft comes from a famous Monty Python skit - "The
> >    Cheese Shop".  There are some useful parallels between this problem
> >    and the skit - watching the skit is encouraged to understand the
> >    problem - https://www.youtube.com/watch?v=cWDdd5KKhts
> >
> >   I know I'm in the minority group, but I'd suggest not making it too
> >   cool for documents supposed to be read and understood by people who
> >   may not necessarily have particular cultural background.
[...]
> >   Specifically, I suggest renaming the file name to, e.g.:
> >   draft-wkumari-dnsop-nsec-aggressiveuse-for-root
> >
> I have requested that the RFC editor remove this section before
> publication.
>
> I have also changed "title" to "filename" and summarized /
> made explicit the parallels. I *think* that this vide does help illustrate
> the issue, but fully get that it is culturally specific (and, many folk
> from the culture where it was created dislike Monty Python :-)) - if this
> still irritates, I'll remove it.

Personally, I still don't see why we just don't rename the file and
remove the note.  It will be the best way to avoid future confusion
for first-time readers of the draft or dnsop subscribers who first
see discussions titled like "Updated cheese-shop".  They will
eventually reach the note and understand it, but what's the point of
that hassle?  Some of them might even skip the discussion or reading
the draft because of the cryptic jargon.

That actually almost happened to me this time.  But, it won't be an
issue for myself (until I forget the context and take the same
memory-refreshing process), and since it now seems clearer that the
note will be removed in the final publication, I wouldn't strongly
argue for that.  If we keep the title and the note, my only favor to
ask is to avoid using the jargon in discussions including email
subjects.

> > - Section 3
> >
> >    [...] - and this is true whether or not this is
> >    implemented (if someone had queried for the exact name, there would
> >    be a negatively cached answer, this simply expands the range of
> >    negative caches).
> >
> >   I think the discussion here should be more careful.  Assume the NSEC
> >   or NXDOMAIN TTL of 1 day, in the following scenario:
> >   - Jan 1 0:00 a resolver queries for .belkin and gets response with
> >      NXDOMAIN+NSEC
> >   - Jan 1 0:01 .beeswax is added to the root (and this fact is widely
> >     published, starting to trigger queries for the name)
> >   - Jan 1 0:02 a resolver gets a query from a client for .beeswax
> >
>   Before this technique is used, the query will succeed at 0:02.  But
> >   if the resolver uses the described technique, it will have to wait
> >   until Jan 2 0:00.  Even if the worst case waiting period is the
> >   same, it may be a bit naive to ignore this difference.  I'm not
> >   necessarily opposed to the conclusion itself (again, I don't have a
> >   particular opinion on the proposal itself, for now), but I'd like to
> >   see some more considerations on the effect.
>
> I would really appreciate some text on this - I fully agree that the
> current text is sucky.
> What I was trying (but poorly) to say is that, it is *likely* that at 0:00
> someone will already have queried for .beeswax, and so it is likely that
> many caches will have the (exact match) NXDOMAIN already cached (it would
> be tricky to publish something widely just after the name actually hits the
> root, but not have people query for it before hand). This is a *very*
> hand-wavy argument, and perhaps I should just delete the whole paragraph?

I wouldn't necessarily argue for removing it.  I just wanted it to
come with more careful considerations.  Clarifying assumptions like
you explained may help, for example.  If it can be backed with some
actual traffic analysis or something, that would be even better.

--
JINMEI, Tatuya