<html><head></head><body><div class="ydp5c379ecfyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
        <div dir="ltr" data-setdir="false">Hi Lee</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">With the current data model it is not possible to have two independent objects with the same primary key. Creating 2 smaller objects is a work around. Having 2 status attributes is another work around. The question is, which work around is preferable?</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">cheers</div><div dir="ltr" data-setdir="false">denis</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">co-chair DB-WG</div><div><br></div>
        
        </div><div id="ydp39cc9b1dyahoo_quoted_6542818136" class="ydp39cc9b1dyahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Tuesday, 17 November 2020, 14:25:35 CET, Howard, Lee <leehoward@hilcostreambank.com> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div id="ydp39cc9b1dyiv4178526307"><div>
<div class="ydp39cc9b1dyiv4178526307WordSection1">
<p class="ydp39cc9b1dyiv4178526307MsoNormal">That sounds like it would be confusing to me.</p> 
<p class="ydp39cc9b1dyiv4178526307MsoNormal">I’d want to see both the allocation to the LIR and the assignment to the end user independently.</p> 
<p class="ydp39cc9b1dyiv4178526307MsoNormal">  </p> 
<p class="ydp39cc9b1dyiv4178526307MsoNormal">Lee</p> 
<p class="ydp39cc9b1dyiv4178526307MsoNormal">  </p> 
<div class="ydp39cc9b1dyiv4178526307yqt9183718812" id="ydp39cc9b1dyiv4178526307yqt57282"><div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in;">
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><b>From:</b> address-policy-wg <address-policy-wg-bounces@ripe.net>
<b>On Behalf Of </b>ripedenis--- via address-policy-wg<br clear="none">
<b>Sent:</b> Monday, November 16, 2020 7:57 AM<br clear="none">
<b>To:</b> address-policy-wg@ripe.net<br clear="none">
<b>Subject:</b> [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call</p> 
</div>
</div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal">  </p> 
<div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">Colleagues</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">We have not had enough comment on this to make a decision if any change is needed. So can we have a last round of comment to decide if this is a sufficiently important issue
 to make a change or if we just close this action item?</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">In brief: when assigning a whole allocation should we be able to give the INET(6)NUM object 2 status values to reflect it being both an allocation and an assignment, rather
 than splitting it into two smaller assignment objects?</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">cheers</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">denis</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">co-chair DB-WG</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;">  </span></p> 
</div>
</div>
<div id="ydp39cc9b1dyiv4178526307ydp4a04109byahoo_quoted_5681846315">
<div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via address-policy-wg <<a shape="rect" href="mailto:address-policy-wg@ripe.net" rel="nofollow" target="_blank">address-policy-wg@ripe.net</a>> wrote:
</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<div id="ydp39cc9b1dyiv4178526307ydp4a04109byiv4630048067">
<div>
<div>
<div>
<div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">Colleagues</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion...</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">Yet another 4 year old NWI that needs to be progressed or closed. The details are here:</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;"><a shape="rect" href="https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html" rel="nofollow" target="_blank">https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html</a></span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object
 and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute.</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects
 to:</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">status:         [mandatory]  [multiple]     [ ]</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could
 be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business
 rules could prevent any other multiple status values.</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">The "descr:" attribute is already multiple so it can describe both the allocation and the assignment.</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">Is this still considered to be an issue?</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">cheers</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">denis</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">co-chair DB-WG</span></p> 
</div>
</div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:12.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
</div>
<div id="ydp39cc9b1dyiv4178526307ydp4a04109byiv4630048067yqt23235">
<div id="ydp39cc9b1dyiv4178526307ydp4a04109byiv4630048067ydp88fc6355yahoo_quoted_2039788714">
<div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais <<a shape="rect" href="mailto:ebais@a2b-internet.com" rel="nofollow" target="_blank">ebais@a2b-internet.com</a>> wrote:
</span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">  </span></p> 
</div>
<div>
<div>
<p class="ydp39cc9b1dyiv4178526307MsoNormal"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">Dear WG, 
<br clear="none">
<br clear="none">
I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period. 
<br clear="none">
<br clear="none">
Please have a look at this discussion again and provide input if you can.  <br clear="none">
<br clear="none">
Regards,<br clear="none">
Erik Bais<br clear="none">
Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) </span></p> 
<div id="ydp39cc9b1dyiv4178526307ydp4a04109byiv4630048067ydp88fc6355yqtfd32914">
<p class="ydp39cc9b1dyiv4178526307MsoNormal" style="margin-bottom:12.0pt;"><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;"><br clear="none">
</span><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;"></span><span style="font-size:10.0pt;font-family:sans-serif;color:#26282A;">On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" <<a shape="rect" href="mailto:address-policy-wg-bounces@ripe.net" rel="nofollow" target="_blank">address-policy-wg-bounces@ripe.net</a>
 on behalf of <a shape="rect" href="mailto:phasani@ripe.net" rel="nofollow" target="_blank">phasani@ripe.net</a>> wrote:<br clear="none">
<br clear="none">
    Dear colleagues,<br clear="none">
    <br clear="none">
    Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies.<br clear="none">
    <br clear="none">
    While this was helpful, it would be great if we could have input from a wider group of people:<br clear="none">
    <br clear="none">
    - Should inetnums with these statuses be allowed to be created inside one another?<br clear="none">
    - Should there be a limit on the minimum size of a sub-allocation?<br clear="none">
    - Do we need a policy update?<br clear="none">
    <br clear="none">
    <a shape="rect" href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2020-June%2F013195.html&data=04%7C01%7CLeeHoward%40hilcostreambank.com%7C7ba19ef79b8f4653681a08d88a2f5f79%7Cff73069906cc473891ab5061e4890dca%7C0%7C0%7C637411283368106800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XX5hMCModpP8X15OOfc4jXuIGlqrY3xQooivZQuA6zM%3D&reserved=0" rel="nofollow" target="_blank">
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.html</a><br clear="none">
    <br clear="none">
    We look forward to hearing from you.<br clear="none">
    <br clear="none">
    Cheers,<br clear="none">
    --<br clear="none">
    Petrit Hasani<br clear="none">
    Policy Officer<br clear="none">
    RIPE NCC<br clear="none">
    <br clear="none">
    <br clear="none">
    <br clear="none">
    <br clear="none">
    <br clear="none">
    > On 16 Jun 2020, at 15:36, Petrit Hasani <<a shape="rect" href="mailto:phasani@ripe.net" rel="nofollow" target="_blank">phasani@ripe.net</a>> wrote:<br clear="none">
    > <br clear="none">
    > Dear colleagues,<br clear="none">
    > <br clear="none">
    > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics).<br clear="none">
    > <br clear="none">
    > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group.<br clear="none">
    > <br clear="none">
    > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes
 ending with the sub-allocation of a single IP address.<br clear="none">
    > <br clear="none">
    > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple
 daughter companies. These daughter companies could then create and maintain assignments for their actual networks.<br clear="none">
    > <br clear="none">
    > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments.<br clear="none">
    > <br clear="none">
    > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states:<br clear="none">
    > <br clear="none">
    > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA".<br clear="none">
    > <br clear="none">
    > [...]<br clear="none">
    > <br clear="none">
    > LIRs may make sub-allocations to multiple downstream network operators."<br clear="none">
    > <br clear="none">
    > <a shape="rect" href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-733%2354&data=04%7C01%7CLeeHoward%40hilcostreambank.com%7C7ba19ef79b8f4653681a08d88a2f5f79%7Cff73069906cc473891ab5061e4890dca%7C0%7C0%7C637411283368106800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n8HiGf012wc81XrQp4Ur5YL0noBsvFpVgRx3WwaB2nY%3D&reserved=0" rel="nofollow" target="_blank">
https://www.ripe.net/publications/docs/ripe-733#54</a><br clear="none">
    > <br clear="none">
    > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group:<br clear="none">
    > <br clear="none">
    > - Should inetnums with these statuses be allowed to be created inside one another?<br clear="none">
    > - Should there be a limit on the minimum size of a sub-allocation?<br clear="none">
    > - Do we need a policy update?<br clear="none">
    > <br clear="none">
    > We look forward to your guidance.<br clear="none">
    > <br clear="none">
    > Kind regards,<br clear="none">
    > --<br clear="none">
    > Petrit Hasani<br clear="none">
    > Policy Officer<br clear="none">
    > RIPE NCC<br clear="none">
    > <br clear="none">
    > <br clear="none">
    > <br clear="none">
    > <br clear="none">
    > <br clear="none">
    <br clear="none">
    </span></p> 
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div>
</div>
</div></div></div>
            </div>
        </div></body></html>