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

[Niels ten Oever <[e-mail]>]

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