This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[routing-wg] Publish in Parent - input requested
- Previous message (by thread): [routing-wg] Publish in Parent - input requested
- Next message (by thread): [routing-wg] Publish in Parent - input requested
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ignas Bagdonas
ibagdona.ripe at gmail.com
Fri Sep 30 11:50:31 CEST 2022
Hi there. Following a discussion with the Executive Board in our meeting last June, > we would like to ask our community for input on the requirements for this > service. The service was originally designed to allow all objects to be > published in our repositories, regardless of whether the associated > resources are part of the RIPE NCC or another RIR, and this is how we would > like to proceed. However, it has been argued that there should be a > restriction in this service so that it allows only RIPE NCC resources to be > published and not resources belonging to a different RIR. > Could you clarify the reasons of why the question of changing the current planned model has been discussed by the board - is that based on resource projections for supporting the service going forward, is that due to possible legal aspects, and also what kind of arguments have been raised to the board for initiating such a change? Backing of a need for such planned changes by actual operational data would be highly appreciated and would bring in clarity to the community on the scope and justification of the changes proposed. > If you are potential user of this service, what are your expectations for > its functionality? Do you want to be able to publish all your objects in > RIPE NCC repositories, regardless of whether they are from the RIPE NCC or > not? Or will you publish each object in the corresponding RIR repositories? > Please note that we are only talking about publication. The objects out of > region will be signed with their own parent certificate. > Working group - please raise your opinions, with elaboration, and specifically in the context of long term usage interface stability for such a service. And please focus on the service consumption and operation - while inventing yet another protocol extension is certainly fun, that is a secondary aspect, while the primary one is on the architectural decision. > To make informed decisions on how we should progress with Publish in > Parent, we need input from potential users of the service. Please reply > with your feedback until 14 October so we can incorporate it in our > planning and inform you about our progress at RIPE 85. > Given this timing, the upcoming RIPE85 routing WG meeting will not discuss this topic (plus the agenda is already full anyway, and the meeting slot is shorter than usual). Depending on how the discussion develops here on the mailing list, it might be practical to have a longer period for this to get resolved. -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/routing-wg/attachments/20220930/8bbc0586/attachment.html>
- Previous message (by thread): [routing-wg] Publish in Parent - input requested
- Next message (by thread): [routing-wg] Publish in Parent - input requested
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]