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

Niels ten Oever <mail@nielstenoever.net> Sat, 17 September 2022 08:42 UTC

Return-Path: <mail@nielstenoever.net>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897CAC14CF0B; Sat, 17 Sep 2022 01:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asjaV0vA5eXD; Sat, 17 Sep 2022 01:42:15 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5D3C14F73D; Sat, 17 Sep 2022 01:42:14 -0700 (PDT)
In-Reply-To: <771F83B4-BDAE-4E6E-AECA-17552D51C4E4@amsl.com>
References: <20220823071211.D4D30877CD@rfcpa.amsl.com> <0faedb95-08ff-dcd1-9474-4964ee676a29@nielstenoever.net> <67774D0F-3296-4A32-9FE6-44352A2B4848@amsl.com> <7df4730a-6e42-ff7b-e46f-62ba36f16e08@nielstenoever.net> <981C7F46-ED9C-464F-A024-35C94E70C062@amsl.com> <bf542ca2-996d-9475-b659-0c426a8d0070@nielstenoever.net> <771F83B4-BDAE-4E6E-AECA-17552D51C4E4@amsl.com>
X-Referenced-Uid: 45886
Thread-Topic: Re: AUTH48: RFC-to-be 9307 <draft-iab-aid-workshop-01> for your review
User-Agent: Android
X-Is-Generated-Message-Id: true
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----IOF2M0WH0JD4Y4REX622AEAMPESY1F"
Content-Transfer-Encoding: 7bit
From: Niels ten Oever <mail@nielstenoever.net>
Date: Sat, 17 Sep 2022 10:42:03 +0200
To: Karen Moore <kmoore@amsl.com>
CC: Colin Perkins <csp@csperkins.org>, mirja.kuehlewind@ericsson.com, corinnecath@gmail.com, RFC Editor <rfc-editor@rfc-editor.org>, iab@ietf.org, auth48archive@rfc-editor.org
Message-ID: <8bfb4043-2df5-424c-aca2-4390d8b87f43@nielstenoever.net>
X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Scan-Signature: 5323bdbef2c69497dd0ec19556cc5a22
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/HyJk4Lpftt8Z77Cv6R5kCdT63uo>
Subject: Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-aid-workshop-01> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Sep 2022 08:42:20 -0000

Perfect, yes! Thank you!

On 17 Sep 2022, 01:00, at 01:00, Karen Moore <kmoore@amsl.com> wrote:
>Niels,
>
>To clarify, in the txt file, the URLs will be removed (from Sections 2
>and 4), so only the citations will remain. For the html and pdf files,
>the appearance will look exactly the same as it does now, but the words
>that currently link directly to an article will instead point to a
>citation, and readers will access the link from the reference entry. If
>you need further clarification or would like an example, please let us
>know.
>
>Please confirm if you would still like the URLs to be removed from the
>txt file (and hence the current links to be redirected to citations in
>the html/pdf files).
>
>Thanks!
>RFC Editor/kc
>
>
>> On Sep 16, 2022, at 2:11 PM, Niels ten Oever <mail@nielstenoever.net>
>wrote:
>> 
>> Hi Karen,
>> 
>> Just to be sure, this would only be in the txt version, and not in
>the html and pdf version, right?
>> 
>> Best,
>> 
>> Niels
>> 
>> On 16-09-2022 22:54, Karen Moore 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
><mail@nielstenoever.net> 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
><mail@nielstenoever.net> wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> On 23-08-2022 09:12, rfc-editor@rfc-editor.org 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
>>>>>>> tools-discuss@ietf.org, 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 tools-discuss@ietf.org.
>>>>>>> -->
>>>>>> 
>>>>>> questions or discussion about the datatracker and possible
>enhancements may be sent to tools-discuss@ietf.org, 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, rfc-editor@rfc-editor.org 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
>>>>>>>        *  rfc-editor@rfc-editor.org (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).
>>>>>>>          *  auth48archive@rfc-editor.org, 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,
>>>>>>>         auth48archive@rfc-editor.org 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: mail@nielstenoever.net
>>>>>> T: @nielstenoever
>>>>>> P/S/WA: +31629051853
>>>>>> 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: mail@nielstenoever.net
>>>> T: @nielstenoever
>>>> P/S/WA: +31629051853
>>>> 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: mail@nielstenoever.net
>> T: @nielstenoever
>> P/S/WA: +31629051853
>> 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
>>