{i see that i missed older emails of the thread :'-(}<div>Dear DBWG,</div><div>Thanks to find few comments below, inline, please.</div><div><br><br>Le jeudi 13 juin 2024, Frank Habicht <<a href="mailto:geier@geier.ne.tz" target="_blank">geier@geier.ne.tz</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I've seen another few domain objects for /64's created :-(<br><br></blockquote><div><br></div><div>Hi Frank,</div><div>Again, thanks for notifying us, brother!</div><div><br></div><div>What AfriNIC could do?</div><div>Let's see...if we could figure it out...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Should we keep allowing this?<br><br></blockquote><div><br></div><div>...already shared my humble opinion on the way to go.</div><div><br></div><div>However, maybe, we should consider following steps:</div><div><br></div><div>Step1| agree to task the Staff to align Whois objects' (maybe only those under the `domain` class) implementation with the constraints stated in the Policy Manual;</div><div>Step2| transition period - organize trainings (as rightly implied in Willy's email) + deployathons to help concerned resource holders/maintainers to fix the delegated zone delimitation problem (if i got it well :-/);</div><div>Step3| [optionally] launch, during the transition period, a "DfArZ - DNS free Auth rZone" service (where all `domain` objects covered/hosted are appropriately record --automatically-- in the Wois DB and the related delegated rZone is managed through a Control Panel by subscribed resource holders are ) as a path to prepare a more interesting side option (as already evocated by Ben): Delegated Wois server idea of project;</div><div>Step4| end of transition period - align all `domain` objects with its IP delegation (allocation/assignment);</div><div>Step5| within the Whois DB, keep only one aligned `domain` object for each delegated IP block;</div><div>Step6| make all of the old unaligned version of the affected (at the step: aligned) `domain` objects available for queries via a parallele instance of Whois DB (WhoWhas);</div><div>Step7| launch a more modern (like ARIN's OT&E - Operational Test & Evaluation environments) instance of the Whois DB for test purposes;</div><div>Step8| such OT&E environnements could help in quickly implement requested changes under our consensually adopted WI (Work Items - WI);</div><div>Step9| add it as a task for the Whois DBWG to build an active team of beta-tester volunteers;</div><div>Step10| monitor and publish stats on the progresses made through steps where it makes sense;</div><div>Step11| put any missing/forgotten step here or anywhere above and remove any bad idea included.</div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...]<br>I propose, if consensus:<br>- domain objects with .ip6.arpa can not have more than 12 hexits when<br> created<br>- staff to contact owners of the domain objects with more than 12 hexits<br> to create an object covering their allocation/assignment and<br> eventually delete the domain object covering an unnecessarily specific<br> prefix<br> There are 110 if my grep counted correctly.<br> Surely from much fewer organisations.<br><br><br>Regards,<br>Frank<br></blockquote></div><div><br></div><div><br></div><div><br></div><div>...i bring back the initial proposal; in hopes that we </div><div>would now all have a better understanding of what </div><div>is at stake...</div><div><br></div><div>...in order, maybe, to update it? prior to adopt the final draft proposal of WI?</div><div><br></div><div><br></div><div>Thanks!</div><div><br></div><div>Shalom,</div><div>--sb.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Regards,<br>
Frank<br>
<br>
<br>
<br>
On 24/03/2024 21:04, Frank Habicht wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi DBWG,<br>
<br>
I didn't see any responses to below email.<br>
<br>
But I've seen some new objects created recently - [1]<br>
<br>
Is there no interest to stop objects like [1] from being created?<br>
<br>
I'm conflicted as in both thinking a change is called for and trying to be a neutral chair.<br>
<br>
So I think if there's no response, then I can not be an impartial chair and declare consensus.<br>
<br>
There seem to be 11 domain objects for /128's.<br>
There seem to be 108 domain objects for longer than /48.<br>
<br>
I.e. not a current problem as much as a potential problem when any average LIR can create 2^96 domain objects.<br>
Sorry. That's the number of objects for /128's to create.<br>
Total of 2^97-1 objects can be created when including all the shorter ones.<br>
<br>
Thanks,<br>
Frank<br>
<br>
[1]<br>
domain: 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.<wbr>0.6.0.0.0.0.0.0.0.0.0.f.f.f.0.<wbr>c.2.ip6.arpa<br>
descr: BTCL INTERNAL6<br>
nserver: <a href="http://ns4.btc.bw" target="_blank">ns4.btc.bw</a><br>
nserver: <a href="http://ns1.btc.bw" target="_blank">ns1.btc.bw</a><br>
nserver: <a href="http://vpsm.btc.bw" target="_blank">vpsm.btc.bw</a><br>
org: ORG-BTC2-AFRINIC<br>
admin-c: BM16-AFRINIC<br>
admin-c: OSD1-AFRINIC<br>
admin-c: IO10-AFRINIC<br>
tech-c: BM16-AFRINIC<br>
tech-c: OSD1-AFRINIC<br>
tech-c: IO10-AFRINIC<br>
zone-c: BM16-AFRINIC<br>
zone-c: OSD1-AFRINIC<br>
zone-c: IO10-AFRINIC<br>
mnt-by: TF-196-1-130-0-196-1-133-255-M<wbr>NT<br>
mnt-lower: TF-196-1-130-0-196-1-133-255-M<wbr>NT<br>
changed: <a href="mailto:malibalak@btc.bw" target="_blank">malibalak@btc.bw</a> 20240319<br>
source: AFRINIC<br>
<br>
<br>
On 22/02/2024 17:01, Frank Habicht wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/09/2020 17:21, Ben Maddison wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Simon, all,<br>
<br>
On 09/07, Simon Seruyinda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Frank,<br>
<br>
<snip/><br>
<br>
Regarding the rdns objects size, thanks for bringing this up for discussion. Currently we have a limit for IPv4 set to minimum of /24, but there is no limit implemented for IPv6, so it will go up to 128.<br>
I agree this could lead to unnecessary db growth and i think a limit should be set. Input from the DBWG members on what would be the appropriate minimum would highly be appreciated.<br>
<br>
</blockquote>
I would align with the minimum allocation size (/48, right?).<br>
It's conceivable that a resource holder might want to delegate down<br>
further, but that, I believe, should be a task for the operator's<br>
nameservers.<br>
</blockquote>
<br>
So,<br>
<br>
I apparently was wrong assuming something was already implemented.<br>
<br>
I've just seen that a domain object for a /128 was created yesterday.<br>
<br>
I think we can now start a 1-week last call on the suggestion from Ben (yes, from long ago) to limit domain objects for IPv6 (i.e. ending in .ip6.arpa) to be covering no smaller(longer) prefixes than the minimum assignment size (currently /48)<br>
<br>
<br>
I propose, if consensus:<br>
- domain objects with .ip6.arpa can not have more than 12 hexits when<br>
created<br>
- staff to contact owners of the domain objects with more than 12 hexits<br>
to create an object covering their allocation/assignment and<br>
eventually delete the domain object covering an unnecessarily specific<br>
prefix<br>
There are 110 if my grep counted correctly.<br>
Surely from much fewer organisations.<br>
<br>
<br>
Regards,<br>
Frank<br>
</blockquote>
<br>[...]</blockquote>
<br>
</blockquote></div>
<br><br>-- <br>Best Regards ! <br>baya.sylvain [AT cmNOG DOT cm] | [[<a href="https://www.cmnog.cm/dokuwiki/Structure">https://www.cmnog.cm/dokuwiki/Structure</a> |cmNOG's Structure]] | <br>[[<a href="https://survey2.cmnog.cm/">https://survey2.cmnog.cm/</a> |cmNOG's Surveys]] | [[<a href="https://lists.cmnog.cm/mailman/listinfo/cmnog">https://lists.cmnog.cm/mailman/listinfo/cmnog</a> |Subscribe to cmNOG's Mailing List]] | <br>[[<a href="https://tools.std.douala-ix.net/lg">https://tools.std.douala-ix.net/lg</a> |DIX's LookingGlass]] | <br>__ <br>#LASAINTEBIBLE|#Colossiens2:14,13-17«14 IL a effacé l'acte dont les ordonnances nous condamnaient et qui subsistait contre nous, et IL l'a détruit en le clouant à la croix;»#AMEN,#Maranatha,#MerciJÉSUS! <br>#MaPrière est que tu naisses de nouveau.#Chrétiennement <br>