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/[email protected]/
[routing-wg] Publish in Parent - input requested
- Previous message (by thread): [routing-wg] Publish in Parent - input requested
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Felipe Victolla Silveira
fvictolla at ripe.net
Fri Sep 30 14:43:27 CEST 2022
Hi Ignas, We presented the Terms and Conditions to the Board. At that stage one of the elements of the T&C brought up the topic of whether this could be a member agreement or whether it needed to be an agreement that could be signed by non-members. And that brought us to a discussion on whether Publish in Parent should be available for RIPE NCC resources only or also resources from other RIRs. At the subsequent Board meeting this Monday, it was agreed by all that bringing this to the community and soliciting input from potential users would be the best way to get consensus on the right way forward. Kind regards, Felipe > On 30 Sep 2022, at 11:50, Ignas Bagdonas <ibagdona.ripe at gmail.com> wrote: > > 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/29c2c9da/attachment.html>
- Previous message (by thread): [routing-wg] Publish in Parent - input requested
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]