[rssac-caucus] NSID support on the root-servers

[John Heidemann]

On Tue, 18 Oct 2016 06:58:01 +0200, =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= wrote: 
>John,
>
>----- Original Message -----
>> From: "John Heidemann" <johnh at isi.edu>
>> To: "Warren Kumari" <warren at kumari.net>
>> Cc: "rssac-caucus" <rssac-caucus at icann.org>
>> Sent: Tuesday, 18 October, 2016 01:47:35
>> Subject: Re: [rssac-caucus] NSID support on the root-servers
>
>[...]
>
>> But I was trying to figure out if the method matters (NSID vs CH TXT).
>> Is there any practical technical advantage NSID has over CH TXT.
>> (Context: to determine if we should have NSID for the anycast latency
>> work I described at DNS-OARC.)
>> 
>> Suzanne Woolf suggested that NSID wins because you can BOTH answer
>> another query (say, SOA) AND find out the server that replied to you.
>> This statement *is* in the abstract of rfc-5001, but because it doesn't
>> say why CH TXT cannot do provide query reply and site in one bundle,
>> it's easy to miss.
>> 
>> For mapping catchments, though, this advantage doesn't matter at all.
>> The only information you want is the site; you have no other query to
>> make.
>
>No, the strong reason for NSID is exactly what you said in previous
>argument.  You want to know how the particular instance of DNS server
>replied to you.  Consecutive queries with f.e. "IN SOA" and "CH TXT"
>doesn't guarantee you that due to the nature of anycast routing.

I get it, for people want some other record AND what server it came
from.

My point was that there are some problems that don't need both.

>> And, at least for now, a practical argument against NSID is that it is
>> not supported  across all Root Letters.
>
>I don't agree, that's a practical argument to _get_ it supported
>across all Root letters.

My statement was unclear.  I meant, a practical argument against NSID
for catchment mapping is incomplete support.

>
>> (* Caveat: Let's just stipulate that NSID is attractive is because it is
>> the New Hotness, and clearly CH TXT is Old And Busted.  And least as
>> evidenced by the larger RFC number and absence of an
>> implementation-specific qname.)
>
>"New Hotness" as in 9+ years?  I understand a certain conservatism
>across root servers deployment, but at the same time the Root servers
>should be a "showcase" of DNS technology.  And it's 9+ years (August 2007)
>since NSID become RFC.

Sorry if not clear, the text in the caveat was partly a movie reference.

What I meant by that paragraph was: yes, I agree that NSID is The Right
Thing and in principle should be more widely supported.  I'm not opposed
to RSSAC taking that question on.

(Oh, and by the way, while we're talking about who should support it if
you want it to superseed CH TXT, one might want to appraoch RIPE Atlas
to start collecting it as a standard dataset.)

The overall point of my message was that I wanted to understand what the
technical advantage of NSID was. For the
subproblem where one's only goal is that a RIPE Atlas probe finds its
catchement, I don't see that it has any technical advantage over CH TXT.

But I think we both agree on its advantage when wants a query AND the
site.  And I think we both agree that NSID is a good thing and should be
more widely supported.

   -John