Hello everyone,

The mailing list has been buzzing this month! This mail is intended to serve as a summary of what happened on the mailing list and behind the scenes.

#######################################################################################################################
By far, one of the most active threads concerned the correct use of the "route" and "route6" objects in a DDOS mitigation scenario. [1]
Context:
Kaupo Ehtnurm runs a multihomed AS, and one of his upstream providers offers DDOS mitigation service. To ensure all traffic passes through the DDOS mitigation service, they announce a more specific prefix. Kaupo explains that to achieve this, they need to create ROAs and Route objects.
ROAs have a max-length field, which allows Kaupo to use just one ROA for a /32 IPv6 with the max-length set to /48. As route objects do not have a max-length field, they explain that they would have to create 65536 /48 route6 objects for their /32, which is difficult to manage.
They ask why route objects don't have a comparable "max-length" field.

Related discussion:
Most of the discussion does not concern the possible reasons why a "max-length" field for route-objects does not exist, but rather discusses operational practice and the actual behavior of DDOS mitigation announcements. Job Snijders explains some of the possible reasons this field does not exist [2]. Job [2] and Nick Hilliard [3] have recommended reading BCP 185 / RFC 9319 for additional information regarding best practices.

Majority consensus:
From what I was able to determine, the following statements are the majority consensus:

Most networks will accept the more specific prefixes, even without a more-specific route object. [4] [5] [6] [7]

Networks have their own reasons for why or why not they might filter more-specifics. [7] [8] [9]

Some traffic might still take the aggregate route instead of the more-specific, this shouldn't be a problem in practice. [10]
Testing the behavior of routes using tools like RIPE Atlas might yield different results, but is said to be unlikely. [7]

Creating a route object for every /48 in a /32 is not recommended. [11] [12]

Announcing and creating route objects for slightly longer prefixes like a few /33 or /34 instead of many /48 might be an acceptable compromise. [13]

#######################################################################################################################
Another very active thread was started by Denis Walker, Co-chair of this working group, and concerned the participation of working group chairs in discussions. [14]
Context:
Starting the discussion, Denis Walker has explained that he – following feedback from community members – has decided to reduce his community engagement temporarily to evaluate the effect on the working group. He explains that he has not seen current NWIs progress during this time, and that, in his opinion, the lack of engagement by co chairs does not work in some working groups. He states that he will return to his original level of engagement.

Majority consensus:
From what I was able to determine, the following statements are the majority consensus:

Overall, people support active working group chairs that drive discussion, but do not support working group chairs taking a side as a working group chair. [15] [16] [17]
Working group chairs can express their personal opinion when they remove themself from the working group position. [18] [19]

Related discussion:
Most of the discussion has been about co-chair neutrality in discussions.
Denis referenced RIPE documents outlaying the responsibilities of a co-chair, where one co chair expressing their opinion to drive discussion is not prohibited. [20]
This was followed up by Nick Hilliard, referencing information regarding non-RIPE chair responsibilities. [21]
In the end, a policy proposal to clarify the rules was mentioned. [22] [23]

#######################################################################################################################
News from the NCC

The "rev-srv:" attribute, which was deprecated in 2009, was removed on July 27th. The maintainers of about 34,711 affected objects were informed. [24]
The "NONE" authentication scheme, which was deprecated in 2004, was removed on July 27th. The maintainers of about 613 affected objects were informed. [25]
Client certificate authentication is planned for the database. The NCC has a working implementation internally and is working on getting it ready for production.
The NCC is working on impact analysis concerning a "tuple" solution for NWI-4, where the prefix and status are considered part of the primary key. This will be published soon.
Preparing for the open-source release, the web application for the RIPE Database service is being audited by an external company. This audit is planned to finish by the end of August.

#######################################################################################################################
Personal note

Please do not hesitate to tell me if you think I should have included something, or I misrepresented something. I didn't want to go into too much detail, and contemplated a lot about the things to include.
You are welcome to contact me if you'd like changes to the format, or you would just like to mention that you thought it was good. I appreciate all feedback.

#######################################################################################################################
All the links