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]
