- dns-wg - mailman.ripe.net

Call For Presentations RIPE 70, submission deadline 1 March 2015
by Benno Overeinder 13 Jan '15

13 Jan '15

Dear colleagues, Please find the CFP for RIPE 70 below. The deadline for submissions is 1 March 2015. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder for the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/pc ---------------------------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 70 will take place from 11-15 May 2015 in Amsterdam, The Netherlands. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 70. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe70.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for "lightning talks", which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 1 March 2015, using the meeting submission system at https://ripe70.ripe.net/submit-topic/submission-form/. Proposals submitted after this date will be considered on a space-available basis. Important Dates regarding RIPE 70 can be found at: https://ripe70.ripe.net/programme/important-dates/ - Lightning talks should also be submitted using the meeting submission system (https://ripe70.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice – in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe70.ripe.net/submit-topic/presentation-formats/. - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panellists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

yet another heave on the WG Chair selection procedure
by Jim Reid 11 Jan '15

11 Jan '15

Happy new year everyone. The list has been silent about the draft selection procedure. This means it's not possible to decide if there's a consensus or not so we can declare victory and move on. Sigh. Could I ask you all to review the proposal and comment on the list? One sticking point appears to be the "A co-chair cannot serve more than 2 consecutive terms." provision in [2]. Someone commented at the mike at RIPE69 that this was a good thing. One of your co-chairs says the opposite. Everyone else has not commented one way or the other. Result: stalemate. WGs are supposed to have adopted a selection process by now and have it up and running in good time for RIPE70. Our WG is lagging behind the others. So, could we please have some comments on the proposed procedure and try to get the WG to converge on a consensus? Thanks. It would be appreciated if people gave clear statements of support or objection. In the latter case, please explain why and suggest alternate text. Simply saying "I disagree" will not be constructive. Though it would of course help with the consensus determination. Here's the suggested process again: # # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ # [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as determined by the WG. [2] A co-chair will serve a term of N years, where N is the number of co-chairs. Terms will be staggered so that one term expires every year. A co-chair cannot serve more than 2 consecutive terms. [3] The WG will be given adequate notice that a co-chair's term is ending and to invite applications for that position. Anyone can volunteer for appointment. [4] At the end of a co-chair's term, the WG will decide by consensus who is appointed to the available co-chair position. In the event of a tie, the consensus tied candidates will draw lots. [5] The WG may decide by consensus to remove a WG co-chair at any time. [6] Consensus will be determined on the DNS WG mailing list. The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair who is the subject of that consensus judgement. [7] Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final.

9 15

Solicitation for Statements of Interest regarding Root KSK Rollover
by KSK Rollover SOI 19 Dec '14

19 Dec '14

ICANN, as the IANA functions operator, in cooperation with Verisign as the Root Zone Maintainer and the National Telecommunications Information Administration (NTIA) as the Root Zone Administrator, together known as the Root Zone Management (RZM) partners, seek to develop a plan for rolling the DNS root zone key-signing key (KSK). The KSK is used to sign the root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the Internet’s root zone. The Root Zone Partners are soliciting five to seven volunteers from the community to participate in a Design Team to develop the Root Zone KSK Rollover Plan (“The Plan”). These volunteers along with the RZM partners will form the Design Team to develop The Plan. Individuals interested in volunteering approximately 5 hours per week for the Design Team should consult the announcement: https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf and submit their Statement of Interest to ksk-rollover-soi(a)icann.org no later than January 16, 2015.

4 6

ripe.net axfr
by Antonio Prado 13 Dec '14

13 Dec '14

hi, can I axfr ripe.net zone? thank you -- antonio

2 2

reminder about the WG Chair appointment process
by Jim Reid 27 Nov '14

27 Nov '14

Colleagues, there's been very little response or discussion about the procedure which was proposed at the beginning of October. I think it's now time to start a "Last Call" on this. If anyone has any tweaks to he proposed text or counter proposals, please speak up now! It would be helpful if any changes are accompanied by suggested replacement text and an explanation. Simply saying "I don't like Clause Foo" is not helpful or productive: please say why you don't like that clause and provide replacement text. Since the PDP uses 4 weeks for its Last Call phase, let's do the same here. So if there are no changes or comments on the suggested text by the end of the year, it will be considered to be the agreed, final version of the procedure. [Well, until we revisit this in the future...] Assuming there is agreement on the final text by the end of the year, I will ask the WG for statements of support for that final text so that we can hopefully declare consensus early in the new year. The plan would then be for the procedure to start in good time for RIPE70. In case anyone cares, here's that proposed text again. # # $Id: appointment,v 1.6 2014/10/06 11:46:56 jim Exp $ # [1] The DNS WG will have N co-chairs. N will normally be 2 or 3, as determined by the WG. [2] A co-chair will serve a term of N years, where N is the number of co-chairs. Terms will be staggered so that one term expires every year. A co-chair cannot serve more than 2 consecutive terms. [3] The WG will be given adequate notice that a co-chair's term is ending and to invite applications for that position. Anyone can volunteer for appointment. [4] At the end of a co-chair's term, the WG will decide by consensus who is appointed to the available co-chair position. In the event of a tie, the consensus tied candidates will draw lots. [5] The WG may decide by consensus to remove a WG co-chair at any time. [6] Consensus will be determined on the DNS WG mailing list. The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair who is the subject of that consensus judgement. [7] Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final.

4 8

New on RIPE Labs: The Resolvers We Use (by Geoff Huston)
by Mirjam Kuehne 26 Nov '14

26 Nov '14

Dear colleagues, For those who missed the plenary talk Geoff Huston gave on Monday during RIPE 69 ("The Resolvers We Use"), it is now published as an article on RIPE Labs: https://labs.ripe.net/Members/gih/the-resolvers-we-use Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [dns-wg] RIPE NCC DNSSEC trust anchors
by Romeo Zwart 18 Nov '14

18 Nov '14

Dear Collegues, Our message from last Thursday (see https://www.ripe.net/ripe/mail/archives/dns-wg/2014-November/002981.html) has stirred a significant amount of discussion. Trying to summarize the responses on the mailing list, I came to the below list of topics: /1 Why does any zone under 62.in-addr.arpa have to be in the DLV? Since 62/8 is under RIPE NCC control, it can be properly signed. /2 Why does RIPE NCC still submit key material to the DLV? RIPE NCC should no longer endorse out-of-band mechanisms for key publication. /3 Discussion around the current use of ripe.int. /4 Discussion around the current use of ripen.cc. I will try to answer each of these point separately. 1/ While the RIPE NCC controls 62/8, the delegations under it are not necessarily under our control. Specifically the /24 mentioned in the original post is part of 62.76/16, which is delegated to the Russian Institute for Public Networks (RIPN). RIPN does not sign its zones, therefore we have been using an out of band mechanism. 2/ The RIPE NCC has been publishing this key material out of band for historical reasons. If there is a consensus in the WG that this is no longer needed, or even undesirable, we are happy to phase out the use of the DLV. 3/ RIPE NCC has been assigned ripe.int in the early 2000's. We are currently not using ripe.int, other than by redirecting to ripe.net. If the community advises the RIPE NCC to request IANA to sign .int, we can spend some effort on this, but we'd like to follow up on this separately. 4/ Ripen.cc is a historical artifact. RIPE NCC is not currently using it and we are not planning any future use. Releasing the domain is an operational decision that we may take in the future. Kind regards, Romeo Zwart RIPE NCC

18 34

RIPE NCC DNSSEC trust anchors
by Anand Buddhdev 14 Nov '14

14 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors in their parent zones, with the exception of these three zones: 151.76.62.in-addr.arpa ripe.int ripen.cc We have been publishing trust anchors for these three zones on our website, as well as in the ISC DLV trust anchor repository (TAR): https://dlv.isc.org On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys and added the new trust anchors for these three zones to the ISC DLV TAR. Because we believe manual configuration of trust anchors is very rare these days, we are taking this opportunity to stop publishing trust anchors for these three zones on our website. The trust anchors remain available via the ISC DLV TAR. Of course, as soon as we are able to publish DS records for these zones in their parents, we will do so and withdraw them from the ISC DLV TAR, as we have done for all our other zones. If you have any questions or concerns, please send email to dns(a)ripe.net. Regards, Anand Buddhdev Senior Engineer RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRkxj4ACgkQi+U8Q0SwlCvWtQCgiCxJt53Ala7tTYXzzXW6787w GPcAn0a/u+aRB8BlpTT5cp5QomFo/LSB =ZAsP -----END PGP SIGNATURE-----

14 25

Experiment proposal to improve K-root
by Romeo Zwart 29 Oct '14

29 Oct '14

Dear colleagues, We used RIPE Atlas to measure latency to K-root, and we believe we can improve average latency by adding new nodes to K-root in strategic locations. In a new RIPE Labs article, we propose performing an experiment that would let us measure this potential improvement. You can find the details, including the full measurement results, here: https://labs.ripe.net/Members/suzanne_taylor_muzzin/experiment-proposal-to-… As we define the experiment, we will publish more specific details about how many nodes we will add, in which locations, and what kind of improvement we might expect. If you have any feedback about these plans, please share your feedback on this list. Kind regards, Romeo Zwart Global Information Infrastructure Manager RIPE NCC

1 0

DNS-WG Draft agenda
by Jaap Akkerhuis 22 Oct '14

22 Oct '14

Apologies for the delay, but ICANN ate my homework and a disk crash didn't help either. Anyway, here is the draft agenda for the DNS-WG. jaap

1 0