{i see that i missed older emails of the thread :'-(}
Dear DBWG,
Thanks to find few comments below, inline, please.Le jeudi 13 juin 2024, Frank Habicht <[email protected]> a écrit : > Hi all, > > I've seen another few domain objects for /64's created :-( > > Hi Frank, Again, thanks for notifying us, brother! What AfriNIC could do? Let's see...if we could figure it out... > > Should we keep allowing this? > > ...already shared my humble opinion on the way to go. However, maybe, we should consider following steps: 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; 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 :-/); 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; Step4| end of transition period - align all `domain` objects with its IP delegation (allocation/assignment); Step5| within the Whois DB, keep only one aligned `domain` object for each delegated IP block; 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); Step7| launch a more modern (like ARIN's OT&E - Operational Test & Evaluation environments) instance of the Whois DB for test purposes; Step8| such OT&E environnements could help in quickly implement requested changes under our consensually adopted WI (Work Items - WI); Step9| add it as a task for the Whois DBWG to build an active team of beta-tester volunteers; Step10| monitor and publish stats on the progresses made through steps where it makes sense; Step11| put any missing/forgotten step here or anywhere above and remove any bad idea included. [...] > I propose, if consensus: > - domain objects with .ip6.arpa can not have more than 12 hexits when > created > - staff to contact owners of the domain objects with more than 12 hexits > to create an object covering their allocation/assignment and > eventually delete the domain object covering an unnecessarily specific > prefix > There are 110 if my grep counted correctly. > Surely from much fewer organisations. > > > Regards, > Frank > ...i bring back the initial proposal; in hopes that we would now all have a better understanding of what is at stake... ...in order, maybe, to update it? prior to adopt the final draft proposal of WI? Thanks! Shalom, --sb. > > Regards, > Frank > > > > On 24/03/2024 21:04, Frank Habicht wrote: > >> Hi DBWG, >> >> I didn't see any responses to below email. >> >> But I've seen some new objects created recently - [1] >> >> Is there no interest to stop objects like [1] from being created? >> >> I'm conflicted as in both thinking a change is called for and trying to >> be a neutral chair. >> >> So I think if there's no response, then I can not be an impartial chair >> and declare consensus. >> >> There seem to be 11 domain objects for /128's. >> There seem to be 108 domain objects for longer than /48. >> >> I.e. not a current problem as much as a potential problem when any >> average LIR can create 2^96 domain objects. >> Sorry. That's the number of objects for /128's to create. >> Total of 2^97-1 objects can be created when including all the shorter >> ones. >> >> Thanks, >> Frank >> >> [1] >> domain: 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.0.0.0.0.0.0.0.f.f.f.0. >> c.2.ip6.arpa >> descr: BTCL INTERNAL6 >> nserver: ns4.btc.bw >> nserver: ns1.btc.bw >> nserver: vpsm.btc.bw >> org: ORG-BTC2-AFRINIC >> admin-c: BM16-AFRINIC >> admin-c: OSD1-AFRINIC >> admin-c: IO10-AFRINIC >> tech-c: BM16-AFRINIC >> tech-c: OSD1-AFRINIC >> tech-c: IO10-AFRINIC >> zone-c: BM16-AFRINIC >> zone-c: OSD1-AFRINIC >> zone-c: IO10-AFRINIC >> mnt-by: TF-196-1-130-0-196-1-133-255-MNT >> mnt-lower: TF-196-1-130-0-196-1-133-255-MNT >> changed: [email protected] 20240319 >> source: AFRINIC >> >> >> On 22/02/2024 17:01, Frank Habicht wrote: >> >>> On 07/09/2020 17:21, Ben Maddison wrote: >>> >>>> Hi Simon, all, >>>> >>>> On 09/07, Simon Seruyinda wrote: >>>> >>>>> Hi Frank, >>>>> >>>>> <snip/> >>>>> >>>>> 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. >>>>> 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. >>>>> >>>>> I would align with the minimum allocation size (/48, right?). >>>> It's conceivable that a resource holder might want to delegate down >>>> further, but that, I believe, should be a task for the operator's >>>> nameservers. >>>> >>> >>> So, >>> >>> I apparently was wrong assuming something was already implemented. >>> >>> I've just seen that a domain object for a /128 was created yesterday. >>> >>> 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) >>> >>> >>> I propose, if consensus: >>> - domain objects with .ip6.arpa can not have more than 12 hexits when >>> created >>> - staff to contact owners of the domain objects with more than 12 hexits >>> to create an object covering their allocation/assignment and >>> eventually delete the domain object covering an unnecessarily specific >>> prefix >>> There are 110 if my grep counted correctly. >>> Surely from much fewer organisations. >>> >>> >>> Regards, >>> Frank >>> >> >> [...] > > > -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] | [[https://www.cmnog.cm/dokuwiki/Structure |cmNOG's Structure]] | [[https://survey2.cmnog.cm/ |cmNOG's Surveys]] | [[ https://lists.cmnog.cm/mailman/listinfo/cmnog |Subscribe to cmNOG's Mailing List]] | [[https://tools.std.douala-ix.net/lg |DIX's LookingGlass]] | __ #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! #MaPrière est que tu naisses de nouveau.#Chrétiennement
_______________________________________________ DBWG mailing list [email protected] https://lists.afrinic.net/mailman/listinfo/dbwg
