Feedback-ID: ic129442d:Fastmail
MIME-Version: 1.0
Date: Tue, 02 Jun 2026 14:27:47 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: rfc-editor <rfc-editor@rfc-editor.org>, "Mark Nottingham" <mnot@mnot.net>
Message-Id: <334c2ff2-d3a4-4992-a6ff-882db08fd395@betaapp.fastmail.com>
In-Reply-To: <178036916018.17.10074559262420644053@rfc-editor.org>
References: <178036916018.17.10074559262420644053@rfc-editor.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: A2JWKZJYVR6IZV6YTUGLG7R74VLN4Y44
CC: auth48archive@rfc-editor.org, iab@iab.org, Dhruv Dhody <dd@dhruvdhody.com>
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_Final_review=3A_RFC-to-be_9998_=28draft-iab-age?=
 =?utf-8?q?ws-report-03=29_in_markdown/GitHub?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/DQmX39iE5-FSp8WaGo28O3IYzrc>

I've responded to each of the issues and the pull request.  All the chan=
ges look good and the suggestions were helpful.  I have suggested no act=
ion in response to a couple, but there are concrete proposals for each n=
ow.  The only (very small) challenge will be managing a couple of minor =
conflicts between the copy edit pass and the proposed resolution to ques=
tions.=20

On Tue, Jun 2, 2026, at 12:59, rfc-editor@rfc-editor.org wrote:
> Authors,
>
> While reviewing this document during Final Review, please resolve (as
> necessary) the following questions, which are also in GitHub issues (s=
ee
> 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 abo=
ut views
> and positions. We believe this is fine because this workshop was conve=
ned by
> both the IAB and W3C, but please confirm.
>
> b) The guidance indicates that the following boilerplate paragraph SHO=
ULD
> appear in the Introduction. We do not see this paragraph in the Introd=
uction
> or elsewhere in the document. Should it be included? If so, please ind=
icate
> 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 obj=
ections.
>
> Original:
>    Appendix B.  Workshop Attendees
>
> Updated:
>    Appendix B.  Workshop Participants
> -->
>
>
> 2) <!--[rfced] Might the first sentence of the Introduction be rephras=
ed as
> follows? We ask because "they" can be misconstrued as referring to "Re=
gulators
> 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"=20
> accordingly.  Please let us know any objections.
> -->
>
>
> 4) <!--[rfced] We note that the first paragraph of Section 2 ("Overvie=
w of the
> Workshop") describes the participants slightly differently than paragr=
aph 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 nuanc=
es
>   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=20
> device-based" are
> used in the first sentence of this paragraph, but "Service-enforced" a=
nd
> "Device-enforced" are used later in the paragraph. Would you like to=20
> 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 Architectu=
re
>    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 Technic=
al
>    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.=20
>
> 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 differ=
ent 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-happ=
ens-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 determinin=
g ...
>    ...
>    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=20
> certainty
> here (we are only able to view a short sample at=20
> 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 origin=
ated?
>
> 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 n=
ot see
> it in the sample we are able to access. If this term does not appear i=
n 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*"=20
> 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 t=
he agenda
> distributed at the workshop? If so, perhaps adding some text to Append=
ix A to
> describe that fact would be helpful? (Note that we did make a few mino=
r 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 t=
opics
>    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 lev=
el
>    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 "Ele=
ctronic
> 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=20
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_la=
nguage>
> and let us know if any changes are needed. Updates of this nature typi=
cally
> result in more precise language, which is helpful for readers.
>
> For example, please consider whether "natively" in the following shoul=
d 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=E2=80=AFPM, rfc-editor@rfc-editor.org wrote:
>
> *****IMPORTANT*****
>
> RFC Author(s):
> --------------
>
> Your document has now entered Final Review (previously AUTH48). =20
>
> 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=3Dpilot_test_kramdown_=
rfc).
>
> Final Review is being handled in GitHub as part of the GitHub pilot=20
> test (see=20
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=3Drpc-github-phase-0-p=
ilot-test).=20
>
> 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:=20
> 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.=20
>
> You and your coauthors are responsible for engaging other parties=20
> (e.g., Contributors or Working Group) as necessary before providing=20
> 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=20
> available, there are several remedies available as listed in the=20
> FAQ (https://www.rfc-editor.org/faq/).
>
> Please let us know if you have any questions.=20
>
> Thank you for your cooperation,
>
> RFC Editor
>
>
> --------------------------------------
> RFC 9998 (draft-iab-agews-report)
>
> Title            : Report from the IAB/W3C Workshop on Age-Based=20
> Restrictions on Content Access
> Author(s)        : M. Nottingham,
>                   M. Thomson
> WG Chair(s)      : Dhruv Dhody
> Area Director(s) : N/A