Hi Tore, 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.
Many thanks,
Brian
-----Original Message-----
From: Tore Anderson <[email protected]>
Sent: Tuesday, September 12, 2023 7:52 AM
To: Brian Storey <[email protected]>; [email protected]
Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add
AGGREGATED-BY-LIR status for IPv4 PA assignments)
Hi Brian,
* Brian Storey
> Thanks for explaining this particular use case.
>
> Reading the proposed New Policy Text, it provides the LIR with an
> adminsitrative choice. Whilst I understand this choice, the rantionale
> behind the proposal is to find a reasonable way to fill the gap for
> the Provider Allocations not registered for the specific exception
> documented: "IP addresses used solely for the connection of an End
> User to a service provider... can be registered as part of the service
> provider's internal infrastructure".
>
> Given the choice provided in the proposal, it seems to me like I could
> go the other way with this and aggregate everything? The end user
> allocation size distinction no longer looks to apply and I could
> interprete that the "purpose" of the whole aggregate is consistent
> (they are all used to reach "stuff") and therefore chose to not
> register any end user assigned /29s, 28s, /27s etc.
It depends on whether or not all your assignments are completely uniform (apart
from the prefix value and length). If they are, you will be able to aggregate
them.
This means that they need to share a single common point of contact, which is
often the case for assignments associated with fully managed Internet services
provided to private individuals and small businesses.
Such assignments would be possible to aggregate.
If on the other hand they are not uniform (for example if your customers
operate their own NOCs and therefore have different contact information), you
will not be able to aggregate them.
I will try to explain by example here as well. Let's say you currently have two
customer assignments as follows:
Customer 1:
inetnum: 192.0.2.0 - 192.0.2.128
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Customer 2:
inetnum: 192.0.2.128 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
As you can see, except for the 'inetnum' value, they are completely identical.
That means you will be able aggregate them into a single
object:
inetnum: 192.0.2.0 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: AGGREGATED-BY-LIR
mnt-by: BRIAN-MNT
source: RIPE
The second example concerns the case where the assignments are not uniform.
Let's say your customers operate their own NOCs, so your starting point instead
is having these two assignments:
Customer 1:
inetnum: 192.0.2.0 - 192.0.2.128
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: CUST1-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Customer 2:
inetnum: 192.0.2.128 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: CUST2-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Note how the 'tech-c' attribute differs between the two assignments.
That means that not be able to replace them with an AGGREGATED-BY-LIR object.
> Does this not contradict other purposes / objectives of the registry,
> including the principles of registering public networks or am I
> missing something?
We do not believe so. As demonstrated above, only highly redundant data can be
aggregated, so very little actual information lost in the process.
Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel idea, it has
been around in the IPv6 policy for many many years. If it was indeed the case
that it contradicted the purposes and/or objectives of the registry, someone
ought to have noticed and attempted to fix that problem by now. That has not
happened, as far as we know, which we take as a sign that there is no such
problem in the first place.
Tore
smime.p7s
Description: S/MIME cryptographic signature
-- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
