<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Denis,
<div class=""><br class="">
</div>
<div class="">Thanks for your comments, the key intent would be to provide the ability for legacy holders to have control over their blocks enabling self-service of the legacy blocks. Currently, that is not the case. There are many instances where a holder
must contact RIPE NCC to intervene on behalf of the number block holder. It is the intent that we just treat legacy fairly to enable legacy holders the ability to keep their own records updated. </div>
<div class=""><br class="">
</div>
<div class="">If I own a legacy number block I should have the ability to manage the records associated with my block. If a record is outdated, I should be able to use a self-service tool to updated my records. </div>
<div class=""><br class="">
</div>
<div class="">In the case where some members of the community were against enabling the reclaim functionality for legacy blocks, I would ask why they believe legacy blocks should be treated separately? From my perspective a legacy holder should have all of
the same abilities. </div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Billy</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 27, 2015, at 9:09 PM, <a href="mailto:ripedenis@yahoo.co.uk" class="">
ripedenis@yahoo.co.uk</a> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div style="background-color: rgb(255, 255, 255); font-family: 'Helvetica Neue-Light', 'Helvetica Neue Light', 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" class="">
<div id="yui_3_16_0_1_1445968061063_6201" class="">HI guys</div>
<div id="yui_3_16_0_1_1445968061063_5757" class=""><br class="">
</div>
<div id="yui_3_16_0_1_1445968061063_5248" class="">You need to think about what you are doing here. If you invent a new mechanism to remove the association of a ROUTE object from some address space what does that mean? If such a mechanism was adopted, implemented
and everyone knew what it means, those ROUTE objects will be ignored. So you may as well have simply deleted them. Don't try to invent a new mechanism that leaves redundant, misleading garbage in the database.</div>
<div id="yui_3_16_0_1_1445968061063_5396" class=""><br class="">
</div>
<div id="yui_3_16_0_1_1445968061063_5758" dir="ltr" class="">This issue was discussed around the time of the last RIPE Meeting. It only relates to legacy space as RIPE address space is covered by the reclaim functionality. The question previously discussed
was whether to allow the reclaim functionality to be used by top level legacy resource holders. If I remember some people were in favour and some weren't.</div>
<div id="yui_3_16_0_1_1445968061063_6200" dir="ltr" class=""><br class="">
</div>
<div id="yui_3_16_0_1_1445968061063_5934" dir="ltr" class="">The arguments for are to allow practical administration of legacy resources which are hindered by some historical objects. The arguments against were those occasions where some legacy resource was
divided and sold/given/otherwise transferred to some other user but the RIPE NCC is not aware of that change and it is not reflected in the RIPE Database. By giving the reclaim functionality to known top level legacy resource holders they may gain control
over resources they have no right to have. But that can be mitigated by the RIPE NCC being able to replace any deleted objects if someone provides the documentation to show they are the legitimate holder of the affected resource.</div>
<div id="yui_3_16_0_1_1445968061063_6049" dir="ltr" class=""><br class="">
</div>
<div id="yui_3_16_0_1_1445968061063_6257" dir="ltr" class="">So you need to make a decision on allowing the reclaim functionality to be used by legacy resource holders rather than inventing some parallel functionality that actually achieves the same effect
with the same benefits/consequences.</div>
<div id="yui_3_16_0_1_1445968061063_6259" dir="ltr" class=""><br class="">
</div>
<div id="yui_3_16_0_1_1445968061063_6301" dir="ltr" class="">cheers</div>
<div dir="ltr" class="">denis<br class="">
</div>
<div id="yui_3_16_0_1_1445968061063_5117" class=""><span class=""></span></div>
<br class="">
<div id="yui_3_16_0_1_1445968061063_5121" style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" class="">
<div id="yui_3_16_0_1_1445968061063_5120" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" class="">
<div id="yui_3_16_0_1_1445968061063_5119" dir="ltr" class="">
<hr id="yui_3_16_0_1_1445968061063_5118" size="1" class="">
<font id="yui_3_16_0_1_1445968061063_6313" face="Arial" size="2" class=""><b class=""><span style="font-weight:bold;" class="">From:</span></b> William Sylvester <<a href="mailto:william.sylvester@addrex.net" class="">william.sylvester@addrex.net</a>><br class="">
<b class=""><span style="font-weight: bold;" class="">To:</span></b> Janos Zsako <<a href="mailto:zsako@iszt.hu" class="">zsako@iszt.hu</a>>
<br class="">
<b class=""><span style="font-weight: bold;" class="">Cc:</span></b> "<a href="mailto:db-wg@ripe.net" class="">db-wg@ripe.net</a>" <<a href="mailto:db-wg@ripe.net" class="">db-wg@ripe.net</a>>
<br class="">
<b class=""><span style="font-weight: bold;" class="">Sent:</span></b> Tuesday, 27 October 2015, 19:02<br class="">
<b class=""><span style="font-weight: bold;" class="">Subject:</span></b> Re: [db-wg] Control over associating objects for number blocks<br class="">
</font></div>
<div id="yui_3_16_0_1_1445968061063_6345" class="y_msg_container"><br class="">
Janos, <br clear="none" class="">
<br clear="none" class="">
Thanks for the email, you have identified the heart of the issue. When a route exists that is not maintained by the same maintainer as the number block what should the authorization hierarchy be for that block? Especially when that record keeps a number block
holder from managing the information associated with their number block. <br clear="none" class="">
<br clear="none" class="">
Previously we had discussed giving an upper maintainer status to the number block holder over those objects but some members of the community were worried that this might cause problems for records they wanted no control over.
<br clear="none" class="">
<br clear="none" class="">
The intent of the language I used was specifically to avoid the issue of provided extra maintainer status for certain objects leaving that for their actual maintainer. But to have the ability to remove them from being associated with your network block.
<br clear="none" class="">
<br clear="none" class="">
I am open to ideas on how to best accomplish this task. I know in certain cases this is already possible based on the status of your space and the tool you are using. I was mostly advocating for this feature to be available for all blocks, enabling holders
to have full control over their number block. <br clear="none" class="">
<br clear="none" class="">
Thanks,<br clear="none" class="">
Billy<br clear="none" class="">
<br clear="none" class="">
<br clear="none" class="">
<div class="qtdSeparateBR"><br class="">
<br class="">
</div>
<div class="yqt3906253678" id="yqtfd62618"><br clear="none" class="">
> On Oct 27, 2015, at 1:46 PM, Janos Zsako <<a shape="rect" ymailto="mailto:zsako@iszt.hu" href="mailto:zsako@iszt.hu" class="">zsako@iszt.hu</a>> wrote:<br clear="none" class="">
> <br clear="none" class="">
> Dear Billy,<br clear="none" class="">
> <br clear="none" class="">
> I think I understand the problem you describe and I think it is useful to<br clear="none" class="">
> try to solve it in some automatic way (i.e. without the human intervention<br clear="none" class="">
> from the RIPE NCC).<br clear="none" class="">
> <br clear="none" class="">
> I cannot, however, understand the following part:<br clear="none" class="">
> <br clear="none" class="">
>> The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block.<br clear="none" class="">
> <br clear="none" class="">
> As an example I think of 192.168.0.0-192.168.255.255 being assigned to<br clear="none" class="">
> COMPANY and the inetnum has COMPANY-MNT as maintainer.<br clear="none" class="">
> <br clear="none" class="">
> In the database we can find the following route:<br clear="none" class="">
> <br clear="none" class="">
> route: 192.168.0.0/16<br clear="none" class="">
> descr: whatever<br clear="none" class="">
> origin: AS64500<br clear="none" class="">
> mnt-by: AS64500-MNT<br clear="none" class="">
> ...<br clear="none" class="">
> source: RIPE # Filtered<br clear="none" class="">
> <br clear="none" class="">
> and COMPANY does not have control over AS64500-MNT.<br clear="none" class="">
> <br clear="none" class="">
> How could COMPANY modify this route in such a way that they remove the<br clear="none" class="">
> association with their assignment _without_ deleting it?<br clear="none" class="">
> <br clear="none" class="">
> The same applies to a reverse delegation, e.g.:<br clear="none" class="">
> <br clear="none" class="">
> domain: 168.192.in-addr.arpa<br clear="none" class="">
> descr: whatever<br clear="none" class="">
> ...<br clear="none" class="">
> mnt-by: AS64500-MNT<br clear="none" class="">
> ..<br clear="none" class="">
> source: RIPE # Filtered<br clear="none" class="">
> <br clear="none" class="">
> Could you please clarify what you meant by the above?<br clear="none" class="">
> <br clear="none" class="">
> Did you have in mind that these could be transformed in a fake route<br clear="none" class="">
> (or domain) mobject like:<br clear="none" class="">
> <br clear="none" class="">
> route: 10.0.0.0/8<br clear="none" class="">
> descr: orphaned 192.168.0.0/16<br clear="none" class="">
> descr: whatever<br clear="none" class="">
> origin: AS64500<br clear="none" class="">
> mnt-by: AS64500-MNT<br clear="none" class="">
> ...<br clear="none" class="">
> source: RIPE # Filtered<br clear="none" class="">
> <br clear="none" class="">
> or<br clear="none" class="">
> <br clear="none" class="">
> domain: 10.in-addr.arpa<br clear="none" class="">
> descr: orphaned 168.192.in-addr.arpa<br clear="none" class="">
> descr: whatever<br clear="none" class="">
> ...<br clear="none" class="">
> mnt-by: AS64500-MNT<br clear="none" class="">
> ..<br clear="none" class="">
> source: RIPE # Filtered<br clear="none" class="">
> <br clear="none" class="">
> respectively?<br clear="none" class="">
> <br clear="none" class="">
> Thanks and regards,<br clear="none" class="">
> Janos<br clear="none" class="">
> <br clear="none" class="">
>> Billy<br clear="none" class="">
>> <br clear="none" class="">
>> William Sylvester<br clear="none" class="">
>> <a shape="rect" ymailto="mailto:william.sylvester@addrex.net" href="mailto:william.sylvester@addrex.net" class="">
william.sylvester@addrex.net</a> <mailto:<a shape="rect" ymailto="mailto:william.sylvester@addrex.net" href="mailto:william.sylvester@addrex.net" class="">william.sylvester@addrex.net</a>><br clear="none" class="">
<br clear="none" class="">
</div>
<br class="">
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>