[rssac-caucus] [Ext] Second round review on "Technical Analysis of the Naming Scheme Used For Individual Root Servers"

[Davey Song]

The addtional round-trip delay was mentioned 3 times and is listed as a
concerns in table of section 6. My argument is that it is not a big
concern, because the priming query is rare and the delay is
trivial compared to the concern of fragmentation or other complexity. I
think people go too far to avoid multiple queries and struggle with packet
size limitation.

An additional recommandation on this may be not necessary,  but we can
leave a note somewhere to lower the concern on addtional round-trip delay
by multiple queries after priming, if my suggestion is accepted.

Davey

On 5 May 2017 at 23:19, Paul Hoffman <paul.hoffman at icann.org> wrote:

> On May 5, 2017, at 1:17 AM, Davey Song <songlinjian at gmail.com> wrote:
> > * Regarding the fragmentation, the concern can be relieved by optionally
> excluding partially or all glues in the additional section at the cost of
> increasing the round-trip delay. IMHO, the round-trip delay or additional
> queries for priming or DNSSEC priming is not a big issue because priming
> query is quite rare and only emitted when resolver bootstraps itself.
> >
> > * In section 5.5 "Names Delegated to Each Operator", the additional
> section of the priming response may not return all A and AAAA glue. It
> depends on the DNS implementations. AFAIK, Bind9 only returns the A and
> AAAA glue of responding root server. It is in that If the zones hosted  by
> root server A is not authoritative for the name of root server B, the
> additional section of priming response from A will not include the glue of
> B. It is exactly the case in Yeti DNS Project where normal domain name is
> used as the name of root server. I think it is also true for
> "a.root-servers" and the case of  short label  "a".
> >
> > * In addition, #5.5 makes it possible to incrementally deploy DNSSEC
> support for individual root names. The DNSSEC deployment overhead is
> durable I think if you intend to ask for multiple participants to run the
> root system. In contrary, it introduces diversity to the system.
>
> These all seem like topics for the next round of study.
>
> > * If possbile, i would like to make a recommandation on : Study the
> impact of additional queries after priming exchange. It is possible that by
> adding addtional queries, it will make it easier to balance the priming
> performance and response size limitation.
>
> Can you say more about "impact"? Impact for whom?
>
> --Paul Hoffman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20170508/c8d46ff0/attachment.html>