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]
