Hello Matthias, Thank you for your review of the draft!
Regarding the terminology, we can add definitions of these terms. > I suggest making the information source abstract here, with the only > requirement being a shared identifier for the peering location and where to > look it up You raise a good distinction. We can incorporate the change into the next version. You are right that we should keep PeeringDB as the example, rather than the standard—in future, there could be alternate sources. Regarding Section 6, we will review it at our next authors’ meeting and either clarify or remove it. Thank you for the feedback! We will incorporate these comments into our next version. Jenny From: Matthias Wichtlhuber <[email protected]> Date: Tuesday, July 15, 2025 at 7:44 AM To: Jenny Ramseyer <[email protected]>, grow <[email protected]> Cc: [email protected] <[email protected]>, Aditya Vijay <[email protected]> Subject: Re: Peering API: new version draft-ietf-grow-peering-api-01.txt Hi Jenny (and co-authors), overall, I think it was a good decision to move the authentication part into a separate draft — that improves clarity and separation of concerns. Some additional remarks: -- Terminology: The terms "public peering," Hi Jenny (and co-authors), overall, I think it was a good decision to move the authentication part into a separate draft — that improves clarity and separation of concerns. Some additional remarks: -- Terminology: The terms "public peering," "private peering," and "PNI" are used throughout the draft, but I couldn't find formal definitions. In particular, "PNI" appears in Sections 4.1 and 6.3.3 and seems to be used interchangeably with "private peering" in some places. It would be helpful to define these terms explicitly to avoid ambiguity. -- Section 4.1: Step 5 refers to PeeringDB as the source of peering information. In practice, such information may come from multiple sources (e.g., IXP member lists, IXP AS-SETs, direct communication between peering managers). I suggest making the information source abstract here, with the only requirement being a shared identifier for the peering location and where to look it up (e.g., PeeringDB or whatever pops up in the future). -- Broken structure (missing line break): "Optional: checks traffic levels, prefix limit counters, other desired internal checks. 2. ADD SESSIONS (SERVER BATCHED RESPONSE)" -- Section 6: This section includes implementation-specific guidance (e.g., fuzz testing endpoints, internal system access restrictions). These may be out of scope for the draft and could benefit from clarification or removal. -- Great to see progress on the document. Best regards, Matthias On 09.07.25, 17:20, "Jenny Ramseyer" <[email protected]> wrote: Hello GROW WG, Based on the feedback we received at the previous IETF meetings, we (Arturo, Carlos, Matt, Q, Tom, and I) have posted a new version of the Peering API draft: https://datatracker.ietf.org/doc/draft-ietf-grow-peering-api/01/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-grow-peering-api/01/__;!!Bt8RZUm9aw!8m0ZBRSWaD5v2QDZ3l2e6eSYrXMprH6ZjWKmertCpK6yZsUdF6ESbt2WVHGgI0b99UucanZo02RA7A1tnmQpR_avz3Dq$> <https://datatracker.ietf.org/doc/draft-ietf-grow-peering-api/01/><https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-grow-peering-api/01/*3e__;JQ!!Bt8RZUm9aw!8m0ZBRSWaD5v2QDZ3l2e6eSYrXMprH6ZjWKmertCpK6yZsUdF6ESbt2WVHGgI0b99UucanZo02RA7A1tnmQpR7csuPpu$> Of note: We have changed the authentication method of the API to support both standard OAuth, and RPKI Attested OAuth. The details of RPKI Attested OAuth have been split into a new draft: https://datatracker.ietf.org/doc/html/draft-blahaj-grow-rpki-oauth<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-blahaj-grow-rpki-oauth__;!!Bt8RZUm9aw!8m0ZBRSWaD5v2QDZ3l2e6eSYrXMprH6ZjWKmertCpK6yZsUdF6ESbt2WVHGgI0b99UucanZo02RA7A1tnmQpR0fI1ymb$> <https://datatracker.ietf.org/doc/html/draft-blahaj-grow-rpki-oauth><https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-blahaj-grow-rpki-oauth*3e__;JQ!!Bt8RZUm9aw!8m0ZBRSWaD5v2QDZ3l2e6eSYrXMprH6ZjWKmertCpK6yZsUdF6ESbt2WVHGgI0b99UucanZo02RA7A1tnmQpR2dD4WQM$> Arturo will present Peering API at the next grow and opsarea meetings at IETF123. Thank you all for the feedback on our draft. Jenny
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
