- rssac-caucus - lists.icann.org

[rssac-caucus] FYI: CDAR Study Cannot Predict Stability of the Root Server System
by Daniel Karrenberg Jan. 26, 2016

Jan. 26, 2016

Fellow Caucus Colleagues, I have a personal request for comments: After some reflection I plan to submit the following comment about the CDAR study. I would appreciate any comments or suggestions you might have. Personal e-mail welcome. Thank you for your time and consideration. Daniel ------ To whom it may concern, The proposed core methodology of the study is a "quantitative model" based on measurement of past behavior of the DNS root server system. Such models of complex systems are by nature simplifications. They are indeed very useful to identify possible instabilities in the real-world system they are modeled after. However these models cannot predict the *absence* of instabilities in the real-world system with any useful level of confidence. In other contexts this is referred to as "Past Performance is Not Necessarily Indicative of Future Results". Our main comment and advice to the researchers is to carefully avoid any perception that their results predict the absence of instabilities unless the results solidly support such claims. Our main comment and advice to ICANN is not to expect the study to predict the absence of instabilities in the DNS root name server system that are wholly or partly caused by root zone expansion. ICANN therefore should make proper contingency plans for the unpredictable cases where root zone expansion causes or contributes to instabilities in the DNS root sever system. Research is most useful and should be called scientific only when it can be verified and possibly reproduced by other researchers and scientists. Therefore we support the researchers intention to base their study on openly available measurement data and meta-data wherever possible. Where this is not feasible the observations and meta-data should at least be available to other researchers under reasonable conditions. Daniel Karrenberg Chief Scientist RIPE NCC, not speaking on behalf of the RIPE NCC Relevant experience: 30+ years of operational experience in DNS; 15+ years of operational experience and responsibility for k.root-servers.net; contributor to DNS software diversity by instigating and helping with design and implementation of NSD 1.0, an authoritative name server; inventor and principal implementor of 'dnsmon', the first comprehensive and public monitoring system for high level DNS servers; co-inventor and responsible for the initial deployment of RIPE Atlas, the active measurement system proposed to be used in the study; ... . ICANN entanglements: member of ICANN RSSAC since its inception and not speaking on behalf of RSSAC either.

1 1

[rssac-caucus] Video: Descarga de productos automática
by Peter Jan. 25, 2016

Jan. 25, 2016

[1]http://aspesite.com/ ASPE's RapidTag puede descargar los productos automáticamente Nuestras máquinas de serigrafía pueden personalizarse: Incluyendo agregar una descarga de productos automática, paletas giratorias para impresión en ambos lados, paletas especializadas para gorras, papel, sudaderas, bolsas, etc. Las posibilidades de personalización son infinitas. [2]http://aspesite.com/auto-unload-custom-screen-printing-machine/ [3]http://aspesite.com/auto-unload-custom-screen-printing-machine/ ASPE's RapidTag se especializa en impresión de etiquetas y otras impresiones pequeñas, como logos y mangas. Nuestras pequeñas máquinas estan hechas para ayudarte a liberar tus máquinas serigraficas grandes y acelerar tu producción. [4]Más sobre descargas [5]Construye la Tuya [6]Retorno de Inversión Tradeshows: Información próximamente [7][Autounload-04_zpsg9vzgyap.png] [8][Autounload-05_zps791aomq0.png] [9][Autounload-06_zpspcyxj2jb.png] INGLÉS - (951).296.2595 ESPAÑOL - (664).134.4759 References 1. http://aspesite.com/ 2. http://aspesite.com/auto-unload-custom-screen-printing-machine/ 3. http://aspesite.com/auto-unload-custom-screen-printing-machine/ 4. http://aspesite.com/automatic-screen-printing-machine/ 5. http://aspesite.com/build-your-custom-screen-printing-machine/ 6. http://aspesite.com/roi/ 7. https://www.facebook.com/pages/ASPE-Printing-Equipment/298253406928915?fref… 8. https://twitter.com/aspesite 9. https://www.youtube.com/user/asperevolution This message was sent by: Peter, peter(a)aspesite.com, ASPE, 42295 Avenida Alvarado Unit 5, Temecula, Ca 92590 Unsubscribe: http://app.icontact.com/icp/mmail-mprofile.pl?r=62295777&l=12026&s=77R3&m=4…

1 0

[rssac-caucus] (no subject)
by abby pan Jan. 18, 2016

Jan. 18, 2016

-- Best Regards Pan Lanlan

1 0

[rssac-caucus] Inaccuracy in K-root's RSSAC002 load-time metric
by Anand Buddhdev Jan. 14, 2016

Jan. 14, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear RSSAC caucus, We have recently discovered that K-root's "load-time" metric hasn't been properly calculated since we started publishing our RSSAC002 stats. The cause of this was that some of our servers running Knot DNS didn't log a successful root zone IXFR properly, and so the script that parses the log file didn't see a successful root zone transfer. The effect of this is that the average time we report in the "load-time" metric for K-root didn't include numbers from these servers. Our "load-time" metric is therefore slightly inaccurate. However, I'd like to add that since this value is an average across our entire cluster, I don't expect the value to be wildly inaccurate. I got a patch from CZNIC for this bug, and Knot 1.6.7 and newer will log consistently. I've also applied a patch to our existing 1.6.6 servers, so that our stats should be more accurate from now on. Regards, Anand Buddhdev RIPE NCC -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWl6w4AAoJEBXgoyUMySoFjTYQAIF5ePbsto4yYf9UPiSiwc+7 11VlMp2q5EpLE9j15n2Kcxn7OKXQ36uyBlNc4AVUnHsAuiETXVP2jRe7aoA4f+sc diFdehpnhWH94+XB8IE3Sesp82PMdCmVHWdOIDgh4f33G1d8JaanJBkaJLO2ViwI K4TctunMn2tNXVpcnjyolOyns73MDwg+6N4CXIjG66K4tgr8ZYEW8loOoQoJOZvz xG9Iwx84/pqtV2/Ru+/0MS7+9i0dTMLvgD2SJtOWVyVdmGJwEFosjK/NaAvYhbXP gki9gx1Jz/WVLZ+Gm92/iy/BnKPp9p+z9n/vZz2Q1YuV7YZR4IcVt7tLcWI6vQFU 76wbkrVxZyDYmWWfMkb+6Oi/H9a8gsq6zl/HQjUKnGwEioz5ec1QbrbdC6w47VtS /4AjwS22A3cm+siupcbt6zftIkoUFaMcaTgfy/lfbFLid/pvvugnS17p36TBs3pa DVA01W+B9P+ShvqPVUhzY3Q6q0ns0wxFDKBpq17L7i5+fQb4hvkzubHQS75QFRy3 r3wIlmp5ufMUGii1kuy1cSAZZx1qYY6i43I8HJ3QV2anaUP1lHMsvy1UM/cN8x39 iw8d07+H5CYMTb8tVboA09b0aIKX/FAiYBJrZqTyqpZu30C5QVjXoZb0ZaJ1H3uo yk/B5hoDGPuvXWUEtvHe =Xj+c -----END PGP SIGNATURE-----

1 0

[rssac-caucus] rssac-002 rcode distribution and traffic volume
by Roy Arends Jan. 13, 2016

Jan. 13, 2016

Hi, Section 2.5 reads "The RCODE distribution is a raw count of the RCODE values observed in responses during the reporting period.” This single sentence is ambiguous, since it is interpreted in two ways. Either it includes responses received, or it doesn’t. That needs to be clarified, otherwise the numbers are meaningless as they can’t be compared. Section 4.3 has a similar ambiguity. Does “responses-sent” mean sent by the root server, or sent by something else, and observed by the root server. Warm regards and happy new year! Roy

3 3

[rssac-caucus] Welcome, Suresh!
by Carlos Reyes Jan. 11, 2016

Jan. 11, 2016

Dear RSSAC Caucus, I hope you are well. At the recommendation of the Membership Committee, the RSSAC approved Suresh Krishnaswamy to join the Caucus. His statement of interest can be found here <https://community.icann.org/x/orzhAg> , and he has been added to the mailing list. Please join me in welcoming him. Best, Carlos Carlos Reyes | Policy Specialist carlos.reyes(a)icann.org | +1 (202) 802-8019 ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006

1 0

[rssac-caucus] Presentations on the Continous Data-driven Analysis of Root Server System Stability
by Steve Sheng Jan. 11, 2016

Jan. 11, 2016

Dear RSSAC Caucus, As part of the review of new gTLD program for its security and stability impacts, ICANN recently contracted a study consortium led by TNO (includes SIDN and NLnet Labs) to conduct the continuous data-driven analysis of root server system. TNO recently gave RSSAC a briefing on its study plan and requested some input. Attached please find their presentation slides. If you have any feedback to this study (including the hypothesis) or have data to contribute, please let RSSAC or TNO know. Best, Steve

1 0

[rssac-caucus] Welcome New Member
by Carlos Reyes Dec. 11, 2015

Dec. 11, 2015

Dear RSSAC Caucus, At its meeting on 3 December, the RSSAC approved the Membership Committee's recommendation of a new Caucus member: * Rao Naveed Bin Rais He has been added to this mailing list and is now listed as a Caucus member <https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en> . For you reference, his statements of interest <https://community.icann.org/x/orzhAg> has also been published. Please join me in welcoming him to the Caucus! Best, Carlos Carlos Reyes | Policy Specialist carlos.reyes(a)icann.org | +1 (202) 802-8019 ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006

4 3

[rssac-caucus] RSSAC-001 and RFC 7720 (a.k.a. 2870bis) are now published.
by Lars-Johan Liman Dec. 11, 2015

Dec. 11, 2015

Hi! This is just to inform you that the long overdue* documents above are now fully published and can be obtained at the links below for your reading pleasure. RFC 7720 has inherited the BCP status from 2870, and is now BCP 40. My warmest thanks to all who helped developing and preparing the documents, which also includes our staff support. The documents can be found here: http://www.rfc-editor.org/info/rfc7720 https://www.icann.org/resources/pages/rssac-publications-2014-05-12-en Best regards, /Liman * due to your chair's inherent incapability to push them over the edge

1 0

[rssac-caucus] FOR REVIEW: DRAFT RSSAC002 Version 2
by Steve Sheng Dec. 4, 2015

Dec. 4, 2015

Dear RSSAC Caucus, Attached please find RSSAC002 version 2 for your review. In this version, we made the following changes based on the RSSAC caucus discussions led by Duane: * Section 2.2 (The size of the overall root zone) was amended to clarify that TCP size prefix octets are not included in the metric. * Section 2.4 (The query and response size distribution) was amended to clarify that TCP size prefix octets are not included in these metrics. * Section 2.4 was amended to include 0-15 in size ranges to be tabulated. * Superfluous quotes around YAML keys were removed from example YAML in sections 4.1 (The ‘load-time’ Metric) and 4.2 (The ‘zone-size’ Metric). * Indentation was fixed for example YAML in sections 4.3 (The ‘traffic-volume’ Metric) and 4.6 (The ‘unique-sources’ Metric). * Section 4.5 (The ‘rcode-volume’ Metric) was amended to clarify that nonzero counts should be omitted. In addition, we made the following organizational changes: * Make this document RSSAC002 version 2 * Added a Revision History section (see section 7). Attached please find the redline, clean word and PDF version. Since the proposed revisions have already been discussed and agreed on the caucus list, we will give this update a 7 day additional review period. Please provide your feedback, if any, no later than 23 November 2015. After that, this document will be sent to RSSAC for formal action. Best, Steve

10 17