From kranjbar at ripe.net Thu Aug 7 14:11:07 2014 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Thu, 7 Aug 2014 14:11:07 +0200 Subject: [dns-wg] Proposed criteria for adding new zones to DNSMON Message-ID: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> Dear colleagues, The new DNSMON (https://atlas.ripe.net/dnsmon/) service has been available for several months now, and we would like to propose criteria for adding new zones going forward. Please note that we?ve provided this just as a starting point for consultation with the DNS community, and are asking for feedback about this proposal. First, we believe we should only add these TLDs when we receive a request from the TLD operators themselves, rather than from third parties. If we do receive requests to add a TLD from a third party, we will only do so after first checking with the TLD operator and receiving an official request from them at atlas at ripe.net. Second, we propose allowing the addition of ccTLDs operated by our members for countries within the RIPE NCC?s service region. The new DNSMON infrastructure is capable of handling this number of potential requests. Third, we propose adding up to five gTLDs under the control of any given operator, and only if the operator is a member of the RIPE NCC. We believe these criteria for including new zones will continue to make DNSMON a valuable tool for our members and the wider community. Once the DNS Working Group has provided feedback on these criteria, the RIPE NCC will provide a full service description for DNSMON that includes these criteria and that will be included in the DNSMON documentation. We look forward to hearing your thoughts, and ask you to please respond to this list with any feedback you have preferably before mid-September. Kind regards, Kaveh Ranjbar Chief Information Officer RIPE NCC From Woeber at CC.UniVie.ac.at Tue Aug 12 16:03:34 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 12 Aug 2014 16:03:34 +0200 Subject: [dns-wg] Proposed criteria for adding new zones to DNSMON In-Reply-To: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> References: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> Message-ID: <53EA1EB6.3090803@CC.UniVie.ac.at> [ Disclaimer: I am not a DNS expert, just looking at things from a membership pov ] Kaveh Ranjbar wrote: [...] > Second, we propose allowing the addition of ccTLDs operated by our members > for countries within the RIPE NCC?s service region. I can easily see the rationale for the requirement of RIPE NCC Membership of the operator, but I do not immediately see the reason for the additional restriction based on geography. Just curious. Regarrds, Wilfried From jim at rfc1035.com Thu Aug 14 14:08:15 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Aug 2014 13:08:15 +0100 Subject: [dns-wg] Proposed criteria for adding new zones to DNSMON In-Reply-To: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> References: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> Message-ID: On 7 Aug 2014, at 13:11, Kaveh Ranjbar wrote: > We look forward to hearing your thoughts, and ask you to please respond to this list with any feedback you have preferably before mid-September. Kaveh, I think this is a good starting point. Thanks. However I think the proposed framework misses statements of the obvious: The NCC will provide regular status reports on DNSMON to the DNS WG. Changes to this framework will be discussed and agreed by the DNS WG. From jim at rfc1035.com Thu Aug 14 14:56:34 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Aug 2014 13:56:34 +0100 Subject: [dns-wg] Proposed criteria for adding new zones to DNSMON In-Reply-To: <53EA1EB6.3090803@CC.UniVie.ac.at> References: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> <53EA1EB6.3090803@CC.UniVie.ac.at> Message-ID: <7FEC3568-F8FC-40A4-94E7-E198FCD53028@rfc1035.com> On 12 Aug 2014, at 15:03, Wilfried Woeber wrote: > I can easily see the rationale for the requirement of RIPE NCC Membership > of the operator, but I do not immediately see the reason for the additional > restriction based on geography. Let's learn to walk first before trying to run. :-) My personal opinion is the service should primarily be focused on the NCC's service region with key infrastructure stuff like the root and parts of .arpa as special cases. In theory this will provide enough room for other organisations to offer DNS monitoring services in the other RIR service regions or for different market segments. It would be unwise if DNSMON cherry picks the majority of potential (paying) customers and/or turns into a monopolistic juggernaut that distorts the market. A cautious approach here seems prudent. FWIW, when the NCC began offering TLD monitoring services "for free" a few years ago, it caused a member to abandon their plans to launch a commercial service and write off their investment. Other entrants are now emerging: DNS hosting providers, DNS-OARC's tldmon, (g)TLD registry operators, etc. Some of these might be more than unhappy if DNSMON has eaten their lunch. I think we also have to be particularly careful about the gazillions of new gTLDs. These could overwhelm the current DNSMON platform and/or present scaling problems. Limiting service to a handful of these TLDs in the service region should keep things on a tight leash, at least for now. If it later turns out those concerns were misplaced, a more liberal approach can be introduced when there's evidence to support that. It will also be good to assess the reporting and WG oversight of DNSMON. The NCC may well want the WG to be the one to say yes or no whenever a new "customer" comes along. Personally I think it's crucial the WG has a role in defining the scope of the service. YMMV. At present DNSMON largely operates in a vacuum with an open door "policy" which hasn't been agreed or documented. From that PoV, Kaveh's proposal is a very welcome step in the right direction. I hope the WG can quickly reach consensus on something similar to this draft once the summer holidays are over. From Woeber at CC.UniVie.ac.at Thu Aug 14 15:45:57 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 14 Aug 2014 15:45:57 +0200 Subject: [dns-wg] Proposed criteria for adding new zones to DNSMON In-Reply-To: <7FEC3568-F8FC-40A4-94E7-E198FCD53028@rfc1035.com> References: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> <53EA1EB6.3090803@CC.UniVie.ac.at> <7FEC3568-F8FC-40A4-94E7-E198FCD53028@rfc1035.com> Message-ID: <53ECBD95.5010303@CC.UniVie.ac.at> Hi Jim, thanks for your PoV. I largely agree with you reasoning, with one exception: Jim Reid wrote: > On 12 Aug 2014, at 15:03, Wilfried Woeber wrote: > The NCC may well want the WG to be the one to say yes or no whenever a new > "customer" comes along. IMHO, this is a very bad idea. For more than one reason, e.g. timeliness of decision, definition of criteria, potential for arbitrary outcome based on whatever, lack of interest/involvement,... > Personally I think it's crucial the WG has a role in defining the scope of > the service. Agreed. But this sounds pretty much like AP, where the community defines the rules or "policy", and the NCC implements it. "Sharing" the responsibility for decisions seems to be cumbersome, at least. > YMMV. At present DNSMON largely operates in a vacuum with an open door "policy" > which hasn't been agreed or documented. From that PoV, Kaveh's proposal is a > very welcome step in the right direction. Strongly seconded. > I hope the WG can quickly reach consensus on something similar to this draft > once the summer holidays are over. :-) Wilfried. From jim at rfc1035.com Thu Aug 14 16:04:12 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Aug 2014 15:04:12 +0100 Subject: [dns-wg] Proposed criteria for adding new zones to DNSMON In-Reply-To: <53ECBD95.5010303@CC.UniVie.ac.at> References: <6EC10F66-D1E4-47AC-9640-ED24FCDB1164@ripe.net> <53EA1EB6.3090803@CC.UniVie.ac.at> <7FEC3568-F8FC-40A4-94E7-E198FCD53028@rfc1035.com> <53ECBD95.5010303@CC.UniVie.ac.at> Message-ID: On 14 Aug 2014, at 14:45, Wilfried Woeber wrote: >> The NCC may well want the WG to be the one to say yes or no whenever a new >> "customer" comes along. > > IMHO, this is a very bad idea. For more than one reason, e.g. timeliness of > decision, definition of criteria, potential for arbitrary outcome based on > whatever, lack of interest/involvement,... Wilfried, I'm sorry if my response gave you that impression because that's not what was envisaged. Well, not in my mind at any rate... You are of course absolutely right the WG should have no say in operational matters. And not just for the reasons you outlined. Micromanagement by mailing list simply can't work. So the WG won't be doing that. :-) What I hope we arrive at is a situation where a framework is agreed by the WG. The NCC implement that and report on how things are going at regular intervals. If/when the framework needs to be tweaked -- say for a new class of customer or to add more gTLDs per NCC member -- this comes to the WG. The WG will not need to be consulted at all when a new customer that already meets the current criteria asks for DNSMON. If that customer does not meet the prevailing criteria, that's when the WG should be in the position of making the yes/no decision by either changing the criteria or not. The WG shouldn't be asked to decide if Customer X gets added or not. I expect the discussion would be something like "Customer X meets category foo. DNSMON does not serve that category. Should the NCC include foo? Here's what a yes/no answer will mean.". >> Personally I think it's crucial the WG has a role in defining the scope of >> the service. > > Agreed. But this sounds pretty much like AP, where the community defines the > rules or "policy", and the NCC implements it. That's the objective here too. > "Sharing" the responsibility for decisions seems to be cumbersome, at least. Indeed and that's why this is not what is expected to happen to DNSMON. The WG would do the "policy" aspects and document them -- which IMO shouldn't need the full force of the PDP sledgehammer -- and the NCC be left to implement those as it sees fit. I hope this clarifies things or offers something for the WG to chew on. From ripencc-management at ripe.net Thu Aug 21 10:27:58 2014 From: ripencc-management at ripe.net (Axel Pawlik) Date: Thu, 21 Aug 2014 10:27:58 +0200 Subject: [dns-wg] RIPE NCC Re-Affirms Commitment to Operate K Root Name Server Message-ID: Dear colleagues, The RIPE NCC has been providing DNS root name service via k.root-servers.net since 1997. As the global Internet community considers changes to the NTIA oversight of key DNS functions, the RIPE NCC wishes to assure the Internet community that our commitment to providing this service and to coordinating appropriately with ICANN and the other root server operators will not be affected by the outcome of these discussions. The RIPE NCC is a not-for-profit membership association under Dutch law. It is governed by its General Meeting and Executive Board, and is guided by the RIPE community. Root name servers are a crucial part of the Internet DNS infrastructure and the RIPE NCC?s role in this area is supported by the membership for the benefit of the global Internet community. In an open letter to ICANN in 2009, the RIPE NCC affirmed our mutual commitment to coordination of DNS root name service operations, acknowledging that a single, unique DNS root is paramount to the stable operations of the Internet and to ensuring global reachability: https://ripe.net/s/kr2h We remain committed to the principles expressed in this letter, and will continue working to operationalise them, independent of changes to the IANA stewardship. More information about RIPE NCC's operation of K-root is available at: http://k.root-servers.org/ Best regards, Axel Pawlik Managing Director RIPE NCC From benno at NLnetLabs.nl Wed Aug 27 13:32:57 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Wed, 27 Aug 2014 13:32:57 +0200 Subject: [dns-wg] Call For Presentations RIPE 69, deadline 31 August 2014 Message-ID: <53FDC1E9.7070104@NLnetLabs.nl> Dear colleagues, Please find the CFP for RIPE 69 in London below. The deadline for submissions is 31 August 2014. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, RIPE PC 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 69 will take place from 3-7 November 2014 in London, UK. 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 69. 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://ripe69.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 31 August 2014, using the meeting submission system at https://ripe69.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. - Lightning talks should also be submitted using the meeting submission system (https://ripe69.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://ripe69.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/