[auth48] Re: Final review: RFC-to-be 9998 (draft-iab-agews-report-03) in markdown/GitHub

[Martin Thomson <[e-mail]>]

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, [e-mail] 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, [e-mail] 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