June 2014 - Test - lists.nanog.org

2014.06.03 NANOG61 day 2 afternoon notes
by Matthew Petach 04 Jun '14

04 Jun '14

Notes from the afternoon session today are up. :) http://nanog.cluepon.net/index.php/NANOG61aft3 Matt

1 0

2014.06.03 NANOG61 DNS session notes up
by Matthew Petach 03 Jun '14

03 Jun '14

sorry, I'm terribly behind today. I had thought I was going to have time to put together a lightning talk presentation about our IPsec solution, but today's been so hectic I didn't have a chance to pull slides together. maybe next time. ^_^; Instead, you get notes from the DNS track this morning. :) http://nanog.cluepon.net/index.php/NANOG61dns3 (rest of notes are already done but i'm late for my next meeting so i have to dash, and will post the rest after the meetings and socials) Matt

1 0

ARIN PPC Agenda for NANOG 61 Now Available
by John Curran 03 Jun '14

03 Jun '14

NANOG 61 Attendees - The ARIN Public Policy consultation is now starting in the Evergreen Ballroom. /John Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] ARIN PPC Agenda for NANOG 61 Now Available Date: May 28, 2014 at 10:48:22 AM PDT To: <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> Don't forget to mark your calendar and join us for ARIN's Public Policy Consultation (PPC), which will be held during NANOG 61 in Bellevue, Washington on Tuesday, 3 June 2014, from 9:30 - 1:00 PM. The policy consultation is part of ARIN's Policy Development Process, and it is an open public discussion of Internet number resource policy. Registered NANOG 61 attendees do not need to register to participate in this session. If you plan to attend and are not registered for NANOG you must register for the ARIN PPC at the https://www.arin.net/ppcregister There is no registration fee for this ARIN session, and it does not provide you entry to any other NANOG programming or social events. Current policy proposals up for discussion at this meeting are: * Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks * Draft Policy ARIN-2014-1: Out of Region Use * Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements * Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations * Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] * Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to Reality of Business * Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements * Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal * Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy * Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 * Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers * Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers * Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update * Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate Text available at: https://www.arin.net/policy/proposals/ or in the PPC Discussion Guide: https://www.arin.net/ppcnanog61 ARIN will offer a webcast, live transcript, and Jabber chat options for remote participants. Registered remote participants can submit comments and questions to the discussions during the meeting. Details are available at: https://www.arin.net/ppcremote Register to attend in person or remotely today! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net if you experience any issues.

1 0

Request for Community Input – Enhancing ICANN Accountability
by John Curran 03 Jun '14

03 Jun '14

NANOG Folks - There is a fairly important ICANN consultation going on which seeks input from the Internet community regarding ICANN's accountability mechanisms and the desirability of any potential enhancements (this is context of ICANN operating in the absence of a contractual relationship with the US Government.) This topic has the potential for significant impact on the administration of both Internet DNS names and IP addresses, so those who have strong views in these matters might want to provide input accordingly (See the attached message to PPML providing pointers to the consultation) The RIRs, as coordinated via the NRO, have a draft response (attached) and input on that is welcome as well. ICANN extended the deadline to the end of this week, which provides this opportunity to obtain additional community input. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-ppml] Request for Community Input – Enhancing ICANN Accountability Date: June 2, 2014 at 12:03:44 PM PDT To: <arin-ppml(a)arin.net<mailto:arin-ppml@arin.net>> ICANN issued a call for community input regarding its continuing accountability in the future in the absence of a contractual relationship with the U.S. Government. https://www.icann.org/public-comments/enhancing-accountability-2014-05-06-en The Executive Council of the Number Resource Organization (NRO) has drafted a response on behalf of the five Regional Internet Registry (RIR) communities. (See below) ARIN welcomes your feedback on this draft, and we will be accepting input through 4 June 2014. Please send your comments to info(a)arin.net. The community may also participate directly by providing feedback directly to ICANN as described here: https://www.icann.org/resources/pages/enhancing-accountability-2014-05-06-en Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) *** ICANN call for public comments on Enhancing ICANN’s Accountability Response from the Number Resource Organization (NRO) DRAFT ONLY - 29 May 2014 The NRO thanks ICANN for the opportunity to comment on means for improving its accountability, and we provide the following responses to the questions contained in the call for comments: https://www.icann.org/public-comments/enhancing-accountability-2014-05-06-en 1. What issues does the community identify as being core to strengthening ICANN’s overall accountability in the absence of its historical contractual relationship to the US government? Regarding ICANN's accountability with respect to IP addressing functions, we believe that the ASO structure provides a necessary and sufficient separation between policy formation and policy implementation. Global IP addressing policy is developed by the RIR communities and passed via the ASO to ICANN, in accordance with the ASO MoU; while policy is implemented by the IANA in the form of services delivered to the RIRs under specific service agreements. While these existing mechanisms have proven successful over the past 10 years, we believe than a review is appropriate at this time, prior to the expected NTIA transition, along with reviews by each of the RIRs of their own accountability mechanisms. Notwishstanding any improvements needed, these agreements must clearly define appropriate dispute resolution, escalation and arbitration procedures. We note that there is no agreement or expectation of any role for the USG NTIA in these processes; therefore we do not view the historical contractual relationship between ICANN and the US government as an accountability mechanism, and neither do we consider the NTIA's role as a source of ICANN’s accountability with respect to Internet number resources. In the hypothetical case that IANA had ever failed to provide number allocation services to any RIR in accordance to existing policies and agreements, we would have not relied upon the US government to solve this issue. Rather we would have worked transparently with ICANN, in accordance to the terms of existing agreements, to address the issue. The NRO is committed to continue to work with ICANN to strengthen escalation and dispute resolution mechanisms to allow the parties to work better in any hypothetical case of failed expectations. 2. What should be the guiding principles to ensure that the notion of accountability is understood and accepted globally? What are the consequences if the ICANN Board is not being accountable to the community? Is there anything that should be added to the Working Group’s mandate? The NRO does not believe that the contract with the US government should be replaced with a similar mechanism at a global level, therefore a guiding principle is specifically not to create any "superior" structure or organisation; rather ICANN's accountability should be defined in terms of transparent agreements with ICANN stakeholders, in which roles and responsibilities, and dispute resolution and arbitration mechanisms are fully defined. We believe that a failure by ICANN to abide clearly by established accountability mechanisms, and in particular by defined dispute resolution and arbitration mechanisms should have clear consequences, and therefore that arbitration mechanisms should be binding. Furthermore, they must be implementable and effective upon ICANN, regardless of its final structure or locale. The guiding principles for defining or strengthening these accountability mechanisms should be: that they are transparent, implementable and open to improvement; and that they operate in the interests of the open, stable and secure operation of the Internet. 3. Do the Affirmation of Commitments and the values expressed therein need to evolve to support global acceptance of ICANN’s accountability and so, how? The NRO believes that the Affirmation of Commitments is a good umbrella covering higher-level issues that may not be specifically included in existing contracts, MoUs, accountability frameworks and documents that govern ICANN’s relationships with its different stakeholder groups. While the most important accountability of ICANN is with its respective stakeholders and community, the Affirmation of Commitments and its evolution could support wider trust in ICANN’s ongoing operations at the international level. We believe that this evolution could take the form of a new affirmation into which many more stakeholder communities, including Governments, would enter. 4. What are the means by which the Community is assured that ICANN is meeting its accountability commitments? The current contracts, MoUs, accountability frameworks and documents that ICANN currently has with different parts of its community provide certain levels of accountability. These documents can evolve and improve however this should be an ongoing process which continues beyond the end of NTIA’s role, and throughout the entire lifetime of ICANN. 5. Are there other mechanisms that would better ensure that ICANN lives up to its commitments? If ICANN can in time be incorporated as an international organization under international law, this may provide the ICANN community with additional mechanisms to solve disputes through mediation, arbitration or judicial avenues; and added confidence in the ability to serve stakeholders uniformly across the globe. While we would like this possibility to be actively explored by ICANN, we do not believe it is a necessary prerequisite to any of the other measures described in this response, but welcome continued engagement with the global stakeholder community on this topic. 6. What additional comments would you like to share that could be of use to the ICANN Accountability Working Group? The NRO notes the present clarity of responsibility that exists with respect ICANN's roles in administration of Internet protocol identifiers for the IETF and Internet number resources for the Internet address community, and suggests that it might helpful for the ICANN Accountability Working Group to examine these successes in its efforts. The NRO expects to contribute and work together with the ICANN Accountability Working Group, and other stakeholders in the ICANN community, to improve mechanisms for enhancing accountability in the years to come. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML(a)arin.net) Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info(a)arin.net if you experience any issues.

1 0

2014.06.02 NANOG61 day 1 afternoon notes
by Matthew Petach 02 Jun '14

02 Jun '14

I posted my notes from the afternoon session up at http://nanog.cluepon.net/index.php/NANOG61aft2 I am in the security track, but not recording notes, as speakers have asked to be off the record for the discussions. So, I'll resume notes tomorrow morning. Have a wonderful evening everyone! Matt

1 0

2014.06.02 NANOG61 morning notes posted
by Matthew Petach 02 Jun '14

02 Jun '14

If anyone isn't here in Bellevue today (unlikely, given how packed it is; amazing turnout for this NANOG!) but is curious about notes from this morning, I've put my notes up at http://nanog.cluepon.net/index.php/NANOG61morn2 Thank you Dave Meyer for a great keynote, and kudos to NTT for an awesomely funny kickoff video. And yes, Ren, I'll be your friend now. ;) Thanks everyone! Matt PS--I'm never going to let Dorian come up behind me ever again.... #scarredforlife

1 0

Re: ipmi access
by Brian Dickson 02 Jun '14

02 Jun '14

Here's one useful method, which depends on having appropriate subnet and VLAN capabilities. Have all hosts at a given site, have their main interface do dot1q (switch config trunked port). The ipmi interfaces will be on one VLAN (put those ports in that VLAN). The first VLAN is the public routed subnet. The router needs to be configured with this VLAN. The second VLAN is the IPMI, and is NOT CONFIGURED ON THE ROUTER. This second VLAN has only hosts and IMPIs. No connectivity to the world, period. (Be sure IP packet forwarding is disabled on the hosts!) On (some subset of) the hosts' main interface, run suitable remote KVM-ish protocol. For instance, use ssh with X forwarding, and/or VNC (or XVNC), and whatever local IMPI client thing you want (browser). Connecting to ipmi is by IP on the second VLAN (or by name, left as exercise for the reader.) Avoids ACL fiddling, is as secure as your host access method (but no more secure, obviously). YMMV. Brian

1 0

Off Topic Friday
by Alain Hebert 02 Jun '14

02 Jun '14

Well happy friday. We're planning to build a MPLS lab this summer. If anyone has suggestion for cheap hardware to simulate a implementation of all the RFC's from the Core to the CPE. it would be greatly appreciated. >From our research, It is pretty much all over the place, like the vendor did it on purpose to milk all the money they could from the spec :). As usual, off-list would be best. PS: I'll forward a summary of the information to the people interested by this subject. -- ----- Alain Hebert ahebert(a)pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

5 5

Hulu contact?
by Brzozowski, John 01 Jun '14

01 Jun '14

If there is anyone from Hulu on the NANOG list can you please contact me unicast? Thanks, John ========================================= John Jason Brzozowski Comcast Cable m) 609-377-6594 o) 484-962-0060 w) www.comcast6.net e) john_brzozowski(a)cable.comcast.com =========================================

1 0