RIPE 59

Chair: Gert Doering
Co-chair: Sander Steffann
Scribe: Ingrid Wijte (RIPE NCC)

Wednesday 7 October | 09:00-10:30 | Session 1

A. Administrative Matters

• Welcome
• Finalise agenda
• Scribe/Jabber
• Approve minutes from RIPE 58

Gert Doering (Chair) opened the session and reminded people that the session is webcast. There were no changes to the agenda.

The minutes from RIPE 58 were approved and are now final.

B. Current Policy Topics
Filiz Yilmaz, RIPE NCC

https://ripe59.ripe.net/presentations/yilmaz-current-policy-topics.pdf

• Overview of concluded proposals
  2009-05 Multiple IPv6 /32 Allocations - withdrawn
  2008-05 Anycast for ENUM - accepted
  2009-02 Resources to the RIPE NCC - accepted
• Overview of proposals currently in Last Call
  2009-06 Routing Requirements
  2009-07 Global ASN Block Policy
  2009-08 IPv6 PI for LIRs
• Common policy topics in all regions
  (End of IPv4, transfers, etc)

Stacey Hughes (ARIN AC) commented on slide 11, “Equitable IPv4 Run-Out", that ARIN is still discussing the proposal and that nothing is final yet.

Roque Gagliano (LACNIC) clarified that both the proposal to remove IPv6 routing requirements and the transfer policy are still under discussion in the LACNIC region.

John Schnizlein (ISOC) said that he believes there is less uniformity across regions. According to him APNIC does not require justification for transfers.

Geoff Houston (APNIC) clarified this up to the point of the last /8 and the specific policies 'attached' to it. He said that recipients of transfers needed to justify the address space they would receive through a transfer using the prevailing allocation policies at that point in time.

C. Rough Edges of Current Policies
Alex Le Heux, RIPE NCC

https://ripe59.ripe.net/presentations/leheux-rough-edges-of-policies.pdf

A report from the RIPE NCC Registration Services (RS) Department on issues and unintended side effects showing up in the daily implementation of the RIPE policies. Followed by a brief discussion.

There some comments and questions on the ASN policy:

Ruediger Volk (Deutsche Telekom) asked if RS uses abstract policy where routing policy is technically defined in terms of boxes that have a technically defined policy.

Daniel Karrenberg (RIPE NCC) said that if you have a single routing policy, only one ASN is needed. If you have distinct routing policies multiple ASNs are needed.

Alex answered that RS sees organisations that have specified their routing policy and define in their single routing policy all the peers they have in all the various places. RS also sees organisations that have the exact same set-up but they specify their routing policy per POP.

Gert interrupted by saying that solutions would be discussed on Thursday.

Daniel asked if RS had a 'gut' feeling on why the burn of ASNs is higher in RIPE NCC than in the other RIRs.

Alex answered that when an organisation comes for a PA allocation or a PI assignment in two thirds of these cases they also request an ASN.

Wilfried Woeber (Vienna University, Vienna Internet Exchange and National Research Network) stated that he recently requested another ASN. His organisation is formally one organisation but they have different divisions offering different services and/or functionalities in the network, which requires separate specific routing policy, for which another ASN is used. The complexity could make the network unmanageable if done in another way.

Rob Blokzijl (RIPE Chair) stated that he did not believe that the absolute numbers are so much higher in the RIPE NCC region than in the other regions when you look at the number of members as well. He added that the community should also be careful not to interpret policies in such a way that prescribe people how to run their business. There is no acute shortage of AS numbers.

Geoff Houston (APNIC) added some numbers in response: In 2009, since 1 January, the RIPE NCC has made 2260 separate IPv4 allocations and 1671 ASN assignments, which is slightly more than 50% in terms of absolute numbers. In the same period APNIC has made 973 IPv4 allocations and assigned 367 AS numbers. ARIN has made 1242 separate IPv4 allocations and assigned 1157 AS numbers, which is much closer than as a one-to-one ratio than anyone else. He added that it will take a bit of time to further analyse all these numbers.

Ruediger commented that it is likely that a large driver in high number of AS number requests would be the multi-homing of rather small sites and that is a very different problem than multiple ASN for a single organisation and it is possible that the take up of multi-homing practices may be different in various regions.

Gert suggested that the RS people from the different RIRs could look at what the typical distribution is in the different regions.

Daniel said that although there may be no immediately imminent shortage of ASNs, there is a shortage of 16-bit ASN.

Andrea Cima (RIPE NCC) added that in 2006 the RIPE NCC made about 1800 PI assignments. In 2007 there were 2200, as in 2000. Many of these were accompanied by an ASN request.

Gert wrapped up the discussion and added that the discussion will take place during the AP WG session on Thursday.

D. "Routing Issues" Update

Gert summarised what happened on this topic. During RIPE 58, it was discussed that the routing requirements be removed from the IPv6 policy document and instead have the routing recommendations documented in a Best Common Practices document. A policy proposal was made and this has been accepted since then. The discussion regarding the routing recommendations should take place in the Routing WG.

Ruediger commented that the term deaggregation is used many times when we should talk about announcing additional prefixes.

Rob Evans (JANET(UK)) author of the current draft, responded that the terminology used in the document can also be discussed in the Routing WG session.

E. Document Cosmetic Surgeries Project
Filiz Yilmaz, RIPE NCC

https://ripe59.ripe.net/presentations/yilmaz-cosmetic-surgery-project.pdf

There were no questions.

Wednesday 7 October | 11:00-12:30 | Session 2

F1. New Proposals since RIPE 58

Overview of what's coming.

F2. Discussion of Open Policy Proposals

- Various - Not directly related to IPv4 run-out
2006-05 PI Assignment Size
2008-07 Ensuring Efficient Use of Historical IPv4 Resources - Philip Smith
2008-08 Initial Certification Policy for PA Space Holders - Nigel Titley, CA TF
2009-01 Global Policy for the allocation of IPv4 blocks to RIRs - Cross RIR design team represented by Axel Pawlik

- Directly related to IPv4 run-out
2009-03 Run Out Fairly - Daniel Karrenberg
2008-06 Use of Final /8 - Philip Smith
2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment - Alain Bidron

2006-05 PI Assignment Size

Gert briefly described the content of the proposal and what has happened since it was proposed. This proposal suggests the minimum assignment size for PI assignments to be a /24 when routing is a major issue. So far no consensus has been reached on this one. Currently, there is no proposer anymore. He suggested that unless a proposer stands up, this proposal should be withdrawn.

Ruediger asked if dropping the proposal would mean that there is no way to ask for a /24.

Gert replied that in order to receive a /24 you would have to justify a need for more than 128 machines in the first twelve months.

Ruediger asked whether that would be different from practices used up to now.

Alex responded that currently, in order to receive a /24 you would have to justify an immediate need of 64 IPs, 50 % usage after one year and after two years the /24 would be fully used. Many of the requests justify 64 IPs. If in doubt, RS would aks for more information to support the request. Looking at the request size distribution there is a sudden cut off at a /24. He mentioned some numbers for 2009 so far: 230 /22 requests, 322 /23, 575 /24 and 7 /25 requests. He added that it seems that most PI requests may take into account the minimum routable size.

Ruediger responded that he wanted to know whether RS was liberal in these cases and concluded that RS is not and that parties are giving RS a view of the world that seems to be twisted.

Alex responded that RS does have a view of the world through these parties and that RS tries to verify with the tools at their disposal if that view is correct or not. But, when looking at the size distribution, there seems to be something strange going on.

Ruediger then concluded that by dropping the proposal nothing would change and therefore he feels that it would be a good idea to drop it, especially since the address pool will be empty at some point and all requests will have to find other solutions anyway.

Gert concluded that he would announce on the mailing list that unless somebody steps up to drive the proposal it will be dropped as there is no consensus. He added that this is how the PDP works: if there is no consensus, we do not go forward.

2008-07 Ensuring Efficient Use of Historical IPv4 Resources - Philip Smith

After a short introduction of the proposal, Gert proposed to talk to Philip about specific wording, feedback received and to come up with version 4 that will be discussed on the lists again.

Peter Koch, speaking as concerned member of Working Group (WG) Chairs collective, commented that it is very difficult for the WG chairs to make a decision when there are no, or few, comments on the list. He reminded the audience that people should speak out on the list so that the chairs can make a well-informed decision.

Wilfried stated that he feels that the proposal as it is structured right now, does not properly take into account that in some pockets of the world there is a large amount of address space which are legacy and the holders are not an LIR. For example in the case of his LIR, where the amount of address space managed in the framework of the LIR is very small compared to the address space used by their customer collective. He does not expect that many of those institutions, universities, and research sites would become an LIR. He commented that the proposal should be structured in a way that any party is required to disclose the use of existing address space before applying for additional address space, regardless of whether that party is an LIR or not.

Gert responded by asking whether Wilfried would volunteer to work with Philip to produce a new version of the proposal.

Wilfried accepted.

2008-08 Initial Certification Policy for PA Space Holders - Nigel Titley, CA TF

Nigel Titley summarised this proposal and explained what had been done so far.

RPKI Local Processing Model: BBN technologies on PKI
http://www.ripe.net/ripe/meetings/ripe-59/presentations/kent-rpki.pdf
Stephen Kent (BBN Technologies)

Daniel asked whether it would be possible to have an option to un-accept in case a mistake is spotted immediately and whether it would be possible to have a field to indicate reason for revocation. If so, it would also be good to ask for feedback for meaningful classes of reasons since that would make configuration easier.

Stephen responded that it is possible to have reason code field but that the current profile calls for not using it. He added that it is also technically possible to split the CRL by reason code. The standard already provides a means for doing this.

Andrei Robachevsky (RIPE NCC) asked how those recommendations would actually fit into the standards framework, say IETF framework.

Stephen responded that reason codes are already in the standards but were not included in the document written by Geoff Houston, as we did not want to add that complexity. However, it can be added if we decide we want that.

Andrei commented that his question was not related to an assumption that you would be violating standards, rather that it would be useful to publish a best practices document, something within the standard practice work.

Stephen responded that he agreed that would be useful but that in the end the relying parties (ISPs) always get to make the final decisions.

Ruediger stated that he would like to clear up that it is up to the RIR membership to make sure that essential rules and policies get into this CPS document.

Stephen answered that the concrete way to go forward would be to start writing the relevant sections of the CPS and put those up as individual policy items to be approved or to modify them until they can be accepted.

Daniel commented that he might want to include an API or something where they can actually go back to their own tools that they have for looking at address space, in other words. This should not be a closed piece of software.

Gert thanked the speakers for their update and that he trusts that the certification Working Group will go forward with the CPS document and with this policy proposal and keep us informed about when it's ready to be reviewed and to be discussed in the Working Group again.

2009-03 Run Out Fairly - Daniel Karrenberg

Gert summarised the proposal. He added that there has been some doubts about whether the timelines used are helpful. Nick Hilliard posted some calculations that might suggest that we could end up at a point where the RIPE NCC has enough space to last for four months while the evaluation period would be three months.

Nick Hilliard (INEX) commented that as we cannot really know what will happen until we get closer to the date, the issue really is whether it would be possible to model this in a way that would be more accurate. Data is needed, which we do not really have, and the question is whether the RIPE NCC would be able to make various models.

Daniel (proposer) answered that the dates were chosen not to try and be very accurate but to have memorable and predictable dates. This was to make sure that it will not come at the last minute or unexpectedly. You can predict the future but it is difficult to be correct.

Geoff stated that that is very correct. He added some numbers: Of the 11000 IPv4 allocations that happened in the last twelve months or so, 12 /8, a 100 individual allocations accounted for half of the address space. 1% of the applicants account for 50% of the space. Now, what if that 1% became 2%? Predictions rely on the law of very large numbers. The reality is that a small number of large players actually have the keys to the run out in their hand and it is impossible to know what they will do.

Niall O'Reilly stated that there is a choice to go back and do the analysis again, adjust the proposal and hope that we will have something in place on time or continue with this and if needed make another proposal later. He believed, however, that we cannot afford to have nothing in place.

Wolfgang Tremmel (DE-CIX) asked why the choice was made to do this in three steps instead of just having one point in time, for example, going to a six months evaluation period in July 2010.

Daniel responded that this was considered but it was concluded that it would cause too much overhead, resistance, and fragmentation.

Gert asked both Nick and Wolfgang whether they were satisfied with the explanations and would feel comfortable to go ahead.

Both answered they would be comfortable to move forward.

Gert asked the RIPE NCC if they would be comfortable to move forward and they confirmed as well.

2008-06 Use of Final /8 - Philip Smith
2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment - Alain Bidron

http://meetings.ripe.net/ripe-59/presentations/sander-final-8.pdf

Sander Steffann (Co-Chair) briefly summarised the current status. Currently there are two incompatible proposals on the table and we need to decide how we want to proceed. There was no consensus on either of them. He posted questions to the mailing list. The outcome was that:
- IPv4 requests and IPv6 requests should remain completely independent of each other.
- Most agreed that there would be some down scaling of the request size rather than a fixed size. The question remains how to do that.

Axel Pawlik (RIPE NCC) presented the outcome of the legal research that was done. The report was sent to the list. The general conclusion was that the legal implications were limited.

Sander concluded by saying that there has been some discussion on the list whether there should be a new policy at all. He therefore asked Remco van Mook to help and come up with an alternative proposal.

A Rough Draft
https://ripe59.ripe.net/presentations/vanmook-rough-draft.pdf
Remco van Mook

Raul Echeberría (LACNIC) asked if it was correct that when a request for a /17 is approved, they would get the largest available contiguous block, say a /19.

Remco confirmed that they could indeed get the largest available block (only one prefix).

Rob said that he liked the idea of reserving a /10 for unforeseen future use. The RIPE NCC grows on an annual basis with between 500 and 1000 new members and he thinks this will continue after IPv4 run-out. Therefore, new entrants have some choices: they either acquire IPv4 from somewhere, or use IPv6 for which they would need a little bit of IPv4. Therefore reserving some space would be a good idea, also from a political point of view. He added that he liked the idea of keeping it very simple; it will run out and the more complexity you build in during the last twelve months, the more liabilities you would have. When asked, Rob confirmed that he likes all three points of the proposal.

Marco Hogewoning (XS4ALL) commented that reserving some space is important, as it is impossible to predict the future. Regarding rule 2, only allocating one prefix, closest match to the request, he had some doubts with regards to the slotting and the prefix size it would end up with. Depending on how it is carved this could be /23 and /24 rather quickly.

Remco agreed with that point but added that there is a method to the carving up of the /8.

Alex answered that RS can implement what is proposed by Remco. It is not what the RIPE NCC does at the moment. Currently, RS starts making large allocations from new /8 and smaller ones once the available space in the /8 shrinks.

John Schnizlein (ISOC) asked if, assuming the method for carving up the /8 remains the same, this proposal would lead to the abruptness that the Run Out Fairly proposal seeks to avoid. The proposal does not change the periods of forecasting so one large request could take a large fraction of what is still available.

Remco responded that he does not think that in the end, the consequences of taking a shorter interval, or getting a smaller block is that much different.

Filiz commented on rule 2. She does not see this as a change in policy as the RIPE NCC currently only allocates one prefix as well. She stated that she understands that the goal is to avoid people coming for more in smaller pieces each time. She added that there is no option to avoid that people receive a /18 on Monday and come back on Tuesday for another /18, saying that the first one is full already. That needs some attention.

Remco responded that the only goal he has with this is that when someone comes for a large block, they will receive the best match available.

Alex agreed with the point made by Filiz. In the situation where someone comes for a /17, which presumably means they have assignments to make, and there would be no /17 available, they would receive a /19, smaller than the assignment needed. After they register the assignment, the allocation would be fully used again, according to current definition of 'in use'. Therefore, if the goal is to avoid that one request can clean up the remaining address space available there should be a way of limiting this.

Remco agreed with the point but at the same time he did not see any other way of limiting this. The main goal we should aim for, as a community is to ensure that the remaining space is used efficiently.

Sander added that it is going to hurt anyway so let's not fine tune too much.

Steve Padgett (Google) asked whether this should be lined up with the timelines in the Run Out Fairly proposal. By using those dates as end dates you could avoid a flood of people coming at the very last moment.

Remco responded that he felt that one of the downsides of the Run Out Fairly proposal was that it would require more or less arbitrary timelines.

Niall O 'Reilly (UCD and ENUM WG Chair) commented that some references to the run rate will be necessary, to avoid exactly the situation that Filiz and Alex were describing earlier. If people are able to come back the next day for more, they would be concatenating allocations and that way it would favour the large players at the expense of smaller players and new entrants. Whether the reserved /10 would be enough to mitigate those effects he was not sure. He added that we should look at both capacity and rate together.

Wilfried stated that he likes this self-regulating approach. Additionally his first assumption would be that we could rely on the IPRAs at RIPE NCC to do a reasonable job. He added that it would not be needed to be too specific in the policy wording. In the implementation simple things could be done to avoid the large players coming back the next day, for example by queuing the requests differently.

Martin Levy (Hurricane Electric) asked what rights the requester would have after being denied.

Remco responded that by carving out a /10, at some point there would be a policy to use that for IPv6 deployment. Coming up with a policy for that /10 at this moment would not reach consensus so he would prefer to get at least something in place for the last /8 now and tackle the remaining part at a later stage.

Thursday 8 October | 14:00-15:30 | Session 3

G. IPv6 Addressing Outside Traditional "Internet'' Deployments
Dr. Joerg Wellbrink, German Ministry of Defense
https://ripe59.ripe.net/presentations/wellbrink-v6-germany.pdf

Aaron Hughes (6connect Inc.) asked why the choice was made to do dual stack and the double NATing while they would be in a unique position, with a rather closed network, to jump to IPv6 immediately.

Joerg answered that although the hardware is brand new, the applications were developed for IPv4 and they are researching if these are IPv6 compatible. Additionally there even are some hard coded addresses in there.

Aaron asked if they would be making routing decisions in the sky or on the ground.

Joerg answered that they wished they could do that but they are researching it.

Jan Zorz (RTV Slo) asked if the assignment unit for a /48 would be a soldier.

Joerg answered that an assignment unit would be an end site. In each military unit one soldier carries the communication node that would be the end site.

H. New Policy Proposal: IPv4 Temporary Assignment Pool
Nick Hilliard, INEX
https://ripe59.ripe.net/presentations/hilliard-temp-assignments.pdf

Lance Wright (Chocolate Redhead), over Jabber, asked what would happen with countries that don't necessarily follow these policies and encourage usage such as SPAM.

Nick replied that that was a difficult question because the addresses will be assigned to people/organisations, not countries. This would be based on the contractual relation in place.

Denesh Bhabuta (Aexiomus/Cyberstrider), over Jabber, wanted to know what would happen with address space that ended up being used for spam. He asked how that would affect future usage of that address space when it would be re-assigned later.

Nick answered that RIPE and RIPE NCC cannot stop that from happening. So the question really is if we want to have this pool of address space knowing there will be some issues like this, or just not bother at all with it.

Aaron commented that currently ARIN does what it can to clean the space up before reassigning. That would be more difficult closer to running out. However, at that point of time it would be better to have dirty space than have nothing at all.

Gert closed the discussion by saying that the proposal will go to the list and through the PDP as normal.

Resumption of open policy proposals discussions, if needed

2009-01 Global Policy for the allocation of IPv4 blocks to RIRs - Cross RIR design team represented by Axel Pawlik
https://ripe59.ripe.net/presentations/pawlik-2009-01-update.pdf

John Curran (ARIN) explained what happened with the proposal in the ARIN region. The ARIN Advisory Council (AC) is responsible for making good policy and sometimes that means estimating what the community will endorse as good policy. Part of the aspect that causes material difference between the proposals is probably the staff comments (and council) that discuss some of the implications of a policy in the ARIN region that mandate the return of the space to the IANA under all circumstances, effectively unless there is an overwhelming mandate from the community for that to happen. There is significant liability for ARIN if we have such a policy that mandatorily designates the returns of the space to IANA, to the point where ARIN's council has advised against us, and the Board of Trustees has to take that into consideration. The proposal will be discussed at the ARIN meeting in Dearborn and it is possible that the ARIN community could stand up and say that the right thing to do would be to mandate returns of the address space. Therefore it could happen that ARIN will move in the direction of a RIPE version.

Nigel Titley (proposer) stated that the problem is that it is not just two versions but actually five. There is substantial agreement in four regions. If ARIN does not accept the global policy, it cannot become policy. Therefore it would seem sensible that ARIN at least attempts to present it to their community rather than changing it before even presenting it.

Axel responded that in that case it would be possible to try and start over with the ARIN version through the PDP in different regions. This could take years though.

Lance, over Jabber, asked why anybody would be interested or motivated to return the space as it takes a while to obtain IP space.

Raúl Echeberría (LACNIC) clarified the objective of the proposal. The objective is not to promote recovery of IP space. The objective is to ensure that if address space is recovered it would be made available to all regions. This would improve distribution across regions.

John responded that that is actually causing a liability. Address space has always been distributed based on need. If addresses recovered in one region would be then issued to another region, causing a sooner depletion in the region that it came from, in ARIN region this could be seen as making address space unavailable instead of available.

Axel commented that in both versions of the proposal the address space will get allocated from IANA to the RIRs based on need.

Wilfried pointed out that a big part of the problem is related to the process of making global policy. In some regions there is a wish to get the policy through as quick as possible. Another option would have been to start with a simpler proposal (for example just allowing IANA to receive recovered address space) for which it would have been relatively easy to get consensus on. After that, start with a proposal to handle the re-distribution. Pushing ahead is likely to cause this ship to sink altogether.

Raúl added that this is still a needs-based policy and it is maintaining the main characteristics of the current system. The main difference is that it enables IANA to manage smaller allocation units. The main idea is that addresses given out before the RIRs that caused the inequity in distribution amongst region will be made available to all regions. Also, as long as the concept accepted is the same in all regions it should be relatively easy to get a common version later, as happened with the different version of the last /8 proposals.

Kurtis Lindquist (Netnod) stated that it seemed we are making policy based on discussion in other regions and he does not like that. This policy basically says that if you feel like giving back addresses, you can. It will not make distribution among regions fairer.

Lance, over Jabber, asked how people would feel about charging for space on a monthly or quarterly basis with the understanding that if there is no requirement people might be more inclined to return the space. Perhaps, a deposit based policy where organisations pay a fee based on predetermined blocks and amounts are returned when space is returned.

Denesh Bhabuta (Aexiomus/Cyberstrider) over Jabber, stated that it also makes the administration of the addresses from the RIPE NCC's point of view more complicated and thus implies higher membership fees.

Gert proposed to stall this proposal until the ARIN community has decided what it wants to do.

Z. AOB

Pending - A PDP Change Proposal - Dave Wilson
https://ripe59.ripe.net/presentations/wilson-pdp-change-proposal.pdf

Geoff commented that in the APNIC region the PDP includes, as its final step, the shift from a proposal to a policy, which is actually formally made by the executive council of APNIC, in other words an endorsement of an existing consensus process. For global policy proposals the endorsement has been that the APNIC community accepts this formally pending the adoption by the other RIRs.

Filiz said that the RIPE NCC Executive Board is not stamping policies or the consensus of the community as a last step in the Policy Development Process. It is the Working Group Chairs collective that does that. Obviously the Board can have some opinions about an accepted proposal later on but this hasn't happened really. The proposed extra step in the PDP already happens in reality. A global proposal is accepted pending ratification by ICANN. However it would be good to document that in order to have it clear.

Wilfried stated that this should actually be sort of an emergency hook to allow us to go to a certain point in the process and then the next steps in the process should be dependent upon a review whether the text is still the same in other regions.

Filiz confirmed that this is already in place in the current Policy Development Process. The Working Groups Chairs will be involved in this decision making process.

Gert concluded the discussion by asking Dave if he would be willing to make a formal policy proposal.

Dave agreed to do that.

J. Ideas of How to Tackle Any Problems Experienced by the RIPE NCC Registration Services Department

Gert explained that there would now be a short discussion on the topics raised the other day on the ASN and routing policies. There is not enough time to discuss all three issues raised. The other two will be taken to the mailing list directly.

Piotr Strzyzewski (Silesian University of Technology, Computer Centre) commented that they have two ASNs, assigned through two different LIRs. One is used for the academic network, the other for the commercial network. Mixing these two networks would not be good and it should be perfectly fine to run two separate networks like this.

Alex responded that RS understands that but that they feel the policy can be interpreted in two ways. The idea is to clarify.

Wilfried stated that although they are one legal entity, they provide very different services, different network activities, different routing clouds and different prefixes. Multiple ASNs are needed for that. He added that Registration Services should use their common knowledge and judgment in a particular situation and do the right thing. Trying to predefine every potential aspect that could be different than others is not going to scale.

Dave agreed with the previous two speakers and added that the scenarios described where you have one organisation operating multiple networks, are very close to what he recalls as being the most compelling argument for removing the routing requirement out of the IPv6 addressing policy.

Geoff agreed with Wilfried that he sees no benefit in changing or defining the policy for each aspect. The 16-bit ASN are going to run out anyways.

Gert responded that they were not proposing to change policy but get feedback for guidance on the current one.

Ruediger stated that the requirement for getting an additional ASN was essentially that you document distinct routing policy. This should not be changed.

Izumi Okutani (JPNIC) commented that in JPNIC they do not look in terms of organisation but in terms of networks and who they peer with and reason why they need an additional ASN. That seems to work very well.

Alex concluded if they can document distinct routing policies that should be sufficient for an additional ASN.

Gert confirmed this.

Nick stated that the guidelines of common sense should apply. There may be a shortage of 16-bit ASN, but not of 32-bit ASN. Therefore there is no reason to be extra stringent.

Gert concluded the discussion by thanking Alex and the Working Group. This will be sent to the mailing list for conclusion. The other two matters will be clarified on the mailing list.

The session closed.