- rssac-caucus - lists.icann.org

Re: [rssac-caucus] FOR REVIEW: DRAFT RSSAC002 Version 2
by Kash, Howard M CIV USARMY RDECOM ARL (US) Nov. 19, 2015

Nov. 19, 2015

> > Section 2.1, second paragraph - "may present as anomalies in measurements", > > perhaps change to "may introduce anomalies"? > > How would you feel about "may appear as anomalies"? To me "introduce" > sounds just a little too much like blaming anycast for causing a problem. Or > maybe since this is the same section as the above item, it will likely all > get rewritten in v3 so we save it until then? Either is fine, or "may be present as anomalies", or "may present anomalies". The phrase "present as anomalies" just doesn't parse for me. Howard

1 0

[rssac-caucus] On versioning our documents
by Paul Hoffman Nov. 17, 2015

Nov. 17, 2015

Greetings. This might sound really weenie, but it turns out to be important in the long run. I propose that from now on, we alway publish our documents as "RSSAC 0xx version 1". It is impossible to predict when will or will not need a version 2 (and beyond). If someone says "see RSSAC 0xx", that should always mean "the highest version number of 0xx", not "exactly the one numbered 0xx". The issues in 002 version 2 are not that big but NIST (the US government standards department that creates cryptographic standards) has had *huge* headaches when they have published revisions because Google still refers to the base version, not the most recent one. --Paul Hoffman

3 2

[rssac-caucus] Welcome Two New Members
by Carlos Reyes Nov. 16, 2015

Nov. 16, 2015

Dear RSSAC Caucus, At its meetings on 12 November, the RSSAC approved the Membership Committee's recommendation of two new Caucus members: * Roy Arends * Ondrej Sury They have been added to this mailing list and are now listed as Caucus members <https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en> . For you reference, their statements of interest <https://community.icann.org/x/orzhAg> have also been published. Please join me in welcoming them 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

1 0

[rssac-caucus] Revised proposal for updating RSSAC-002
by Wessels, Duane Nov. 12, 2015

Nov. 12, 2015

The RSSAC Caucus met about a week ago in Yokohama. During that meeting we discussed some proposed edits to RSSAC-002. I had written previously about this with a proposal to include TCP's extra two octets in the size calculations. However, in Yokohama we came to agreement that the two octets should be excluded. I was tasked with submitting a revised proposal for RSSAC-002 updates. Additionally, around the same time, Bruce Crabill sent a message to the list with some additional points of clarification based on his implementation experience. In my revised proposal below I'm also including three items that Bruce raised. If the Caucus agrees with the proposed remedies below I would be happy to present them at the next RSSAC exec call (Thursday Nov 12). DW -------------------------------------------------------------------------------------------------------- Six editorial/clarification problems have been identified in the RSSAC-002 document published November 20, 2014. #1 YAML Indentation =================== Problem: In sections 4.3 (traffic-volume) and 4.6 (unique-sources) the example YAML shows some lines indented when they should not be. In these YAML documents none of the lines should be indented. If they are indented as given in the example, a YAML parser generates an error and fails to load the document. Proposed Remedy: Remove indentation from the example YAML documents in sections 4.3 and 4.6. #2 TCP Response Size ==================== Problem: Section 2.4 describes the query and response size distributions. The description does not specifically mention the two-octet prefix for TCP messages, which leads to ambiguity. While the difference is not especially significant (i.e. two octets out of 50-500), the ambiguity should be removed. The text currently says: DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. Proposed Remedy: Insert the following new paragraph immediately following the paragraph quoted above: A DNS message carried over TCP is prefixed with a 16-bit (two octet) value indicating the size of the message. Implementations should exclude these two octets in the calculation of message size. [The RSSAC Caucus debated whether or not to include these two octets in the size calculation. While some argued for its inclusion and others argued for its exclusion, there was strong agreement that consistency is more important than whether or not to count the two extra octets. In the end the Caucus agreed to exclude the size prefix.] The bracketed text could either be written as a footnote or remain in the document body (without brackets). #3 Zone Size Metric =================== Problem: Section 2.2 describes how to calculate the zone size as a wire-format AXFR response. Since AXFR happens only over TCP, those DNS messages also have a two-octet length prefix. The description is unclear whether or not to include the two-octet length prefix in the reported value. Proposed Remedy: Amend the paragraph in section 2.2 to read: The size of the compiled root zone is measured in wire-format AXFR response encoded as if to be transmitted in the smallest number of messages with the names in the zone and the resource records in each RRset sorted into DNSSEC order, and using compression pointers wherever possible. Note that since AXFR occurs over TCP, this measurement must exclude the two-octet size prefix for each message transmitted. #4 Size List Values omit 0-15 ============================= Problem: Section 2.4 describes the query and response size distributions and specifies a list of size ranges. The size range lists begin with 16-31, perhaps under the assumption that 16 octets is the smallest valid DNS message. However, a DNS message with a header only and no RRs is smaller than 16 octets and such have been observed in production traffic. Proposed Remedy: Include 0-15 in the two size lists given for query and response sizes. #5 Quotes Around YAML Keys ========================== Problem: The example YAML documents for load-time (section 4.1) and zone-size (section 4.2) include single quotes around the indented key values. For example: time: '2013082600': 6 '2013082601': 6 These quotes are unnecessary, but accepted by known YAML parsers. The quotes would likely not be generated in the output produced by a YAML library. Proposed Remedy: Remove the single quotes from YAML keys in sections 4.1 and 4.2. #6 'traffic-sizes' format silent on excluding 0 counts ====================================================== Problem: Section 4.5 (rcode-volume) states: Only RCODEs with nonzero counts shall be listed. Section 4.4 (traffic-volume) similarly describes a long list of size values, but does not state that keys with count of zero should be omitted. Proposed Remedy: The following sentence should be added to the paragraph describing traffic-sizes in section 4.4: Only size ranges with nonzero counts shall be listed.

2 2

[rssac-caucus] Opening RSSAC-002 for revision
by Wessels, Duane Nov. 2, 2015

Nov. 2, 2015

Dear RSSAC Caucus, RSSAC has decided to open the RSSAC-002 "Measurements of the Root Server System" document for revision and is asking the Caucus to produce an update. Based on implementation experience, three minor problems have been identified in the current document. It is my belief that these problems and remedies are simple enough that a work party is not warranted. I'd like to ask the Caucus to consider my descriptions of the problems and proposed remedies below as a starting point for this discussion. If we can come to a consensus by RSSAC's December 3 meeting then it is likely the revised document can be approved and published shortly after that. Duane W. #1 YAML Indentation =================== Problem: In sections 4.3 (traffic-volume) and 4.6 (unique-sources) the example YAML shows some lines indented when they should not be. In these YAML documents none of the lines should be indented. If they are indented as given in the example, a YAML parser generates an error and fails to load the document. Proposed Remedy: Remove indentation from the example YAML documents in sections 4.3 and 4.6. #2 TCP Response Size ==================== Problem: Section 2.4 describes the query and response size distributions. The description does not specifically mention the two-octet prefix for TCP messages, which leads to ambiguity. While the difference is not especially significant (i.e. two octets out of 50-500), the ambiguity should be removed. The text currently says: DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. Proposed Remedy: Amend the paragraph above to read: DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. For TCP the DNS payload also includes a two-octet size prefix. Implementations should include these two octets in the calculation of message size. #3 Zone Size Metric =================== Problem: Section 2.2 describes how to calculate the zone size as a wire-format AXFR response. Since AXFR happens only over TCP, those DNS messages also have a two-octet length prefix. The description is unclear whether or not to include the two-octet length prefix in the reported value. Proposed Remedy: Amend the paragraph in section 2.2 to read: The size of the compiled root zone is measured in wire-format AXFR response encoded as if to be transmitted in the smallest number of messages with the names in the zone and the resource records in each RRset sorted into DNSSEC order, and using compression pointers wherever possible. Note that since AXFR occurs over TCP, this measurement must also include the two-octet size prefix for each message transmitted.

8 21

[rssac-caucus] RSSAC Caucus Meeting at IETF94
by Carlos Reyes Oct. 31, 2015

Oct. 31, 2015

Dear All, The RSSAC Caucus Meeting at IETF94 is scheduled for: Sunday, 1 November 2015 06:30 UTC / 15:30 JST (Yokohama, Japan) For other times: http://tinyurl.com/p578rje Pacifico Yokohama Rooms 414 / 415 REMOTE PARTICIPATION Adobe Connect: http://icann.adobeconnect.com/rssac Verizon Bridge: +1 (866) 780-9216 (Dial-in numbers for other countries listed below) Participant Passcode: 2111690 DRAFT AGENDA 0. Welcome and introductions 1. a discussion on updating RSSAC002 2. an update / feedback on the root-servers.net work party 3. a discussion on identifying server instances, documenting which operators use what methods for such identification 4. process for document errata 5. Creating a testbed to measure root server conformance to RSSAC001(Service Expectations) and RFC2870bis (Protocol Requirements) 6. Open Discussion - next meeting for the Caucus - How could RSSAC improve its relationship and interaction with the Caucus 7. Adjournment Country Local/Toll Number Toll Free Number ARGENTINA 0800-777-0487 AUSTRALIA ADELAIDE: 61-8-8121-4859 1-800-880-484 AUSTRALIA BRISBANE: 61-7-3102-0961 1-800-880-484 AUSTRALIA CANBERRA: 61-2-6100-1961 1-800-880-484 AUSTRALIA MELBOURNE: 61-3-9010-7730 1-800-880-484 AUSTRALIA PERTH: 61-8-9467-5240 1-800-880-484 AUSTRALIA SYDNEY: 61-2-8211-1382 1-800-880-484 AUSTRIA 43-1-92-89-574 0800-999-850 BELGIUM 32-2-400-6717 0800-4-8474 BRAZIL 55-11-3958-0764 0800-7610666 CHILE 1230-020-0288 CHINA CHINA A: 86-400-810-4757 10800-712-1194 CHINA CHINA B: 86-400-810-4757 10800-120-1194 COLOMBIA 01800-9-156471 CROATIA 080-08-06-319 CZECH REPUBLIC 420-2-25-98-56-11 800-700-164 DENMARK 45-7014-0235 8088-5347 ESTONIA 800-011-1124 FINLAND 358-9-5424-7147 0-800-1-12418 FRANCE LYON: 33-4-26-69-12-72 080-511-1516 FRANCE MARSEILLE: 33-4-86-06-00-72 080-511-1516 FRANCE PARIS: 33-1-70-70-60-73 080-511-1516 GERMANY 49-69-2222-20267 0800-101-4259 GREECE 30-80-1-100-0635 00800-12-6136 HONG KONG 852-3001-3828 800-964-135 HUNGARY 36-1-700-8841 06-800-15442 INDIA BANGALORE: 91-80-61275252 INDIA MUMBAI: 91-22-61501688 INDIA INDIA B: 000-800-001-6249 INDIA INDIA C: 1800-300-00430 INDIA INDIA A: 000-800-852-1213 INDONESIA 001-803-011-3491 IRELAND 353-1-246-0095 1800-992-121 ISRAEL 1-80-9214002 ITALY MILAN: 39-02-3600-3564 800-985-429 ITALY ROME: 39-06-8751-6013 800-985-429 ITALY TORINO: 39-011-510-0113 800-985-429 JAPAN OSAKA: 81-6-7739-4760 00531-12-1150 JAPAN TOKYO: 81-3-5539-5150 00531-12-1150 LATVIA 8000-3168 LUXEMBOURG 352-27-000-1310 8002-9125 MALAYSIA 1-800-80-8105 MEXICO GUADALAJARA (JAL): 52-33-3208-7322 001-866-318-9747 MEXICO MEXICO CITY: 52-55-5062-9122 001-866-318-9747 MEXICO MONTERREY: 52-81-2482-0622 001-866-318-9747 NETHERLANDS 31-20-712-1372 0800-023-1492 NEW ZEALAND 64-9-970-4637 0800-443-823 NORWAY 47-21-59-00-10 800-12069 PANAMA 011-001-800-5072077 PERU 0800-53715 PHILIPPINES 63-2-858-3706 1800-111-42452 POLAND 00-800-1210160 PORTUGAL 8008-12108 ROMANIA 40-31-630-01-64 RUSSIA 8-10-8002-9913011 SAUDI ARABIA 800-8-110058 SINGAPORE 65-6883-9193 800-120-4060 SLOVAK REPUBLIC 421-2-322-422-12 0800-002032 SOUTH AFRICA 080-09-93392 SOUTH KOREA 82-2-6744-1048 00798-14800-6324 SPAIN 34-91-414-14-65 800-099-374 SWEDEN 46-8-566-10-474 0200-887-680 SWITZERLAND 41-44-580-3270 0800-000-246 TAIWAN 886-2-2795-7342 00801-137-568 THAILAND 001-800-1206-65076 TURKEY 00-800-151-1241 UNITED ARAB EMIRATES 8000-35702362 UNITED KINGDOM BIRMINGHAM: 44-121-210-9012 0800-279-9352 UNITED KINGDOM GLASGOW: 44-141-202-3212 0800-279-9352 UNITED KINGDOM LEEDS: 44-113-301-2112 0800-279-9352 UNITED KINGDOM LONDON: 44-20-7019-0830 0800-279-9352 UNITED KINGDOM MANCHESTER: 44-161-601-1412 0800-279-9352 URUGUAY 000-413-598-3452 USA 1-210-795-0469 866-780-9216 VENEZUELA 0800-1-00-2853

1 0

[rssac-caucus] Vídeo: Serigrafia em moletons
by Peter Oct. 23, 2015

Oct. 23, 2015

[1] O RapidTag pode ajudá-lo a serigrafía mais rápido e melhor em muitos tipos de materiais, incluindo velo. Esta máquina tem uma palete personalizado para o capô não interfere com a serigrafía! [2][Hoodies-01_zpsi7g8jyry.png] [3]Mais em moletons [4]Construir su propio [5]Retorno do Investimento Aparências em feiras: SGIA Expo Atlanta: Nov. 4th - 6th [6][Autounload-04_zpsg9vzgyap.png] [7][Autounload-05_zps791aomq0.png] [8][Autounload-06_zpspcyxj2jb.png] INGLÊS - (951).296.2595 ESPANHOL - (664).134.4759 References 1. http://aspesite.com/ 2. http://aspesite.com/pallet-custom-screen-printing-machine/ 3. http://aspesite.com/pallet-custom-screen-printing-machine/ 4. http://aspesite.com/build-your-custom-screen-printing-machine/ 5. http://aspesite.com/roi/ 6. https://www.facebook.com/pages/ASPE-Printing-Equipment/298253406928915?fref… 7. https://twitter.com/aspesite 8. 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] DRAFT RSSAC Caucus Meeting Agenda
by Steve Sheng Oct. 21, 2015

Oct. 21, 2015

Dear RSSAC Caucus, Based on the Caucus feedback for the IETF meeting, the RSSAC decided to convene a caucus meeting at IETF 94. The proposed agenda, based on the caucus feedback is attached. Best Steve >RSSAC Caucus Meeting @ IETF 94 >Sunday, 1 November 2015, 15:30 - 18:00 >Room TBD, Yokohama, Japan > >DRAFT AGENDA > > 1. a discussion on updating RSSAC002 > >2. an update / feedback on the root-servers.net <http://root-servers.net/> >work party > >3. a discussion on identifying server instances, documenting which >operator use what methods for such identification > >4. process for document errata > >5. Creating a testbed to measure root server conformance to RSSAC-001 >(Service Expectations) and RFC-2870bis (Protocol Requirements). > >Open Discussion > >- next meeting time for Caucus > >- How could RSSAC improve the relationship and interaction with the Caucus Steve

1 0

[rssac-caucus] Finalized Agenda for Yeti DNS Workshop 2015-10-31 (Pre-IETF 94)
by Davey Song Oct. 21, 2015

Oct. 21, 2015

<For people who may be interested and available in this mailing list > Hi colleagues, We finalize the agenda of this workshop ; ) **In order to receive further information like slides, remote access link, please send mail to Davey or coordinators(a)lists.yeti-dns.org <mailto:coordinators@lists.yeti-dns.org> to registry your attendance (or remote participation).** Event: Yeti DNS Project Workshop Time: 13:00-17:00, 31st, Oct, 2015 (a day before IETF meeting) Location: Room 514 in the Pacifico Yokohama Conference Center Host: BII Sponsor: Yeti Coordinators Draft Agenda: * Welcome address (5 min) * Keynote speech: From 2005 to 2015: Eleven Years (and Counting!) of Responsible Alternate Rootism (Paul Vixie) (20 min+10min Q&A) * Yeti project Introduction and status update (30 min+10min Q&A) * Problem Statement/Motivation * System Status (Server, traffic, operation bugs) * Technical findings Coffee break (15 min) (Some research done by Yeti members and invited talk) * Research and Experiments in BII lab (30 min+10min Q&A) * Multi-DM/Multi-ZSK, Root renumbering issue, KsK rollever and DNS Fragments * Monitoring and measuring Yeti root name servers, Stephane Bortzmeyer (20 min+10min Q&A) * Yeti experiment in MSK-IX , Dmitry Kovalenko (20 min+10 min Q&A) * AS112 update , Keith Mitchell (20 min+10 min Q&A)) Cheers, Davey ------------------------------ Davey Song(宋林健) BII Lab songlinjian(a)gmail.com <mailto:songlinjian@gmail.com>

1 0

[rssac-caucus] Caucus meeting in Yokohama? Agenda items?
by Lars-Johan Liman Oct. 20, 2015

Oct. 20, 2015

Hi there! We're evaluating whether to conduct a caucus meeting on the Sunday preceding the IETF in Yokohama. We would much like to see active participation from the caucus during such a meeting, and in line with that we hereby ask for what you think we should discuss if the meeting is held. As we all go to too many meetings, having the meeting just for meeting's sake doesn't sound like a lot of fun, but if there are sensible things to discuss, we'll make sure it happens. The tentative time slot we're looking at is Sunday November 1 @1430 local time in Yokohama. Please allow for slight variation in the time of day, depending on room availability. So, bring it on! We know that there are ideas flourishing out there. ;-) Best regards, /Tripti Sinha and Lars-Johan Liman RSSAC co-chairs

8 8