I've responded to each of the issues and the pull request. All the changes look good and the suggestions were helpful. I have suggested no action in response to a couple, but there are concrete proposals for each now. The only (very small) challenge will be managing a couple of minor conflicts between the copy edit pass and the proposed resolution to questions.
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]
