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
- [auth48] AUTH48: RFC-to-be 9307 <draft-iab-aid-wo… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Niels ten Oever
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Colin Perkins
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Sandy Ginoza
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Karen Moore
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Niels ten Oever
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Karen Moore
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Niels ten Oever
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Karen Moore
- Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-ai… Niels ten Oever
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Corinne Cath
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Niels ten Oever
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Niels ten Oever
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Colin Perkins
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Corinne Cath
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Colin Perkins
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Mirja Kuehlewind
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Colin Perkins
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Karen Moore
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Niels ten Oever
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Colin Perkins
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Niels ten Oever
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Colin Perkins
- Re: [auth48] [IAB] AUTH48: RFC-to-be 9307 <draft-… Sandy Ginoza