[DBWG] person without email... and domain object size

Mon Jun 17 10:56:27 UTC 2024

{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 <geier at geier.ne.tz> 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:        malibalak at btc.bw 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20240617/f83b831a/attachment.html>