January 2016 - rssac-caucus

[rssac-caucus] RSSAC002v2 published; future work items
by Wessels, Duane Jan. 26, 2016

Jan. 26, 2016

Dear Caucus members, As you may know, the RSSAC002v2 document was published a couple of weeks ago. That document can be found at https://www.icann.org/en/system/files/files/rssac-002-measurements-root-07j… I've been trying to keep a list of all the other proposed changes that people have mentioned while we were working on and waiting for v2 to be published. My notes are below. Please let me know if I've missed anything. I'd like to suggest that RSSAC establish a work party to tackle some of these issues and come up with v3 of the document. Unless anyone is opposed to that idea I will propose it at the next call. DW ======================================================================== - more realistic YAML examples (Akkerhuis) Steve Sheng has already updated the master copy of the document with real examples from A-root. - zone-size metric. Is this metric worth the trouble? It is somewhat difficult to define. Every operator that reports this is measuring it "out of band" because measuring it "in band" is all but impossible. All letters report the same value for this metric which leads to wasted effort. - load-time (Crabill, Kash) This could be clarified with respect to large number of instances - Are there additional metrics to consider? (Crabill) - publication-time (Kash, Akkerhuis) is this still true?: "There are current DNS software logging limitations that inhibit the perfect collection and resolution of latency in publishing available data values due to the lack of zone serial numbers in AXFR/IXFR logging statements. " For NSD this is fixed starting with version 4.12, since 4.1.4 it will now also be logged at a less verbose log level (on request of Anand Buddhdev, Ripe-NCC). - RCODE distribution (Roy Arends) 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 doesnt. That needs to be clarified, otherwise the numbers are meaningless as they cant 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. - RCODE distrubtion (Ondrej Sury) I would move the text from 4.5 (or add short note) about extended RCODEs to 2.5. - traffic-volume (Ray Bellis) descriptive text in section 2.3 doesn't talk about responses. it is titled "The number of queries" The stated rationale (measuring increasing loads over time) doesn't need response volumes, and in the presence of RRL it's not a useful proxy measurement for the reliability of a server either.

1 0

[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