From v.giotsas at lancaster.ac.uk Mon Jan 6 17:09:25 2020 From: v.giotsas at lancaster.ac.uk (Giotsas, Vasileios) Date: Mon, 6 Jan 2020 16:09:25 +0000 Subject: [address-policy-wg] FW: ASNs of organizations in reported IPv4 transfers Message-ID: Hello everyone, I'm a researcher from Lancaster University (UK) studying the IPv4 transfer market, and I'm trying to correlate IPv4 transfers with BGP routing dynamics. I've collected the reported transfers but they list only owner organizations names and not AS numbers (ASN). Same with the reported transfers of other RIRs. I tried to map the organization names to ASNs using WHOIS but I couldn?t find a match for about 50% of the organizations involved in transfers. What is the rationale behind not listing the AS number? Is it because organizations without an ASN (e.g. enterprise networks) can obtain an address? Is there a suggested way of mapping the organizations to ASNs besides WHOIS lookup? Thank you and best wishes for 2020! Vasileios Giotsas Lecturer School of Computing and Communications Lancaster University ? 01524 595130 https://bit.ly/LancsGiotsas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue Jan 7 07:07:53 2020 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Jan 2020 06:07:53 +0000 Subject: [address-policy-wg] FW: ASNs of organizations in reported IPv4 transfers In-Reply-To: References: Message-ID: > On 6 Jan 2020, at 16:09, Giotsas, Vasileios wrote: > > I tried to map the organization names to ASNs using WHOIS but I couldn?t find a match for about 50% of the organizations involved in transfers. What is the rationale behind not listing the AS number? Because it's not rational or meaningful to do that. There's no reason to assume that there's a static, unchanging binding between address space and an ASN. Whatever ASN is associated with some address block today (if there is one) might not be associated with that block tomorrow. Or an organisation might buy transit from two (or more) providers and have each of them use their ASNs when announcing routes for that organisation's address block(s). Also, the RIRs only issue an ASN when a network is multi-homed: ie connected to more than one external network. See RIPE 679. It's possible the recipients of some of the transfers you found might not have multi-homed networks. Which would mean there was no relevant ASN for these to include in the transfer database. > Is it because organizations without an ASN (e.g. enterprise networks) can obtain an address? Organisations generally only need an ASN if they intend to do BGP and manage external routing by themselves. Sometimes an organisation will "outsource" routing and BGP operations to a third party -- for instance buying transit from an upstream provider -- and therefore won't really need their own ASN. [This is what your university does. Its address space seems to sit behind JANET's ASN and doesn't appear to have its own - just like most/all UK universities.] In other cases, an organisation could use globally unique IP addresses for their internal network. In that case, they'd have no reason to route these addresses on the public Internet => no need for an ASN. > Is there a suggested way of mapping the organizations to ASNs besides WHOIS lookup? whois is never the answer. Avoid. Use ripestat. This will probably have answers for all/most of the research data you are looking for. From randy at psg.com Tue Jan 7 07:39:25 2020 From: randy at psg.com (Randy Bush) Date: Mon, 06 Jan 2020 22:39:25 -0800 Subject: [address-policy-wg] FW: ASNs of organizations in reported IPv4 transfers In-Reply-To: References: Message-ID: > Because it's not rational or meaningful to do that. There's no reason > to assume that there's a static, unchanging binding between address > space and an ASN. if there was, we would not need routing :) further, there is no actual _routing_ binding of an AS to a member LIR identity. i.e. an LIR may have no ASs, or multiple ASs. address space 'belonging' to an LIR might be legitimately announced by an AS belonging to a different LIR. from a research point of view, one might ask whether these confounding complications are sufficiently prevalent to obscure the signal which vasileios seeks. [ persoanlly, i would not go down this capybara hole ] randy From v.giotsas at lancaster.ac.uk Wed Jan 8 02:08:35 2020 From: v.giotsas at lancaster.ac.uk (Giotsas, Vasileios) Date: Wed, 8 Jan 2020 01:08:35 +0000 Subject: [address-policy-wg] [External] Re: FW: ASNs of organizations in reported IPv4 transfers In-Reply-To: References: Message-ID: Thank you both for your responses! > There's no reason to assume that there's a static, unchanging binding between address space and an ASN. That's a good point, but I didn't assume there's a static unchanged binding but a binding at the moment of the transfer. If an organization with an ASN acquires an address block I assumed that in case they want to change ASN and keep using the same addresses they need to transfer the addresses (many of the transfers appear to be between "sibling" organizations). > It's possible the recipients of some of the transfers you found might not have multi-homed networks. Which would mean there was no relevant ASN for these to include in the transfer database. I guess that explains why often the origin ASN in BGP doesn't change after the transfer. > Use ripestat. This will probably have answers for all/most of the research data you are looking for. I'll definitely try the RIPE stat API, I assumed for my organization names it just provided a layer over WHOIS > further, there is no actual _routing_ binding of an AS to a member LIR identity. i.e. an LIR may have no ASs, or multiple ASs. Maybe using the extended RIR delegation reports can help me find such LIRs > [ personally, i would not go down this capybara hole ] Too late for me :) -----Original Message----- From: Randy Bush Sent: 07 January 2020 06:39 To: Jim Reid Cc: Giotsas, Vasileios ; address-policy-wg at ripe.net Subject: [External] Re: [address-policy-wg] FW: ASNs of organizations in reported IPv4 transfers This email originated outside the University. Check before clicking links or attachments. > Because it's not rational or meaningful to do that. There's no reason > to assume that there's a static, unchanging binding between address > space and an ASN. if there was, we would not need routing :) further, there is no actual _routing_ binding of an AS to a member LIR identity. i.e. an LIR may have no ASs, or multiple ASs. address space 'belonging' to an LIR might be legitimately announced by an AS belonging to a different LIR. from a research point of view, one might ask whether these confounding complications are sufficiently prevalent to obscure the signal which vasileios seeks. [ persoanlly, i would not go down this capybara hole ] randy From mschmidt at ripe.net Wed Jan 8 12:20:53 2020 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 8 Jan 2020 12:20:53 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) Message-ID: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> Dear colleagues, Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is now in the extended Review Phase. This proposal aims to remove obsoleted text and simplify the IPv6 policy. You can find the full proposal and the RIPE NCC impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-06 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-06/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week extended Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 6 February 2020. Kind regards, Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC From gert at space.net Wed Jan 8 13:34:48 2020 From: gert at space.net (Gert Doering) Date: Wed, 8 Jan 2020 13:34:48 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> Message-ID: <20200108123448.GG72330@Space.Net> Dear WG, On Wed, Jan 08, 2020 at 12:20:53PM +0100, Marco Schmidt wrote: > Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is > now in the extended Review Phase. This proposal got support in discussion phase, but no comments whatsoever in review phase. Based on this, we cannot advance it, even if chairs and proposer think it is reasonable and had support beforehand... So, please have a look and express your opinion - continued support, or disagreement. thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ripe at liopen.fr Wed Jan 8 13:45:46 2020 From: ripe at liopen.fr (Denis Fondras - Liopen) Date: Wed, 8 Jan 2020 13:45:46 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <20200108123448.GG72330@Space.Net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <20200108123448.GG72330@Space.Net> Message-ID: <20200108124546.GF75696@carcass.ledeuns.net> On Wed, Jan 08, 2020 at 01:34:48PM +0100, Gert Doering wrote: > Dear WG, > > On Wed, Jan 08, 2020 at 12:20:53PM +0100, Marco Schmidt wrote: > > Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is > > now in the extended Review Phase. > > This proposal got support in discussion phase, but no comments whatsoever > in review phase. Based on this, we cannot advance it, even if chairs > and proposer think it is reasonable and had support beforehand... > I fully support this proposal. -- Denis Fondras / Liopen Mob: +33.761.029.186 M?l: contact at liopen.fr PGP: 0xF7D4828559706135 From nick at foobar.org Wed Jan 8 17:12:34 2020 From: nick at foobar.org (Nick Hilliard) Date: Wed, 8 Jan 2020 16:12:34 +0000 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <20200108123448.GG72330@Space.Net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <20200108123448.GG72330@Space.Net> Message-ID: Gert Doering wrote on 08/01/2020 12:34: > This proposal got support in discussion phase, but no comments whatsoever > in review phase. Based on this, we cannot advance it, even if chairs > and proposer think it is reasonable and had support beforehand... Looks fine - I support this. Nick From Piotr.Strzyzewski at polsl.pl Wed Jan 8 20:52:38 2020 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 8 Jan 2020 20:52:38 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <20200108123448.GG72330@Space.Net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <20200108123448.GG72330@Space.Net> Message-ID: <20200108195238.GA31313@hydra.ck.polsl.pl> On Wed, Jan 08, 2020 at 01:34:48PM +0100, Gert Doering wrote: > On Wed, Jan 08, 2020 at 12:20:53PM +0100, Marco Schmidt wrote: > > Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is > > now in the extended Review Phase. > > This proposal got support in discussion phase, but no comments whatsoever > in review phase. Based on this, we cannot advance it, even if chairs > and proposer think it is reasonable and had support beforehand... > > So, please have a look and express your opinion - continued support, or > disagreement. Support. -- Piotr Strzy?ewski From randy at psg.com Thu Jan 9 02:23:24 2020 From: randy at psg.com (Randy Bush) Date: Wed, 08 Jan 2020 17:23:24 -0800 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <20200108123448.GG72330@Space.Net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <20200108123448.GG72330@Space.Net> Message-ID: sorry. as it has not changed, my opinion has not ( yes, sometimes it does :). so i still support it. randy From swmike at swm.pp.se Thu Jan 9 10:42:26 2020 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 9 Jan 2020 10:42:26 +0100 (CET) Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <20200108123448.GG72330@Space.Net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <20200108123448.GG72330@Space.Net> Message-ID: On Wed, 8 Jan 2020, Gert Doering wrote: > So, please have a look and express your opinion - continued support, or > disagreement. I support this. -- Mikael Abrahamsson email: swmike at swm.pp.se From mschmidt at ripe.net Thu Jan 9 15:59:56 2020 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 9 Jan 2020 15:59:56 +0100 Subject: [address-policy-wg] 2019-07 Policy Proposal Withdrawn (Default assignment size for IXPs) Message-ID: <7d2a8634-a906-d7e9-191b-496d2d8ddd64@ripe.net> Dear colleagues, The policy proposal 2019-07, "Default assignment size for IXPs" has been withdrawn. This proposal aimed to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposer felt that there was no clear direction on how to proceed with the proposal. Kind regards, Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC From tore at fud.no Sat Jan 11 11:43:06 2020 From: tore at fud.no (Tore Anderson) Date: Sat, 11 Jan 2020 11:43:06 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <20200108123448.GG72330@Space.Net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <20200108123448.GG72330@Space.Net> Message-ID: * Gert Doering > So, please have a look and express your opinion - continued support, or > disagreement. Support. Tore From ripe-wgs at radu-adrian.feurdean.net Mon Jan 13 17:11:34 2020 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 13 Jan 2020 17:11:34 +0100 Subject: [address-policy-wg] =?utf-8?q?2019-06_Review_Phase_Extended_=28M?= =?utf-8?q?ultiple_Editorial_Changes_in_IPv6_Policy=29?= In-Reply-To: <20200108123448.GG72330@Space.Net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <20200108123448.GG72330@Space.Net> Message-ID: <20abfdb8-64d4-4fba-9d1d-b50c6cb49201@www.fastmail.com> On Wed, Jan 8, 2020, at 13:34, Gert Doering wrote: > So, please have a look and express your opinion - continued support, or > disagreement. Support. -- Radu-Adrian FEURDEAN From abdullahcemil.akcam at btk.gov.tr Mon Jan 13 18:08:04 2020 From: abdullahcemil.akcam at btk.gov.tr (=?iso-8859-3?Q?Abdullah_Cemil_AK=C7AM?=) Date: Mon, 13 Jan 2020 17:08:04 +0000 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> Message-ID: Dear I liked the simplified version of this document. Just a small feedback: section titled "Definitions" can be shortened further by eliminating well known jargon. Best ________________________________ From: address-policy-wg on behalf of Marco Schmidt Sent: Wednesday, January 8, 2020 2:20:53 PM To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) Dear colleagues, Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is now in the extended Review Phase. This proposal aims to remove obsoleted text and simplify the IPv6 policy. You can find the full proposal and the RIPE NCC impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-06 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-06/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week extended Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 6 February 2020. Kind regards, Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC [BTK] Abdullah Cemil AK?AM Bili?im Uzman? Bilgi Teknolojileri Dairesi Ba?kanl??? Tel: +90 312 586 52 82 Adres: Eski?ehir Yolu 10.Km No: 276 Posta Kodu: 06530 ?ankaya/Ankara www.btk.gov.tr _ _ _ __ _ _ _ ________________________________ YASAL UYARI: Bu e-postada yer alan bilgiler, beraberinde iletilen t?m bilgi, onay ve her t?rl? formattaki dosyalar, gizlidir ve ki?iye ?zel olabilir ve sadece g?nderildi?i ki?i ya da kuruma ya da bu bilgileri kullanmaya ya da almaya yetkili di?er ki?ilere ?zeldir. E?er siz do?ru ki?i de?ilseniz, bu e-postay? a??klamak, kopyalamak, da??tmak ya da i?eri?ine istinaden i?lem yapmak t?m?yle yasakt?r ve kanuna ayk?r? olabilir. Bu nedenle bu e-postay? yanl??l?kla ald?ysan?z, bu durumu derhal g?nderene haber veriniz ve e-postay? siliniz. Bu e-postan?n taraf?n?za yanl??l?kla iletilmi? olmas? y?z?nden e-postan?n gizli ve ki?iye ?zel niteli?i kaybolmaz ya da bu niteli?inden vazge?ilmez. BTK, bu e-postada yer alan bilgilerin ya da e-postan?n kendisinin usul?ne g?re ve/veya tam iletiminden ya da e-postan?n al?nmas?nda ya?anan herhangi bir gecikmeden sorumlu de?ildir. BTK bu e-postan?n i?eri?i ile ilgili olarak hi? bir hukuksal sorumlulu?u kabul etmez. BTK, vir?s filtreleme uygulamakla birlikte, e-postan?n vir?s i?ermedi?ini garanti ya da temin etmez. DISCLAIMER: The information, consent and file attached thereto, contained in this e-mail is confidential and may be legally privileged, and is intended solely for the use of the individual or entity to whom it is addressed and others authorized to use it or receive it. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this e-mail is strictly prohibited and may be unlawful. If therefore you have received this e-mail in error, please notify the sender immediately and then delete it. Confidentiality and legal privileges are not waived or lost even if you have been accidentally transmitted by this e-mail. ICTA is not responsible for the proper and/or complete transmission of the information contained in this e-mail or of the e-mail itself nor in any delay in its receipt. ICTA does not accept any form of legal responsibility for the content of this e-mail. Whilst ICTA does apply virus filtering, it provides no guarantee or warranty that the e-mail is virus-free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jan 13 22:18:00 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 13 Jan 2020 22:18:00 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> Message-ID: <7A1A9441-64CC-44F7-AE9A-0759843C89FF@consulintel.es> Hi Abdullah, I don?t think that will be good. In fact, in many cases, we have a hard time to understand the text of the rest of the policy text if we don?t rely in a very good set of definitions. However, I just noticed something that could be removed: ?[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]? But at this stage of the proposal, I?m not sure how feasible is it, without restarting everything ? (and in that case, if we need to restart everything, it?s probably better to keep it for any future proposal that needs to change anything else). Or it can be considered an editorial change? What the chairs believe, and also Marco/Petrit? Regards, Jordi @jordipalet El 13/1/20 18:08, "address-policy-wg en nombre de Abdullah Cemil AK?AM" escribi?: Dear I liked the simplified version of this document. Just a small feedback: section titled "Definitions" can be shortened further by eliminating well known jargon. Best From: address-policy-wg on behalf of Marco Schmidt Sent: Wednesday, January 8, 2020 2:20:53 PM To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) Dear colleagues, Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is now in the extended Review Phase. This proposal aims to remove obsoleted text and simplify the IPv6 policy. You can find the full proposal and the RIPE NCC impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-06 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-06/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week extended Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 6 February 2020. Kind regards, Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC Abdullah Cemil AK?AM Bili?im Uzman? Bilgi Teknolojileri Dairesi Ba?kanl??? Tel: +90 312 586 52 82 Adres: Eski?ehir Yolu 10.Km No: 276 Posta Kodu: 06530 ?ankaya/Ankara www.btk.gov.tr _ _ _ __ _ _ _ YASAL UYARI: Bu e-postada yer alan bilgiler, beraberinde iletilen t?m bilgi, onay ve her t?rl? formattaki dosyalar, gizlidir ve ki?iye ?zel olabilir ve sadece g?nderildi?i ki?i ya da kuruma ya da bu bilgileri kullanmaya ya da almaya yetkili di?er ki?ilere ?zeldir. E?er siz do?ru ki?i de?ilseniz, bu e-postay? a??klamak, kopyalamak, da??tmak ya da i?eri?ine istinaden i?lem yapmak t?m?yle yasakt?r ve kanuna ayk?r? olabilir. Bu nedenle bu e-postay? yanl??l?kla ald?ysan?z, bu durumu derhal g?nderene haber veriniz ve e-postay? siliniz. Bu e-postan?n taraf?n?za yanl??l?kla iletilmi? olmas? y?z?nden e-postan?n gizli ve ki?iye ?zel niteli?i kaybolmaz ya da bu niteli?inden vazge?ilmez. BTK, bu e-postada yer alan bilgilerin ya da e-postan?n kendisinin usul?ne g?re ve/veya tam iletiminden ya da e-postan?n al?nmas?nda ya?anan herhangi bir gecikmeden sorumlu de?ildir. BTK bu e-postan?n i?eri?i ile ilgili olarak hi? bir hukuksal sorumlulu?u kabul etmez. BTK, vir?s filtreleme uygulamakla birlikte, e-postan?n vir?s i?ermedi?ini garanti ya da temin etmez. DISCLAIMER: The information, consent and file attached thereto, contained in this e-mail is confidential and may be legally privileged, and is intended solely for the use of the individual or entity to whom it is addressed and others authorized to use it or receive it. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this e-mail is strictly prohibited and may be unlawful. If therefore you have received this e-mail in error, please notify the sender immediately and then delete it. Confidentiality and legal privileges are not waived or lost even if you have been accidentally transmitted by this e-mail. ICTA is not responsible for the proper and/or complete transmission of the information contained in this e-mail or of the e-mail itself nor in any delay in its receipt. ICTA does not accept any form of legal responsibility for the content of this e-mail. Whilst ICTA does apply virus filtering, it provides no guarantee or warranty that the e-mail is virus-free. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phasani at ripe.net Tue Jan 14 12:25:31 2020 From: phasani at ripe.net (Petrit Hasani) Date: Tue, 14 Jan 2020 12:25:31 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <7A1A9441-64CC-44F7-AE9A-0759843C89FF@consulintel.es> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <7A1A9441-64CC-44F7-AE9A-0759843C89FF@consulintel.es> Message-ID: <0C871E7E-3B66-411F-BACB-959C6FE6E6DC@ripe.net> Hello Jordi, The sentence below makes it easier to do changes to the definitions sections in this document in case there are changes in other RIRs. (Example: If the NIR system is removed in APNIC, we would update the hierarchical structure): ?[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]? Considering that removing the sentence creates an impact, it would have to be mentioned in the impact analysis which would mean that we need to start the review phase again. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC > On 13 Jan 2020, at 22:18, JORDI PALET MARTINEZ via address-policy-wg wrote: > > Hi Abdullah, > > I don?t think that will be good. In fact, in many cases, we have a hard time to understand the text of the rest of the policy text if we don?t rely in a very good set of definitions. > > However, I just noticed something that could be removed: > > ?[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]? > > > But at this stage of the proposal, I?m not sure how feasible is it, without restarting everything ? (and in that case, if we need to restart everything, it?s probably better to keep it for any future proposal that needs to change anything else). > > Or it can be considered an editorial change? What the chairs believe, and also Marco/Petrit? > > Regards, > Jordi > > @jordipalet > > > > > > El 13/1/20 18:08, "address-policy-wg en nombre de Abdullah Cemil AK?AM" escribi?: > > Dear > I liked the simplified version of this document. Just a small feedback: section titled "Definitions" can be shortened further by eliminating well known jargon. > Best > From: address-policy-wg on behalf of Marco Schmidt > Sent: Wednesday, January 8, 2020 2:20:53 PM > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) > > Dear colleagues, > > Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is > now in the extended Review Phase. > > This proposal aims to remove obsoleted text and simplify the IPv6 policy. > > You can find the full proposal and the RIPE NCC impact analysis at: > https://www.ripe.net/participate/policies/proposals/2019-06 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2019-06/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this > four week extended Review Phase is to continue discussing the proposal, > taking the impact analysis into consideration, and to review the full > draft RIPE Policy Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will > determine whether the WG has reached rough consensus. It is therefore > important to provide your opinion, even if it is simply a restatement of > your input from the previous phase. > > We encourage you to read the proposal, impact analysis and draft > document and send any comments to before 6 > February 2020. > > Kind regards, > > Marco Schmidt > Registration Services and Policy Development Assistant Manager > RIPE NCC > > > > > > Abdullah Cemil AK?AM > Bili?im Uzman? > Bilgi Teknolojileri Dairesi Ba?kanl??? > > Tel: +90 312 586 52 82 > Adres: Eski?ehir Yolu 10.Km No: 276 Posta Kodu: 06530 ?ankaya/Ankara > > www.btk.gov.tr > _ _ _ __ _ _ _ > > > > YASAL UYARI: > Bu e-postada yer alan bilgiler, beraberinde iletilen t?m bilgi, onay ve her t?rl? formattaki dosyalar, gizlidir ve ki?iye ?zel olabilir ve sadece g?nderildi?i ki?i ya da kuruma ya da bu bilgileri kullanmaya ya da almaya yetkili di?er ki?ilere ?zeldir. E?er siz do?ru ki?i de?ilseniz, bu e-postay? a??klamak, kopyalamak, da??tmak ya da i?eri?ine istinaden i?lem yapmak t?m?yle yasakt?r ve kanuna ayk?r? olabilir. Bu nedenle bu e-postay? yanl??l?kla ald?ysan?z, bu durumu derhal g?nderene haber veriniz ve e-postay? siliniz. Bu e-postan?n taraf?n?za yanl??l?kla iletilmi? olmas? y?z?nden e-postan?n gizli ve ki?iye ?zel niteli?i kaybolmaz ya da bu niteli?inden vazge?ilmez. BTK, bu e-postada yer alan bilgilerin ya da e-postan?n kendisinin usul?ne g?re ve/veya tam iletiminden ya da e-postan?n al?nmas?nda ya?anan herhangi bir gecikmeden sorumlu de?ildir. BTK bu e-postan?n i?eri?i ile ilgili olarak hi? bir hukuksal sorumlulu?u kabul etmez. BTK, vir?s filtreleme uygulamakla birlikte, e-postan?n vir?s i?ermedi?ini garanti ya da temin etmez. > > DISCLAIMER: > The information, consent and file attached thereto, contained in this e-mail is confidential and may be legally privileged, and is intended solely for the use of the individual or entity to whom it is addressed and others authorized to use it or receive it. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this e-mail is strictly prohibited and may be unlawful. If therefore you have received this e-mail in error, please notify the sender immediately and then delete it. Confidentiality and legal privileges are not waived or lost even if you have been accidentally transmitted by this e-mail. ICTA is not responsible for the proper and/or complete transmission of the information contained in this e-mail or of the e-mail itself nor in any delay in its receipt. ICTA does not accept any form of legal responsibility for the content of this e-mail. Whilst ICTA does apply virus filtering, it provides no guarantee or warranty that the e-mail is virus-free. > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jordi.palet at consulintel.es Tue Jan 14 12:54:33 2020 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 14 Jan 2020 12:54:33 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <0C871E7E-3B66-411F-BACB-959C6FE6E6DC@ripe.net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> <7A1A9441-64CC-44F7-AE9A-0759843C89FF@consulintel.es> <0C871E7E-3B66-411F-BACB-959C6FE6E6DC@ripe.net> Message-ID: <21F9DCA0-1F49-41BD-AE57-620B91D695DB@consulintel.es> Hi Petrit, My reading of the sentence is a bit different. Of course, I may be wrong ... It comes from the original IPv6 policy that was developed jointly by folks from APNIC, ARIN and RIPE NCC. It was there just so each RIR make their own changes (in other RIRs, this was removed) and we forgot about it ... just copy and paste. If anything, change in any RIR that affects this definitions section, we will need to use the PDP to amend it in our own policy. So, this sentence doesn't fix that at all, and consequently I don't think the analysis impact should be different. However, as said, I'm fine keeping it, just wondering if we all agree without the need to restart the process (which I believe, unless chairs think otherwise, is not good at this stage). Regards, Jordi @jordipalet ?El 14/1/20 12:25, "address-policy-wg en nombre de Petrit Hasani" escribi?: Hello Jordi, The sentence below makes it easier to do changes to the definitions sections in this document in case there are changes in other RIRs. (Example: If the NIR system is removed in APNIC, we would update the hierarchical structure): ?[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]? Considering that removing the sentence creates an impact, it would have to be mentioned in the impact analysis which would mean that we need to start the review phase again. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC > On 13 Jan 2020, at 22:18, JORDI PALET MARTINEZ via address-policy-wg wrote: > > Hi Abdullah, > > I don?t think that will be good. In fact, in many cases, we have a hard time to understand the text of the rest of the policy text if we don?t rely in a very good set of definitions. > > However, I just noticed something that could be removed: > > ?[Note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.]? > > > But at this stage of the proposal, I?m not sure how feasible is it, without restarting everything ? (and in that case, if we need to restart everything, it?s probably better to keep it for any future proposal that needs to change anything else). > > Or it can be considered an editorial change? What the chairs believe, and also Marco/Petrit? > > Regards, > Jordi > > @jordipalet > > > > > > El 13/1/20 18:08, "address-policy-wg en nombre de Abdullah Cemil AK?AM" escribi?: > > Dear > I liked the simplified version of this document. Just a small feedback: section titled "Definitions" can be shortened further by eliminating well known jargon. > Best > From: address-policy-wg on behalf of Marco Schmidt > Sent: Wednesday, January 8, 2020 2:20:53 PM > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) > > Dear colleagues, > > Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is > now in the extended Review Phase. > > This proposal aims to remove obsoleted text and simplify the IPv6 policy. > > You can find the full proposal and the RIPE NCC impact analysis at: > https://www.ripe.net/participate/policies/proposals/2019-06 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2019-06/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this > four week extended Review Phase is to continue discussing the proposal, > taking the impact analysis into consideration, and to review the full > draft RIPE Policy Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will > determine whether the WG has reached rough consensus. It is therefore > important to provide your opinion, even if it is simply a restatement of > your input from the previous phase. > > We encourage you to read the proposal, impact analysis and draft > document and send any comments to before 6 > February 2020. > > Kind regards, > > Marco Schmidt > Registration Services and Policy Development Assistant Manager > RIPE NCC > > > > > > Abdullah Cemil AK?AM > Bili?im Uzman? > Bilgi Teknolojileri Dairesi Ba?kanl??? > > Tel: +90 312 586 52 82 > Adres: Eski?ehir Yolu 10.Km No: 276 Posta Kodu: 06530 ?ankaya/Ankara > > www.btk.gov.tr > _ _ _ __ _ _ _ > > > > YASAL UYARI: > Bu e-postada yer alan bilgiler, beraberinde iletilen t?m bilgi, onay ve her t?rl? formattaki dosyalar, gizlidir ve ki?iye ?zel olabilir ve sadece g?nderildi?i ki?i ya da kuruma ya da bu bilgileri kullanmaya ya da almaya yetkili di?er ki?ilere ?zeldir. E?er siz do?ru ki?i de?ilseniz, bu e-postay? a??klamak, kopyalamak, da??tmak ya da i?eri?ine istinaden i?lem yapmak t?m?yle yasakt?r ve kanuna ayk?r? olabilir. Bu nedenle bu e-postay? yanl??l?kla ald?ysan?z, bu durumu derhal g?nderene haber veriniz ve e-postay? siliniz. Bu e-postan?n taraf?n?za yanl??l?kla iletilmi? olmas? y?z?nden e-postan?n gizli ve ki?iye ?zel niteli?i kaybolmaz ya da bu niteli?inden vazge?ilmez. BTK, bu e-postada yer alan bilgilerin ya da e-postan?n kendisinin usul?ne g?re ve/veya tam iletiminden ya da e-postan?n al?nmas?nda ya?anan herhangi bir gecikmeden sorumlu de?ildir. BTK bu e-postan?n i?eri?i ile ilgili olarak hi? bir hukuksal sorumlulu?u kabul etmez. BTK, vir?s filtreleme uygulamakla birlikte, e-postan?n vir?s i?ermedi?ini garanti ya da temin etmez. > > DISCLAIMER: > The information, consent and file attached thereto, contained in this e-mail is confidential and may be legally privileged, and is intended solely for the use of the individual or entity to whom it is addressed and others authorized to use it or receive it. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this e-mail is strictly prohibited and may be unlawful. If therefore you have received this e-mail in error, please notify the sender immediately and then delete it. Confidentiality and legal privileges are not waived or lost even if you have been accidentally transmitted by this e-mail. ICTA is not responsible for the proper and/or complete transmission of the information contained in this e-mail or of the e-mail itself nor in any delay in its receipt. ICTA does not accept any form of legal responsibility for the content of this e-mail. Whilst ICTA does apply virus filtering, it provides no guarantee or warranty that the e-mail is virus-free. > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From me at cynthia.re Tue Jan 21 14:59:05 2020 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Tue, 21 Jan 2020 14:59:05 +0100 Subject: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> References: <3b0e9cd4-e0be-a282-e7c3-15a53e9803da@ripe.net> Message-ID: I fully support this proposal. - Cynthia On Wed, Jan 8, 2020 at 12:21 PM Marco Schmidt wrote: > Dear colleagues, > > Policy proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy" is > now in the extended Review Phase. > > This proposal aims to remove obsoleted text and simplify the IPv6 policy. > > You can find the full proposal and the RIPE NCC impact analysis at: > https://www.ripe.net/participate/policies/proposals/2019-06 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2019-06/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this > four week extended Review Phase is to continue discussing the proposal, > taking the impact analysis into consideration, and to review the full > draft RIPE Policy Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will > determine whether the WG has reached rough consensus. It is therefore > important to provide your opinion, even if it is simply a restatement of > your input from the previous phase. > > We encourage you to read the proposal, impact analysis and draft > document and send any comments to before 6 > February 2020. > > Kind regards, > > Marco Schmidt > Registration Services and Policy Development Assistant Manager > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Tue Jan 21 16:26:49 2020 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 21 Jan 2020 16:26:49 +0100 Subject: [address-policy-wg] Policy Proposal Implemented: 2019-05 "Revised IPv4 assignment policy for IXPs" Message-ID: <9074d103-a88a-0398-482c-83fef2e84a98@ripe.net> Dear colleagues, We are pleased to announce that we have fully implemented the RIPE Policy Proposal 2019-05 "Revised IPv4 assignment policy for IXPs?. This policy increased the reserved IPv4 pool for IXPs to a /15 and finetuned assignment criteria. The default IPv4 assignment size for IXP remains a /24 however on request or once there are no more assignments of /24 (or larger) available, assignments can be made down to /27. The pool management part of this proposal was already implemented in October 2019. The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2019-05 The RIPE Document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: https://www.ripe.net/publications/docs/ripe-733 Kind regards, Marco Schmidt Registration Services and Policy Development Assistant Manager RIPE NCC From erik at bais.name Fri Jan 31 17:16:04 2020 From: erik at bais.name (Erik Bais) Date: Fri, 31 Jan 2020 16:16:04 +0000 Subject: [address-policy-wg] Co-Chair re-election - Address policy WG Message-ID: Dear WG, As time flies while we are having fun, it is almost the time to re-do the chair dance again. And this time it will be my seat that is up for a re-election. If the WG is willing to put up with me as a co-chair, that I'm more than willing to go for another 2 years. If someone would like to become co-chair of AP-WG, it is possible to send Gert an email and we can have an actual election ... If we don't have multiple candidates 1 month before the next RIPE meeting in Berlin, it will be a step down - step up process. ( most likely ) ... It would be nice if we would get a (third?) young WG chair, someone who has been to a couple meetings, but doesn't fall in the category .. old-white male .. that has been longer around than the initial IPv4 runout .. Both Gert and myself tend to fall in that category .. or are getting close to it .. and a young padiwan that we can help settle into the WG collective would be highly appreciated. Kind regards, Erik Bais Co-chair for Address Policy WG - RIPE