Hi Martin, Thanks for sending along your questions and feedback.
> Who merges PRs? This needs to be very crisp. (I *think* that authors can > and should, but I want to check.) For the current GitHub-based process for Final Review, the RPC is responsible for merging. This is because the RPC may need to review a PR for editorial issues, ask a question, or request AD approval. > Who is ultimately responsible for resolving issues? I've closed a couple > where it seemed like the answer was unequivocal, but I'm not sure that I hold > ultimate responsibility here. The RPC will close an issue after applying a requested update or when merging an author-created PR linked with the issue. Authors are welcome to close issues, but the RPC will review each closed issue and reopen if we have a followup question. > Finally, I think that the guidance on branches is a bit off. Or the practice > is. The README suggests targeting the "RPC-Edits" branch, but that is not > the default, so all of my PRs target "Approved". I don't know how to fix the > default targeting in GitHub, so I would suggest a different order of > operations: Point people at PR#1 first (or where the RPC edits are). Ask > them to resolve *and merge* that before proposing other changes. Then the > whole business of which branch is which is not that complicated. You can > still call them what they are called (the names make sense), but authors > won't have to struggle quite so much with the setup. Also, you avoid > conflicts: my pull requests will conflict with the RPC edits. That is easy > to resolve, but unnecessary churn. > > That should really be more clearly documented (I read emails and README and > couldn't spot it). Thank you for this helpful feedback. We will highlight the RPC-edits branch in our initial Final Review email, and we will also experiment with default targeting (we believe we found a way to do this). Let us know if you have any further questions or comments! The RPC takes feedback into consideration as we discuss how the process evolves. Sincerely, Rebecca VanRheenen RFC Production Center > On Jun 2, 2026, at 3:56 PM, Martin Thomson <[email protected]> wrote: > > Some questions and feedback on process: > > Who merges PRs? This needs to be very crisp. (I *think* that authors can > and should, but I want to check.) > > Who is ultimately responsible for resolving issues? I've closed a couple > where it seemed like the answer was unequivocal, but I'm not sure that I hold > ultimate responsibility here. > > Finally, I think that the guidance on branches is a bit off. Or the practice > is. The README suggests targeting the "RPC-Edits" branch, but that is not > the default, so all of my PRs target "Approved". I don't know how to fix the > default targeting in GitHub, so I would suggest a different order of > operations: Point people at PR#1 first (or where the RPC edits are). Ask > them to resolve *and merge* that before proposing other changes. Then the > whole business of which branch is which is not that complicated. You can > still call them what they are called (the names make sense), but authors > won't have to struggle quite so much with the setup. Also, you avoid > conflicts: my pull requests will conflict with the RPC edits. That is easy > to resolve, but unnecessary churn. > > That should really be more clearly documented (I read emails and README and > couldn't spot it). > > On Tue, Jun 2, 2026, at 12:59, [email protected] wrote: >> Authors, >> >> While reviewing this document during Final Review, please resolve (as >> necessary) the following questions, which are also in GitHub issues (see >> https://github.com/rfc-editor/FinalReview-rfc9998/issues). >> >> >> 1) <!--[rfced] Regarding the guidance for IAB documents at >> https://wiki.ietf.org/en/group/iab/iab-stream-rfc-format: >> >> a) The text in the Abstract adds "W3C" to the boilerplate sentence about >> views >> and positions. We believe this is fine because this workshop was convened by >> both the IAB and W3C, but please confirm. >> >> b) The guidance indicates that the following boilerplate paragraph SHOULD >> appear in the Introduction. We do not see this paragraph in the Introduction >> or elsewhere in the document. Should it be included? If so, please indicate >> the desired placement within the Introduction. >> >> The Internet Architecture Board (IAB) holds occasional workshops >> designed to consider long-term issues and strategies for the >> Internet, and to suggest future directions for the Internet >> architecture. This long-term planning function of the IAB is >> complementary to the ongoing engineering efforts performed by working >> groups of the Internet Engineering Task Force (IETF). >> >> c) We have retitled Appendix B as follows. Please let us know any >> objections. >> >> Original: >> Appendix B. Workshop Attendees >> >> Updated: >> Appendix B. Workshop Participants >> --> >> >> >> 2) <!--[rfced] Might the first sentence of the Introduction be rephrased as >> follows? We ask because "they" can be misconstrued as referring to >> "Regulators >> and legislators". >> >> Original: >> >> Regulators and legislators around the world are increasingly >> restricting what can be made available to young people on the >> Internet, in an effort to reduce the online harms that they >> encounter. >> >> Perhaps: >> >> Regulators and legislators around the world are increasingly >> restricting what can be made available to young people on the >> Internet in an effort to reduce online harm. >> >> --> >> >> >> 3) <!--[rfced] We note that the dictionary lists "harm" as a noncount noun >> (see >> https://www.britannica.com/dictionary/harm). We have updated "harms" to >> "harm" >> accordingly. Please let us know any objections. >> --> >> >> >> 4) <!--[rfced] We note that the first paragraph of Section 2 ("Overview of >> the >> Workshop") describes the participants slightly differently than paragraph 2 >> of >> the Introduction. Should these descriptions be made uniform? >> >> Intro: >> ...brought together technologists, civil society advocates, >> business interests, and government stakeholders to discuss the nuances >> of the introduction of such measures. >> >> Section 2: >> ...brought together a diverse group of participants from technical, >> policy, regulatory, and research communities... >> --> >> >> >> 5) <!-- [rfced] We note that "service-based, network-based, and >> device-based" are >> used in the first sentence of this paragraph, but "Service-enforced" and >> "Device-enforced" are used later in the paragraph. Would you like to >> make any >> updates for consistency? (Note: double hyphen removed for comment.) >> >> Original: >> Technical sessions explored a spectrum of enforcement models: >> service-based, network-based, and device-based. Service-enforced >> systems place the compliance burden on websites, risking >> fragmentation and user fatigue from repeated verification flows. >> Network-based filtering - already common in some jurisdictions - >> offers broad coverage but limited accuracy and significant privacy >> trade-offs. Device-enforced models, in which operating systems >> mediate access based on a one-time verification, were praised for >> their potential usability and consistency but criticized for >> potential concentration of power among major vendors. Many >> participants noted that a pluralistic approach is more likely to be >> successful, recognizing that no single architecture can meet all >> requirements equally across jurisdictions. >> --> >> >> >> 6) <!-- [rfced] Please review the use of "places" in this sentence and let us >> know if any updates are needed. >> >> Original: >> While this workshop would not provide specific standards proposals or >> take positions on the advisability of regulatory proposals, it was >> suggested that leadership bodies, including the Internet Architecture >> Board and Technical Architecture Group, could be places to make such >> statements. >> >> Perhaps A: >> While this workshop did not provide specific standards proposals or >> take positions on the advisability of regulatory proposals, it was >> suggested that leadership bodies, including the IAB and the Technical >> Architecture Group (TAG), could make such statements. >> --> >> >> >> 7) <!--[rfced] Should the following be updated to give these modifiers (i.e., >> "piecemeal, opaque, and often privacy-eroding") a noun? (Note: double hyphen >> removed for comment.) >> >> Original: >> While the current status quo - piecemeal, opaque, and often privacy- >> eroding - was unsatisfactory to most participants, many cautioned >> that hasty solutions could entrench worse problems. >> >> Perhaps: >> While the current status quo - piecemeal, opaque, and often privacy- >> eroding age-based restriction - was unsatisfactory to most >> participants, many cautioned that hasty solutions could entrench worse >> problems. >> --> >> >> >> 8) <!-- [rfced] We note the roles used in [HANSON] are slightly different >> from >> the roles listed in Section 3.2. Please review and let us know if any updates >> are needed. >> >> URL for [HANSON]: >> https://www.ietf.org/slides/slides-agews-slides-where-enforcement-happens-00.pdf >> >> [HANSON] - Jurisdiction detector >> Section 3.2 - Policy selector >> >> [HANSON] - Content rater >> Section 3.2 - Rater >> >> Original: >> One of the more substantive discussions on architecture involved >> presentations on the functional roles involved in any system >> [HANSON]. >> >> Four key roles were identified: >> ... >> Policy selector: The policy selector is responsible for determining ... >> ... >> Rater: The rater is responsible for determining whether content or ... >> --> >> >> >> 9) <!--[rfced] Please review the terms listed in Section 3.3 ("A Common >> Vocabulary Is Necessary") with regard to the following. Note that this >> reference is behind a paywall, so we are unable to question with >> certainty >> here (we are only able to view a short sample at >> https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27566:-1:ed-1:v1:en). >> >> a) It seems the definitions are not verbatim from [ISO-IEC-27566-1]. What >> are >> your thoughts about adding some text before this list along the lines of the >> following to clarify for the reader where the terms/definitions originated? >> >> Original: >> There was a recognition of the value of shared language, and some >> participants pointed to {{ISO-IEC-27566-1}}, which establishes key >> terms, including: >> >> Perhaps: >> There was a recognition of the value of shared language, and some >> participants pointed to {{ISO-IEC-27566-1}}, which establishes key >> terms, including the following [with definitions paraphrased from that >> specification / drafted by the authors of this document / agreed upon >> at the workshop]: >> >> b) Does "Age gating" appear in this referenced specification? We do not see >> it in the sample we are able to access. If this term does not appear in the >> cited reference, please consider how any misattribution caused by the lead-in >> text could be cleared up. >> --> >> >> >> 10) <!-- [rfced] In Figure 2, what does the "*" symbol in "Rater*" >> indicate? Is an >> explanation needed, or should the "*" be removed? >> --> >> >> >> 11) <!--[rfced] Who does "community" refer to in the following? >> >> Original: >> An analysis that considers the constraints and assumptions necessary >> to successfully deploy different architectures is a contribution >> that would likely be welcomed by the community. >> >> --> >> >> >> 12) <!-- [rfced] Are all the subsections of Appendix A verbatim from the >> agenda >> distributed at the workshop? If so, perhaps adding some text to Appendix A to >> describe that fact would be helpful? (Note that we did make a few minor edits >> to the text in Appendix A.) >> >> Original: >> The following sections cover each of the main topics of discussion >> sessions. >> >> Perhaps A: >> The following subsections include the agenda for each of the main topics >> of the discussion sessions. >> >> Perhaps B: >> The agenda from the workshop is archived below. >> >> >> Alternately, you could rephrase to summarize each topic. For example: >> >> Original: >> A.1. Topic: Introduction >> >> We will launch the workshop with a greeting, a round of >> introductions, and an explanation of the terms of engagement, >> background, goals and non-goals of the workshop. >> >> A.2. Topic: Setting the Scene >> >> Successfully deploying age restrictions at Internet scale has many >> considerations and constraints. We will explore them at a high level >> in order. The goal is to discuss within the group about the scope of >> topics that the workshop will seek to address. >> >> Perhaps: >> A.1. Topic: Introduction >> >> The workshop started with a greeting, a round of >> introductions, and an explanation of the terms of engagement, >> background, goals and non-goals of the workshop. >> >> A.2. Topic: Setting the Scene >> >> Successfully deploying age restrictions at Internet scale has many >> considerations and constraints. The goal was to explore them at a high >> level >> in order and to discuss within the group about the scope of >> topics that the workshop will seek to address. >> --> >> >> >> 13) <!-- [rfced] Is a word missing from the bullet item "End-to-End"? >> >> Original: >> And effects on the internet and web architecture, such as: >> >> * Deployment, Extensibility and Evolution >> * Avoid Centralization >> * End-to-End >> * One Global Internet/Web >> * Layering and Modularity >> --> >> >> >> 14) <!--[rfced] The term "age control mechanism" sounds strange. Maybe >> "age verification mechanism" was intended? (Note: double-hyphen removed >> for comment.) >> >> Original: >> During the workshop, participants were asked to name potential >> impacts - whether positive or negative - that could be seen in >> association with the introduction of an age control mechanism. >> >> --> >> >> >> 15) <!--[rfced] Should Alexis Hancock's affiliation be updated to "Electronic >> Frontier Foundation"? >> >> Original: >> * Alexis Hancock, Electronic Freedom Foundation >> >> Perhaps: >> * Alexis Hancock, Electronic Frontier Foundation >> --> >> >> >> 16) <!-- [rfced] May we hyphenate "age verification", "age assurance", and >> "age >> inference" in the attributive position (i.e., before a noun)? We would >> typically hyphenate these, but we see that [ISO-IEC-27566-1] uses "age >> assurance system" (and similar) that are not hyphenated. >> >> Some examples in this document: >> age verification providers >> age assurance provider >> age assurance functions >> Age inference techniques >> --> >> >> >> 17) <!--[rfced] Please review any abbreviation expansions or placements >> made/changed during the editing process and let us know if any updates >> are necessary. >> --> >> >> >> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> >> For example, please consider whether "natively" in the following should be >> updated: >> >> "Participants observed that the web does not natively distinguish..." >> --> >> >> >> Thank you. >> >> Megan Ferguson and Rebecca VanRheenen >> RFC Production Center >> >> >> On Jun 1, 2026, at 7:55 PM, [email protected] wrote: >> >> *****IMPORTANT***** >> >> RFC Author(s): >> -------------- >> >> Your document has now entered Final Review (previously AUTH48). >> >> The document was edited in kramdown-rfc as part of the RPC pilot test (see >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). >> >> Final Review is being handled in GitHub as part of the GitHub pilot >> test (see >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). >> >> >> Your document is available for review at: >> https://github.com/rfc-editor/FinalReview-rfc9998 >> >> Please do the following: >> >> a) accept your invitations to join the repo as collaborators. >> >> b) see the README for details on the Final Review process: >> https://github.com/rfc-editor/FinalReview-rfc9998/blob/Approved/README.md >> >> c) review and resolve the issues: >> https://github.com/rfc-editor/FinalReview-rfc9998/issues >> >> Once the content of the .md file is stable, we will convert it to .xml >> and provide the .html, .pdf, .txt, and .xml files for review. >> >> You and your coauthors are responsible for engaging other parties >> (e.g., Contributors or Working Group) as necessary before providing >> your approval. >> >> Once the document has been reviewed and approved by all of the authors, >> it will be published as an RFC. If an author is no longer >> available, there are several remedies available as listed in the >> FAQ (https://www.rfc-editor.org/faq/). >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> >> -------------------------------------- >> RFC 9998 (draft-iab-agews-report) >> >> Title : Report from the IAB/W3C Workshop on Age-Based >> Restrictions on Content Access >> Author(s) : M. Nottingham, >> M. Thomson >> WG Chair(s) : Dhruv Dhody >> Area Director(s) : N/A > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
