[address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

Hi,

On Mon, Oct 31, 2022 at 01:49:46PM +0100, Tore Anderson wrote:
> I never quite understood why we appear to be totally OK with not
> requiring each individual IPv6 customer assignment to be registered in
> the database, while we continue to require it for IPv4.

For pool assignments (dynamic IP addresses handed out to dial-in
customers), we as a LIR just registered them as ASSIGNED PA assigned
to ourselves (and "back then" these assignments fell under the
INFRA-AW clause).

But for "static assignments", I think policy never permitted this.

> In IPv6, LIRs may create an status:AGGREGATED-BY-LIR inet6num,
> essentially saying something like «in this block there are a gazillion
> end users, and I am the tech/abuse contact for all of them».
> 
> In IPv4, there is no such option. The LIR is required by policy to
> create a gazillion individual status:ASSIGNED inetnums instead, all
> containing the exact same contact info. These do not add any value
> though, they're just a PITA to maintain.
> 
> Is there any particular reason why we can't simply "backport"
> status:AGGREGATED-BY-LIR to IPv4?

The way you word it for IPv6 seems to make sense for IPv4 as well - so
yes, this sounds like a good idea to cover the "these addresses are
assigned, but there is no interesting contact info here" aspect, and
at the same time making IPv4 and IPv6 policy less different.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20221031/1bf28559/attachment.sig>