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

Corinne Cath <corinnecath@gmail.com> Wed, 21 September 2022 13:17 UTC

Return-Path: <cattekwaad@gmail.com>
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 5B8EDC14F720; Wed, 21 Sep 2022 06:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CPhtLHwY7Thj; Wed, 21 Sep 2022 06:17:14 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6620CC14F72D; Wed, 21 Sep 2022 06:17:14 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id m65so6688264vsc.1; Wed, 21 Sep 2022 06:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=vsUlHPmHDyylIzx9yAZrGnlERoKr2PAhMPHfzMZOG/U=; b=WMMj8zRrX8qbtA3/BLbjK2ZsFOk9/AvHJPxvuzwWWDTCVIixFfeT2nhynIzgoTpN+p ACxNoWQgn/rzNgpqpO3CS3If91zmc1XSXwk5BDQO4SprhnBOm9UAbfrGXay61z1kC+cH efoTzqaAZgNa45k/x2drHDPrd7z4rfASMNpJ2GA20P3ATnL8yqBfWuhk98MXD/1aN+zZ Wlamzu1y5IrG85UMpZdTn8fApoO4OpvGg5Y14DfOvbQ+dXXrcd/JO1A+y0EO4+qQPR8a oY2vtOFJl675CNhsOPxvh9ptzvjACA5gAYHpfO/CrjPrZRcaZk1FMiO7nJxI6yQsddt4 5U5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=vsUlHPmHDyylIzx9yAZrGnlERoKr2PAhMPHfzMZOG/U=; b=1ujY+3oGlk4XebpXaOzgRK7mw/HyHoTvOvAIz68lidfT/PEV9ENskMfbEqrCj7v8Fi Z+UWVaJE4uzoCvVedhTQk3toy1oOkkdEnXZk5LHPTfzzOTaNVNLWuzFy3+WHPNMDkhH8 wzcrnEjKLg8DcXCQgBcVOuFK3YFTcPdcPxcC23P8tZlABqJZexgjdXqwkowQBMn1fbLA 8bWr/F5+s8nZ3N6oU0oC8y+PeRu4HbN13Q9IEIonPq3y+WfubY65/eh9IvrI+2dijxb0 Za1KAg9cLnhkWKGiHucHtk+AtoSs0rhfxWAy32HUBM0FMubsLBZV4p4xWUMLngFZDULP guWw==
X-Gm-Message-State: ACrzQf1Tz8kVO2AKg9dmoJN9gfNZOVSvQoQWilsvB2BdxA2nyRtTH2an LkAoWiuQrc2aEgtkWYgYXK63mkJiwor5CJRL67U=
X-Google-Smtp-Source: AMsMyM4fSnWXsyMlwho8XK0/vWpvfImjd1VP9yUUev86BH9ciRmhQCF3ZZlENGiFYH7fYl637DGTa9C8SLYqdqpC85U=
X-Received: by 2002:a05:6102:2005:b0:398:cc09:ba3d with SMTP id p5-20020a056102200500b00398cc09ba3dmr10110892vsr.53.1663766232651; Wed, 21 Sep 2022 06:17:12 -0700 (PDT)
MIME-Version: 1.0
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> <B4CE2E5B-F5C0-4D7D-A2BE-5B24FA0EBEC5@ericsson.com> <3DBCA78D-2B4B-4423-9CAF-7DADD15F00BA@amsl.com> <1d7806ab-c491-04f9-3a0d-8c7b20360070@nielstenoever.net> <49D54132-5730-4319-AB60-3AAD37E3647B@amsl.com>
In-Reply-To: <49D54132-5730-4319-AB60-3AAD37E3647B@amsl.com>
From: Corinne Cath <corinnecath@gmail.com>
Date: Wed, 21 Sep 2022 15:15:31 +0200
Message-ID: <CAD499eL33cddpRTvDQ+AT5VBZUA8CtRfD7gjfdjx=Wca=VDiKw@mail.gmail.com>
To: Karen Moore <kmoore@amsl.com>
Cc: Niels ten Oever <mail@nielstenoever.net>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Colin Perkins <csp@csperkins.org>, RFC Editor <rfc-editor@rfc-editor.org>, IAB <iab@ietf.org>, auth48archive@rfc-editor.org
Content-Type: multipart/alternative; boundary="000000000000495a8305e92fc3b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/Ur2v61byBbpzzUBUYr2CHxjVbKs>
Subject: Re: [auth48] [IAB] 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: Wed, 21 Sep 2022 13:17:19 -0000

Hi Karen,

Looks great, thanks so much for all the hard work! kind regards, corinne

On Wed, Sep 21, 2022 at 2:04 AM Karen Moore <kmoore@amsl.com> wrote:

> Dear Colin, Corinne, Niels, and Mirja,
>
> Thank you for your replies.  We have added the “University of Cambridge”
> for Corinne’s affiliation and left the other affiliations as is. We also
> noted Niels’ approval on the AUTH48 status page for this document.
>
> Please contact us with any further updates or with your approval of the
> document in its current form.  We will await approvals from Corinne, Colin,
> and Mirja prior to moving forward in the publication process.
>
> (Please refresh)
> 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
>
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9307
>
> Thank you,
>
> RFC Editor/kc
>
>
> > On Sep 20, 2022, at 1:16 AM, Niels ten Oever <mail@nielstenoever.net>
> wrote:
> >
> > Approved!
> >
> > Thanks a lot for your work.
> >
> > Best,
> >
> > Niels
> >
> > On 19-09-2022 22:21, Karen Moore 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 <
> mirja.kuehlewind@ericsson.com> 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 <kmoore@amsl.com> 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
> >
>
>

-- 
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