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

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

Ah excellent. Thank you very much. Is there a particular reason this is not mention in the RFC (for instance underneath ISSN)?

Best,

Niels

On 3 Oct 2022, 10:49, at 10:49, Colin Perkins <[e-mail]> wrote:
>All the RFCs have DOIs assigned: 10.17487/RFC9307
>
>Colin
>
>
>On 3 Oct 2022, at 7:15, Niels ten Oever wrote:
>
>> Hi RFC editor,
>>
>> Thanks so much for publication of RFC 9307. I was wondering, will
>this RFC also receive a DOI, or not? It is completely clear to me
>if/when RFCs get one. For me it would be helpful.
>>
>> Best,
>>
>> Niels
>>
>> On 21-09-2022 16:22, Mirja Kuehlewind wrote:
>>> Thanks! All changes look good to me as well!
>>>
>>> *From: *Corinne Cath <[e-mail]>
>>> *Date: *Wednesday, 21. September 2022 at 15:18
>>> *To: *Karen Moore <[e-mail]>
>>> *Cc: *Niels ten Oever <[e-mail]>, Mirja Kuehlewind
><[e-mail]>, Colin Perkins <[e-mail]>, RFC
>Editor <[e-mail]>, IAB <[e-mail]>,
>"[e-mail]" <[e-mail]>
>>> *Subject: *Re: [IAB] AUTH48: RFC-to-be 9307
><draft-iab-aid-workshop-01> for your review
>>>
>>> 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 <[e-mail]
><mailto:[e-mail]>> 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
><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.txt>
>>>   https://www.rfc-editor.org/authors/rfc9307.pdf
><https://www.rfc-editor.org/authors/rfc9307.pdf>
>>>   https://www.rfc-editor.org/authors/rfc9307.html
><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
><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
><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
><https://www.rfc-editor.org/auth48/rfc9307>
>>>
>>>     Thank you,
>>>
>>>     RFC Editor/kc
>>>
>>>
>>>      > On Sep 20, 2022, at 1:16 AM, Niels ten Oever
><[e-mail] <mailto:[e-mail]>> 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
><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.txt>
>>>      >> https://www.rfc-editor.org/authors/rfc9307.pdf
><https://www.rfc-editor.org/authors/rfc9307.pdf>
>>>      >> https://www.rfc-editor.org/authors/rfc9307.html
><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
><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
><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
><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
><https://www.rfc-editor.org/auth48/rfc9307>
>>>      >> Thank you,
>>>      >> RFC Editor/kc
>>>      >>> On Sep 19, 2022, at 2:21 AM, Mirja Kuehlewind
><[e-mail] <mailto:[e-mail]>>
>wrote:
>>>      >>>
>>>      >>> Hi all,
>>>      >>>
>>>      >>> Thanks for the updates. These look all good to me.
>>>      >>>
>>>      >>> About affiliations: I guess we could put for Colin and me
>just “IAB” in there. Collin, what do you think?
>>>      >>>
>>>      >>> Mirja
>>>      >>>
>>>      >>>
>>>      >>>
>>>      >>>> On 16. Sep 2022, at 22:54, Karen Moore <[e-mail]
><mailto:[e-mail]>> wrote:
>>>      >>>>
>>>      >>>> Niels,
>>>      >>>>
>>>      >>>> Thank you for the reply; we will work on removing the URLs
>and will get back to you shortly.
>>>      >>>>
>>>      >>>> RFC Editor/kc
>>>      >>>>
>>>      >>>>> On Sep 16, 2022, at 6:50 AM, Niels ten Oever
><[e-mail] <mailto:[e-mail]>> wrote:
>>>      >>>>>
>>>      >>>>> Dear RFC Editor,
>>>      >>>>>
>>>      >>>>> It would indeed better for the txt file to be more
>readable, so feel free to remove the URLs in the text.
>>>      >>>>>
>>>      >>>>> Best,
>>>      >>>>>
>>>      >>>>> Niels
>>>      >>>>>
>>>      >>>>> On 08-09-2022 02:13, Karen Moore wrote:
>>>      >>>>>> Dear Niels and Colin,
>>>      >>>>>> We have updated our files based on your replies. As
>discussed, we have also included a list of IAB members and an
>Informative References section. We have a follow-up question:
>>>      >>>>>> 1) We built an Informative References section and added
>citations for the URLs listed in Sections 2.1, 2.2, and 4.  Please note
>that the output looks clean in the html and pdf files (as the URLs are
>not displayed), but the txt file is a bit harder to read as it includes
>all of the URLs.  If you would like the txt file to be more readable
>and match the formatting in RFC 9075 (which is also an IAB document),
>we can remove the URLs (so instead of being able to access an article
>directly from the text in the html and pdf files, a reader would click
>on the citation in the text and then click on the link to the article
>from the reference entry).
>>>      >>>>>> Please confirm if you would like to leave the visible
>URLs in the txt file or if you would like to remove them.
>>>      >>>>>> ...
>>>      >>>>>> The updated XML file is here:
>>>      >>>>>> https://www.rfc-editor.org/authors/rfc9307.xml
><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.txt>
>>>      >>>>>> https://www.rfc-editor.org/authors/rfc9307.pdf
><https://www.rfc-editor.org/authors/rfc9307.pdf>
>>>      >>>>>> https://www.rfc-editor.org/authors/rfc9307.html
><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
><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
><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
><https://www.rfc-editor.org/auth48/rfc9307>
>>>      >>>>>> Thank you,
>>>      >>>>>> RFC Editor/kc
>>>      >>>>>>> On Aug 23, 2022, at 7:39 AM, Niels ten Oever
><[e-mail] <mailto:[e-mail]>> wrote:
>>>      >>>>>>>
>>>      >>>>>>> Hi all,
>>>      >>>>>>>
>>>      >>>>>>> On 23-08-2022 09:12, [e-mail]
><mailto:[e-mail]> wrote:
>>>      >>>>>>>> Authors,
>>>      >>>>>>>> While reviewing this document during AUTH48, please
>resolve (as necessary)
>>>      >>>>>>>> the following questions, which are also in the XML
>file.
>>>      >>>>>>>> 1) <!-- [rfced] Please review the guidance for IAB
>documents
>>>      >>>>>>>> <https://www.rfc-editor.org/materials/iab-format.txt
><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/
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-61ecd4ae9402f3ac&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=https%3A%2F%2Fwww.iab.org%2Fabout%2Fiab-members%2F>>
>(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
><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 <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
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2e119dbb88e2b356&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=https%3A%2F%2Fwww.arkko.com%2Ftools%2Fdocstats.html>
>) page and the datatracker
>>>      >>>>>>>>  statistics (https://datatracker.ietf.org/stats/
><https://datatracker.ietf.org/stats/> ), e.g., related to
>>>      >>>>>>>>  gender questions, however, privacy issues andd
>implication of making
>>>      >>>>>>>>  such data publicly available were discussed as well.
>>>      >>>>>>>> -->
>>>      >>>>>>> s/annd/and
>>>      >>>>>>>> 8) <!-- [rfced] Are you still encouraging discussion
>to take place on
>>>      >>>>>>>> [e-mail] <mailto:[e-mail]>
>, or should this be changed to past tense?
>>>      >>>>>>>> Should a qualifier be added to this sentence, for
>example, questions
>>>      >>>>>>>> or discussion about the datatracker and possible
>enhancements may
>>>      >>>>>>>> be sent to...?
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  Questions or any
>>>      >>>>>>>>  discussion can be issued to [e-mail]
><mailto:[e-mail]> .
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> questions or discussion about the datatracker and
>possible enhancements may be sent to [e-mail]
><mailto:[e-mail]> , sounds good to me.
>>>      >>>>>>>
>>>      >>>>>>>> 9) <!-- [rfced] We had trouble parsing this sentence.
>Please review
>>>      >>>>>>>> and let us know how we may clarify.
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  To assess these question it
>>>      >>>>>>>>  has ben discussed to investigate participant's
>affiliations including
>>>      >>>>>>>>  "indirect" affiliation e.g. by funding and changes in
>affiliation as
>>>      >>>>>>>>  well as the nessecarity to model company
>characteristics or
>>>      >>>>>>>>  stakeholder groups.
>>>      >>>>>>>> Perhaps:
>>>      >>>>>>>>  To assess these questions, investigating participant
>affiliations,
>>>      >>>>>>>>  including "indirect" affiliations (e.g., by tracking
>funding and
>>>      >>>>>>>>  changes in affiliation) was discussed.  The need to
>model company
>>>      >>>>>>>>  characteristics or stakeholder groups was also
>discussed.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> Agreed with proposal.
>>>      >>>>>>>
>>>      >>>>>>>> 10) <!-- [rfced] Would "highlighted" or "emphasized"
>be more clear
>>>      >>>>>>>> than "stressed" here?
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  The human element of the community and diversity was
>stressed, in
>>>      >>>>>>>>  order to understand the IETF community's diversity it
>is important to
>>>      >>>>>>>>  talk to people (beyond text analysis) and in order to
>ensure
>>>      >>>>>>>>  inclusivity individual participants must make an
>effort to, as one
>>>      >>>>>>>>  participant recounted, tell them their participation
>is valuable.
>>>      >>>>>>>> Current:
>>>      >>>>>>>>  The human element of the community and diversity was
>stressed.  In
>>>      >>>>>>>>  order to understand the IETF community's diversity,
>it is important
>>>      >>>>>>>>  to talk to people (beyond text analysis). ...
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> s/stressed/highlighted
>>>      >>>>>>>
>>>      >>>>>>>> 11) <!-- [rfced] This document seems to use "draft"
>generically and to
>>>      >>>>>>>> refer to Internet-Drafts in some places.  Please
>review and consider
>>>      >>>>>>>> whether the text should refer specifically to
>Internet-Drafts in some
>>>      >>>>>>>> places for clarity.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> Agreed
>>>      >>>>>>>
>>>      >>>>>>>> 12) <!-- [rfced] Have these questions already been
>answered or does
>>>      >>>>>>>> analysis need to be completed to identify the answers?
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  Answers to these questions come from analysis of IETF
>emails, RFCs
>>>      >>>>>>>>  and Internet-Drafts, meeting minutes, recordings,
>Github data, and
>>>      >>>>>>>>  external data such as surveys, etc.
>>>      >>>>>>>> Perhaps:
>>>      >>>>>>>>  Analysis of data such as IETF emails, RFCs and
>Internet-Drafts,
>>>      >>>>>>>>  meeting minutes, recordings, Github data, and
>external data (e.g., surveys)
>>>      >>>>>>>>  may help answer these questions.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> Agreed with proposal, perhaps add a comma as follows:
>>>      >>>>>>>
>>>      >>>>>>>   Analysis of data, such as IETF emails, RFCs and
>Internet-Drafts,
>>>      >>>>>>>   meeting minutes, recordings, Github data, and
>external data (e.g., surveys)
>>>      >>>>>>>   may help answer these questions.
>>>      >>>>>>>
>>>      >>>>>>>
>>>      >>>>>>>> 13) <!-- [rfced] Note that we changed "CO2 emissions"
>to "carbon emissions"
>>>      >>>>>>>> here to match use in the rest of the paragraph. 
>Please let us know if
>>>      >>>>>>>> corrections are needed.
>>>      >>>>>>>> Original (the whole paragraph is provided for
>context):
>>>      >>>>>>>>  Discussion started by considering how sustainable are
>IETF meetings,
>>>      >>>>>>>>  focussing on how much CO2 emissions are IETF meetings
>responsible for
>>>      >>>>>>>>  and how can we make the IETF more sustainable. 
>Analysis looked at
>>>      >>>>>>>>  the home locations of participants, meeting
>locations, and carbon
>>>      >>>>>>>>  footprint of air travel and remote attendance, to
>estimate the carbon
>>>      >>>>>>>>  costs of an IETF meeting.  Initial results suggest
>that the costs of
>>>      >>>>>>>>  holding multiple in-person IETF meetings per year are
>likely
>>>      >>>>>>>>  unsustainable in terms of carbon emission, although
>the analysis is
>>>      >>>>>>>>  ongoing.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> I think we should be using the scientifically correct
>terms (not the colloquial ones), which would be: C02 emissions or
>carbon dioxide emissions.
>>>      >>>>>>>
>>>      >>>>>>> But we can leave carbon footprint in the text imho.
>>>      >>>>>>>
>>>      >>>>>>>> 14) <!-- [rfced] This text was difficult to follow. 
>Please consider
>>>      >>>>>>>> our suggested text and and let us know if it captures
>your intended meaning:
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  Discussion also considered to what extent are climate
>impacts
>>>      >>>>>>>>  considered in the development and standardization of
>Internet
>>>      >>>>>>>>  protocols?  It reviewed the text of RFCs and active
>working group
>>>      >>>>>>>>  drafts, looking for relevant keywords to highlight
>the extent to
>>>      >>>>>>>>  which climate change, energy efficiency, and related
>topics are
>>>      >>>>>>>>  considered in the design of Internet protocols, to
>show the limited
>>>      >>>>>>>>  extent to which these topics have been considered. 
>Ongoing work is
>>>      >>>>>>>>  considering meeting minutes and mail archives, to get
>a fuller
>>>      >>>>>>>>  picture, but initial results show only limited
>consideration of these
>>>      >>>>>>>>  important issues.
>>>      >>>>>>>> Current:
>>>      >>>>>>>>  The extent to which climate impacts are
>>>      >>>>>>>>  considered during the development and standardization
>of Internet
>>>      >>>>>>>>  protocols was discussed.  RFCs and Internet-Drafts of
>active working
>>>      >>>>>>>>  groups were reviewed for relevant keywords to
>highlight the extent to
>>>      >>>>>>>>  which climate change, energy efficiency, and related
>topics were
>>>      >>>>>>>>  considered in the design of Internet protocols.  This
>review revealed
>>>      >>>>>>>>  the limited extent to which these topics have been
>considered.  There
>>>      >>>>>>>>  is ongoing work to get a fuller picture by reviewing
>meeting minutes
>>>      >>>>>>>>  and mail archives as well, but initial results show
>only limited
>>>      >>>>>>>>  consideration of these important issues.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> Agreed with the proposal.
>>>      >>>>>>>
>>>      >>>>>>>> 15) <!-- [rfced] Would it be helpful for readers to
>include a reference
>>>      >>>>>>>> for the IETF gather.town area?
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  All groups had their own work space and
>>>      >>>>>>>>  could use their own communication methods and
>channels, or use IETF's
>>>      >>>>>>>>  gather.town.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> Agreed.
>>>      >>>>>>>
>>>      >>>>>>>> 16) <!-- [rfced] Please confirm that asking
>participants to "submit groups"
>>>      >>>>>>>> is correct, as this reads "asking participants to
>submit groups to facilitate
>>>      >>>>>>>> the formation of groups".  Perhaps "groups" could be
>ommitted?
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  Future workshops that choose to integrate a hackathon
>could consider
>>>      >>>>>>>>  to ask participants to submit groups, issues, and
>questions
>>>      >>>>>>>>  beforehand (potentially as part of the positions
>paper or the sign-up
>>>      >>>>>>>>  process) to facilitate the formation of groups.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> Agreed, so it would be as follows:
>>>      >>>>>>>
>>>      >>>>>>>   Future workshops that choose to integrate a hackathon
>could consider
>>>      >>>>>>>   to ask participants to submit issues, and questions
>>>      >>>>>>>   beforehand (potentially as part of the positions
>paper or the sign-up
>>>      >>>>>>>   process) to facilitate the formation of groups.
>>>      >>>>>>>
>>>      >>>>>>>
>>>      >>>>>>>> 17) <!-- [rfced] Sections 4.1 - 4.5: While possibly a
>bit redundant, it may be
>>>      >>>>>>>> helpful to the reader to include text to introduce the
>position papers and
>>>      >>>>>>>> subject matter.  Please provide text if you would like
>to make updates.
>>>      >>>>>>>> -->
>>>      >>>>>>>
>>>      >>>>>>> Not necessary imho
>>>      >>>>>>>
>>>      >>>>>>>> 18) <!-- [rfced] Concerning the titles of the two
>position papers discussed below, please consider whether any updates
>are desired.
>>>      >>>>>>>> a) Don Le's paper originally was named "Position
>Paper" in the reference.
>>>      >>>>>>>> We have updated this to “Article 19” to match what we
>see at the URL provided.
>>>      >>>>>>>> However, perhaps "Analysing IETF Data Position Paper
>[ARTICLE 19]" as shown in
>>>      >>>>>>>> the page info would be more informative?
>>>      >>>>>>>
>>>      >>>>>>>> Original:
>>>      >>>>>>>>  Don Le Position Paper
>(https://www.iab.org/wp-content/IAB-
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-26d12c12b571b1a7&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=https%3A%2F%2Fwww.iab.org%2Fwp-content%2FIAB->
>>>      >>>>>>>>  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-
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-26d12c12b571b1a7&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=https%3A%2F%2Fwww.iab.org%2Fwp-content%2FIAB->
>>>      >>>>>>>>  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
><https://www.rfc-editor.org/styleguide/part2/#inclusive_language>>
>>>      >>>>>>>> and let us know if any changes are needed.  Note that
>our script did not
>>>      >>>>>>>> flag any words or phrases of concern. -->
>>>      >>>>>>>
>>>      >>>>>>> Thanks - nothing found.
>>>      >>>>>>>
>>>      >>>>>>> Best,
>>>      >>>>>>>
>>>      >>>>>>> Niels
>>>      >>>>>>>> Thank you.
>>>      >>>>>>>> RFC Editor
>>>      >>>>>>>> On Aug 22, 2022, at 11:57 PM,
>[e-mail] <mailto:[e-mail]> wrote:
>>>      >>>>>>>> *****IMPORTANT*****
>>>      >>>>>>>> Updated 2022/08/22
>>>      >>>>>>>> RFC Author(s):
>>>      >>>>>>>> --------------
>>>      >>>>>>>> Instructions for Completing AUTH48
>>>      >>>>>>>> Your document has now entered AUTH48.  Once it has
>been reviewed and
>>>      >>>>>>>> approved by you and all coauthors, it will be
>published as an RFC.
>>>      >>>>>>>> If an author is no longer available, there are several
>remedies
>>>      >>>>>>>> available as listed in the FAQ
>(https://www.rfc-editor.org/faq/ <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/
><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
><https://authors.ietf.org/rfcxml-vocabulary>> .
>>>      >>>>>>>> *  Formatted output
>>>      >>>>>>>>  Please review the PDF, HTML, and TXT files to ensure
>that the
>>>      >>>>>>>>  formatted output, as generated from the markup in the
>XML file, is
>>>      >>>>>>>>  reasonable.  Please note that the TXT will have
>formatting
>>>      >>>>>>>>  limitations compared to the PDF and HTML.
>>>      >>>>>>>> Submitting changes
>>>      >>>>>>>> ------------------
>>>      >>>>>>>> To submit changes, please reply to this email using
>‘REPLY ALL’ as all
>>>      >>>>>>>> the parties CCed on this message need to see your
>changes. The parties
>>>      >>>>>>>> include:
>>>      >>>>>>>>  *  your coauthors
>>>      >>>>>>>>      * [e-mail]
><mailto:[e-mail]> (the RPC team)
>>>      >>>>>>>>  *  other document participants, depending on the
>stream (e.g.,
>>>      >>>>>>>>     IETF Stream participants are your working group
>chairs, the
>>>      >>>>>>>>     responsible ADs, and the document shepherd).
>>>      >>>>>>>>        * [e-mail]
><mailto:[e-mail]> , which is a new archival mailing
>list
>>>      >>>>>>>>     to preserve AUTH48 conversations; it is not an
>active discussion
>>>      >>>>>>>>     list:
>>>      >>>>>>>>          *  More info:
>>>      >>>>>>>>
>https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
><https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
>>>      >>>>>>>>          *  The archive itself:
>>>      >>>>>>>>
>https://mailarchive.ietf.org/arch/browse/auth48archive/
><https://mailarchive.ietf.org/arch/browse/auth48archive/>
>>>      >>>>>>>>    *  Note: If only absolutely necessary, you may
>temporarily opt out
>>>      >>>>>>>>       of the archiving of messages (e.g., to discuss a
>sensitive matter).
>>>      >>>>>>>>       If needed, please add a note at the top of the
>message that you
>>>      >>>>>>>>       have dropped the address. When the discussion is
>concluded,
>>>      >>>>>>>> [e-mail]
><mailto:[e-mail]> will be re-added to the CC list
>and
>>>      >>>>>>>>       its addition will be noted at the top of the
>message.
>>>      >>>>>>>> You may submit your changes in one of two ways:
>>>      >>>>>>>> An update to the provided XML file
>>>      >>>>>>>> — OR —
>>>      >>>>>>>> An explicit list of changes in this format
>>>      >>>>>>>> Section # (or indicate Global)
>>>      >>>>>>>> OLD:
>>>      >>>>>>>> old text
>>>      >>>>>>>> NEW:
>>>      >>>>>>>> new text
>>>      >>>>>>>> You do not need to reply with both an updated XML file
>and an explicit
>>>      >>>>>>>> list of changes, as either form is sufficient.
>>>      >>>>>>>> We will ask a stream manager to review and approve any
>changes that seem
>>>      >>>>>>>> beyond editorial in nature, e.g., addition of new
>text, deletion of text,
>>>      >>>>>>>> and technical changes.  Information about stream
>managers can be found in
>>>      >>>>>>>> the FAQ.  Editorial changes do not require approval
>from a stream manager.
>>>      >>>>>>>> Approving for publication
>>>      >>>>>>>> --------------------------
>>>      >>>>>>>> To approve your RFC for publication, please reply to
>this email stating
>>>      >>>>>>>> that you approve this RFC for publication.  Please use
>‘REPLY ALL’,
>>>      >>>>>>>> as all the parties CCed on this message need to see
>your approval.
>>>      >>>>>>>> Files
>>>      >>>>>>>> -----
>>>      >>>>>>>> The files are available here:
>>>      >>>>>>>> https://www.rfc-editor.org/authors/rfc9307.xml
><https://www.rfc-editor.org/authors/rfc9307.xml>
>>>      >>>>>>>> https://www.rfc-editor.org/authors/rfc9307.html
><https://www.rfc-editor.org/authors/rfc9307.html>
>>>      >>>>>>>> https://www.rfc-editor.org/authors/rfc9307.pdf
><https://www.rfc-editor.org/authors/rfc9307.pdf>
>>>      >>>>>>>> https://www.rfc-editor.org/authors/rfc9307.txt
><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-diff.html>
>>>      >>>>>>>>
>https://www.rfc-editor.org/authors/rfc9307-rfcdiff.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
><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
><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
><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
><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
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7337d2f7ba42fde2&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=https%3A%2F%2Fnielstenoever.net%2F>
>>>      >>>>>>> E: [e-mail]
><mailto:[e-mail]>
>>>      >>>>>>> T: @nielstenoever
>>>      >>>>>>> P/S/WA: [phone]
>>>      >>>>>>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
>>>      >>>>>>>
>>>      >>>>>>> Read my latest article on understanding power in
>standardization in the Journal of Standardisation here:
>https://journals.open.tudelft.nl/jos/article/view/6205/5361
><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
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7337d2f7ba42fde2&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=https%3A%2F%2Fnielstenoever.net%2F>
>>>      >>>>> E: [e-mail] <mailto:[e-mail]>
>>>      >>>>> T: @nielstenoever
>>>      >>>>> P/S/WA: [phone]
>>>      >>>>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
>>>      >>>>>
>>>      >>>>> Read my latest article on understanding power in
>standardization in the Journal of Standardisation here:
>https://journals.open.tudelft.nl/jos/article/view/6205/5361
><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
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7337d2f7ba42fde2&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=https%3A%2F%2Fnielstenoever.net%2F>
>>>      > E: [e-mail] <mailto:[e-mail]>
>>>      > T: @nielstenoever
>>>      > P/S/WA: [phone]
>>>      > PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
>>>      >
>>>      > Read my latest article on understanding power in
>standardization in the Journal of Standardisation here:
>https://journals.open.tudelft.nl/jos/article/view/6205/5361
><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/
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-957b69578722a689&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=http%3A%2F%2Fwww.mctd.ac.uk%2Fteam-members%2Fcorinne-cath%2F>
> & www.corinnecath.com
><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-569768f0eb9e0bbc&q=1&e=bbec11dc-0471-4e56-aaef-344948da2125&u=http%3A%2F%2Fwww.corinnecath.com%2F>
>>>
>>> Twitter: @C__CS
>>>
>>
>> -- 
>> Niels ten Oever, PhD
>> Postdoctoral Researcher - Media Studies Department - University of
>Amsterdam
>> Affiliated Faculty - Digital Democracy Institute - Simon Fraser
>University
>> Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
>> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação
>Getúlio Vargas
>> Research Fellow - Centre for Internet and Human Rights - European
>University Viadrina
>>
>> Vice chair - Global Internet Governance Academic Network (GigaNet)
>>
>> W: https://nielstenoever.net
>> E: [e-mail]
>> T: @nielstenoever
>> P/S/WA: [phone]
>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
>>
>> Read my latest article on understanding power in standardization in
>the Journal of Standardisation here:
>https://journals.open.tudelft.nl/jos/article/view/6205/5361