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

[Ben Maddison]

Hi Willy,

On 03/27, Willy Manga wrote:
> Hi,
> 
> speaking in my personal capacity...
> 
> On 24/03/2024 22: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 will split into 2 sections.
> 
> Section 1: what is clear
> 
[snip]
> 
> Section 2: where we need an agreement.
> 
> Shall we allow creation of domain object for IPv6 prefix longer than 48?
> Yes. Until ISP decide unilaterally to assign at least 1x/48 to each
> corporate or 'premium' customer, domain object speaking, we shall accept
> these objects.
> 
> The challenge is to find a 'right' limit . I will suggest we allow creation
> of domain object for IPv6 reverse zone up to 56.
> 
> Between 48 and 56, you might have enterprise or 'premium' customer. You have
> such examples in AFRINIC database. Prefix speaking, longer than 56, it's
> usually residential user, smartphone or let put it that way: user with low
> to zero capacity to manage a DNS zone.

We disagree here.
The `domain` object is there to describe the delegation from the RIR to
the LIR. The LIR should be operating the zone containing further
downstream delegations to its end-users.

Perhaps the confusion here is that LIRs *are* expected to register
inet[6]num objects for their sub-allocations/assignments?
In a perfect world, I would like to see LIRs running their own whois
services, but the necessary delegation mechanisms do not exist.

However, performance of whois services are rarely mission critical in
the way that DNS services are.

There are competing concerns here:
1.  The zone size at the RIR must be constrained to a reasonable size;
    and
2.  We should not be in the business of legislating downstream
    allocation policy in this WG (we have the PDWG for that).

Accordingly, I still believe that the permitted domain object size limit
should track the minimum RIR allocation size.

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20240404/4f0e255e/attachment.sig>