- address-policy-wg - mailman.ripe.net

Decision on 2024-02 (IPv6 Initial Allocations /28 and extension to /28) Discussion Phase
by Leo Vegoda 27 Nov '25

27 Nov '25

Dear Address Policy WG, The proposers have decided to prepare an updated proposal, taking account of the feedback provided during the most recent Discussion Phase. A new Discussion Phase will start when their new proposal is available on the website. We'd like to thank Jordi and Rinse for their work on this proposal, along with everyone who reviewed and commented on the most recent version. Thank you, Alex, Franziska, Leo Your co-chairs

1 0

Decision on 2025-01 (ASN assignment criteria revisited) Discussion Phase
by Leo Vegoda 24 Nov '25

24 Nov '25

Dear Address Policy WG, Urban and Tobias have confirmed that they are working on an updated version of their proposal. When that is ready we will start a new discussion phase. We'd like to thank them for their work and everyone who commented on their proposal. Kind regards, Alex, Franziska, Leo Your co-chairs

1 0

Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
by Vincentas Grinius 19 Nov '25

19 Nov '25

Hi all, I want to address the underlying logic behind this proposal, because several arguments being used to justify a policy change actually demonstrate something else. The data about processing times and the 0.5 FTE burden are symptoms of a process that has not been modernized. They are no evidence that the policy itself is flawed. We have seen this dynamic before. The workflow for legacy transfers still resembles something from the 1990s, where everything relied on manual checks, email loops, and individual hostmasters. The operational Internet has long since evolved into an automated environment. Yet here we are trying to solve process gaps with policy restrictions instead of technology. That approach does not move the community forward. Marco confirmed that manual provenance checks and fragmented historical documentation create an additional workload. This is precisely the type of work that disappears once resources are onboarded into standardized and automated processes. Gaps in onboarding and documentation primarily drive the lengthy processing time for legacy cases. Once a resource is fully onboarded, it behaves exactly like any other allocation. This shows clearly that the bottleneck is procedural, not policy-based. It is worth recognizing that RIPE NCC has already taken meaningful steps in the right direction. The new fully automated process for ending PI sponsorship shows that automation can reduce workload while improving accuracy. This is exactly the mindset we should encourage, and it would be great to see the same approach applied to legacy onboarding and transfers. Multiple people in this thread have raised legitimate concerns that this proposal would effectively push transfers off the registry altogether. If that happens, we lose accuracy in the RIPE Database, we lose RPKI coverage, and we increase reliance on non-authoritative IRRs. That is real harm to routing security. Trying to close loopholes by tightening restrictions may feel tidy, but it ignores predictable side effects. Regarding John Curran’s comment about ARIN providing basic services to legacy holders, I do not think ARIN’s model should be held up as a success story. ARIN’s strict transfer and needs-based environment has created prolonged processing timelines, significant procedural friction, and one of the most burdensome governance models in the RIR system. I do not think that is something the industry should replicate or admire, and I hope RIPE does not follow that path. If the goal here is to reduce NCC workload, then the answer is obvious. It is automation, not new restrictions, not rebranding resources, and not creating incentives for people to avoid the registry altogether. Modernizing the legacy transfer workflow with the same automated checks used for standard resources would eliminate most of the processing burden without compromising transparency or routing security. Before moving this proposal forward, I strongly recommend that the working group step back and evaluate what a fully automated legacy onboarding and transfer model looks like, and how it can preserve accuracy without pushing operators into the shadows. Policy should not replace engineering. Policy should enable it. One final point, Clara. You mentioned that legacy status is being used as a loophole to increase market speculation. Can you provide concrete evidence for this statement? Before the community proceeds, we need to see the specific data or cases that clearly show legacy space being used as a speculative instrument. Best regards, Vincentas Grinius IPXO

1 0

Re: Early Feedback on Legacy Status Transfer Proposal
by Vincentas Grinius 19 Nov '25

19 Nov '25

Hi all, I want to address the underlying logic behind this proposal, because several arguments being used to justify a policy change actually demonstrate something else. The data about processing times and the 0.5 FTE burden are symptoms of a process that has not been modernized. They are no evidence that the policy itself is flawed. We have seen this dynamic before. The workflow for legacy transfers still resembles something from the 1990s, where everything relied on manual checks, email loops, and individual hostmasters. The operational Internet has long since evolved into an automated environment. Yet here we are trying to solve process gaps with policy restrictions instead of technology. That approach does not move the community forward. Marco confirmed that manual provenance checks and fragmented historical documentation create an additional workload. This is precisely the type of work that disappears once resources are onboarded into standardized and automated processes. Gaps in onboarding and documentation primarily drive the lengthy processing time for legacy cases. Once a resource is fully onboarded, it behaves exactly like any other allocation. This shows clearly that the bottleneck is procedural, not policy-based. It is worth recognizing that RIPE NCC has already taken meaningful steps in the right direction. The new fully automated process for ending PI sponsorship shows that automation can reduce workload while improving accuracy. This is exactly the mindset we should encourage, and it would be great to see the same approach applied to legacy onboarding and transfers. Multiple people in this thread have raised legitimate concerns that this proposal would effectively push transfers off the registry altogether. If that happens, we lose accuracy in the RIPE Database, we lose RPKI coverage, and we increase reliance on non-authoritative IRRs. That is real harm to routing security. Trying to close loopholes by tightening restrictions may feel tidy, but it ignores predictable side effects. Regarding John Curran’s comment about ARIN providing basic services to legacy holders, I do not think ARIN’s model should be held up as a success story. ARIN’s strict transfer and needs-based environment has created prolonged processing timelines, significant procedural friction, and one of the most burdensome governance models in the RIR system. I do not think that is something the industry should replicate or admire, and I hope RIPE does not follow that path. If the goal here is to reduce NCC workload, then the answer is obvious. It is automation, not new restrictions, not rebranding resources, and not creating incentives for people to avoid the registry altogether. Modernizing the legacy transfer workflow with the same automated checks used for standard resources would eliminate most of the processing burden without compromising transparency or routing security. Before moving this proposal forward, I strongly recommend that the working group step back and evaluate what a fully automated legacy onboarding and transfer model looks like, and how it can preserve accuracy without pushing operators into the shadows. Policy should not replace engineering. Policy should enable it. One final point, Clara. You mentioned that legacy status is being used as a loophole to increase market speculation. Can you provide concrete evidence for this statement? Before the community proceeds, we need to see the specific data or cases that clearly show legacy space being used as a speculative instrument. Best regards, Vincentas Grinius IPXO

1 0

Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
by Tom Fantacone 18 Nov '25

18 Nov '25

Hi All, I'm a bit perplexed about whether or how much this proposal would actually do much to lessen RIPE's workload. Marco wrote: >The Legacy Updates group is similar. Randy is correct, updates of legacy resources under contract between two existing members are typically far below the 360-minute average, but they represent only a small portion of this group. >The longer processing times mainly occur when a new contract must be signed with the RIPE NCC or a sponsoring member, or when only one party has a contractual relationship. In particular, cases where the offering party has no >contract (while the receiving party has or will have one) can take significantly longer, as the RIPE NCC must perform extensive due-diligence checks before the Legacy update can be completed." Correct me if I'm wrong, but it seems that if a legacy holder with no contract transfers space to another legacy holder who wants no contract, as current policy allows, we might expect long processing times since RIPE must, to some degree, vet the recipient for the first time. If this policy were in effect, we have the case where a new contract must be signed by the recipient (no more legacy status), but this also incurs longer processing times, so in this case I don't see any workload savings. Now if, under current policy, a recipient of a legacy transfer with no contract later decided to transfer the space elsewhere, I would expect the initial vetting of the recipient of the first transfer would extend so it wouldn't require RIPE to start from scratch in vetting them as the source of the 2nd transfer. I guess in principle it's possible the RIPE workload would be greater if the same space were being transferred over and over again to different, new, unvetted recipients who would keep the space as legacy. Is this something we could get some statistics on? Are there a significant number of cases where the same legacy space is churned over and over again to different recipients who all need to be vetted by RIPE, or are these just fringe cases? Otherwise, it seems the policy doesn't do much to mitigate the higher "legacy workload". Regarding RPKI and its cost-load, ARIN chose the path of requiring legacy holders to sign a Registration Services Agreement and relinquish legacy status to receive RPKI services. While this incentivizes entities to become ARIN members and reduces the amount of legacy space out there, it also incentivizes legacy holders who wish to remain legacy holders to forego RPKI entirely, reducing RPKI adoption. RIPE chose the path of allowing legacy holders to adopt RPKI without foregoing legacy status, as long as they enter into a contractual agreement with RIPE, generally as a member or via a sponsoring LIR. So they pay the same fees to receive the service as non-legacy holders, but aren't dissuaded by being forced to give up their legacy status. I think the current system strikes the perfect middle-ground in encouraging legacy holders to adopt RPKI and to pay for it. Finally, I agree with Niall's comment that "clarifying" should not be the operative word in the proposal's title. It implies that this policy was RIPE's actual intent when it formulated the rules governing legacy transfers, but I don't think that's the case at all. For these reasons, I'm opposed to the policy as written. Best Regards, Tom Fantacone

2 1

Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status
by Wade, Clara 18 Nov '25

18 Nov '25

Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: 1. “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. 2. “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: 1. RIPE registration services fees. 2. The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. 3. Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade

17 26

2024-02 New Version Policy Proposal (IPv6 Initial Allocations /28 and extension to /28)
by Angela Dall'Ara 14 Nov '25

14 Nov '25

Dear colleagues,   A new version of RIPE policy proposal 2024-02 "IPv6 Initial Allocations /28 and extension to /28" is now available for discussion.  Following the last round of discussion, this proposal has been updated and it is now at version 4.0.  The main difference from version 3.0 is that it allows the extension without additional documentation of a single allocation per LIR instead of per Member. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-02/ As per the RIPE Policy Development Process (PDP), the purpose of this six-week Discussion Phase is to discuss the proposal and provide feedback to the proposers. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.   The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781  We encourage you to review this proposal and send your comments to  address-policy-wg(a)ripe.net before 7 November 2025.   Kind regards,   Angela Dall'Ara Policy Officer RIPE NCC

16 23

New Self-Service Form for Ending Sponsorships Now Live
by Marco Schmidt 04 Nov '25

04 Nov '25

Dear colleagues, As announced during the Address Policy session at RIPE 91, we have now deployed a new request form that allows RIPE NCC members to easily stop the sponsorship of Provider Independent (PI) resources (IPv4 PI, IPv6 PI, and AS Numbers). This new form introduces our first true self-service workflow in Registry Services. It enables immediate execution of the request, offers a clearer process, and significantly reduces manual handling. You will find the form in the LIR Portal under the same section previously used to notify the RIPE NCC about changes. Full details are available in this RIPE Labs article: https://labs.ripe.net/author/marco_schmidt/automated-self-service-to-end-sp… If your organisation sponsors independent resources, please take a moment to review your current customer agreements and use the new form to notify us of any sponsorships that have ended. Thank you for helping us maintain accurate registry data. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

Re: 2024-02 New Version Policy Proposal (IPv6 Initial Allocations /28 and extension to /28)
by ember 30 Oct '25

30 Oct '25

> If you support this draft of the proposal, please indicate that with a > simple message. It can be a +1 or a 👍. Absolutely in favor of this! +1 from me ~ ember

1 0

Re: address-policy-wg Digest, Vol 161, Issue 9
by Hien Nguyen 30 Oct '25

30 Oct '25

Ekkomagicboy.senju ---------- Forwarded message --------- Từ: <address-policy-wg-request(a)ripe.net> Date: 4:53 Th 5, 30 thg 10, 2025 Subject: address-policy-wg Digest, Vol 161, Issue 9 To: <address-policy-wg(a)ripe.net> Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Randy Bush) 2. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Marco Schmidt) 3. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status (Max Emig) ---------------------------------------------------------------------- Message: 1 Date: Tue, 28 Oct 2025 18:05:53 -0700 From: Randy Bush <randy(a)psg.com> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: "Wade, Clara" <clarawad(a)amazon.com> Cc: RIPE address policy WG <address-policy-wg(a)ripe.net> Message-ID: <m2frb234b2.wl-randy(a)psg.com> Content-Type: text/plain; charset=ISO-8859-1 hi clara as usual, i am a bit confused; yes, a low bar. have sympathy; you have been doing this *far* longer than i. CSTFR sez: > it takes staff an average of 75 minutes to process each intra-RIR > transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six > hours for a legacy transfer between parties with contractual > relationships with the RIPE NCC looking at table 7, i think we're comparing "RIPE NCC Region Transfers" with "Legacy Updates," whatever the heck they are. i suspect that they are not inter-member transfers of legacy space. as you were on the CSTF, so i hope you remember what these numbers actually measure and could please whack me with a clue bat. Clara: > legacy status, regardless of whether there is a contractual > relationship or not, need to undergo a more stringent diligence > process for transfers that puts additional burden on the NCC i naïvely assume that the extra diligence of provenance is incurred once when the space is first registered, e.g. when the holder becomes a member or it is acquired by a member. and that cost would be a one time cost. from then on, why is it not just space with a different paint job? if member A transfers legacy space to member B why the heck would it take significantly more effort than if A transfers non-legacy space to B? can someone from the registry comment? similarly if A transfers legacy space to B as non-legacy, does it really require less effort than if B receives it as legacy space? randy, trying to understand what problems we really need to solve ------------------------------ Message: 2 Date: Wed, 29 Oct 2025 14:16:34 +0100 From: Marco Schmidt <mschmidt(a)ripe.net> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: Randy Bush <randy(a)psg.com>, "Wade, Clara" <clarawad(a)amazon.com> Cc: RIPE address policy WG <address-policy-wg(a)ripe.net> Message-ID: <f075336f-b51d-46d9-b1c2-da01d4df9341(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Hello Martin, Randy, all Please allow me to provide a bit more context regarding the processing times shown in the report of the Charging Scheme Task Force. First, these figures are averages based on samples and experience in Registration Services. Actual cases may be completed faster, or sometimes significantly slower. Second, the four categories mentioned in the Charging Scheme Task Force report cover a range of scenarios, and this grouping creates some cluster effects that can be confusing. For example, policy transfers of PI resources within the RIPE NCC region can involve: - two members, - a member and a non-member - two non-members. Transfers between two members are usually below the average of 75 minutes, while those involving non-members usually take a bit longer, especially when the receiving party is new to the RIPE NCC and additional checks are required. The Legacy Updates group is similar. Randy is correct, updates of legacy resources under contract between two existing members are typically far below the 360-minute average, but they represent only a small portion of this group. The longer processing times mainly occur when a new contract must be signed with the RIPE NCC or a sponsoring member, or when only one party has a contractual relationship. In particular, cases where the offering party has no contract (while the receiving party has or will have one) can take significantly longer, as the RIPE NCC must perform extensive due-diligence checks before the Legacy update can be completed. I hope this clarifies. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 29/10/2025 02:05, Randy Bush wrote: > hi clara > > as usual, i am a bit confused; yes, a low bar. have sympathy; you have > been doing this *far* longer than i. > > CSTFR sez: >> it takes staff an average of 75 minutes to process each intra-RIR >> transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six >> hours for a legacy transfer between parties with contractual >> relationships with the RIPE NCC > looking at table 7, i think we're comparing "RIPE NCC Region Transfers" > with "Legacy Updates," whatever the heck they are. i suspect that they > are not inter-member transfers of legacy space. as you were on the > CSTF, so i hope you remember what these numbers actually measure and > could please whack me with a clue bat. > > Clara: >> legacy status, regardless of whether there is a contractual >> relationship or not, need to undergo a more stringent diligence >> process for transfers that puts additional burden on the NCC > i naïvely assume that the extra diligence of provenance is incurred once > when the space is first registered, e.g. when the holder becomes a > member or it is acquired by a member. and that cost would be a one time > cost. from then on, why is it not just space with a different paint > job? > > if member A transfers legacy space to member B why the heck would it > take significantly more effort than if A transfers non-legacy space to > B? can someone from the registry comment? > > similarly if A transfers legacy space to B as non-legacy, does it > really require less effort than if B receives it as legacy space? > > randy, trying to understand what problems we really need to solve > ----- > To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ ------------------------------ Message: 3 Date: Wed, 29 Oct 2025 22:53:21 +0100 From: "Max Emig" <ripe(a)emigm.ax> Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying the non-transferability of legacy status To: Wade, Clara <clarawad(a)amazon.com> Cc: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net>, peter.hessler(a)zayo.com <peter.hessler(a)zayo.com> Message-ID: <1ad4e135-4e93-0f0f-5b84-a957a86056f0(a)emigm.ax> Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_ org_NGMime-66-1761774801.073449-1------" Good evening all, I oppose this policy proposal as it may lead to an increase on out-of-date data and less RPKI adoption. However, I would support adding a fee or another disincentive for keeping legacy status. Thanks Max On 27 October, 2025 17:12 CET, "Wade, Clara via address-policy-wg" < address-policy-wg(a)ripe.net> wrote: Hello everyone, Following the suggestion of the RIPE NCC, we are seeking early feedback on an upcoming policy proposal we currently have in draft status. As mentioned last week after the Registration Services update from Marco at the AP-WG session - Peter Hessler and I, members of the now concluded Charging Scheme Task Force, are drafting a policy proposal to clarify the non-transferability of legacy status to address the issues of increasing overhead for the RIPE NCC, increasing market speculation around a scarce resource and its impact on the adoption of best practices like RPKI. Our proposal will modify these existing policies: * “RIPE Resource Transfer Policies” (RIPE-807) with additional clarifications in the Transfer Restrictions section and the Inter-RIR policy section. M&A/org restructuring transfers will be explicitly excluded. * “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with modifications to remove the language implying new holders can keep legacy status after transfer. For background, legacy status was meant to indicate when an Internet resource had been directly assigned to the holder by IANA, before the RIRs were established. As such, ARIN, LACNIC and AFRINIC policies dictate that IPv4 legacy resources will no longer be regarded as legacy resources after a policy transfer takes place (excluding M&A transfers). RIPE is the only RIR that currently allows the recipient of a legacy transfer the ability to inherit the legacy status that was assigned to the original holder by IANA. This is currently being used as a loophole by certain actors to opt out of having a contractual relationship with the RIPE NCC in order to circumvent: * RIPE registration services fees. * The 24-month transfer lock that was introduced by this working group to prevent flipping of scarce resources. * Needs-based inter-RIR transfer policy utilization requirements in the case of transfers from another RIR to a recipient of a legacy resource transfer in the RIPE region. Following the publication of the Report of the RIPE NCC Charging Scheme Task Force, the membership learned that the RIPE NCC currently needs to dedicate a 0.5FTE to process legacy transfers. There are currently around 2,400 legacy resources held by 1,600 holders with no contractual relationship with the RIPE NCC (neither direct nor via a sponsor). That is around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC staff have processed between 370-280 legacy transfers per year, of which roughly a third do not involve a party with a contractual relationship with the NCC. Legacy transfers are more labor-intensive than other transfer types because the due diligence process requires the Registration Services team to manually source and verify pertaining documentation without the benefits of the automated processes for standard allocations. Legacy transfers take an average seven working hours to process when neither party has a contractual relationship with the NCC (around a third of legacy transfers), and six working hours to process when the parties have a contractual relationship with the NCC. If resources lost their legacy status after a transfer, these would then become standard allocations and staff could leverage enhanced compliance checks and automated processes to facilitate any future updates/transfers. These just take 1-3 working hours to process instead. Given that the task force was deemed out of scope for a policy change to address this gap, this is being brought to the attention of the Address Policy Working Group for action. If there are any concerns, questions or considerations you would like to bring up before we submit this proposal for discussion in the next week or two, we would really appreciate hearing from you so we can address these and/or incorporate them. Thanks in advance, Clara Wade

1 0