From chrisb at ripe.net Fri Sep 5 17:22:54 2014 From: chrisb at ripe.net (Chris Buckridge) Date: Fri, 5 Sep 2014 17:22:54 +0200 Subject: [cooperation-wg] RIPE NCC Report on IGF 2014 Message-ID: Dear colleagues, The ninth annual Internet Governance Forum (IGF) concluded on Friday, 5 September, in Istanbul, Turkey. Over the course of the week, RIPE NCC staff and RIPE community members contributed to many of the workshops and main sessions. These sessions looked at topics like the impact of carrier-grade NAT technology on users and policymakers, the IANA oversight transition process, cybersecurity and capacity building. You can find more information about the week?s discussions, and the RIPE NCC?s involvement, on the RIPE NCC website: https://www.ripe.net/internet-coordination/news/ripe-ncc-report-on-igf-2014 Best regards, Chris Buckridge Senior External Relations Officer RIPE NCC From rhill at hill-a.ch Wed Sep 10 10:50:09 2014 From: rhill at hill-a.ch (Richard Hill) Date: Wed, 10 Sep 2014 10:50:09 +0200 Subject: [cooperation-wg] Key elements of the transition of IANA stewardship Message-ID: NOTE: this message has been cross-posted individually to the RIR mailing lists dealing with this issue. Here are some things that appear to me to be key elements for the transition of the IANA stewardship. At present, the "RIRs are an interested and affected party of the IANA contract because IANA holds ultimate responsibility for allocated and unallocated IPv4, IPv6 and Autonomous System Number address spaces. IANA delegates IP and ASN address blocks to the RIRs on a needs-based approach according to global policies agreed by all the Regional Internet Registries (RIRs). The ?global policy development process? is described in the ICANN Address Supporting Organization (ASO) memorandum of understanding. ICANN and the Number Resource Organization (NRO) signed this MoU in 2004. The NRO is an unincorporated organization created in 2003 as a coordination mechanism for the RIRs. The NRO fulfills the role, responsibilities and functions of the ASO as defined within the ICANN Bylaws." (This is a citation from the document at: https://blog.apnic.net/wp-content/uploads/2014/09/NRO-RELATIONSHIP-IANA.pdf ) The Mou between ICANN and the NRO is at: https://aso.icann.org/about-the-aso/aso-memorandum-of-understanding/ That MoU specifies how ICANN's ASO is constituted and provides that "Under this agreement the ICANN Board will ratify proposed global policies in accordance with the Global Policy Development Process, using review procedures as determined by ICANN." Thus, the ICANN Board has ultimate responsibility for IP address policies. This is consistent with the ICANN Bylaws. Up to now, under the IANA functions contract with the NTIA, ICANN was clearly bound to defer to the RIRs for what concerns IP address policies. If there is no contract between ICANN and some external entity, then ICANN would have unrestricted ultimate authority over IP addresses. That is, the ICANN Board could, if it considered it appropriate, override RIR policies. This puts too much power in the ICANN Board which, under ICANN's current structure, is not accountable to any external entity. It would appear desirable that the IANA functions should be contracted for by the served communities, that is, by the NRO/RIRs for what concerns IP addresses. And indeed the draft proposal presented by APNIC on 8 September 2014 envisages a Service Level Agreement between ICANN and NRO and also a non-binding Affirmation of Committments between ICANN and NRO. These proposals are found in the slide show contained in the web page at: http://blog.apnic.net/2014/09/08/iana-session-apnic-38-a-discussion-propos al/ But a non-binding Affirmation of Committments, coupled with a Service Level Agreement, are not the equivalent of a contract for the IANA functions. Thus, it would appear more appropriate to adopt the same approach that has been adopted by the IETF regarding protocol parameters, namely a Memorandum of Understanding (which appears to be a contract) between the NRO and ICANN for the IP addresses. The Memorandum of Understanding between ICANN and the IETF is at: https://www.icann.org/resources/unthemed-pages/ietf-icann-mou-2000-03-01-e n and http://tools.ietf.org/html/rfc2860 That text could easily be modified to refer to NRO and IP addresses instead of IETF and protocol parameters. However, item 4 of the text should be modified so that it reads as follows: "4. Agreed technical work items. ICANN agrees, notwithstanding any provisions in its Bylaws or other corporate documents that might be construed differently, that during the term of this MOU it shall cause IANA to comply ..." In addition, consideration should be given to adding a choice of law clause and a dispute resolution clause, presumably referring to arbitration rather than to national courts. There was extensive discussion (but no agreement) on the IANA Transition mailing list regarding whether or not the fact that a US court could, in theory, order ICANN/IANA to do something contrary to agreed community policies is an issue and, if so, whether anything should be proposed to deal with that issue, such as proposing that the entity that performs the IANA function should have immunity of jurisdiction, or that the entity should have redundant sites in more than one jurisdiction. If there is support for dealing with that issue, then some text could be added. Finally, and in addition to the above, article I.1 of the ICANN Bylaws should be modified to make it clear that it is the NRO that has the overall responsibility for the coordination and allocation and assignment of IP addresses. That change is needed because, at present, article I.1 of the ICANN Bylaws implies that ICANN has the overall responsibility for the coordination and allocation and assignment of IP addresses. Best, Richard From chrisb at ripe.net Wed Sep 17 12:15:21 2014 From: chrisb at ripe.net (Chris Buckridge) Date: Wed, 17 Sep 2014 12:15:21 +0200 Subject: [cooperation-wg] Principles for a RIPE Proposal on IANA Oversight References: <21E07C7A-7ECF-4D7A-A05A-93234ACB7B45@ripe.net> Message-ID: <4A6E9BA7-F4F3-492F-9E81-700D11DB3EA9@ripe.net> Dear colleagues, The RIPE NCC is working closely with the Cooperation Working Group Co-chairs and members of the RIPE community to draft a proposal on the future oversight of the IANA functions. To assist in the process, we developed a straightforward set of principles based primarily on the discussions in this working group at RIPE 68 and on the working group?s mailing list. Feedback from the working group on the three areas listed below, on whether to express agreement or otherwise, and on any other related issues or questions is a vital part of this process. We would appreciate this feedback by the end of September. At the beginning of October, we plan to present a rough draft proposal to the working group for further discussion ahead of the RIPE 69 Meeting in London. Further background information, including a detailed overview of the NTIA IANA functions contract and a timeline for the five RIR community discussion processes, was recently published on the NRO website: https://www.nro.net/iana-oversight Best regards, Chris Buckridge RIPE NCC -------------- Background The Regional Internet Registry (RIR) communities have successful, long-established processes for making Internet number resource policy at the global and regional levels. These processes are defined as being open to all interested parties, transparent in their processes and operations, and driven by the community themselves in a ?bottom-up? fashion via consensus-based decision-making processes. These processes operate at the regional level to create policies that address regional needs and interests. More rarely, they serve to create global policies regarding the top level of the Internet number registration hierarchy. These global policies are implemented by the IANA operator, a role currently fulfilled by ICANN. RIR policy development processes pre-date ICANN and the current NTIA IANA functions contract. The NTIA plays no explicit role in making or directing policy for the operation of those IANA functions relating to Internet number resources. The current processes and structures have resulted in excellent operation of the IANA functions relating to Internet number administration by ICANN, under policy direction from the RIR communities. 1. The following are priorities for the RIPE community: - There should be minimal operational change. The current processes for IANA operation and related policy-making are effective and allow for the participation of all interested parties. - Any new oversight mechanism should incorporate and build on the existing RIR community policy-making processes. - The RIR communities are ultimately accountable for the management of those IANA functions relating to management of the global Internet number resource pools, and this should be reflected in any new oversight mechanisms defined in a global proposal to NTIA. 2. A model for IANA oversight endorsed by the RIPE community should include the following elements: - ICANN has historically managed operation of the IANA functions well, and should continue to do so at this time. - The IANA functions operator must be answerable and accountable to the communities that it serves. The number resource community is represented in such accountability processes by the membership-based RIR organisations. - Funding arrangements to cover the staff, equipment and other operational costs associated with operation of the IANA functions should be transparent and stable. - Efforts should be made to maintain the IANA functions as a ?bundle?, managed by a single operator. - This does not necessarily imply a single, central point of oversight authority. Any proposed oversight mechanism should reflect the legitimate authority of different communities for specific functions as they relate to number resources, domain names and protocol parameters. 3. RIPE community input to the IANA Stewardship Transition Coordination Group (ICG), which is responsible for developing a global proposal to NTIA, will be developed according to the following process: - Discussion in the RIPE community is centralised in the RIPE Cooperation Working Group. - The RIPE community discussion will aim to produce an output document by 1 December 2014. - The RIPE Cooperation Working Group Chairs will be responsible for assessing community consensus on this output document. - This RIPE output document will be sent to the Number Resource Organization Executive Council (made up of the five RIR CEOs), who will compile a single NRO input to the ICG. - A representative of the NRO Number Council will confirm that text compiled by the NRO EC accurately reflects the output of the five RIR community discussions. - The NRO proposal will be shared with the five RIR communities ahead of submission to the ICG. - Any global proposal produced by the ICG will be conveyed back to the RIPE community via the RIPE Cooperation Working Group to allow for discussion of any objections or concerns. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: From chrisb at ripe.net Wed Sep 17 13:33:26 2014 From: chrisb at ripe.net (Chris Buckridge) Date: Wed, 17 Sep 2014 13:33:26 +0200 Subject: [cooperation-wg] Call for nominations: IGF MAG References: Message-ID: <3E0DB62B-7B3B-4F38-940E-E06ACFBFF0ED@ripe.net> Dear colleagues, Please note the email forwarded below - volunteers from the technical community are being sought to participate in the Internet Governance Forum (IGF) Multistakeholder Advisory Group (MAG). The MAG develops the programme and schedule of the IGF, and includes 55 members from governments, the private sector, civil society, and the academic and technical communities. More information about the MAG is available at: http://www.intgovforum.org/cms/magabout Best regards, Chris Buckridge, RIPE NCC > From: Elizabeth Oluoch > Date: Tuesday, September 16, 2014 5:58 AM > > > Dear All, > > Under-Secretary-General of UNDESA, Mr. Wu Hongbo, has issued a public request for nominations for the 2015 Multistakeholder Advisory Group, which will advise the Secretary-General of the United Nations on the programme and schedule of the IGF 2015 meeting. The aim is to rotate one third of MAG members. > > The Internet Society (ISOC) is coordinating a process leading to recommendations of representatives of the Internet technical community for the renewal of the MAG. > > Individuals interested in being suggested by the NomCom set up for this purpose are invited to read more about the process and to fill in a submission template by 1 October: http://www.internetcollaboration.org/wp-content/uploads/sites/12/2014/09/2015MagRenewalNomProcess.pdf > > Any questions or requests for additional information can be sent to: information.itcg at gmail.com. > > Useful links: > IGF website: http://www.intgovforum.org/cms/ > About the MAG:: http://www.intgovforum.org/cms/magabout > > Thank you and best regards, > > Elizabeth Oluoch > Public Policy Coordinator > Internet Society -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: From rhill at hill-a.ch Thu Sep 18 10:44:01 2014 From: rhill at hill-a.ch (Richard Hill) Date: Thu, 18 Sep 2014 10:44:01 +0200 Subject: [cooperation-wg] Principles for a RIPE Proposal on IANA Oversight In-Reply-To: <4A6E9BA7-F4F3-492F-9E81-700D11DB3EA9@ripe.net> Message-ID: Chris, Thank you for this. For what concerns IP addresses, IANA at present publishes top level information, for example the list of /16 IPv4 allocations at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtm l That list has not always been up to date regarding what happened to the legacy (old Class A) allocations. For example it still lists 16/8 as being allocated to Digital Equipment Corporation (DEC). But in fact DEC was acquired by Compaq some time ago, and Compaq was then acquired by Hewlett-Packard (HP), so 16/8 is now allocated to HP. This is correctly shown in the ARIN WHOIS. So I wonder whether it wouldn't be more efficient for the NRO to publish directly this sort of information, since the RIRs are actu ally the authoritative sources. Best, Richard > -----Original Message----- > From: cooperation-wg-bounces at ripe.net > [mailto:cooperation-wg-bounces at ripe.net]On Behalf Of Chris Buckridge > Sent: mercredi, 17. septembre 2014 12:15 > To: RIPE Cooperation Working Group > Subject: [cooperation-wg] Principles for a RIPE Proposal on IANA > Oversight > > > Dear colleagues, > > The RIPE NCC is working closely with the Cooperation Working > Group Co-chairs and members of the RIPE community to draft a > proposal on the future oversight of the IANA functions. > > To assist in the process, we developed a straightforward set of > principles based primarily on the discussions in this working > group at RIPE 68 and on the working group?s mailing list. > Feedback from the working group on the three areas listed below, > on whether to express agreement or otherwise, and on any other > related issues or questions is a vital part of this process. We > would appreciate this feedback by the end of September. > > At the beginning of October, we plan to present a rough draft > proposal to the working group for further discussion ahead of the > RIPE 69 Meeting in London. > > Further background information, including a detailed overview of > the NTIA IANA functions contract and a timeline for the five RIR > community discussion processes, was recently published on the NRO website: > https://www.nro.net/iana-oversight > > Best regards, > > Chris Buckridge > RIPE NCC > > -------------- > > Background > > The Regional Internet Registry (RIR) communities have successful, > long-established processes for making Internet number resource > policy at the global and regional levels. These processes are > defined as being open to all interested parties, transparent in > their processes and operations, and driven by the community > themselves in a ?bottom-up? fashion via consensus-based > decision-making processes. These processes operate at the > regional level to create policies that address regional needs and > interests. More rarely, they serve to create global policies > regarding the top level of the Internet number registration > hierarchy. These global policies are implemented by the IANA > operator, a role currently fulfilled by ICANN. > > RIR policy development processes pre-date ICANN and the current > NTIA IANA functions contract. The NTIA plays no explicit role in > making or directing policy for the operation of those IANA > functions relating to Internet number resources. The current > processes and structures have resulted in excellent operation of > the IANA functions relating to Internet number administration by > ICANN, under policy direction from the RIR communities. > > > 1. The following are priorities for the RIPE community: > > - There should be minimal operational change. The current > processes for IANA operation and related policy-making are > effective and allow for the participation of all interested parties. > - Any new oversight mechanism should incorporate and build on > the existing RIR community policy-making processes. > - The RIR communities are ultimately accountable for the > management of those IANA functions relating to management of the > global Internet number resource pools, and this should be > reflected in any new oversight mechanisms defined in a global > proposal to NTIA. > > > 2. A model for IANA oversight endorsed by the RIPE community > should include the following elements: > > - ICANN has historically managed operation of the IANA > functions well, and should continue to do so at this time. > - The IANA functions operator must be answerable and > accountable to the communities that it serves. The number > resource community is represented in such accountability > processes by the membership-based RIR organisations. > - Funding arrangements to cover the staff, equipment and other > operational costs associated with operation of the IANA functions > should be transparent and stable. > - Efforts should be made to maintain the IANA functions as a > ?bundle?, managed by a single operator. > - This does not necessarily imply a single, central point of > oversight authority. Any proposed oversight mechanism should > reflect the legitimate authority of different communities for > specific functions as they relate to number resources, domain > names and protocol parameters. > > > 3. RIPE community input to the IANA Stewardship Transition > Coordination Group (ICG), which is responsible for developing a > global proposal to NTIA, will be developed according to the > following process: > > - Discussion in the RIPE community is centralised in the RIPE > Cooperation Working Group. > - The RIPE community discussion will aim to produce an output > document by 1 December 2014. > - The RIPE Cooperation Working Group Chairs will be responsible > for assessing community consensus on this output document. > - This RIPE output document will be sent to the Number Resource > Organization Executive Council (made up of the five RIR CEOs), > who will compile a single NRO input to the ICG. > - A representative of the NRO Number Council will confirm that > text compiled by the NRO EC accurately reflects the output of the > five RIR community discussions. > - The NRO proposal will be shared with the five RIR communities > ahead of submission to the ICG. > - Any global proposal produced by the ICG will be conveyed back > to the RIPE community via the RIPE Cooperation Working Group to > allow for discussion of any objections or concerns. > From seun.ojedeji at gmail.com Thu Sep 18 11:13:40 2014 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 18 Sep 2014 10:13:40 +0100 Subject: [cooperation-wg] Principles for a RIPE Proposal on IANA Oversight In-Reply-To: References: <4A6E9BA7-F4F3-492F-9E81-700D11DB3EA9@ripe.net> Message-ID: On Thu, Sep 18, 2014 at 9:44 AM, Richard Hill wrote: > Chris, > > So I wonder whether it wouldn't be more efficient for the NRO to publish > directly this sort of information, since the RIRs are actually the > authoritative sources. > When you say NRO publish, you are also indicating that NRO should do the actual allocation (which is largely the numbers function carried out by IANA). I think whoever allocates should also publish (NRO or anyone could re-publish for all its worth). I understand your concern about the possible inconsistency of the information published on the IANA record. Considering that those IPs are now maintained by relevant RIR, it is not clear whether IANA needs to also update his own record (since the RIR is now there to perform such role). I don't think there is actually a defined directive on how IANA handles legacy allocations whose organisation has changed, i think that role is left to regional RIRs. So maybe its not a flaw of operation from IANA but an actual compliance with existing processes. Cheers! > > Best, > Richard > > > -----Original Message----- > > From: cooperation-wg-bounces at ripe.net > > [mailto:cooperation-wg-bounces at ripe.net]On Behalf Of Chris Buckridge > > Sent: mercredi, 17. septembre 2014 12:15 > > To: RIPE Cooperation Working Group > > Subject: [cooperation-wg] Principles for a RIPE Proposal on IANA > > Oversight > > > > > > Dear colleagues, > > > > The RIPE NCC is working closely with the Cooperation Working > > Group Co-chairs and members of the RIPE community to draft a > > proposal on the future oversight of the IANA functions. > > > > To assist in the process, we developed a straightforward set of > > principles based primarily on the discussions in this working > > group at RIPE 68 and on the working group?s mailing list. > > Feedback from the working group on the three areas listed below, > > on whether to express agreement or otherwise, and on any other > > related issues or questions is a vital part of this process. We > > would appreciate this feedback by the end of September. > > > > At the beginning of October, we plan to present a rough draft > > proposal to the working group for further discussion ahead of the > > RIPE 69 Meeting in London. > > > > Further background information, including a detailed overview of > > the NTIA IANA functions contract and a timeline for the five RIR > > community discussion processes, was recently published on the NRO > website: > > https://www.nro.net/iana-oversight > > > > Best regards, > > > > Chris Buckridge > > RIPE NCC > > > > -------------- > > > > Background > > > > The Regional Internet Registry (RIR) communities have successful, > > long-established processes for making Internet number resource > > policy at the global and regional levels. These processes are > > defined as being open to all interested parties, transparent in > > their processes and operations, and driven by the community > > themselves in a ?bottom-up? fashion via consensus-based > > decision-making processes. These processes operate at the > > regional level to create policies that address regional needs and > > interests. More rarely, they serve to create global policies > > regarding the top level of the Internet number registration > > hierarchy. These global policies are implemented by the IANA > > operator, a role currently fulfilled by ICANN. > > > > RIR policy development processes pre-date ICANN and the current > > NTIA IANA functions contract. The NTIA plays no explicit role in > > making or directing policy for the operation of those IANA > > functions relating to Internet number resources. The current > > processes and structures have resulted in excellent operation of > > the IANA functions relating to Internet number administration by > > ICANN, under policy direction from the RIR communities. > > > > > > 1. The following are priorities for the RIPE community: > > > > - There should be minimal operational change. The current > > processes for IANA operation and related policy-making are > > effective and allow for the participation of all interested parties. > > - Any new oversight mechanism should incorporate and build on > > the existing RIR community policy-making processes. > > - The RIR communities are ultimately accountable for the > > management of those IANA functions relating to management of the > > global Internet number resource pools, and this should be > > reflected in any new oversight mechanisms defined in a global > > proposal to NTIA. > > > > > > 2. A model for IANA oversight endorsed by the RIPE community > > should include the following elements: > > > > - ICANN has historically managed operation of the IANA > > functions well, and should continue to do so at this time. > > - The IANA functions operator must be answerable and > > accountable to the communities that it serves. The number > > resource community is represented in such accountability > > processes by the membership-based RIR organisations. > > - Funding arrangements to cover the staff, equipment and other > > operational costs associated with operation of the IANA functions > > should be transparent and stable. > > - Efforts should be made to maintain the IANA functions as a > > ?bundle?, managed by a single operator. > > - This does not necessarily imply a single, central point of > > oversight authority. Any proposed oversight mechanism should > > reflect the legitimate authority of different communities for > > specific functions as they relate to number resources, domain > > names and protocol parameters. > > > > > > 3. RIPE community input to the IANA Stewardship Transition > > Coordination Group (ICG), which is responsible for developing a > > global proposal to NTIA, will be developed according to the > > following process: > > > > - Discussion in the RIPE community is centralised in the RIPE > > Cooperation Working Group. > > - The RIPE community discussion will aim to produce an output > > document by 1 December 2014. > > - The RIPE Cooperation Working Group Chairs will be responsible > > for assessing community consensus on this output document. > > - This RIPE output document will be sent to the Number Resource > > Organization Executive Council (made up of the five RIR CEOs), > > who will compile a single NRO input to the ICG. > > - A representative of the NRO Number Council will confirm that > > text compiled by the NRO EC accurately reflects the output of the > > five RIR community discussions. > > - The NRO proposal will be shared with the five RIR communities > > ahead of submission to the ICG. > > - Any global proposal produced by the ICG will be conveyed back > > to the RIPE community via the RIPE Cooperation Working Group to > > allow for discussion of any objections or concerns. > > > > > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji at fuoye.edu.ng * The key to understanding is humility - my view ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Thu Sep 18 11:40:59 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 18 Sep 2014 10:40:59 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: Message-ID: On 18 Sep 2014, at 09:44, Richard Hill wrote: > For what concerns IP addresses, IANA at present publishes top level > information, for example the list of /16 IPv4 allocations at: > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml > > That list has not always been up to date regarding what happened to the > legacy (old Class A) allocations. For example it still lists 16/8 as being > allocated to Digital Equipment Corporation (DEC). But in fact DEC was > acquired by Compaq some time ago, and Compaq was then acquired by > Hewlett-Packard (HP), so 16/8 is now allocated to HP. This is correctly > shown in the ARIN WHOIS. IIUC the above IANA list essentially publishes the details of who these /8s were allocated to and when those allocations were made. For instance that list says 193/8, 194/8 and 195/8 were allocated to RIPE NCC in 1993. [I stumbled across this nugget yesterday.] But RIPE NCC wasn't incorporated until 1997. Obviously there was a RIPE NCC in the early 1990s even before it had its own distinct legal identity. 196/8 is tagged as LEGACY but is administered by AFRINIC. IMO it's useful to have that sort of historical info even though making sense of it takes a bit of effort. > So I wonder whether it wouldn't be more efficient for the NRO to publish > directly this sort of information, since the RIRs are actually the authoritative sources. I'm confused Richard. ARIN's whois -- and presumably all the other data ARIN publishes -- correctly shows who is the current holder of 16/8. Could you please explain why someone else should take responsibility for this task and how that would be more efficient? And for whom? If the NRO is to take on that role, it will need extra funding and infrastructure. Which will presumably have to come from the RIRs who are already providing the funds and infrastructure which currently supports this function. That said, there are improvements which could be made to help people identify legacy numbering resources. [Disclaimer: I'm working on a project which in part is trying to do just that and finding this out is more awkward than it should be.] That's probably a discussion for another WG, perhaps AP and/or NCC Services. It doesn't seem appropriate to this WG at all. From hph at oslo.net Thu Sep 18 12:57:59 2014 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 18 Sep 2014 12:57:59 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: Message-ID: <541ABAB7.20606@oslo.net> On 18/09/2014 11:40, Jim Reid wrote: > were allocated to RIPE NCC in 1993. (...) But RIPE NCC wasn't incorporated until 1997. Obviously there was a RIPE NCC in the early 1990s even before it had its own distinct legal identity. RIPE had its first meeting in May 1989 and according to RIPE 164 the RIPE NCC was a project of TERENA from 1. april 1992. -hph From daniel.karrenberg at ripe.net Thu Sep 18 13:24:21 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 Sep 2014 13:24:21 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <541ABAB7.20606@oslo.net> References: <541ABAB7.20606@oslo.net> Message-ID: <541AC0E5.5070701@ripe.net> On 18.09.14 12:57 , Hans Petter Holen wrote: > > RIPE had its first meeting in May 1989 and according to RIPE 164 the > RIPE NCC was a project of TERENA from 1. april 1992. I would not quite put it like that! It was rather that RARE (predecessor of TERENA) agreed to be the formal host of a project defined and governed by RIPE and above all funded by the ISPs at the time. Most of these ISPs were in fact members of RARE, but not all of them. ISPs provided specific funding for the operation of the RIPE NCC. Otherwise it would have been called RARE NCC, an organisation that I would not have considered working for. Just read the name out loud. :-) Daniel From rhill at hill-a.ch Thu Sep 18 15:55:36 2014 From: rhill at hill-a.ch (Richard Hill) Date: Thu, 18 Sep 2014 15:55:36 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: Message-ID: Please see below. Thanks and best, Richard > -----Original Message----- > From: Jim Reid [mailto:jim at rfc1035.com] > Sent: jeudi, 18. septembre 2014 11:41 > To: rhill at hill-a.ch > Cc: Chris Buckridge; RIPE Cooperation Working Group > Subject: publication of data about legacy resources > > > On 18 Sep 2014, at 09:44, Richard Hill wrote: > SNIP > > > So I wonder whether it wouldn't be more efficient for the NRO to publish > > directly this sort of information, since the RIRs are actually > the authoritative sources. > > I'm confused Richard. ARIN's whois -- and presumably all the > other data ARIN publishes -- correctly shows who is the current > holder of 16/8. Could you please explain why someone else should > take responsibility for this task and how that would be more > efficient? And for whom? Good point. So maybe all that is needed is for the RIRs to publish the blocks that are assigned to them, so that it is easy to find out which WHOIS to query. Or maybe it would suffice to have an aggregated WHOIS. >If the NRO is to take on that role, it > will need extra funding and infrastructure. Which will presumably > have to come from the RIRs who are already providing the funds > and infrastructure which currently supports this function. True. But the RIRs at present do make a financial contribution to ICANN, presumably in part to fund the IANA function for the IP addresses. SNIP From seun.ojedeji at gmail.com Thu Sep 18 16:22:26 2014 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 18 Sep 2014 15:22:26 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: Message-ID: sent from Google nexus 4 kindly excuse brevity and typos. On 18 Sep 2014 15:00, "Richard Hill" wrote: > > Good point. So maybe all that is needed is for the RIRs to publish the > blocks that are assigned to them, so that it is easy to find out which WHOIS > to query. > And you think this is currently not happening or perhaps it needs to be improved? > Or maybe it would suffice to have an aggregated WHOIS. > Same comment as above. > >If the NRO is to take on that role, it > > will need extra funding and infrastructure. Which will presumably > > have to come from the RIRs who are already providing the funds > > and infrastructure which currently supports this function. > > True. But the RIRs at present do make a financial contribution to ICANN, > presumably in part to fund the IANA function for the IP addresses. > But you want them to pay the contribution to IANA instead? Cheers! > SNIP > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at internetpolicyagency.com Fri Sep 19 13:30:20 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Fri, 19 Sep 2014 12:30:20 +0100 Subject: [cooperation-wg] Principles for a RIPE Proposal on IANA Oversight In-Reply-To: References: <4A6E9BA7-F4F3-492F-9E81-700D11DB3EA9@ripe.net> Message-ID: In message , at 10:44:01 on Thu, 18 Sep 2014, Richard Hill writes >For what concerns IP addresses, IANA at present publishes top level >information, for example the list of /16 IPv4 allocations at: > > > >That list has not always been up to date regarding what happened to the >legacy (old Class A) allocations. For example it still lists 16/8 as being >allocated to Digital Equipment Corporation (DEC). But in fact DEC was >acquired by Compaq some time ago, and Compaq was then acquired by >Hewlett-Packard (HP), so 16/8 is now allocated to HP. This is correctly >shown in the ARIN WHOIS. Some allocations do get updated though. I note that the IANA entry: 051/8 UK Government Department for Work and Pensions 1994-08 references a department which didn't exist until 2001. And originally they had it allocated to the now-defunct Department of Social Security. Therefore I conclude that updates are possible, if there's someone sufficiently motivated to follow it through. Whose role it is to do this, is a good question. However, if the RIR knows that their information is more up to date than IANA's, perhaps the RIR should be pushing it upstream (even if the body to whom it's allocated doesn't seem to care about keeping the IANA record up to date). -- Roland Perry From jim at rfc1035.com Sun Sep 21 16:13:49 2014 From: jim at rfc1035.com (Jim Reid) Date: Sun, 21 Sep 2014 15:13:49 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: Message-ID: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> On 18 Sep 2014, at 14:55, Richard Hill wrote: > So maybe all that is needed is for the RIRs to publish the > blocks that are assigned to them, so that it is easy to find out which WHOIS > to query. IANA already publishes which RIR holds which /8. Querying the IANA whois server for an IP address tells you which whois server to query for that IP address. > Or maybe it would suffice to have an aggregated WHOIS. Given that the problem seems to be satisfactorily addressed already, it's not clear what more needs to be done or why. Can you please provide a clear problem statement so we can work out what solution(s) can best deal with that? >> If the NRO is to take on that role, it >> will need extra funding and infrastructure. Which will presumably >> have to come from the RIRs who are already providing the funds >> and infrastructure which currently supports this function. > > True. But the RIRs at present do make a financial contribution to ICANN, > presumably in part to fund the IANA function for the IP addresses. Indeed. But it is not up to the RIRs or anyone else who contributes money to (part) fund IANA to define what services IANA provides. At least not yet. Maybe that'll change if/when the DoC contract goes away. From daniel.karrenberg at ripe.net Sun Sep 21 16:48:10 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sun, 21 Sep 2014 16:48:10 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> Message-ID: <541EE52A.7030401@ripe.net> On 21.09.14 16:13 , Jim Reid wrote: > On 18 Sep 2014, at 14:55, Richard Hill wrote: > >> So maybe all that is needed is for the RIRs to publish the >> blocks that are assigned to them, so that it is easy to find out which WHOIS >> to query. > > IANA already publishes which RIR holds which /8. Querying the IANA whois server for an IP address tells you which whois server to query for that IP address. Of course! I keep forgetting that IANA has a whois service. Right on the money Jim! Daniel From roland at internetpolicyagency.com Mon Sep 22 10:44:48 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Mon, 22 Sep 2014 09:44:48 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> Message-ID: In message <633C224A-AC27-4423-95E4-2765E5798C88 at rfc1035.com>, at 15:13:49 on Sun, 21 Sep 2014, Jim Reid writes >> So maybe all that is needed is for the RIRs to publish the >> blocks that are assigned to them, so that it is easy to find out which WHOIS >> to query. > >IANA already publishes which RIR holds which /8. Querying the IANA whois server for an IP address tells you which whois server to query for >that IP address. > >> Or maybe it would suffice to have an aggregated WHOIS. > >Given that the problem seems to be satisfactorily addressed already, it's not clear what more needs to be done or why. Can you please provide a >clear problem statement so we can work out what solution(s) can best deal with that? The problem is one of public confidence in the system, when as was brought to my attention a few years ago, the IANA entry for 51/8 was pointing at a UK Government Department which had ceased to exist some five years previously. Several questions then arise: Did the need for the allocation die along with the department, or was it transferred to a successor department (and if so which one and who is now the contact point). If the need did die, wouldn't be helpful to try to recover the address space. If it didn't die, why is neither the Government Department nor RIPE NCC apparently interested in the record-keeping being up to date. Five years is a very long time, and makes it look like there's no process in place to keep it up to date. When it's such a huge block of addresses, why is everyone apparently so apathetic? Some might then start jumping to conclusions and ask: If you can't keep such a small number of global records up to date, what hope is there for keeping the much larger number of smaller records up to date? Note: These aren't my questions, they are simply quite reasonable ones which concerned members of the public (or even governments) might ask. I'm not looking for answers, here. >>> If the NRO is to take on that role, it >>> will need extra funding and infrastructure. Which will presumably >>> have to come from the RIRs who are already providing the funds >>> and infrastructure which currently supports this function. >> >> True. But the RIRs at present do make a financial contribution to ICANN, >> presumably in part to fund the IANA function for the IP addresses. > >Indeed. But it is not up to the RIRs or anyone else who contributes money to (part) fund IANA to define what services IANA provides. At least >not yet. Maybe that'll change if/when the DoC contract goes away. The only service IANA needs to provide here is updating a very small number of entries comprising the /8 allocation records, when the need arises. Also note I'm not suggesting the records for 51/8 are still out of date, or need any maintenance. Nor am I suggesting that the same ideas be applied to legacy blocks smaller than a /8, because that doesn't seem to me to be anything to do with "IANA oversight". -- Roland Perry From seun.ojedeji at gmail.com Mon Sep 22 11:11:44 2014 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Mon, 22 Sep 2014 10:11:44 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> Message-ID: On Mon, Sep 22, 2014 at 9:44 AM, Roland Perry < roland at internetpolicyagency.com> wrote: > > >Indeed. But it is not up to the RIRs or anyone else who contributes > money to (part) fund IANA to define what services IANA provides. At least > >not yet. Maybe that'll change if/when the DoC contract goes away. > > The only service IANA needs to provide here is updating a very small > number of entries comprising the /8 allocation records, when the need > arises. > I think the point here is that IANA no longer assign to orgs(and somewhat transferred initial legacy spaces maintenance to RIR) and since they now only assign to RIRs the records already reflects the relevant assignments. If there is any regular update that is required, it will/should be at the RIR level because there is apparently no major changes that will happen at /8 level. [1] > Also note I'm not suggesting the records for 51/8 are still out of date, > or need any maintenance. > > Nor am I suggesting that the same ideas be applied to legacy blocks > smaller than a /8, because that doesn't seem to me to be anything to do > with "IANA oversight". > This seem to negate your call for IANA to update its records; because i think your scenario above would have been a good example. Nevertheless, i also agree that "how IANA maintain whois record is definitely not within the IANA oversight scope" but rather an operation/policy issue. (though it doesn't hurt discussing it for all its worth) Regards 1. Speaking about who maintains legacy spaces, it may be good to note that its been raised by region members why its not "just" to maintain legacy spaces with paying members money. > -- > Roland Perry > > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji at fuoye.edu.ng * The key to understanding is humility - my view ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Mon Sep 22 11:28:45 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Sep 2014 10:28:45 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> Message-ID: <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> On 22 Sep 2014, at 09:44, Roland Perry wrote: > These aren't my questions, they are simply quite reasonable ones > which concerned members of the public (or even governments) might ask. Anyone is free to ask those questions and get more than satisfactory answers Roland. As long as there's a clear and transparent mechanism for handling those sorts of queries -- ie who to ask and how to ask them -- all should be well. Though I doubt it would help. Those who make those sorts of questions are generally looking for a stick studded with rusty nails to beat any Internet governance body. When they find one stick no longer works, they just move on and find another. Repeat ad nauseam. I suppose it might help if there's something which explains that the prime responsibility for maintaining timely and accurate contact data rests with the address holder, not IANA or the RIR. They can intervene when there's a problem. From roland at internetpolicyagency.com Mon Sep 22 11:34:46 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Mon, 22 Sep 2014 10:34:46 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> Message-ID: In message , at 10:11:44 on Mon, 22 Sep 2014, Seun Ojedeji writes >>The only service IANA needs to provide here is updating a very small >>number of entries comprising the /8 allocation records, when the need >>arises. > >I think the point here is that IANA no longer assign to orgs(and >somewhat transferred initial legacy spaces maintenance to RIR) and >since they now only assign to RIRs the records already reflects the >relevant assignments. If there is any regular update that is required, >it will/should be at the RIR level because there is apparently no major >changes that will happen at /8 level. If so, then the IANA table should be clearly annotated so that people know that the "Designation" for these non-RIR legacy entries is the name of the organisation that the allocation was *originally* made to. Although because 51/8 has been updated to say "UK Government Department for Work and Pensions", that isn't actually true. -- Roland Perry From jim at rfc1035.com Mon Sep 22 11:46:23 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Sep 2014 10:46:23 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> Message-ID: <5C133E8B-8390-48F8-93D3-1F5AB641BEAC@rfc1035.com> On 22 Sep 2014, at 10:34, Roland Perry wrote: > If so, then the IANA table should be clearly annotated so that people know that the "Designation" for these non-RIR legacy entries is the name of the organisation that the allocation was *originally* made to. That just provides other sticks: "what happened to 16/8 after DEC died?", "why is Stanford University listed as holding 28/8 when it no longer uses that space?", "when will MIT hand back 18/8?" etc, etc. From roland at internetpolicyagency.com Mon Sep 22 11:45:07 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Mon, 22 Sep 2014 10:45:07 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> Message-ID: In message <96C31A09-3BFF-4733-AA62-660722537FA8 at rfc1035.com>, at 10:28:45 on Mon, 22 Sep 2014, Jim Reid writes >On 22 Sep 2014, at 09:44, Roland Perry wrote: > >> These aren't my questions, they are simply quite reasonable ones >> which concerned members of the public (or even governments) might ask. > >Anyone is free to ask those questions and get more than satisfactory >answers Roland. Sometimes the answers aren't what they'd regard as satisfactory, though. >As long as there's a clear and transparent mechanism for handling those >sorts of queries -- ie who to ask and how to ask them -- all should be >well. Precisely. Most of those questions were about 'governance', which is why the mechanisms you mention should be revisited as part of a process of recasting IANA's oversight. >Though I doubt it would help. Those who make those sorts of questions >are generally looking for a stick studded with rusty nails to beat any >Internet governance body. When they find one stick no longer works, >they just move on and find another. Repeat ad nauseam. That's politics, which you'll never get rid of. Although sometimes real engineers want to know is in charge of a block of numbers, and get a bit frustrated when the data is so obviously out of date (and hence of no use). >I suppose it might help if there's something which explains that the >prime responsibility for maintaining timely and accurate contact data >rests with the address holder, not IANA or the RIR. They can intervene >when there's a problem. What does the enquirer do when the holding entity mentioned (eg on IANA's list of /8's no longer exists (Like the UK's Department of Social Security). -- Roland Perry From jim at rfc1035.com Mon Sep 22 12:25:34 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Sep 2014 11:25:34 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> Message-ID: <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> On 22 Sep 2014, at 10:45, Roland Perry wrote: > the mechanisms you mention should be revisited as part of a process of recasting IANA's oversight. Good point. Though I don't care enough about that to feed it in to the current discussion on IANA oversight. Maybe someone else does. > What does the enquirer do when the holding entity mentioned (eg on IANA's list of /8's no longer exists (Like the UK's Department of Social Security). Well, we both know that for this specific case Roland the holding entity does still exist. It just has a different name. To answer in more general terms for these sorts of questions, IANA could say "We issued FOO/8 to BAR on DATE and here's the contact info we got at the time. We understand that FUBAR is the current address holder and contact for FOO/8. For FOO/16 or FOO/24, that's legacy space which is now overseen by the RIRs and $RIR for the address block in question." BTW, I'm still struggling to understand why real engineers would need to care about the name of the organisation that holds some address space. If Bad Things are happening with 51/8 (say) I doubt it matters if the address holder is called the Department of (Health and) Social Security or the Department for Work and Pensions. From roland at internetpolicyagency.com Mon Sep 22 14:06:30 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Mon, 22 Sep 2014 13:06:30 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> Message-ID: In message <9D519571-6D19-4C70-81EE-928D5D804C01 at rfc1035.com>, at 11:25:34 on Mon, 22 Sep 2014, Jim Reid writes >> What does the enquirer do when the holding entity mentioned (eg on >>IANA's list of /8's no longer exists (Like the UK's Department of >>Social Security). > >Well, we both know that for this specific case Roland the holding >entity does still exist. It just has a different name. Not really. The entity has been "reorganised", the address allocation used elsewhere within government via various departments concerned with "delivery" of government services. It's actually quite messy. >To answer in more general terms for these sorts of questions, IANA >could say "We issued FOO/8 to BAR on DATE and here's the contact info >we got at the time. So far so good. >We understand that FUBAR is the current address holder and contact for >FOO/8. This is the crux - how does IANA come to the understanding? >For FOO/16 or FOO/24, that's legacy space which is now overseen by the >RIRs and $RIR for the address block in question." Again, this thread isn't about resources smaller than /8. >BTW, I'm still struggling to understand why real engineers would need >to care about the name of the organisation that holds some address >space. If Bad Things are happening with 51/8 (say) I doubt it matters >if the address holder is called the Department of (Health and) Social >Security or the Department for Work and Pensions. But it does matter if (one or more of): The building whose address is mentioned has closed, the phone numbers and emails don't work any more, the named person has retired, the addresses appear to be used by completely different bits of the government as well. -- Roland Perry From roland at internetpolicyagency.com Mon Sep 22 14:14:47 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Mon, 22 Sep 2014 13:14:47 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <5C133E8B-8390-48F8-93D3-1F5AB641BEAC@rfc1035.com> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <5C133E8B-8390-48F8-93D3-1F5AB641BEAC@rfc1035.com> Message-ID: In message <5C133E8B-8390-48F8-93D3-1F5AB641BEAC at rfc1035.com>, at 10:46:23 on Mon, 22 Sep 2014, Jim Reid writes >On 22 Sep 2014, at 10:34, Roland Perry wrote: > >> If so, then the IANA table should be clearly annotated so that people >>know that the "Designation" for these non-RIR legacy entries is the >>name of the organisation that the allocation was *originally* made to. > >That just provides other sticks: "what happened to 16/8 after DEC >died?", That's Richard Hill's question, and the answer has to lie somewhere within the successor companies to whom various aspects of the business were transferred/sold. If it was broken up, then perhaps the listing should be removed from IANA's /8 table, and re-documented in smaller fragments to relevant RIRs. If it's still under one entity's overall control, why can't IANA tell us [ARIN knows, it's claimed]. >"why is Stanford University listed as holding 28/8 when it no longer >uses that space?", "when will MIT hand back 18/8?" etc, etc. As far as I know both of those still exist, and maybe the listed contacts are even traceable (I haven't tried, but it seems more likely than the other examples here). Questions like "why does MIT have more address space than the whole of China" would be even harder to debunk if MIT had in fact ceased to exist, and this wasn't recorded somewhere easy-to-find at IANA. -- Roland Perry From jim at rfc1035.com Mon Sep 22 14:28:24 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Sep 2014 13:28:24 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> Message-ID: <35B3918F-26C3-4450-9196-B93EFADF9E17@rfc1035.com> On 22 Sep 2014, at 13:06, Roland Perry wrote: >> Well, we both know that for this specific case Roland the holding entity does still exist. It just has a different name. > > Not really. The entity has been "reorganised", the address allocation used elsewhere within government via various departments concerned with "delivery" of government services. It's actually quite messy. True. But that's internal detail for the address holder which is nobody else's business. >> We understand that FUBAR is the current address holder and contact for FOO/8. > > This is the crux - how does IANA come to the understanding? It could poll the holders of these /8s once a year. Or ask them to keep the info about those allocations up to date. No big deal. There are only a handful of /8s which could be problematical. And since IPv4 is just about used up, it's hard to see why anyone should be worrying about those legacy /8s. As I said before, if someone thinks this really matters, they are welcome to feed their concerns into the IANA oversight discussions. > But it does matter if (one or more of): The building whose address is mentioned has closed, the phone numbers and emails don't work any more, the named person has retired, the addresses appear to be used by completely different bits of the government as well. Yeah. But this is no different from a teeny subset of the problem space for whois in the context of domain names. All of the above concerns (and more) exist for domain names. The world just has to cope with that, even if the answers are not to everyone's liking. Frankly, I think it's a waste of time focusing on whois at all. IMO what we should be concentrating on is how concerned stakeholders get access to timely and accurate data about holders of Internet resources in general. whois is not the answer. It's just not up to the job and was never intended to provide the functionality some people expect it to provide today. However this takes us well into layer 9+ territory where any mention of the w-word results in screaming and endless pain. From nick at inex.ie Mon Sep 22 17:07:36 2014 From: nick at inex.ie (Nick Hilliard) Date: Mon, 22 Sep 2014 16:07:36 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> Message-ID: <54203B38.8050000@inex.ie> On 22/09/2014 11:25, Jim Reid wrote: > BTW, I'm still struggling to understand why real engineers would need to > care about the name of the organisation that holds some address space. as far as I was aware, this is the entire point of a RIR - to ensure accurate registration details of address holders. Did I miss something? Nick From jim at rfc1035.com Mon Sep 22 17:25:10 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Sep 2014 16:25:10 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <54203B38.8050000@inex.ie> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> Message-ID: On 22 Sep 2014, at 16:07, Nick Hilliard wrote: > as far as I was aware, this is the entire point of a RIR - to ensure accurate registration details of address holders. Did I miss something? Well the discussion seems to be about a handful of legacy /8s where IANA holds the registration details, not an RIR. Unless I'm more confused than usual, the accuracy of the registration details for 51/8 (say) are not a matter for RIPE or the NCC. Maybe they should be. But that's another discussion altogether. Probably. BTW, that /8 has never been routed on the Internet (bogus announcements excepted) and probably never will be. That's why I'm so doubtful if it matters operationally what the name of the organisation holding that space happens to be this week. After all, it's not as if one of the biggest departments of Her Majesty's Government is well hidden. YMMV. From nick at inex.ie Mon Sep 22 17:52:24 2014 From: nick at inex.ie (Nick Hilliard) Date: Mon, 22 Sep 2014 16:52:24 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> Message-ID: <542045B8.7060906@inex.ie> On 22/09/2014 16:25, Jim Reid wrote: > Unless I'm more confused than usual, the accuracy of the registration details for 51/8 (say) are not a matter for RIPE or the NCC. Maybe they should be. But that's another discussion altogether. Probably. ripe-605: -- The RIPE NCC maintains and publishes registry data for resources held by its members and by legacy resource holders located in the RIPE NCC service area. It strives to maintain the accuracy of these data. -- Probably it would sensible for IANA to record these assignments as legacy and point them to the correct RIR rather than maintaining the original assignee. Stale information is worse than a pointer to correct info. Nick From andrew.dul at quark.net Mon Sep 22 17:51:24 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 22 Sep 2014 08:51:24 -0700 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> Message-ID: <5420457C.5050408@quark.net> On 9/22/2014 8:25 AM, Jim Reid wrote: > On 22 Sep 2014, at 16:07, Nick Hilliard wrote: > >> as far as I was aware, this is the entire point of a RIR - to ensure accurate registration details of address holders. Did I miss something? > Well the discussion seems to be about a handful of legacy /8s where IANA holds the registration details, not an RIR. > > Unless I'm more confused than usual, the accuracy of the registration details for 51/8 (say) are not a matter for RIPE or the NCC. Maybe they should be. But that's another discussion altogether. Probably. > > BTW, that /8 has never been routed on the Internet (bogus announcements excepted) and probably never will be. That's why I'm so doubtful if it matters operationally what the name of the organisation holding that space happens to be this week. After all, it's not as if one of the biggest departments of Her Majesty's Government is well hidden. YMMV. > > Perhaps the better question to ask is if the Internet community wants to keep the organizational names in the /8 IANA records or if that information should just be moved to the RIRs and the /8 records should be updated to reflect the RIR which is managing the /8 record. (I personally think it would probably be better to just move the ORG records to the RIRs) If we don't really want the organizational record in the IANA registry any more for the /8s, then we should instruct IANA to update the records in a way the community desires. Andrew From roland at internetpolicyagency.com Tue Sep 23 10:10:25 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Tue, 23 Sep 2014 09:10:25 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <35B3918F-26C3-4450-9196-B93EFADF9E17@rfc1035.com> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <35B3918F-26C3-4450-9196-B93EFADF9E17@rfc1035.com> Message-ID: In message <35B3918F-26C3-4450-9196-B93EFADF9E17 at rfc1035.com>, at 13:28:24 on Mon, 22 Sep 2014, Jim Reid writes >On 22 Sep 2014, at 13:06, Roland Perry wrote: > >>> Well, we both know that for this specific case Roland the holding >>>entity does still exist. It just has a different name. >> >> Not really. The entity has been "reorganised", the address allocation >>used elsewhere within government via various departments concerned >>with "delivery" of government services. It's actually quite messy. > >True. But that's internal detail for the address holder which is nobody >else's business. Sounds to me more like a transfer to me; the original address-holder was one specified department, not the whole of HM Government. Perhaps it would have saved a lot of grief if the original allocation had been to the latter in the first place. >>> We understand that FUBAR is the current address holder and contact >>>for FOO/8. >> >> This is the crux - how does IANA come to the understanding? > >It could poll the holders of these /8s once a year. Or ask them to keep >the info about those allocations up to date. No big deal. There are >only a handful of /8s which could be problematical. And since IPv4 is >just about used up, it's hard to see why anyone should be worrying >about those legacy /8s. As I said before, if someone thinks this really >matters, they are welcome to feed their concerns into the IANA >oversight discussions. Perhaps they will. >> But it does matter if (one or more of): The building whose address is >>mentioned has closed, the phone numbers and emails don't work any >>more, the named person has retired, the addresses appear to be used by >>completely different bits of the government as well. > >Yeah. But this is no different from a teeny subset of the problem space >for whois in the context of domain names. All of the above concerns >(and more) exist for domain names. The world just has to cope with >that, even if the answers are not to everyone's liking. In the case of /8's it's more like an entire ccTLD going off the grid. >Frankly, I think it's a waste of time focusing on whois at all. The entries in IANA's /8 table aren't really a whois, they are a hint at what one of the lines in the whois might be. -- Roland Perry From roland at internetpolicyagency.com Tue Sep 23 13:40:12 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Tue, 23 Sep 2014 12:40:12 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <5420457C.5050408@quark.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> Message-ID: In message <5420457C.5050408 at quark.net>, at 08:51:24 on Mon, 22 Sep 2014, Andrew Dul writes >If we don't really want the organizational record in the IANA registry >any more for the /8s, Which might be a good idea. >then we should instruct IANA to update the records in a way the >community desires. Who are "we", and which community? How do you make IANA comply? And if they don't, what sort of oversight mechanism needs to be in place to escalate it to. ps There are also two /8's with a blank in the fourth column (053/8 & 057/8) so they need solving somehow. -- Roland Perry From nick at inex.ie Tue Sep 23 13:55:36 2014 From: nick at inex.ie (Nick Hilliard) Date: Tue, 23 Sep 2014 12:55:36 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> Message-ID: <54215FB8.9070205@inex.ie> On 23/09/2014 12:40, Roland Perry wrote: > How do you make IANA comply? iana will act on a request from the ietf. Nick From roland at internetpolicyagency.com Tue Sep 23 15:45:20 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Tue, 23 Sep 2014 14:45:20 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <54215FB8.9070205@inex.ie> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> Message-ID: In message <54215FB8.9070205 at inex.ie>, at 12:55:36 on Tue, 23 Sep 2014, Nick Hilliard writes >> How do you make IANA comply? > >iana will act on a request from the ietf. Does that mean the ietf is the long term oversight mechanism? -- Roland Perry From andrew.dul at quark.net Tue Sep 23 16:37:27 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 23 Sep 2014 07:37:27 -0700 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> Message-ID: <542185A7.8050803@quark.net> On 9/23/2014 4:40 AM, Roland Perry wrote: > In message <5420457C.5050408 at quark.net>, at 08:51:24 on Mon, 22 Sep > 2014, Andrew Dul writes > >> If we don't really want the organizational record in the IANA registry >> any more for the /8s, > > Which might be a good idea. > >> then we should instruct IANA to update the records in a way the >> community desires. > > Who are "we", and which community? > You and me, and the other interested parties in the internet community. We set internet number policy for the resources. > How do you make IANA comply? And if they don't, what sort of oversight > mechanism needs to be in place to escalate it to. We can ask IANA on the status of managing these records and if there is anything they are currently working on to make these records more up to date. If the current policy does not allow them to update the records as we would like, we could put together a global policy which would instruct IANA how to manage the records. This isn't a simple or quick process, but it is the process of how iana receives its instructions from the Internet community on how to manage the resources. See: https://www.nro.net/policies/global-policies-development-process Andrew From roland at internetpolicyagency.com Wed Sep 24 10:25:20 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Wed, 24 Sep 2014 09:25:20 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <542185A7.8050803@quark.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <542185A7.8050803@quark.net> Message-ID: In message <542185A7.8050803 at quark.net>, at 07:37:27 on Tue, 23 Sep 2014, Andrew Dul writes >>> If we don't really want the organizational record in the IANA registry >>> any more for the /8s, >> >> Which might be a good idea. >> >>> then we should instruct IANA to update the records in a way the >>> community desires. >> >> Who are "we", and which community? >> >You and me, and the other interested parties in the internet community. >We set internet number policy for the resources. I see. So not whoever gets to be the new oversight body. Of course if "we" are the people running the oversight body (or perhaps it's supposed to be more *multi*stakeholder than that) then we could exert an influence via that route. >> How do you make IANA comply? And if they don't, what sort of oversight >> mechanism needs to be in place to escalate it to. > >We can ask IANA on the status of managing these records and if there is >anything they are currently working on to make these records more up to >date. > >If the current policy does not allow them to update the records as we >would like, The current policy might allow them, but for some reason they decline to update. >we could put together a global policy which would instruct IANA how to >manage the records. You are suggesting a replacement policy would place a duty on them, rather than simply allowing them to? -- Roland Perry From chrisb at ripe.net Wed Sep 24 10:46:18 2014 From: chrisb at ripe.net (Chris Buckridge) Date: Wed, 24 Sep 2014 10:46:18 +0200 Subject: [cooperation-wg] IGF community impressions of the IGF Message-ID: Dear colleagues, The RIPE NCC funded the participation of several RIPE community members at the recent Internet Governance Forum in Istanbul. We have now published an article on RIPE Labs, compiling brief interviews with three of those RIPE community participants on their experiences and thoughts on the event: https://labs.ripe.net/Members/chrisb/ripe-community-impressions-of-igf-2014 Best regards, Chris Buckridge, RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: From daniel.karrenberg at ripe.net Wed Sep 24 13:50:55 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 24 Sep 2014 13:50:55 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <54215FB8.9070205@inex.ie> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> Message-ID: <5422B01F.5020800@ripe.net> On 23.09.14 13:55 , Nick Hilliard wrote: > On 23/09/2014 12:40, Roland Perry wrote: >> How do you make IANA comply? > > iana will act on a request from the ietf. Not quite for address (read: Internet Numbers) policy: First we adopt a global policy that says how the IANA registry should look like. Then we ask the IANA to implement it. So far this has worked perfectly. In the unlikely event that the IANA should not follow global address policy, we currently have to ask the NTIA (part of the US Department of Commerce) to make the IANA comply with global address policy. The NTIA holds the IANA service contract and therefore is the party that can enforce it. NB: The oversight of the US executive branch is with the US legislative and judiciary. The whole discussion about this transition is about what mechanism will replace this contract *should* the NTIA follow through and not extend it. It appears to me that a straightforward replacement in the area of address polict would be for the RIRs to hold the contract. Oversight is already implemented thorough our existing mechanisms of regional and global policy making and implementation. Nothing to it really ..... ;-) Daniel From seun.ojedeji at gmail.com Wed Sep 24 14:03:18 2014 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Wed, 24 Sep 2014 13:03:18 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <5422B01F.5020800@ripe.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> <5422B01F.5020800@ripe.net> Message-ID: sent from Google nexus 4 kindly excuse brevity and typos. On 24 Sep 2014 12:51, "Daniel Karrenberg" wrote: > > On 23.09.14 13:55 , Nick Hilliard wrote: > > On 23/09/2014 12:40, Roland Perry wrote: > >> How do you make IANA comply? > > > > iana will act on a request from the ietf. > > Not quite for address (read: Internet Numbers) policy: > > First we adopt a global policy that says how the IANA registry should > look like. Then we ask the IANA to implement it. > +1 > So far this has worked perfectly. > > In the unlikely event that the IANA should not follow global address > policy, we currently have to ask the NTIA (part of the US Department of > Commerce) to make the IANA comply with global address policy. The NTIA > holds the IANA service contract and therefore is the party that can > enforce it. NB: The oversight of the US executive branch is with the US > legislative and judiciary. > Hmm... do you have reference for this? Because I know the GPDP is currently active as per the agreement between the NRO and IANA operator (ICANN) and as defined in the MOU if IANA(in this case ICANN) is not respecting the global policy, the manner to resolving/ensuring compliance is for the NRO/ASO to discuss with the ICANN board. I don't know of any reference that bypass that process and will be good to know if such exist. Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Wed Sep 24 15:39:31 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 24 Sep 2014 15:39:31 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> <5422B01F.5020800@ripe.net> Message-ID: <5422C993.4040606@ripe.net> On 24.09.14 14:03 , Seun Ojedeji wrote: > > Hmm... do you have reference for this? Because I know the GPDP is > currently active as per the agreement between the NRO and IANA operator > (ICANN) and as defined in the MOU if IANA(in this case ICANN) is not > respecting the global policy, the manner to resolving/ensuring > compliance is for the NRO/ASO to discuss with the ICANN board. I don't > know of any reference that bypass that process and will be good to know > if such exist. You are (also) correct. That is the other way to look at it and it is the mechanism I would prefer to use too. However the NTIA contract exists and ICANN is bound to both the NRO MoU and this contract. The reference is http://www.ntia.doc.gov/page/iana-functions-purchase-order and in particular http://www.ntia.doc.gov/other-publication/2012/icann-proposal This is a huge pile of bits. The Internet Numbers part is really almost lost in it. Daniel From chrisb at ripe.net Wed Sep 24 16:41:50 2014 From: chrisb at ripe.net (Chris Buckridge) Date: Wed, 24 Sep 2014 16:41:50 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <5422C993.4040606@ripe.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> <5422B01F.5020800@ripe.net> <5422C993.4040606@ripe.net> Message-ID: <3DD5A215-3F15-4A2B-9292-9D32DC72BBE1@ripe.net> Dear colleagues, Thank you Richard for your initial query, and to all for the many responses. To bring the focus back to the task at hand, I wanted to float a suggestion responding specifically to the question of what registration information IANA publishes. You may be aware of the draft IANA stewardship proposal that was presented to the APNIC community ahead of their recent meeting: http://blog.apnic.net/2014/08/18/next-steps-towards-the-iana-transition/ Included in this model is the development of a Service Level Agreement (SLA) between the RIRs and the IANA operator (currently ICANN), to be signed before 30 June 2015. Without pre-judging the outcome of RIPE community discussions, it seems likely that a RIPE proposal would include a similar provision. Would it address the concerns raised by Richard (and others) to include an explicit review of existing IANA services (including publication practices) in the development phase for such an SLA? Best regards, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: From seun.ojedeji at gmail.com Wed Sep 24 16:59:54 2014 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Wed, 24 Sep 2014 15:59:54 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <5422C993.4040606@ripe.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> <5422B01F.5020800@ripe.net> <5422C993.4040606@ripe.net> Message-ID: On Wed, Sep 24, 2014 at 2:39 PM, Daniel Karrenberg < daniel.karrenberg at ripe.net> wrote: > On 24.09.14 14:03 , Seun Ojedeji wrote: > > > > Hmm... do you have reference for this? Because I know the GPDP is > > currently active as per the agreement between the NRO and IANA operator > > (ICANN) and as defined in the MOU if IANA(in this case ICANN) is not > > respecting the global policy, the manner to resolving/ensuring > > compliance is for the NRO/ASO to discuss with the ICANN board. I don't > > know of any reference that bypass that process and will be good to know > > if such exist. > > You are (also) correct. That is the other way to look at it and it is > the mechanism I would prefer to use too. However the NTIA contract > exists and ICANN is bound to both the NRO MoU and this contract. > Coming back because of the "also" which still mean you believe there is another existing process by which the RIR (NRO) could charge IANA to comply aside going through the process already indicated in the NRO/ICANN MOU > > The reference is > http://www.ntia.doc.gov/page/iana-functions-purchase-order > > and in particular > http://www.ntia.doc.gov/other-publication/2012/icann-proposal > > This is a huge pile of bits. The Internet Numbers part is really almost > lost in it. > Good you know this is just a contract and does not specify the details of how NRO resolve IANA's "possible" non-compliance with global policies...those are clearly indicated in the signed MOU. Cheers! > > > Daniel > > > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji at fuoye.edu.ng * The key to understanding is humility - my view ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Wed Sep 24 17:02:13 2014 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Wed, 24 Sep 2014 16:02:13 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <3DD5A215-3F15-4A2B-9292-9D32DC72BBE1@ripe.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> <5422B01F.5020800@ripe.net> <5422C993.4040606@ripe.net> <3DD5A215-3F15-4A2B-9292-9D32DC72BBE1@ripe.net> Message-ID: On Wed, Sep 24, 2014 at 3:41 PM, Chris Buckridge wrote: > Dear colleagues, > > You may be aware of the draft IANA stewardship proposal that was presented > to the APNIC community ahead of their recent meeting: > http://blog.apnic.net/2014/08/18/next-steps-towards-the-iana-transition/ > > Included in this model is the development of a Service Level Agreement > (SLA) between the RIRs and the IANA operator (currently ICANN), to be > signed before 30 June 2015. Could you be kind to provide the direct url to this proposal? Thanks -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji at fuoye.edu.ng * The key to understanding is humility - my view ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Wed Sep 24 17:09:54 2014 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 24 Sep 2014 08:09:54 -0700 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <542185A7.8050803@quark.net> Message-ID: <5422DEC2.2030208@quark.net> On 9/24/2014 1:25 AM, Roland Perry wrote: > In message <542185A7.8050803 at quark.net>, at 07:37:27 on Tue, 23 Sep > 2014, Andrew Dul writes >>>> If we don't really want the organizational record in the IANA registry >>>> any more for the /8s, >>> >>> Which might be a good idea. >>> >>>> then we should instruct IANA to update the records in a way the >>>> community desires. >>> >>> Who are "we", and which community? >>> >> You and me, and the other interested parties in the internet community. >> We set internet number policy for the resources. > > I see. So not whoever gets to be the new oversight body. Of course if > "we" are the people running the oversight body (or perhaps it's > supposed to be more *multi*stakeholder than that) then we could exert > an influence via that route. > >>> How do you make IANA comply? And if they don't, what sort of oversight >>> mechanism needs to be in place to escalate it to. >> >> We can ask IANA on the status of managing these records and if there is >> anything they are currently working on to make these records more up to >> date. >> >> If the current policy does not allow them to update the records as we >> would like, > > The current policy might allow them, but for some reason they decline > to update. I would say the current policy is moot about how the records should be recorded. https://aso.icann.org/global-policies/global-policies-2/ > >> we could put together a global policy which would instruct IANA how >> to manage the records. > > You are suggesting a replacement policy would place a duty on them, > rather than simply allowing them to? I suppose the policy document could be constructed either way. Ideally we would have the conversation about variables in the policy language at the time we are figuring out exactly what the Internet community wants to see in the IANA v4 registry. Andrew From chrisb at ripe.net Wed Sep 24 17:25:29 2014 From: chrisb at ripe.net (Chris Buckridge) Date: Wed, 24 Sep 2014 17:25:29 +0200 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> <5422B01F.5020800@ripe.net> <5422C993.4040606@ripe.net> <3DD5A215-3F15-4A2B-9292-9D32DC72BBE1@ripe.net> Message-ID: <094695A8-E718-4902-95F5-54083049A099@ripe.net> On 24 Sep 2014, at 17:02, Seun Ojedeji wrote: > On Wed, Sep 24, 2014 at 3:41 PM, Chris Buckridge wrote: > Dear colleagues, > > You may be aware of the draft IANA stewardship proposal that was presented to the APNIC community ahead of their recent meeting: > http://blog.apnic.net/2014/08/18/next-steps-towards-the-iana-transition/ > > Included in this model is the development of a Service Level Agreement (SLA) between the RIRs and the IANA operator (currently ICANN), to be signed before 30 June 2015. > > Could you be kind to provide the direct url to this proposal? The only version I can find online is in a slide deck from the APNIC meeting session. The draft proposal is on slide 13: http://www.slideshare.net/apnic/iana-stewardship-transition-consultaion-apnic-38 Hope this helps! Regards, Chris > > Thanks > -- > ------------------------------------------------------------------------ > Seun Ojedeji, > Federal University Oye-Ekiti > web: http://www.fuoye.edu.ng > Mobile: +2348035233535 > alt email: seun.ojedeji at fuoye.edu.ng > > The key to understanding is humility - my view ! > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: From seun.ojedeji at gmail.com Wed Sep 24 17:36:50 2014 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Wed, 24 Sep 2014 16:36:50 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <094695A8-E718-4902-95F5-54083049A099@ripe.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <54215FB8.9070205@inex.ie> <5422B01F.5020800@ripe.net> <5422C993.4040606@ripe.net> <3DD5A215-3F15-4A2B-9292-9D32DC72BBE1@ripe.net> <094695A8-E718-4902-95F5-54083049A099@ripe.net> Message-ID: Yes it does help. Re: The draft proposal; I somewhat agree with the actionable but the content produced after the review is what will really determine how well. Secondly perhaps a legal person would care to explain how binding an Affirmation of commitment (AoC) could really be. i.e Does the terms really carry any form of "force" with it (things like you have no choice than to abide with the terms we agreed upon unless you want to stop being the operator of our function) Thanks On Wed, Sep 24, 2014 at 4:25 PM, Chris Buckridge wrote: > > On 24 Sep 2014, at 17:02, Seun Ojedeji wrote: > > > On Wed, Sep 24, 2014 at 3:41 PM, Chris Buckridge > wrote: > > Dear colleagues, > > > > You may be aware of the draft IANA stewardship proposal that was > presented to the APNIC community ahead of their recent meeting: > > http://blog.apnic.net/2014/08/18/next-steps-towards-the-iana-transition/ > > > > Included in this model is the development of a Service Level Agreement > (SLA) between the RIRs and the IANA operator (currently ICANN), to be > signed before 30 June 2015. > > > > Could you be kind to provide the direct url to this proposal? > > The only version I can find online is in a slide deck from the APNIC > meeting session. The draft proposal is on slide 13: > > http://www.slideshare.net/apnic/iana-stewardship-transition-consultaion-apnic-38 > > Hope this helps! > > Regards, > Chris > > > > > Thanks > > -- > > ------------------------------------------------------------------------ > > Seun Ojedeji, > > Federal University Oye-Ekiti > > web: http://www.fuoye.edu.ng > > Mobile: +2348035233535 > > alt email: seun.ojedeji at fuoye.edu.ng > > > > The key to understanding is humility - my view ! > > > > -- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng Mobile: +2348035233535**alt email: seun.ojedeji at fuoye.edu.ng * The key to understanding is humility - my view ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at internetpolicyagency.com Wed Sep 24 21:12:59 2014 From: roland at internetpolicyagency.com (Roland Perry) Date: Wed, 24 Sep 2014 20:12:59 +0100 Subject: [cooperation-wg] publication of data about legacy resources In-Reply-To: <5422DEC2.2030208@quark.net> References: <633C224A-AC27-4423-95E4-2765E5798C88@rfc1035.com> <96C31A09-3BFF-4733-AA62-660722537FA8@rfc1035.com> <9D519571-6D19-4C70-81EE-928D5D804C01@rfc1035.com> <54203B38.8050000@inex.ie> <5420457C.5050408@quark.net> <542185A7.8050803@quark.net> <5422DEC2.2030208@quark.net> Message-ID: In message <5422DEC2.2030208 at quark.net>, at 08:09:54 on Wed, 24 Sep 2014, Andrew Dul writes >>> we could put together a global policy which would instruct IANA how >>> to manage the records. >> >> You are suggesting a replacement policy would place a duty on them, >> rather than simply allowing them to? > >I suppose the policy document could be constructed either way. Ideally >we would have the conversation about variables in the policy language at >the time we are figuring out exactly what the Internet community wants >to see in the IANA v4 registry. The Internet community is not the only one which might have "wants". Unless we think that anyone who ever used the Internet is part of the community. A lot of people apparently see an invisible 'technical' in between 'Internet' and 'community', rather than for example an invisible 'user', who traditionally doesn't get much say in any of the discussions. -- Roland Perry