[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi again Brian,

* Brian Storey

> I'm conscious you've gone to a great deal of effort to respond back
> to me promptly and I've not come back to you sooner. Sorry to keep
> you waiting for at least an acknowledgement.
> 
> Firstly, thank you for taking us through this example. I can see
> yourself and Dennis have developed this converdation further.
> 
> Rather than tread on that, I'll perhaps offer a slightly different
> spin on this which is neither in support or against your proposal,
> but in respect to how a LIR is supposed to determine what they should
> or shouldn't do. I'll be honest and say that I'm a relative newcomer
> to this having taken on the adminsitrative responisbility and
> compliance here less than 12 months ago.
> 
> Whilst there is a degree of "This is the way" (from an internal &
> external perspective) with what I or anyone else takes on, I did want
> to audit and review as many aspects of what we should be doing as per
> policies, terms and conditions, RIPE DB Training, assumed best
> practice etc.
> 
> What is apparent to me is that whilst a policy may describe a "must",
> it isn't nessecarily prescriptive on the "how" and is sufficiently
> narrow leaving how the end result is achieved. Certaintly I don't
> think this how the policies are intended to be written but there are
> some leaps you need to make as to what you should perhaps do or not
> do. A policy alone, in the case of RIPE-733 is a good example of
> this, in particular when you also consider clause 3.0 bullet 4.
> 
> I know this isn't a unique problem but:-
>         - Within quick succession I had two end business customers
> reach out to us to remove their business name from the description of
> the relevant INET ASSIGNED PA entry. Reasons cited were security.
> Whilst I looked at what we could possibly do, on balance we
> determined that it wasn't an option because of policy, other
> obligations and objectives. To also help support this view, we could
> see other LIRs providing service for the same end business who have
> taken the same approach as us, so at least we are collectively
> consistent!
>         - On the other side, there was another new end business
> reaching out asking why the assignment with their details hadn't been
> published yet!
> 
> Clearly two competing interests!
> 
> Where does this lead me? 
> 
> Well, clearly we want administrative simplicity. Not only that, a
> clear way to explain internally and externally downstream to end
> customers but also up to RIPE NCC why we do it the way we do.
> Referencing clear policies is important to help justify why we take a
> certain approach and explain any limitations we may have. With the
> proposal you have presented, whilst I understand the rationale of it,
> I'm not quite seeing how without some of the discussion being had
> here, someone can read it and proceed as intended or take our
> explanation / interpretation of our obligations and apply them
> consistently. I recognise the latter part is part of the challenge
> now and a goal to be addressed. The path of least resistance starts
> to become very attractive!
> 
> Perhaps I'm going down a rabbit hole with this. Ultimately I'm
> looking to make sure I understand how to remain on the right side of
> things! 😊.
> 
> With regard to AGGREGATED-BY-LIR and its existence with IPV6; yes,
> it's something which drew some interest when I first started and the
> different approaches. Feels like there is a bit more subtly to this
> though.

You bring up an interesting debate here. Different LIRs have different
policies when it comes to how much and what kind of information should
be injected into the RIPE database, and as you point out, even end
users might have different expectations here.

The actual requirements of the policy is quite clear though - it is
mandatory to register all assignments, and it is mandatory to register
the end user's contact information (the admin-c and tech-c attributes).
 
However, often the LIR/ISP itself will assume the admin-c/tech-c role
on behalf of the end user (who might not be very tech-savvy and would
therefore prefer to "outsource" this role to the LIR in this manner),
so it is actually not mandatory to identify the assignee by name.

Additionally, the RIPE database inetnum template makes it mandatory to
include one or more country attributes.

Other than these mandatory minimums, each individual LIR is free to set
its own policies on which additional information to publish, if any.
The sky's the limit here - there are not one, but two free-text
attributes (descr and remarks), so anything goes!

For the record, the full inetnum template can be seen here:

https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true&searchtext=-t%20inetnum&source=RIPE

Coming back to our 2023-04 proposal, we would like to make it clear
that it does not take a position in this larger debate you bring up.
2023-04 does not take away the ability of any LIR to publish any kind
of optional information they would like to, nor does it relax the
mandatory minimums described above. That is: anything that is currently
OK, will be OK after the implementation of 2023-04 too. No LIR will be
forced to change their current policies to register AGGREGATED-BY-LIR
objects instead of what it is that they are currently doing.

Instead, we recognise the current policy for what it is, and see that
it in some situations requires LIRs to register large numbers of small
and essentially identical objects in the database. We see these as both
pointless and labour-intensive to maintain, so our aim is to provide an
optional mechanism that can ease this work load significantly.

Since the IPv6 policy have for a long time contained a tried'n'true
mechanism that does just that, we believe the easiest way is to copy
that into IPv4.

Tore