<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1463926174694_68701"><span>Hi Job</span></div><div id="yui_3_16_0_ym19_1_1463926174694_68720"><br><span></span></div><div id="yui_3_16_0_ym19_1_1463926174694_68756"><span id="yui_3_16_0_ym19_1_1463926174694_68755">Again for clarification, I was jumping the gun a bit talking about possible solutions. I agree with the problem statement as put forward.</span></div><div id="yui_3_16_0_ym19_1_1463926174694_68779"><br><span id="yui_3_16_0_ym19_1_1463926174694_68755"></span></div><div id="yui_3_16_0_ym19_1_1463926174694_68780"><span id="yui_3_16_0_ym19_1_1463926174694_68755">cheers</span></div><div id="yui_3_16_0_ym19_1_1463926174694_68792"><span id="yui_3_16_0_ym19_1_1463926174694_68755">denis</span></div><div id="yui_3_16_0_ym19_1_1463926174694_68757" class="qtdSeparateBR"><br><br></div><div style="display: block;" id="yui_3_16_0_ym19_1_1463926174694_68762" class="yahoo_quoted"> <div id="yui_3_16_0_ym19_1_1463926174694_68761" style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1463926174694_68760" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1463926174694_68759" dir="ltr"> <font id="yui_3_16_0_ym19_1_1463926174694_68793" size="2" face="Arial"> <hr id="yui_3_16_0_ym19_1_1463926174694_68794" size="1"> <b><span style="font-weight:bold;">From:</span></b> "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk><br> <b><span style="font-weight: bold;">To:</span></b> Job Snijders <job@instituut.net>; "db-wg@ripe.net" <db-wg@ripe.net> <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, 25 May 2016, 15:40<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [db-wg] NWI-4 - role of status: field in multivalued status context<br> </font> </div> <div id="yui_3_16_0_ym19_1_1463926174694_68773" class="y_msg_container"><br><div id="yiv6328767924"><div id="yui_3_16_0_ym19_1_1463926174694_68772"><div id="yui_3_16_0_ym19_1_1463926174694_68771" style="color:#000;background-color:#fff;font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px;"><div id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59162">Hi Job</div><div id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59161"><br clear="none"></div><div dir="ltr" id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59159">This is another excellent example of how the data model could be improved. Currently we are constrained by this issue of the address range being the primary key that cannot be duplicated. What we see here is the need for an address range to be stored internally as both an allocation and an assignment. Then depending on the query the 'information' returned either shows the allocation data or the assignment data rather than the 'raw' data held in the database.<br clear="none"></div><div id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59158"><br clear="none"><span></span></div><div id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59235"><span>cheers</span></div><div id="yui_3_16_0_ym19_1_1463926174694_68770"><span>denis</span></div><div class="yiv6328767924qtdSeparateBR" id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59101"><br clear="none"><br clear="none"></div><div class="yiv6328767924yqt4879679459" id="yiv6328767924yqt08286"><div class="yiv6328767924yahoo_quoted" id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59105" style="display:block;"> <div id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59104" style="font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px;"> <div id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59103" style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px;"> <div dir="ltr" id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59102"> <font id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59106" size="2" face="Arial"> </font><hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Job Snijders <job@instituut.net><br clear="none"> <b><span style="font-weight:bold;">To:</span></b> db-wg@ripe.net <br clear="none"> <b><span style="font-weight:bold;">Sent:</span></b> Wednesday, 25 May 2016, 15:20<br clear="none"> <b><span style="font-weight:bold;">Subject:</span></b> [db-wg] NWI-4 - role of status: field in multivalued status context<br clear="none"> </div> <div class="yiv6328767924y_msg_container" id="yiv6328767924yui_3_16_0_ym19_1_1463926174694_59236"><br clear="none">Dear Working Group,<br clear="none"><br clear="none">(You can review <a rel="nofollow" shape="rect" target="_blank" href="https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html">https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html </a><br clear="none">to ensure you have an overview of the next steps.)<br clear="none"><br clear="none">NWI-4 <br clear="none">---------<br clear="none"> The RIPE NCC was tasked with the following action point: AP70.2<br clear="none"> [RIPE NCC] Come up with a proposal for the status: field to fix the<br clear="none"> requirement that certain objects may need multivalued status.<br clear="none"><br clear="none"> Some believe that the main underlying issue here is that it is<br clear="none"> currently not possible to create an assignment that is the same size<br clear="none"> as an allocation in the RIPE Database. And resource holders are of<br clear="none"> course supposed to create an assignment for the address space in an<br clear="none"> allocation that is in use, by address policy.<br clear="none"><br clear="none"> The main reason for this limitation is that the INET(6)NUM attribute<br clear="none"> is a primary key. There is a work-around for this problem. Instead<br clear="none"> of creating an assignment of the same size it's possible to create<br clear="none"> two smaller assignments instead. In our (red: RIPE NCC) experience<br clear="none"> this work-around has always been accepted.<br clear="none"><br clear="none"> Still if the allocation is used as a whole, having a single<br clear="none"> assignment for the whole block is a more accurate reflection of<br clear="none"> reality, and it reduces the amount of objects to maintain.<br clear="none">----------<br clear="none"><br clear="none">The AP70.2 action point refers to a suggest solution, following earlier<br clear="none">discussion. But the chairs believe it would be good to bring this back<br clear="none">to a clear problem statement first, and then suggest different solutions<br clear="none">and their respective benefits and/or problems.<br clear="none"><br clear="none">Furthermore address-policy wg policies mention the different statuses<br clear="none">and what the different statusses reflect. Therefore we'll need to inform<br clear="none">the address policy working group as well.<br clear="none"><br clear="none">If you agree or disagree with this problem statement, please indicate<br clear="none">your opinion on this mailinglist. Refinements to the text are welcome<br clear="none">too.<br clear="none"><br clear="none">Kind regards,<br clear="none"><br clear="none">Job<br clear="none"><br clear="none"><br clear="none"><br clear="none"></div> </div> </div> </div></div></div></div></div><br><br></div> </div> </div> </div></div></body></html>