- rssac-caucus - lists.icann.org

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

[RSS Metrics WP] Outline/initial draft of report
by Steve Sheng May 24, 2019

May 24, 2019

Dear RSS Metrics WP, Following the last WP meeting and the extended WP discussion at RSSAC workshop, the co-chairs with staff put together a outline/initial draft of the report. The Co-chairs would like to request you read the outline/initial draft ahead of the next RSS Metrics WP meeting. Please also feel free to provide comments on the document directly. https://docs.google.com/document/d/1vC2OTSOdWKjmUQanYx4ZlUGnu-5npwvJzRRSFg1… Best Steve

1 0

Posting of RSSAC042
by Andrew McConachie May 17, 2019

May 17, 2019

Dear RSSAC Caucus Members, The RSSAC has recently published "RSSAC042: RSSAC Statement on Root Server Operator Independence". RSSAC042 can be found here. <https://www.icann.org/en/system/files/files/rssac-042-17may19-en.pdf> Thanks, Andrew

1 0

Six New RSSAC Caucus Members
by Carlos Reyes May 15, 2019

May 15, 2019

Dear all, The RSSAC recently adopted the recommendation of the RSSAC Caucus Membership Committee to appoint six new RSSAC Caucus members: Mohamed Abuabed Jack Biesiadecki Paul Ebersman Dmitrii Kovalenko Willem Toorop Mauricio Vergara Ereche They have been subscribed to this mailing list and their statements of interest are available here: https://community.icann.org/display/RSI/RSSAC+Caucus+Statements+of+Interest Please join me in welcoming them. Best, Carlos Carlos Reyes Strategic Policy Planning Director Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 202 802 8019 Skype: carlos.reyes.icann www.icann.org

1 0