June 2019 - rssac-caucus - lists.icann.org

RSS Metrics update from ICANN 65
by Wessels, Duane June 28, 2019

June 28, 2019

Caucus Members, There were a number of discussions about the RSS Metrics work party here at ICANN 65 in Marrakech. Some of you may not have been able to participate due to the time zone of the local meeting. When the transcripts and recordings are available we will let you know. Meanwhile I want to let you know about a few discussion topics in particular. There was some spare time on RSSAC's agenda on Tuesday so we took advantage of that to discuss some of the metrics work. Since this was not known in advance, it was not possible for remote work party participants to join the call. One thing we went over in this session was the use of Standard Deviation versus Percentiles to represent precision. I presented some real data from RIPE Atlas probe measurements that demonstrated why percentiles are preferred over standard deviation. This material is attached here as a file named stddev-vs-percentiles.pdf. In the discussion that followed, we reached consensus that percentiles should be used going forward. Next we discussed the "BPQ" section of the document. There is new text here that proposes take real packet capture files and use them to determine the relationship between raw packets and query counts over UDP and TCP. Then these can be applied in reverse by taking RSSAC002 data to calculate bandwidth and packets. On Wednesday we held the scheduled Metrics WP discussion. Here we spent a lot of time talking about "near" versus "far" probes. Near probes are probably better for some metrics (such as correctness) because it reduces or eliminates parts of the network out of the operator's control. That is, the nearer that a probe is to a server, the more likely the response is unchanged. However, near probes may be less desirable for certain metrics, such as latency, especially in the sense that they don't really capture latencies experienced by recursive name servers and end users. Although there was plenty of discussion on this topic, there was no consensus The work party needs to consider this further and make some specific proposals. Our research fellow, John Kristoff, completed some of the work in analyzing RIPE Atlas data and applying it to the proposed metrics. I presented his materials, also attached here. One thing in particular to note here is that these measurements are from RIPE Atlas "Anchors" and show a very wide range of measured latencies for different root servers. We have given John some preliminary feedback and look forward to his future progress. Another topic of discussion was the use of locally operated recursive name server software to implement some of the RSS metrics. After thinking about this, Russ and I feel that this approach has some drawbacks. One is that we may end up measuring the behavior of the recursive software itself, rather than the RSS. For example, the recursive software implementation of retry behavior (timeouts etc) can affect latency results. Also we are concerned that this approach could lead to incomparable results over time as implementations evolve and software is updated. Therefore at this time we recommend removing these alternative approaches from the work party document. I believe those are the highlights. I invite anyone else to chime in with their own observations from the Marrakech meetings. DW

1 0

Call for Presentations: 31st DNS-OARC Workshop, Austin, Texas, Oct 31 - N ov 01 2019
by Shumon Huque June 27, 2019

June 27, 2019

(Apologies to those seeing this notice on multiple mailing lists ..) The 31st DNS-OARC Workshop will take place at the JW Marriott Austin in Austin, Texas, USA on October 31st and November 1st 2019. It is co-located with and will take place right after NANOG 77 (Oct 27th to Oct 30th 2019). The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A time slot will also be available for lightning talks (5-10 minutes each) on day two of the workshop, for which submissions will be accepted just before the start of the workshop and until the start of the morning break on day two. There will be an OARC Business and AGM session during the workshop, which will be for OARC Members only. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 25 Jun 2019 - Submissions open via Indico 16 Aug 2019 - Deadline for submission (midnight CDT) 28 Aug 2019 - Initial Contribution list published 28 Sep 2019 - Full agenda published 18 Oct 2019 - Deadline for slideset submission 31 Oct 2019 - Workshop Details for presentation submission are published here: <https://indico.dns-oarc.net/event/32/call-for-abstracts/> The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Shumon Huque, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)

1 0

How to do analysis of resolvers on the Internet
by Paul Hoffman June 26, 2019

June 26, 2019

The Modern Resolver Behaviours Work Party has two general areas of work: the code bases of DNS resolvers, and the actual resolvers on the Internet. This discussion is about the latter. The two tasks from the Statement of Work: 1. Analyze DNS resolver network traffic and behaviour to better understand how they operate as they interact with authoritative servers generally and the RSS specifically in terms of preferred root server selection. 4. Analyze DNS resolver systems using multiple resolution instances (with potentially individual or shared caching systems) to understand how they interact with the RSS. (e.g. google, cloudflare, quad9 type systems) Currently, these tasks are only being done at a large scale by APNIC. The APNIC resolver test system has three basic parts: - Javascript code that contains unique names - A mechanism to get that Javascript in front of a large number of users - Authoritative servers to receive queries from resolvers and provide customized answers The Javascript code is relatively easy to create. There are many ways to set up the authoritative servers using enough programming and configuration creativity, good logging, and horsepower. The mechanism for getting the Javascript in front of user largely controls the value of the data received from the test system. For its delivery mechanism, APNIC uses the Google Ad network using nearly-free advertising given to APNIC. As part of this plan, APNIC cannot control who will see the ads in the short term, but it appears that Google tries to get a wide dispersion of ads over the longer term. Other delivery mechanisms are possible, such as: - Other advertising networks. These might have wider or at least different user populations, depending on the content of the ads that are prevalent on the networks. - Web properties with international scope. For example, a business that has users throughout the world might be willing to host the Javascript. - Games or other applications with international scope. These would likely be more focused on younger Internet users. There are additional issues such as: - Should a user be prevented from contributing more than once? Even if they move between networks? - How much information is it acceptable to get from the user before we get into the PII realm? - Is it useful to compare "home" users and "office" workers? Or users during "the day" and "at night"? Some of this comes down to if RSSAC wants to just measure resolver behavior versus also measuring the user population behind a resolver. In the former case, the goal of the delivery mechanism is just to get any user behind a resolver to participate, but not to worry about representation. In the latter case, there are more questions about counting the same user multiple times and the locality of users in the delivery mechanism.

1 0

Fwd: [ICANN Community Leaders] March-June 2019 Report from CCWG Internet Governance
by Fred Baker June 20, 2019

June 20, 2019

You may find this interesting if you are in Marrakech on Monday. > Begin forwarded message: > > From: Olivier MJ Crépin-Leblond <ocl(a)gih.com> > Subject: [ICANN Community Leaders] March-June 2019 Report from CCWG Internet Governance > Date: June 18, 2019 at 2:28:41 PM GMT+3 > To: "so-ac-sg-cleaders(a)icann.org" <so-ac-sg-cleaders(a)icann.org> > > Dear Colleagues, > > please be so kind to find attached, the report of the CCWG Internet Governance work since ICANN64 which I have the honour of forwarding to you, thanking Nigel Hickson and Vera Major for its preparation. > > I invite you to let your constituents know about the session we are organising in Marrakesh - the group's F2F session on Monday afternoon (15:15-16:30) where we'll meet with the Board Working Group on Internet Governance (BWG-IG) and will also discuss ways forward relating to the group's future structure as an un-chartered Cross Community Engagement Group. > https://65.schedule.icann.org/meetings/1058290 <https://65.schedule.icann.org/meetings/1058290> > > Kindest regards, > > Olivier MJ Crépin-Leblond > CCWG IG Chair > _______________________________________________ > SO-AC-SG-CLeaders mailing list > SO-AC-SG-CLeaders(a)icann.org > https://mm.icann.org/mailman/listinfo/so-ac-sg-cleaders > > _______________________________________________ > By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

2 1

ICANN65 RSSAC Schedule
by Ozan Sahin June 14, 2019

June 14, 2019

Dear RSSAC Caucus members, The RSSAC schedule for ICANN65 has been finalized. Schedule: https://docs.google.com/spreadsheets/d/1eDWkZ0L2VLIMYtbhgozWZvqCz9ekMAnPe6p… Remote participation details are available from the schedule. Best, Ozan Sahin Community Services Sr. Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Telephone: +90 212 999 6218 Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org<applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org>

1 0

Nomination Period: RSSAC Liaison to the ICANN Nominating Committee
by Ozan Sahin June 14, 2019

June 14, 2019

Dear RSSAC Caucus Members, It is time to begin the selection process for the Outgoing RSSAC Liaison to the ICANN Nominating Committee. Please refer to this page<https://www.icann.org/nomcom2019> for more information about the Nominating Committee. I have also copied below the relevant sections from “RSSAC000v3: Operational Procedures” for your reference. With this notice, a one-month nomination period via this distribution list is now open. Nominations or self-nominations will be accepted and require a second. Nominees must then accept or decline their nomination and may provide a statement with more context for their decision. The nomination period will close at 23:59 UTC on 10 July. The RSSAC will then consider the slate of candidates at its 6 August teleconference. As you may recall, the RSSAC appointed Alejandro Acosta to this role in 2015 and re-appointed him in 2016, 2017, and 2018. As announced during the RSSAC monthly teleconference on 4 June, Alejandro will not be available this time for re-appointment. The RSSAC Co-Chairs appreciate your consideration. Please do not hesitate to contact the RSSAC Co-Chairs or support staff with any questions or concerns. Best, Ozan Sahin on behalf of Fred Baker and Brad Verd RSSAC Co-Chairs 1.2.6.5 Outgoing RSSAC Liaison to the ICANN Nominating Committee The outgoing RSSAC Liaison to the ICANN Nominating Committee is specified in the ICANN Bylaws. The term for the outgoing RSSAC Liaison to the ICANN Nominating Committee shall be one year. A person may only serve for three consecutive terms. The eligibility status for a previous liaison is reset one year after having stepped down. The RSSAC must elect the outgoing RSSAC Liaison to the ICANN Nominating Committee according to the outgoing RSSAC liaisons election procedure (Section 1.2.6.8) from the members of the RSSAC Caucus. The outgoing RSSAC Liaison to the ICANN Nominating Committee acts as a conduit between the RSSAC and the ICANN Nominating Committee reporting on matters that need to be coordinated or communicated between the two bodies. The role requires discretion, management skills, and considerable time commitment. 1.2.6.8 Outgoing RSSAC Liaisons Election Procedure One month prior to each election, qualified nominees will be accepted for the outgoing liaison position and announced on the RSSAC distribution list. During the meeting that includes election of an outgoing liaison position on its announced agenda, additional nominations will be accepted, and all nominees will indicate their intentions: to accept or to decline their nomination. In the event that only one candidate is standing for election, the RSSAC may elect the new outgoing liaison by acclamation. In the event that two or more candidates are standing for election, the presiding Co-Chair will call for a vote. Members will indicate their selection. A simple majority (half plus one) of the voting members will establish the new liaison. In the event a simple majority is not achieved due to having more than two nominees, the nominee with the least number of votes is eliminated and the voting is repeated with the reduced slate of names. The process is repeated until a nominee achieves a simple majority. In the event of a tie, a run-off election will occur with members indicating their selection. In the event of a second tie, the floor will be opened for discussion followed by a new vote with the simple majority designating the new liaison. The Co-Chairs will forward the name of the outgoing liaison-elect to the reciprocating body. If a vacancy exists in an outgoing liaison role, the RSSAC will elect a new outgoing liaison through this process.

18 17

RSS metrics work party topics
by Wessels, Duane June 12, 2019

June 12, 2019

Fellow caucus members: There is an RSS Metrics work party call scheduled for tomorrow. I've been adding to and editing the draft document and wanted to bring a few particular items to your attention before the call. Measurement vs Metric. In the terminology section we have some definitions for Measurement and Metric, and a number of comments about whether or not these are the right definitions. I understand that the definition of Metric may not be perfect, but I feel as though we don't have anything better yet. For now these comments are unresolved and AFAIK their usage throughout the document matches their definitions. RSOs. There were a number of comments about "RSO" versus Root Server, versus other ideas (identity, entry point, etc). In my opinion just "Root Server" is the best choice so far, so I went ahead and changed most occurrences of RSO to Root Server. Measurement Intervals. I spent some time thinking about measurement intervals and also read through the April meeting transcripts. I think there is value in giving all metrics the same measurement intervals. It would be much simpler. Whereas previously some measurements were specified at one minute intervals, I think, and based on the transcripts, five minutes would be fine. I'd like to propose five minutes for most measurements. Aggregation Intervals. On the one hand I think it could be useful to define metrics in such a way that they can be used for any aggregation interval, from hours to days to months. On the other hand, it is simpler to just define consistent aggregation intervals for all metrics. I think one day would make a good aggregation interval for all metrics. PTI Naming Performance Reports. During the April meeting with RSSAC we looked at the PTI performance reports for examples. You can find them at https://www.iana.org/performance/csc-reports. There are some things that I think the PTI reports do very nicely, and I've added some examples of how the RSS metrics might look in the PTI report style. Platform and Probe Locations. Thus far we've been imagining that measurement probes are sort of widely distributed and located on third-party networks. One difficulty with this approach is that third-party networks are perhaps susceptible to interception, spoofing, and so on. Also we've spent some time talking about the difficulty of getting meaningful latency measurements over third-party networks that are out of the operator's control. I would like to have a discussion where we might consider probes located closer to the root servers to eliminate some of those uncertainties. Random Query Names. For some metrics I think we have a need to send queries for non-existent names. At one point I proposed using reserved TLDs (.localhost, .invalid, etc). I also have a proposal to use a randomly generated query name in the form of a single letter followed by some number of digits. See RAND-NXD in the document. DW

2 1

Posting of RSSAC043
by Andrew McConachie June 10, 2019

June 10, 2019

Dear RSSAC Caucus Members, The RSSAC has recently published "RSSAC043: Report from the RSSAC April 2019 Workshop". RSSAC043 can be found here. <https://www.icann.org/en/system/files/files/rssac-043-04jun19-en.pdf> Thanks, Andrew

1 0

RSSAC Meeting Minutes | 25 April 2019 Meeting
by Ozan Sahin June 7, 2019

June 7, 2019

Dear RSSAC Caucus Members, The meeting minutes from 25 April 2019 RSSAC Meeting at April Workshop have been approved during the last RSSAC Teleconference on Tuesday, 4 June 2019. The meeting minutes have been posted on the RSSAC Meetings page https://www.icann.org/resources/pages/rssac-meetings-2014-05-06-en. You may also find the meeting minutes attached to this note. Best, Ozan Sahin Community Services Sr. Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Telephone: +90 212 999 6218 Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org<applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org>

1 0