Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-iab-aid-workshop-01> for your review

[Corinne Cath <[e-mail]>]

Hi Niels,

Can you put University of Cambridge as my affiliation?

Many thanks,

--
Dr. Corinne Cath
Minderoo Center for Technology & Democracy, University of Cambridge
Web: www.mctd.ac.uk/team-members/corinne-cath/ & www.corinnecath.com
Twitter: @C__CS


On Mon, Sep 19, 2022 at 10:21 PM Karen Moore <[e-mail]> wrote:

> Niels and Mirja,
>
> Thank you for your replies.  We have removed the URLs in Sections 2 and 4
> as discussed.  We have not made any changes to the author affiliations yet
> (we will wait for replies to Mirja’s query).
>
> The updated XML file is here:
>  https://www.rfc-editor.org/authors/rfc9307.xml
>
> The updated output files are here:
>  https://www.rfc-editor.org/authors/rfc9307.txt
>  https://www.rfc-editor.org/authors/rfc9307.pdf
>  https://www.rfc-editor.org/authors/rfc9307.html
>
> This diff file shows only the changes made during the last edit round:
>  https://www.rfc-editor.org/authors/rfc9307-lastdiff.html
>
> This diff file shows all changes made during AUTH48:
>  https://www.rfc-editor.org/authors/rfc9307-auth48diff.html
>
> This diff file shows all changes made to date:
>  https://www.rfc-editor.org/authors/rfc9307-diff.html
>
> Note that it may be necessary for you to refresh your browser to view the
> most recent version. Please review the document carefully to ensure
> satisfaction as we do not make changes once it has been published as an RFC.
>
> Please contact us with any further updates or with your approval of the
> document in its current form.  We will await approvals from each author
> prior to moving forward in the publication process.
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9307
>
> Thank you,
>
> RFC Editor/kc
>
>
> > On Sep 19, 2022, at 2:21 AM, Mirja Kuehlewind <
> [e-mail]> wrote:
> >
> > Hi all,
> >
> > Thanks for the updates. These look all good to me.
> >
> > About affiliations: I guess we could put for Colin and me just “IAB” in
> there. Collin, what do you think?
> >
> > Mirja
> >
> >
> >
> >> On 16. Sep 2022, at 22:54, Karen Moore <[e-mail]> wrote:
> >>
> >> Niels,
> >>
> >> Thank you for the reply; we will work on removing the URLs and will get
> back to you shortly.
> >>
> >> RFC Editor/kc
> >>
> >>> On Sep 16, 2022, at 6:50 AM, Niels ten Oever <[e-mail]>
> wrote:
> >>>
> >>> Dear RFC Editor,
> >>>
> >>> It would indeed better for the txt file to be more readable, so feel
> free to remove the URLs in the text.
> >>>
> >>> Best,
> >>>
> >>> Niels
> >>>
> >>> On 08-09-2022 02:13, Karen Moore wrote:
> >>>> Dear Niels and Colin,
> >>>> We have updated our files based on your replies. As discussed, we
> have also included a list of IAB members and an Informative References
> section. We have a follow-up question:
> >>>> 1) We built an Informative References section and added citations for
> the URLs listed in Sections 2.1, 2.2, and 4.  Please note that the output
> looks clean in the html and pdf files (as the URLs are not displayed), but
> the txt file is a bit harder to read as it includes all of the URLs.  If
> you would like the txt file to be more readable and match the formatting in
> RFC 9075 (which is also an IAB document), we can remove the URLs (so
> instead of being able to access an article directly from the text in the
> html and pdf files, a reader would click on the citation in the text and
> then click on the link to the article from the reference entry).
> >>>> Please confirm if you would like to leave the visible URLs in the txt
> file or if you would like to remove them.
> >>>> ...
> >>>> The updated XML file is here:
> >>>> https://www.rfc-editor.org/authors/rfc9307.xml
> >>>> The updated output files are here:
> >>>> https://www.rfc-editor.org/authors/rfc9307.txt
> >>>> https://www.rfc-editor.org/authors/rfc9307.pdf
> >>>> https://www.rfc-editor.org/authors/rfc9307.html
> >>>> This diff file shows all changes made during AUTH48:
> >>>> https://www.rfc-editor.org/authors/rfc9307-auth48diff.html
> >>>> This diff file shows all changes made to date:
> >>>> https://www.rfc-editor.org/authors/rfc9307-diff.html
> >>>> Note that it may be necessary for you to refresh your browser to view
> the most recent version. Please review the document carefully to ensure
> satisfaction as we do not make changes once it has been published as an RFC.
> >>>> Please contact us with any further updates or with your approval of
> the document in its current form.  We will await approvals from each author
> prior to moving forward in the publication process.
> >>>> For the AUTH48 status of this document, please see:
> >>>> https://www.rfc-editor.org/auth48/rfc9307
> >>>> Thank you,
> >>>> RFC Editor/kc
> >>>>> On Aug 23, 2022, at 7:39 AM, Niels ten Oever <[e-mail]>
> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> On 23-08-2022 09:12, [e-mail] wrote:
> >>>>>> Authors,
> >>>>>> While reviewing this document during AUTH48, please resolve (as
> necessary)
> >>>>>> the following questions, which are also in the XML file.
> >>>>>> 1) <!-- [rfced] Please review the guidance for IAB documents
> >>>>>> <https://www.rfc-editor.org/materials/iab-format.txt>
> >>>>>> and let us know if any changes are needed.
> >>>>>> a) Consensus is set to “true” in the XML and the datatracker, but
> >>>>>> the document is missing the “IAB Members at the Time of Approval”
> section.
> >>>>>> Please let us know if we may add this section and include the names
> appearing
> >>>>>> at <https://www.iab.org/about/iab-members/> (excluding ex-officio
> members).
> >>>>>> b) We will remove each author’s affiliation unless we hear
> objection.
> >>>>>
> >>>>> I would prefer to keep mine, unless there is a strong reason not to.
> >>>>>
> >>>>>> c) We will move “Workshop Participants” section to be an appendix
> as suggested
> >>>>>> at <https://www.rfc-editor.org/materials/iab-format.txt>. Should
> the “Program
> >>>>>> Committee” section be treated the same?
> >>>>>
> >>>>> Fine with me!
> >>>>>
> >>>>>> -->
> >>>>>> 2) <!-- [rfced] Niels, you previously indicated you prefer that
> your last
> >>>>>> name be capitalized in footers as "Ten Oever" but appear as "ten
> Oever"
> >>>>>> wherever preceded by your first name or initial (i.e., document
> header,
> >>>>>> Authors' Addresses) (e.g., RFC 8280).  We are unable to follow this
> guidance
> >>>>>> in the current XML.  Note that the PDF is the only paginated form.
> It shows
> >>>>>> "ten Oever, et al." in the page footers.
> >>>>>> -->
> >>>>>
> >>>>> Fine with me!
> >>>>>
> >>>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear
> >>>>>> in the title) for use on https://www.rfc-editor.org/search. -->
> >>>>>
> >>>>> data science, data anlaysis, data science
> >>>>>
> >>>>>> 4) <!-- [rfced] We are having trouble parsing this sentence.  Does
> >>>>>> "including of Internet protocols..." refer to the standardization
> activities?
> >>>>>> What does "its institutions" mean?
> >>>>>> Original:
> >>>>>>  The IETF, as an international Standards Developing Organization
> >>>>>>  (SDO), hosts a diverse set of data including on the organization's
> >>>>>>  history, development, and current standardization activities,
> >>>>>>  including of Internet protocols and its institutions.
> >>>>>> Perhaps:
> >>>>>>  The IETF, as an international Standards Developing Organization
> >>>>>>  (SDO), hosts a diverse set of data that includes the organization's
> >>>>>>  history, development, and current standardization activities, which
> >>>>>>  includes Internet protocols and its institutions.
> >>>>>> -->
> >>>>>
> >>>>> Perhaps:
> >>>>>
> >>>>>   The IETF, as an international Standards Developing Organization
> >>>>>   (SDO), hosts a diverse set of data that includes the organization's
> >>>>>   history, development, and current standardization activities, which
> >>>>>   includes Internet protocols, architecture, and its institutions.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> 5) <!-- [rfced] We have expanded ICT as "information and
> communication
> >>>>>> technologies".  Please let us know if any corrections are needed.
> >>>>>> Current:
> >>>>>>  A large
> >>>>>>  portion of this data is publicly available, yet it is underutilized
> >>>>>>  as a tool to inform the work in the IETF or the broader
> >>>>>>  research community focused on topics like Internet governance and
> >>>>>>  trends in information and communication technologies (ICT)
> standard-
> >>>>>>  setting.
> >>>>>> -->
> >>>>>
> >>>>> Excellent
> >>>>>
> >>>>>> 6) <!-- [rfced] Section 2.1 includes several links to external
> documents.
> >>>>>> For a clearer reference section, may we specify these in an
> "Informative
> >>>>>> References" section along with a list of position papers. This
> would be
> >>>>>> similar to RFC 8980 and RFC 9075.
> >>>>>> -->
> >>>>>
> >>>>> Sounds good to me.
> >>>>>
> >>>>>> 7) <!-- [rfced] "related to gender questions" is awkward here.
> Perhaps this
> >>>>>> could be rephrased as "gender-related information"?  Alternatively,
> perhaps
> >>>>>> "responses to gender-related questions" would work.
> >>>>>
> >>>>> gender-related information seems like the best option
> >>>>>
> >>>>>> Original:
> >>>>>>  These projects could be used to add
> >>>>>>  additional insights to the existing IETF statistics
> >>>>>>  (https://www.arkko.com/tools/docstats.html) page and the
> datatracker
> >>>>>>  statistics (https://datatracker.ietf.org/stats/), e.g., related to
> >>>>>>  gender questions, however, privacy issues andd implication of
> making
> >>>>>>  such data publicly available were discussed as well.
> >>>>>> -->
> >>>>> s/annd/and
> >>>>>> 8) <!-- [rfced] Are you still encouraging discussion to take place
> on
> >>>>>> [e-mail], or should this be changed to past tense?
> >>>>>> Should a qualifier be added to this sentence, for example, questions
> >>>>>> or discussion about the datatracker and possible enhancements may
> >>>>>> be sent to...?
> >>>>>> Original:
> >>>>>>  Questions or any
> >>>>>>  discussion can be issued to [e-mail].
> >>>>>> -->
> >>>>>
> >>>>> questions or discussion about the datatracker and possible
> enhancements may be sent to [e-mail], sounds good to me.
> >>>>>
> >>>>>> 9) <!-- [rfced] We had trouble parsing this sentence. Please review
> >>>>>> and let us know how we may clarify.
> >>>>>> Original:
> >>>>>>  To assess these question it
> >>>>>>  has ben discussed to investigate participant's affiliations
> including
> >>>>>>  "indirect" affiliation e.g. by funding and changes in affiliation
> as
> >>>>>>  well as the nessecarity to model company characteristics or
> >>>>>>  stakeholder groups.
> >>>>>> Perhaps:
> >>>>>>  To assess these questions, investigating participant affiliations,
> >>>>>>  including "indirect" affiliations (e.g., by tracking funding and
> >>>>>>  changes in affiliation) was discussed.  The need to model company
> >>>>>>  characteristics or stakeholder groups was also discussed.
> >>>>>> -->
> >>>>>
> >>>>> Agreed with proposal.
> >>>>>
> >>>>>> 10) <!-- [rfced] Would "highlighted" or "emphasized" be more clear
> >>>>>> than "stressed" here?
> >>>>>> Original:
> >>>>>>  The human element of the community and diversity was stressed, in
> >>>>>>  order to understand the IETF community's diversity it is important
> to
> >>>>>>  talk to people (beyond text analysis) and in order to ensure
> >>>>>>  inclusivity individual participants must make an effort to, as one
> >>>>>>  participant recounted, tell them their participation is valuable.
> >>>>>> Current:
> >>>>>>  The human element of the community and diversity was stressed.  In
> >>>>>>  order to understand the IETF community's diversity, it is important
> >>>>>>  to talk to people (beyond text analysis). ...
> >>>>>> -->
> >>>>>
> >>>>> s/stressed/highlighted
> >>>>>
> >>>>>> 11) <!-- [rfced] This document seems to use "draft" generically and
> to
> >>>>>> refer to Internet-Drafts in some places.  Please review and consider
> >>>>>> whether the text should refer specifically to Internet-Drafts in
> some
> >>>>>> places for clarity.
> >>>>>> -->
> >>>>>
> >>>>> Agreed
> >>>>>
> >>>>>> 12) <!-- [rfced] Have these questions already been answered or does
> >>>>>> analysis need to be completed to identify the answers?
> >>>>>> Original:
> >>>>>>  Answers to these questions come from analysis of IETF emails, RFCs
> >>>>>>  and Internet-Drafts, meeting minutes, recordings, Github data, and
> >>>>>>  external data such as surveys, etc.
> >>>>>> Perhaps:
> >>>>>>  Analysis of data such as IETF emails, RFCs and Internet-Drafts,
> >>>>>>  meeting minutes, recordings, Github data, and external data (e.g.,
> surveys)
> >>>>>>  may help answer these questions.
> >>>>>> -->
> >>>>>
> >>>>> Agreed with proposal, perhaps add a comma as follows:
> >>>>>
> >>>>>   Analysis of data, such as IETF emails, RFCs and Internet-Drafts,
> >>>>>   meeting minutes, recordings, Github data, and external data (e.g.,
> surveys)
> >>>>>   may help answer these questions.
> >>>>>
> >>>>>
> >>>>>> 13) <!-- [rfced] Note that we changed "CO2 emissions" to "carbon
> emissions"
> >>>>>> here to match use in the rest of the paragraph.  Please let us know
> if
> >>>>>> corrections are needed.
> >>>>>> Original (the whole paragraph is provided for context):
> >>>>>>  Discussion started by considering how sustainable are IETF
> meetings,
> >>>>>>  focussing on how much CO2 emissions are IETF meetings responsible
> for
> >>>>>>  and how can we make the IETF more sustainable.  Analysis looked at
> >>>>>>  the home locations of participants, meeting locations, and carbon
> >>>>>>  footprint of air travel and remote attendance, to estimate the
> carbon
> >>>>>>  costs of an IETF meeting.  Initial results suggest that the costs
> of
> >>>>>>  holding multiple in-person IETF meetings per year are likely
> >>>>>>  unsustainable in terms of carbon emission, although the analysis is
> >>>>>>  ongoing.
> >>>>>> -->
> >>>>>
> >>>>> I think we should be using the scientifically correct terms (not the
> colloquial ones), which would be: C02 emissions or carbon dioxide emissions.
> >>>>>
> >>>>> But we can leave carbon footprint in the text imho.
> >>>>>
> >>>>>> 14) <!-- [rfced] This text was difficult to follow.  Please consider
> >>>>>> our suggested text and and let us know if it captures your intended
> meaning:
> >>>>>> Original:
> >>>>>>  Discussion also considered to what extent are climate impacts
> >>>>>>  considered in the development and standardization of Internet
> >>>>>>  protocols?  It reviewed the text of RFCs and active working group
> >>>>>>  drafts, looking for relevant keywords to highlight the extent to
> >>>>>>  which climate change, energy efficiency, and related topics are
> >>>>>>  considered in the design of Internet protocols, to show the limited
> >>>>>>  extent to which these topics have been considered.  Ongoing work is
> >>>>>>  considering meeting minutes and mail archives, to get a fuller
> >>>>>>  picture, but initial results show only limited consideration of
> these
> >>>>>>  important issues.
> >>>>>> Current:
> >>>>>>  The extent to which climate impacts are
> >>>>>>  considered during the development and standardization of Internet
> >>>>>>  protocols was discussed.  RFCs and Internet-Drafts of active
> working
> >>>>>>  groups were reviewed for relevant keywords to highlight the extent
> to
> >>>>>>  which climate change, energy efficiency, and related topics were
> >>>>>>  considered in the design of Internet protocols.  This review
> revealed
> >>>>>>  the limited extent to which these topics have been considered.
> There
> >>>>>>  is ongoing work to get a fuller picture by reviewing meeting
> minutes
> >>>>>>  and mail archives as well, but initial results show only limited
> >>>>>>  consideration of these important issues.
> >>>>>> -->
> >>>>>
> >>>>> Agreed with the proposal.
> >>>>>
> >>>>>> 15) <!-- [rfced] Would it be helpful for readers to include a
> reference
> >>>>>> for the IETF gather.town area?
> >>>>>> Original:
> >>>>>>  All groups had their own work space and
> >>>>>>  could use their own communication methods and channels, or use
> IETF's
> >>>>>>  gather.town.
> >>>>>> -->
> >>>>>
> >>>>> Agreed.
> >>>>>
> >>>>>> 16) <!-- [rfced] Please confirm that asking participants to "submit
> groups"
> >>>>>> is correct, as this reads "asking participants to submit groups to
> facilitate
> >>>>>> the formation of groups".  Perhaps "groups" could be ommitted?
> >>>>>> Original:
> >>>>>>  Future workshops that choose to integrate a hackathon could
> consider
> >>>>>>  to ask participants to submit groups, issues, and questions
> >>>>>>  beforehand (potentially as part of the positions paper or the
> sign-up
> >>>>>>  process) to facilitate the formation of groups.
> >>>>>> -->
> >>>>>
> >>>>> Agreed, so it would be as follows:
> >>>>>
> >>>>>   Future workshops that choose to integrate a hackathon could
> consider
> >>>>>   to ask participants to submit issues, and questions
> >>>>>   beforehand (potentially as part of the positions paper or the
> sign-up
> >>>>>   process) to facilitate the formation of groups.
> >>>>>
> >>>>>
> >>>>>> 17) <!-- [rfced] Sections 4.1 - 4.5: While possibly a bit
> redundant, it may be
> >>>>>> helpful to the reader to include text to introduce the position
> papers and
> >>>>>> subject matter.  Please provide text if you would like to make
> updates.
> >>>>>> -->
> >>>>>
> >>>>> Not necessary imho
> >>>>>
> >>>>>> 18) <!-- [rfced] Concerning the titles of the two position papers
> discussed below, please consider whether any updates are desired.
> >>>>>> a) Don Le's paper originally was named "Position Paper" in the
> reference.
> >>>>>> We have updated this to “Article 19” to match what we see at the
> URL provided.
> >>>>>> However, perhaps "Analysing IETF Data Position Paper [ARTICLE 19]"
> as shown in
> >>>>>> the page info would be more informative?
> >>>>>
> >>>>>> Original:
> >>>>>>  Don Le Position Paper (https://www.iab.org/wp-content/IAB-
> >>>>>>  uploads/2021/11/Le.pdf)
> >>>>>
> >>>>> Agreed with proposed title ("Analysing IETF Data Position Paper
> [ARTICLE 19]")
> >>>>>
> >>>>>> b) Mark McFadden's paper is named "Position Paper" in the reference
> and the
> >>>>>> paper itself has no title.  Perhaps we can use the title provided
> via
> >>>>>> page info: IAB Workshop Proposal?  Alternatively, perhaps "A
> position paper by Mark McFadden" would work?> Original:
> >>>>>>  Mark McFadden Position Paper (https://www.iab.org/wp-content/IAB-
> >>>>>>  uploads/2021/11/McFadden.pdf)
> >>>>>> -->
> >>>>>
> >>>>> Agreed with: "A position paper by Mark McFadden"
> >>>>>
> >>>>>> 19) <!-- [rfced] Note that the Acknowledgements section was updated
> >>>>>> so that two paragraphs about support for Niels ten Oever appear
> >>>>>> closer together.
> >>>>>> -->
> >>>>>
> >>>>> I think the last paragraph should mention Colin Perkins:
> >>>>>
> >>>>> Efforts in the organization of this workshop by Colin Perkins were
> >>>>> supported in part by the UK Engineering and Physical Sciences
> >>>>> Research Council under grant EP/S036075/1.
> >>>>>
> >>>>>> 20) <!-- [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.  Note that our script
> did not
> >>>>>> flag any words or phrases of concern. -->
> >>>>>
> >>>>> Thanks - nothing found.
> >>>>>
> >>>>> Best,
> >>>>>
> >>>>> Niels
> >>>>>> Thank you.
> >>>>>> RFC Editor
> >>>>>> On Aug 22, 2022, at 11:57 PM, [e-mail] wrote:
> >>>>>> *****IMPORTANT*****
> >>>>>> Updated 2022/08/22
> >>>>>> RFC Author(s):
> >>>>>> --------------
> >>>>>> Instructions for Completing AUTH48
> >>>>>> Your document has now entered AUTH48.  Once it has been reviewed and
> >>>>>> approved by you and all coauthors, 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/).
> >>>>>> You and you coauthors are responsible for engaging other parties
> >>>>>> (e.g., Contributors or Working Group) as necessary before providing
> >>>>>> your approval.
> >>>>>> Planning your review
> >>>>>> ---------------------
> >>>>>> Please review the following aspects of your document:
> >>>>>> *  RFC Editor questions
> >>>>>>  Please review and resolve any questions raised by the RFC Editor
> >>>>>>  that have been included in the XML file as comments marked as
> >>>>>>  follows:
> >>>>>>  <!-- [rfced] ... -->
> >>>>>>  These questions will also be sent in a subsequent email.
> >>>>>> *  Changes submitted by coauthors
> >>>>>>  Please ensure that you review any changes submitted by your
> >>>>>>  coauthors.  We assume that if you do not speak up that you
> >>>>>>  agree to changes submitted by your coauthors.
> >>>>>> *  Content
> >>>>>>  Please review the full content of the document, as this cannot
> >>>>>>  change once the RFC is published.  Please pay particular attention
> to:
> >>>>>>  - IANA considerations updates (if applicable)
> >>>>>>  - contact information
> >>>>>>  - references
> >>>>>> *  Copyright notices and legends
> >>>>>>  Please review the copyright notice and legends as defined in
> >>>>>>  RFC 5378 and the Trust Legal Provisions
> >>>>>>  (TLP – https://trustee.ietf.org/license-info/).
> >>>>>> *  Semantic markup
> >>>>>>  Please review the markup in the XML file to ensure that elements of
> >>>>>>  content are correctly tagged.  For example, ensure that
> <sourcecode>
> >>>>>>  and <artwork> are set correctly.  See details at
> >>>>>>  <https://authors.ietf.org/rfcxml-vocabulary>.
> >>>>>> *  Formatted output
> >>>>>>  Please review the PDF, HTML, and TXT files to ensure that the
> >>>>>>  formatted output, as generated from the markup in the XML file, is
> >>>>>>  reasonable.  Please note that the TXT will have formatting
> >>>>>>  limitations compared to the PDF and HTML.
> >>>>>> Submitting changes
> >>>>>> ------------------
> >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as
> all
> >>>>>> the parties CCed on this message need to see your changes. The
> parties
> >>>>>> include:
> >>>>>>  *  your coauthors
> >>>>>>      *  [e-mail] (the RPC team)
> >>>>>>  *  other document participants, depending on the stream (e.g.,
> >>>>>>     IETF Stream participants are your working group chairs, the
> >>>>>>     responsible ADs, and the document shepherd).
> >>>>>>        *  [e-mail], which is a new archival
> mailing list
> >>>>>>     to preserve AUTH48 conversations; it is not an active discussion
> >>>>>>     list:
> >>>>>>          *  More info:
> >>>>>>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >>>>>>          *  The archive itself:
> >>>>>>       https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>>>>    *  Note: If only absolutely necessary, you may temporarily opt
> out
> >>>>>>       of the archiving of messages (e.g., to discuss a sensitive
> matter).
> >>>>>>       If needed, please add a note at the top of the message that
> you
> >>>>>>       have dropped the address. When the discussion is concluded,
> >>>>>>       [e-mail] will be re-added to the CC list
> and
> >>>>>>       its addition will be noted at the top of the message.
> >>>>>> You may submit your changes in one of two ways:
> >>>>>> An update to the provided XML file
> >>>>>> — OR —
> >>>>>> An explicit list of changes in this format
> >>>>>> Section # (or indicate Global)
> >>>>>> OLD:
> >>>>>> old text
> >>>>>> NEW:
> >>>>>> new text
> >>>>>> You do not need to reply with both an updated XML file and an
> explicit
> >>>>>> list of changes, as either form is sufficient.
> >>>>>> We will ask a stream manager to review and approve any changes that
> seem
> >>>>>> beyond editorial in nature, e.g., addition of new text, deletion of
> text,
> >>>>>> and technical changes.  Information about stream managers can be
> found in
> >>>>>> the FAQ.  Editorial changes do not require approval from a stream
> manager.
> >>>>>> Approving for publication
> >>>>>> --------------------------
> >>>>>> To approve your RFC for publication, please reply to this email
> stating
> >>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> >>>>>> as all the parties CCed on this message need to see your approval.
> >>>>>> Files
> >>>>>> -----
> >>>>>> The files are available here:
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307.xml
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307.html
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307.pdf
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307.txt
> >>>>>> Diff file of the text:
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307-diff.html
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307-rfcdiff.html (side by
> side)
> >>>>>> Diff of the XML:
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307-xmldiff1.html
> >>>>>> The following files are provided to facilitate creation of your own
> >>>>>> diff files of the XML.
> >>>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307.original.v2v3.xml
> >>>>>> XMLv3 file that is a best effort to capture v3-related format
> updates
> >>>>>> only:
> >>>>>>  https://www.rfc-editor.org/authors/rfc9307.form.xml
> >>>>>> Tracking progress
> >>>>>> -----------------
> >>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>  https://www.rfc-editor.org/auth48/rfc9307
> >>>>>> Please let us know if you have any questions.
> >>>>>> Thank you for your cooperation,
> >>>>>> RFC Editor
> >>>>>> --------------------------------------
> >>>>>> RFC9307 (draft-iab-aid-workshop-01)
> >>>>>> Title            : Report from the IAB Workshop on Analyzing IETF
> Data (AID), 2021
> >>>>>> Author(s)        : N. Oever, C. Cath, M. Kühlewind, C. Perkins
> >>>>>> WG Chair(s)      :
> >>>>>> Area Director(s) :
> >>>>>
> >>>>> --
> >>>>> Niels ten Oever, PhD
> >>>>> Postdoctoral Researcher - Media Studies Department - University of
> Amsterdam
> >>>>> Affiliated Faculty - Digital Democracy Institute - Simon Fraser
> University
> >>>>> Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
> >>>>> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação
> Getúlio Vargas
> >>>>> Research Fellow - Centre for Internet and Human Rights - European
> University Viadrina
> >>>>>
> >>>>> Vice chair - Global Internet Governance Academic Network (GigaNet)
> >>>>>
> >>>>> W: https://nielstenoever.net
> >>>>> E: [e-mail]
> >>>>> T: @nielstenoever
> >>>>> P/S/WA: [phone]
> >>>>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
> >>>>>
> >>>>> Read my latest article on understanding power in standardization in
> the Journal of Standardisation here:
> https://journals.open.tudelft.nl/jos/article/view/6205/5361
> >>>>>
> >>>
> >>> --
> >>> Niels ten Oever, PhD
> >>> Postdoctoral Researcher - Media Studies Department - University of
> Amsterdam
> >>> Affiliated Faculty - Digital Democracy Institute - Simon Fraser
> University
> >>> Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
> >>> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação
> Getúlio Vargas
> >>> Research Fellow - Centre for Internet and Human Rights - European
> University Viadrina
> >>>
> >>> Vice chair - Global Internet Governance Academic Network (GigaNet)
> >>>
> >>> W: https://nielstenoever.net
> >>> E: [e-mail]
> >>> T: @nielstenoever
> >>> P/S/WA: [phone]
> >>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
> >>>
> >>> Read my latest article on understanding power in standardization in
> the Journal of Standardisation here:
> https://journals.open.tudelft.nl/jos/article/view/6205/5361
> >>>
> >>
> >>
> >
>
>

-- 
Dr. Corinne Cath
​Minderoo Center for Technology & Democracy, University of Cambridge ​

Web: www.mctd.ac.uk/team-members/corinne-cath/ & www.corinnecath.com
Twitter: @C__CS