At Mon, 29 Feb 2016 16:54:28 +0000,
Warren Kumari <war...@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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to