[address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

Hi Tore,

Thanks for the response.

I only have a short window to reply, however I would clarify that I fall in
to the " Registering a PA Assignment with something like "CUSTOMER-1234" and
an email address pointing to the LIR has been acceptable for all this
time.»" category. I am therefore looking at this through the lens of this
approach.

In which-ever form the end user is illustrated, it's the total permitted
absence of that which is the surprise; Unless I have misunderstood the
recently shared RIPE NNC interpretation. 

Many thanks,
Brian 

-----Original Message-----
From: Tore Anderson <tore at fud.no> 
Sent: Monday, April 8, 2024 1:38 PM
To: Brian Storey <Brian.Storey at gamma.co.uk>; Carlos Friaças
<cfriacas at fccn.pt>
Cc: address-policy-wg at ripe.net
Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR
status

* Brian Storey:
> There is a subtly here which I don't think is fully appreciated.
>
> I previously highlighted my surprise to the RIPE NNCs interpretation 
> of the existing policy; as have others. Why is that? I think it's very 
> important to recognise that LIRs act and publish certain End User data 
> because it was deemed that this was a requirement and that not doing 
> so could see a breach of policy, therefore leading to Allocated PAs 
> being reclaimed - not good with scarce resources! They did this 
> because they understood they HAD to not because they WANTED to.
>
> If this school of thought no longer applies, then it is reasonable to 
> expect that some will reevaluate how much effort they continue to put 
> in and the consequences of that.

Hi Brian,

We have certainly no difficulty understanding that you and others might have
not been aware of this before. But now you are, and so is anyone else that
are following the RIPE policy development process. The cat is out of the
bag, so to speak. Withdrawing 2023-04 would not undo this, because this is
not a property of the proposal itself, but knowledge of the of the RIPE
NCC's interpretation of the *current* address policy.

Or as the working group chairs put it:

«It is fact that the RIPE NCC has interpreted the current policy to not
require a PA Assignment in the RIPE DB to include the actual name and email
address of the end-user since at leas the late 1990s. Registering a PA
Assignment with something like "CUSTOMER-1234" and an email address pointing
to the LIR has been acceptable for all this time.»

Furthermore, it is clear that this comes as no surprise at all to many LIRs,
who have done this for a long time. Again quoting the working group chairs:

«
changing this interpretation would be a major departure of many years of
accepted practice and potentially involve updating thousands of RIPE DB
objects»

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.n
et%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2024-January%2F013980.html
&data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a1c8dfdc044cfcc9f08dc57c8bc2
3%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638481766859115331%7CUnknown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C0%7C%7C%7C&sdata=bWifsFJ9cfucTWDCBWz4WueyMwcy6Ehr6ti5Lgi1Byg%3D&reser
ved=0


> The two questions I previously posed here: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ripe.net%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2023-September
> %2F013863.html&data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a1c8dfdc
> 044cfcc9f08dc57c8bc23%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638
> 481766859125299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JiSFtHNbG6Lz6I
> jzIBE2nf6%2B4JwIJ8Ug3GAs97nIqtw%3D&reserved=0
> were:-
>
> "For me it comes down to this. As a community & considering the 
> permitted exceptions (individuals & P2P assignments):-
>
> 1) Is the publication of End User entities for an assignment important?

Perhaps, perhaps not. That is for the working group to decide. It is however
outside the scope of 2023-04. Again quoting the working group chairs from
the previously linked-to message:

«
we feel this discussion would be best served by an independent policy
proposal that clarifies the issue and would like to invite the working group
to enter one».


> 2) Is the publication of a prefix assignment boundary between end 
> users important?"

We address this question in the proposal itself, see
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.n
et%2Fmembership%2Fpolicies%2Fproposals%2F2023-04%2F%2312-differences-from-ip
v6-aggregated-by-lir-status&data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a
1c8dfdc044cfcc9f08dc57c8bc23%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C63
8481766859132088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=oyHBpPOS0YdV7jw7hXJOhO762
1F%2FY%2BAwBTmtp2f%2F%2F%2BM%3D&reserved=0.

The gist of it is that since IPv4 assignments tend to be right-sized (rather
than gigantic "one size fits all" prefixes like in IPv6), and that there is
no HD-Ratio that needs calculating, we found it more appropriate to leave
the assignment-size attribute optional.


> Now, I've not commented since (for various reasons), however I have 
> followed the discussion of this closely. Internally, I've been 
> highlighting that a Business Risk item based on previous 
> interpretation could evolve and how we manage our exposure changes if 
> this proposal become policy. What this means in reality is that we can 
> choose how much effort we continue to place on updating our 
> Assignments as the end user customer base churns. There are end 
> customers who like their association to a PA Assignment to be 
> published and there are those who don't. It may well be easier for me 
> only publish by exception. I'm still thinking it through pending what 
> happens next with a few other indirect considerations.
>
> I don't believe I'll be the only one doing this.

You and everyone else can do this right now. You do not need to wait for the
possible acceptance of 2023-04. As mentioned above, you have in fact been
free to do this «since at leas [sic] the late 1990s».


Best regards,

Jeroen & Tore


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240408/420ebe3f/attachment-0001.p7s>