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 <[email protected]> Sent: Monday, April 8, 2024 1:38 PM To: Brian Storey <[email protected]>; Carlos Friaças <[email protected]> Cc: [email protected] 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
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
