2014-12 Draft Document and Impact Analysis Published (Allow IPv6 Transfers)
Dear colleagues, The proposal described in 2014-12, "Allow IPv6 Transfers", is now in its Review Phase. The draft document has been published, along with an impact analysis conducted by the RIPE NCC. You can find the full proposal and the impact analysis at: http://www.ripe.net/ripe/policies/proposals/2014-12 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2014-12/draft We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 21 January 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC
* "Marco Schmidt" <mschmidt@ripe.net>
The proposal described in 2014-12, "Allow IPv6 Transfers", is now in its Review Phase.
The need for IPv6 tranfers are probably going to be miniscule as IPv6 numbers are readily available from the NCC, but nevertheless I think it makes sense to harmonise the transfer policies for all the different resource types we have. In some corner cases a transfer could prevent the need to renumber (parts of) a network though. It's worth having this just to support folks in that position. +1 Tore
On 20/01/15 08:08, Tore Anderson wrote:
* "Marco Schmidt" <mschmidt@ripe.net>
The proposal described in 2014-12, "Allow IPv6 Transfers", is now in its Review Phase. The need for IPv6 tranfers are probably going to be miniscule as IPv6 numbers are readily available from the NCC, but nevertheless I think it makes sense to harmonise the transfer policies for all the different resource types we have.
In some corner cases a transfer could prevent the need to renumber (parts of) a network though. It's worth having this just to support folks in that position.
+1
Tore
I also support it, it's a good idea to have a policy that allows the transfer of all kinds of resources. /elvis
On 20/01/2015 07:08, Tore Anderson wrote:
* "Marco Schmidt" <mschmidt@ripe.net>
The proposal described in 2014-12, "Allow IPv6 Transfers", is now in its Review Phase.
The need for IPv6 tranfers are probably going to be miniscule as IPv6 numbers are readily available from the NCC, but nevertheless I think it makes sense to harmonise the transfer policies for all the different resource types we have.
Can I suggest that this text be clarified slightly:
The block that is to be re-assigned must not be smaller than the minimum assignment block size at the time of re-assignment.
e.g.
The block that is to be re-assigned must not be smaller than the minimum RIPE NCC IPv6 Provider Independent assignment block size at the time of re-assignment.
Otherwise the intent is ambiguous. Is there a reason that the 24-month cooling down period was removed for this proposal? Nick
Dear AP WG, the review phase for 2014-12 has ended. Seven persons expressed their support for it (four after we extended the review phase to get more feedback), no questions or objections have been raised. I think this is quite good as it is, and in the larger context of moving towards a unified transfer policy document in the next step, this is an even stronger signal. So, I declare we have consensus, and move 2014-12 to Last Call. Marco will send the formal announcement for that in the next days. For reference, a list of people that voiced support or opposition (or something else) in the review phase is appended below. This is what I have based my decision on. If you disagree with my interpretation of what has been said and the conclusion I have drawn from it, please let us know. Gert Doering, Address Policy WG Chair Review Phase, starting Dec 23, 2014 Support: Tore Anderson Lukas Wunner Andre Keller Andreas Vogler Salvatore Sciacco Oernberg, Eva E. Elvis Daniel Velea (twice :) ) Opposing: <nobody> Questions / Discussion items: <nothing> -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, Apologies, I seem to have slightly messed up my mail indexing, and overlooked a comment from Nick Hilliard. On Thu, Feb 12, 2015 at 03:20:13PM +0100, Gert Doering wrote:
the review phase for 2014-12 has ended. [..]
Questions / Discussion items: Nick Hilliard, request to clarify the wording on the minimum block size requirements for IPv6 PI at that time, and a question about the 24-month cooling period Given the otherwise positive comments, I would suggest the following. Erik: could you please answer Nick's question about the cooling period, and take his suggestion for the wording into account for the upcoming unified transfer document? Nick: after Erik has answered, can you please let us know if that is good enough for you to go ahead? Apologies again, did not pay enough attention there. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert, I missed that one as well, so I'll take a partial (bl/sh)ame on this ...
Questions / Discussion items: Nick Hilliard, request to clarify the wording on the minimum block size requirements for IPv6 PI at that time, and a question about the 24-month cooling period
On the minimum block size requirement for IPv6 PI ... Nick is stating that with the current wording the intent is ambiguous. The specific line is :
Provider Independent (PI) address space may only be re-assigned in accordance with the RIPE Document, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The block that is to be re-assigned must not be smaller than the minimum assignment block size at the time of re-assignment.
It is clear that we are talking about IPv6 PI space here.. that the contract needs to be in place, that we talk about a re-assignment (read - PI space assignment..) and that the minimum assignment size needs to be matched. It is clear that it is not about an allocation (IPv6 PA space) or do I miss something here which is a detail that a native speaker would see and I'm missing .. ?? If we look at the practical side here ... We are talking about PI IPv6 .. where most of those assignments will be a /48 ... Those assignments can't be split up into smaller prefixes ... There are roughly 60 IPv6 PI assignments that I could find which are not a /48 ... And because those need to submit lots of documentation to have received that prefix. I think it is unlikely that they will split their precious.. If a company (End-User) has an IPv6 PI assignment, having third parties (as you may have with PA IPv6) using it, is against the use-case for IPv6 PI space... And as it is still possible to get IPv6 PI space (unlike with IPv4 PI space), there is no requirement to split a PI IPv6 prefix, unless you are breaking up a company / infrastructure. It is my expectation that the majority of the v6 PI transfers will be on complete prefix transfers and not partials or splits... Specifically companies merging together, reorganizing. Having said that .. that also explains the not having the 24 month 'hoarding' cool down period... There is little to hoard ... I don't see a commercial market .. as any LIR will get a larger prefix than anyone would get via a IPv6 PI transfer ... without documentation ... And anyone can request a /48 PI IPv6 if they like, without documentation ... And every PI assignment will cost you a yearly maintenance fee as a sponsoring LIR of at least 50 euro ... I hope that I've addressed the points ( a bit late I admit..) but addressed Nick his points anyway. Regards, Erik Bais
On 12/02/2015 20:38, Erik Bais wrote:
It is clear that we are talking about IPv6 PI space here.. that the contract needs to be in place, that we talk about a re-assignment (read - PI space assignment..) and that the minimum assignment size needs to be matched. It is clear that it is not about an allocation (IPv6 PA space) or do I miss something here which is a detail that a native speaker would see and I'm missing .. ??
the issue that concerns me is that creating a requirement for a contract means that there is a requirement for legal people to be involved in the transfer process. Whatever about legal wording in civil law countries (NL, most of europe), common law countries (ie/uk/us, etc) generally tend to benefit from more specific wording. If there is any hint of ambiguity, it creates the possibility of argument and that is painful when it happens. The term "minimum assignment size" is used sloppily all over the place in the ripe policy document store to mean different things in different places. In this case, the wording isn't particularly ambiguous to you or me, but it would not necessarily be clear at first sight to the man on the Clapham omnibus. If five uncontentious words were added, this would make its interpretation completely clear. Weighing things up, common sense suggests that it would be more sensible to clarify than not. Previous policy proposals have had clarification text added between phases, so it's possible that adding the text wouldn't necessarily delay the proposal - obviously this is a decision for the ap-wg chairs.
It is my expectation that the majority of the v6 PI transfers will be on complete prefix transfers and not partials or splits... Specifically companies merging together, reorganizing.
Having said that .. that also explains the not having the 24 month 'hoarding' cool down period...
my concern with the 24 month cooling off period related to what's going to happen in the future when someone decides to create a unified resource transfer policy. The fewer differences between resource transfer policies, the simpler the policy. But yeah, I agree in this case that it's not necessary. As a more general observation, it might be useful for a future unified policy to differentiate between depleted resources (e.g. ipv4 / asn16) and non depleted resources (e.g. ipv6 /asn32) and make it clear that the cooling off period is intended depleted resources. Nick
Hi Nick,
the issue that concerns me is that creating a requirement for a contract means that there is a requirement for legal people to be involved in the transfer process. Whatever about legal wording in civil law countries (NL, most of europe), common law countries (ie/uk/us, etc) generally tend to benefit from more specific wording. If there is any hint of ambiguity, it creates the possibility of argument and that is painful when it happens.
There are always agreements/contracts in place, also with the current transfer processes. In this particular case you will have to think about an End-User Agreement (for PI IPv6) to be in place with an Sponsoring LIR. Also each transfer needs to be accomplished with a so called Transfer Agreement (template from RIPE).
The term "minimum assignment size" is used sloppily all over the place in the ripe policy document store to mean different things in different places. In this case, the wording isn't particularly ambiguous to you or me, but it would not necessarily be clear at first sight to the man on the Clapham omnibus. If five uncontentious words were added, this would make its interpretation completely clear.
And with that man on the Clapham omnibus you refer to a hypothetical reasonable person ... ( I had to look it up ... ) The irony ..
Weighing things up, common sense suggests that it would be more sensible to clarify than not.
Previous policy proposals have had clarification text added between phases, so it's possible that adding the text wouldn't necessarily delay the proposal - obviously this is a decision for the ap-wg chairs.
As we are going into a full re-styling of the Transfer Policies into a single document, we will have to see if it is going to be required to do that in this particular version or in the next re-style. There is little value imho to add clarification text here as we are going to cut the text in a couple weeks into a new document. If that new version needs a beter explanation it would make more sense in doing it there.
As a more general observation, it might be useful for a future unified policy to differentiate between depleted resources (e.g. ipv4 / asn16) and non depleted resources (e.g. ipv6 /asn32) and make it clear that the cooling off period is intended depleted resources.
I like the suggestion to look into the structure and difference between depleted and non depleted resources. I'll take that in mind for the Transfer doc. Thanks Nick, Regards, Erik
Hi, thanks, Nick and Erik for taking this up. Given what was said... On Mon, Feb 16, 2015 at 11:35:53AM +0100, Erik Bais wrote: [..]
Previous policy proposals have had clarification text added between phases, so it's possible that adding the text wouldn't necessarily delay the proposal - obviously this is a decision for the ap-wg chairs.
As we are going into a full re-styling of the Transfer Policies into a single document, we will have to see if it is going to be required to do that in this particular version or in the next re-style. There is little value imho to add clarification text here as we are going to cut the text in a couple weeks into a new document. If that new version needs a beter explanation it would make more sense in doing it there.
... I'd actually go forward now (that is: go to last call as announced) and spend the extra brain cycles on making sure that the final unified transfer policy document is very clean, language-wise and policy-wise. Erik has clearly stated the intent to do such a unified document, so if what we have now is sufficiently clear policy-wise (which seems to be the case, as per the impact analysis), I'd rather not spend another round on wordsmithing, or think about what sort of language changes are fine going from "review" to "last call" phase (typos, obviously) and what would consist a policy change and should go to another round of review. So: Nick, if that is OK with you? (In the upcoming document, it would be actually good to have the language cleanup right in the discussion phase, and not in review phase, where larger changes would incure another impact analysis...) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (6)
-
Elvis Daniel Velea -
Erik Bais -
Gert Doering -
Marco Schmidt -
Nick Hilliard -
Tore Anderson