feat: subseries api for red - #9556
Merged
jennifer-richards merged 8 commits intoSep 19, 2025
Merged
Conversation
jennifer-richards
marked this pull request as ready for review
September 18, 2025 21:35
holloway
approved these changes
Sep 18, 2025
rjsparks
approved these changes
Sep 19, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds API calls
subseriesListandsubseriesRetrieve. The former retrieves all subseries docs, optionally filtering by type (bcp, std, and fyi are the allowed values). The latter retrieves a single subseries doc.This PR does not yet add the links from RFC documents to the subseries they belong to. The
is_alsovalue for each document is still faked and always an empty list. That will be a separate PR.The subseries doc schema for a subseries document looks like this, with the List returning a list of these records. The
contentsvalue is a list of the RFCs contained in the document. The schema of the entries in contents is the same as thedocListendpoint that retrieves a list of RFCs. This is still incomplete the same way that was incomplete - e.g., the formats lists are faked. I'm planning to straighten that out in the shared code separately also.{ "name": "bcp243", "type": "bcp", "contents": [ { "number": 9813, "title": "Operational Considerations for Using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS", "published": "2025-07-11", "status": { "slug": "bcp", "name": "best current practice" }, "pages": 20, "authors": [ { "person": 108624, "name": "Alan DeKok", "email": "alan.dekok@inkbridge.io", "affiliation": "InkBridge Networks", "country": "" } ], "group": { "acronym": "radext", "name": "RADIUS EXTensions" }, "area": { "acronym": "sec", "name": "Security Area" }, "stream": { "slug": "ietf", "name": "IETF", "desc": "Internet Engineering Task Force (IETF)" }, "identifiers": [ { "type": "doi", "value": "10.17487/RFC9813" } ], "obsoletes": [], "obsoleted_by": [], "updates": [], "updated_by": [], "is_also": [], "see_also": [], "draft": { "id": 119429, "name": "draft-ietf-radext-tls-psk", "title": "Operational Considerations for RADIUS and TLS-PSK" }, "abstract": "This document provides implementation and operational considerations for using TLS Pre-Shared Keys (TLS-PSKs) with RADIUS/TLS (RFC 6614) and RADIUS/DTLS (RFC 7360). The purpose of the document is to help smooth the operational transition from the use of RADIUS/UDP to RADIUS/TLS.", "formats": [ "txt", "xml" ], "keywords": [ "keyword" ], "errata": [] } ] }