Note that I believe we did create a mailing list for this WP, we've since agreed that all WP mail should be conducted on the global caucus list and we shouldn't use the WP specific mailing lists. On Wed, Dec 19, 2018 at 11:22 AM Mario Aleman <mario.aleman@icann.org> wrote:
Hi Fred,
Let me know follow up with Davey Song and the procedure to add him to the WP mailing list.
Best,
--- Mario A. Aleman Support Staff for RSSAC and RZERC Internet Corporation for Assigned Names and Numbers (ICANN)
Mobile: +1 612-245-7112 www.icann.org <http://www.icann.org>
On 12/19/18, 4:10 AM, "Fred Baker" <fredbakersba@gmail.com> wrote:
Mario, would you kindly add Davey to the Work Party mailer?
> On Dec 19, 2018, at 4:39 PM, Davey Song <songlinjian@gmail.com> wrote: > > I'm sorry and I missed last call for Resolver Study Work Party. I'm wondering is there any open document or preliminary result of this work party? I'm personally intereted in the resolver behavior on timeout and re-query. Can anyone give me some hint?
The SOW is at https://www.icann.org/en/system/files/files/rssac-sow-resolver-behaviors-07a.... We have "met", for some definition of that term, three times. The current progress is that:
Paul Hoffman (ICANN) is building a testbed with the intention of facilitating replication, on the theory that science benefits when an experiment can be reproduced with the same or different results. He will be discussing that at our January meeting.
Geoff Huston and Joao Damas are doing work at APNIC. I'm not sure what their schedule is, but they have discussed similarly documenting the means and logic behind their experiments. The experiments they carry out use a basic facility used by George Michelson and others at APNIC, which is "advertisements" carried by Google and others. It might be most easily explained using an example.
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=BE is derived from APNIC data. The advertisement, in this case, contains three URLs, which means that a client resolves three names and opens three TCP sessions. One name has only an A record, so the TCP session uses IPv4. The second name has only a AAAA record, so the TCP session uses IPv6. The third name has both an A and a AAAA record, and it can be interesting to observe which one it chooses. The first TCP session informs the experiment that a client is out there. The second, if its SYN arrives, tells the experiment that the path from client to server is IPv6-capable end to end, and the data shows the blue line indicating that there is a client out there that can possibly use IPv6. The third indicates a choice, and if the client chooses the AAAA record, the experiment reports that the client *prefers* IPv6. Now look at the web page.
Geoff uses a similar mechanism but performs different experiments. Since he is running the resolver and the system the TCP sessions connect to, he can make a number of observations about clients and resolvers, and draws conclusions from them. He'll have to describe anything further (and that's what the Work Party is asking him or Joao to document for the call in January), but that gives you a flavor of what's going on.
I have attached the information about the next call.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Wes Hardaker USC/ISI