Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-aid-workshop-01> for your review
Niels ten Oever <mail@nielstenoever.net> Sat, 17 September 2022 08:42 UTC
Return-Path: <mail@nielstenoever.net>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897CAC14CF0B; Sat, 17 Sep 2022 01:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asjaV0vA5eXD; Sat, 17 Sep 2022 01:42:15 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5D3C14F73D; Sat, 17 Sep 2022 01:42:14 -0700 (PDT)
In-Reply-To: <771F83B4-BDAE-4E6E-AECA-17552D51C4E4@amsl.com>
References: <20220823071211.D4D30877CD@rfcpa.amsl.com> <0faedb95-08ff-dcd1-9474-4964ee676a29@nielstenoever.net> <67774D0F-3296-4A32-9FE6-44352A2B4848@amsl.com> <7df4730a-6e42-ff7b-e46f-62ba36f16e08@nielstenoever.net> <981C7F46-ED9C-464F-A024-35C94E70C062@amsl.com> <bf542ca2-996d-9475-b659-0c426a8d0070@nielstenoever.net> <771F83B4-BDAE-4E6E-AECA-17552D51C4E4@amsl.com>
X-Referenced-Uid: 45886
Thread-Topic: Re: AUTH48: RFC-to-be 9307 <draft-iab-aid-workshop-01> for your review
User-Agent: Android
X-Is-Generated-Message-Id: true
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----IOF2M0WH0JD4Y4REX622AEAMPESY1F"
Content-Transfer-Encoding: 7bit
From: Niels ten Oever <mail@nielstenoever.net>
Date: Sat, 17 Sep 2022 10:42:03 +0200
To: Karen Moore <kmoore@amsl.com>
CC: Colin Perkins <csp@csperkins.org>, mirja.kuehlewind@ericsson.com, corinnecath@gmail.com, RFC Editor <rfc-editor@rfc-editor.org>, iab@ietf.org, auth48archive@rfc-editor.org
Message-ID: <8bfb4043-2df5-424c-aca2-4390d8b87f43@nielstenoever.net>
X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Scan-Signature: 5323bdbef2c69497dd0ec19556cc5a22
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/HyJk4Lpftt8Z77Cv6R5kCdT63uo>
Subject: Re: [auth48] AUTH48: RFC-to-be 9307 <draft-iab-aid-workshop-01> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Sep 2022 08:42:20 -0000
Perfect, yes! Thank you! On 17 Sep 2022, 01:00, at 01:00, Karen Moore <kmoore@amsl.com> wrote: >Niels, > >To clarify, in the txt file, the URLs will be removed (from Sections 2 >and 4), so only the citations will remain. For the html and pdf files, >the appearance will look exactly the same as it does now, but the words >that currently link directly to an article will instead point to a >citation, and readers will access the link from the reference entry. If >you need further clarification or would like an example, please let us >know. > >Please confirm if you would still like the URLs to be removed from the >txt file (and hence the current links to be redirected to citations in >the html/pdf files). > >Thanks! >RFC Editor/kc > > >> On Sep 16, 2022, at 2:11 PM, Niels ten Oever <mail@nielstenoever.net> >wrote: >> >> Hi Karen, >> >> Just to be sure, this would only be in the txt version, and not in >the html and pdf version, right? >> >> Best, >> >> Niels >> >> On 16-09-2022 22:54, Karen Moore wrote: >>> Niels, >>> Thank you for the reply; we will work on removing the URLs and will >get back to you shortly. >>> RFC Editor/kc >>>> On Sep 16, 2022, at 6:50 AM, Niels ten Oever ><mail@nielstenoever.net> wrote: >>>> >>>> Dear RFC Editor, >>>> >>>> It would indeed better for the txt file to be more readable, so >feel free to remove the URLs in the text. >>>> >>>> Best, >>>> >>>> Niels >>>> >>>> On 08-09-2022 02:13, Karen Moore wrote: >>>>> Dear Niels and Colin, >>>>> We have updated our files based on your replies. As discussed, we >have also included a list of IAB members and an Informative References >section. We have a follow-up question: >>>>> 1) We built an Informative References section and added citations >for the URLs listed in Sections 2.1, 2.2, and 4. Please note that the >output looks clean in the html and pdf files (as the URLs are not >displayed), but the txt file is a bit harder to read as it includes all >of the URLs. If you would like the txt file to be more readable and >match the formatting in RFC 9075 (which is also an IAB document), we >can remove the URLs (so instead of being able to access an article >directly from the text in the html and pdf files, a reader would click >on the citation in the text and then click on the link to the article >from the reference entry). >>>>> Please confirm if you would like to leave the visible URLs in the >txt file or if you would like to remove them. >>>>> ... >>>>> The updated XML file is here: >>>>> https://www.rfc-editor.org/authors/rfc9307.xml >>>>> The updated output files are here: >>>>> https://www.rfc-editor.org/authors/rfc9307.txt >>>>> https://www.rfc-editor.org/authors/rfc9307.pdf >>>>> https://www.rfc-editor.org/authors/rfc9307.html >>>>> This diff file shows all changes made during AUTH48: >>>>> https://www.rfc-editor.org/authors/rfc9307-auth48diff.html >>>>> This diff file shows all changes made to date: >>>>> https://www.rfc-editor.org/authors/rfc9307-diff.html >>>>> Note that it may be necessary for you to refresh your browser to >view the most recent version. Please review the document carefully to >ensure satisfaction as we do not make changes once it has been >published as an RFC. >>>>> Please contact us with any further updates or with your approval >of the document in its current form. We will await approvals from each >author prior to moving forward in the publication process. >>>>> For the AUTH48 status of this document, please see: >>>>> https://www.rfc-editor.org/auth48/rfc9307 >>>>> Thank you, >>>>> RFC Editor/kc >>>>>> On Aug 23, 2022, at 7:39 AM, Niels ten Oever ><mail@nielstenoever.net> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> On 23-08-2022 09:12, rfc-editor@rfc-editor.org wrote: >>>>>>> Authors, >>>>>>> While reviewing this document during AUTH48, please resolve (as >necessary) >>>>>>> the following questions, which are also in the XML file. >>>>>>> 1) <!-- [rfced] Please review the guidance for IAB documents >>>>>>> <https://www.rfc-editor.org/materials/iab-format.txt> >>>>>>> and let us know if any changes are needed. >>>>>>> a) Consensus is set to “true” in the XML and the datatracker, >but >>>>>>> the document is missing the “IAB Members at the Time of >Approval” section. >>>>>>> Please let us know if we may add this section and include the >names appearing >>>>>>> at <https://www.iab.org/about/iab-members/> (excluding >ex-officio members). >>>>>>> b) We will remove each author’s affiliation unless we hear >objection. >>>>>> >>>>>> I would prefer to keep mine, unless there is a strong reason not >to. >>>>>> >>>>>>> c) We will move “Workshop Participants” section to be an >appendix as suggested >>>>>>> at <https://www.rfc-editor.org/materials/iab-format.txt>. Should >the “Program >>>>>>> Committee” section be treated the same? >>>>>> >>>>>> Fine with me! >>>>>> >>>>>>> --> >>>>>>> 2) <!-- [rfced] Niels, you previously indicated you prefer that >your last >>>>>>> name be capitalized in footers as "Ten Oever" but appear as "ten >Oever" >>>>>>> wherever preceded by your first name or initial (i.e., document >header, >>>>>>> Authors' Addresses) (e.g., RFC 8280). We are unable to follow >this guidance >>>>>>> in the current XML. Note that the PDF is the only paginated >form. It shows >>>>>>> "ten Oever, et al." in the page footers. >>>>>>> --> >>>>>> >>>>>> Fine with me! >>>>>> >>>>>>> 3) <!-- [rfced] Please insert any keywords (beyond those that >appear >>>>>>> in the title) for use on https://www.rfc-editor.org/search. --> >>>>>> >>>>>> data science, data anlaysis, data science >>>>>> >>>>>>> 4) <!-- [rfced] We are having trouble parsing this sentence. >Does >>>>>>> "including of Internet protocols..." refer to the >standardization activities? >>>>>>> What does "its institutions" mean? >>>>>>> Original: >>>>>>> The IETF, as an international Standards Developing >Organization >>>>>>> (SDO), hosts a diverse set of data including on the >organization's >>>>>>> history, development, and current standardization activities, >>>>>>> including of Internet protocols and its institutions. >>>>>>> Perhaps: >>>>>>> The IETF, as an international Standards Developing >Organization >>>>>>> (SDO), hosts a diverse set of data that includes the >organization's >>>>>>> history, development, and current standardization activities, >which >>>>>>> includes Internet protocols and its institutions. >>>>>>> --> >>>>>> >>>>>> Perhaps: >>>>>> >>>>>> The IETF, as an international Standards Developing >Organization >>>>>> (SDO), hosts a diverse set of data that includes the >organization's >>>>>> history, development, and current standardization activities, >which >>>>>> includes Internet protocols, architecture, and its >institutions. >>>>>> >>>>>> >>>>>> >>>>>>> 5) <!-- [rfced] We have expanded ICT as "information and >communication >>>>>>> technologies". Please let us know if any corrections are >needed. >>>>>>> Current: >>>>>>> A large >>>>>>> portion of this data is publicly available, yet it is >underutilized >>>>>>> as a tool to inform the work in the IETF or the broader >>>>>>> research community focused on topics like Internet governance >and >>>>>>> trends in information and communication technologies (ICT) >standard- >>>>>>> setting. >>>>>>> --> >>>>>> >>>>>> Excellent >>>>>> >>>>>>> 6) <!-- [rfced] Section 2.1 includes several links to external >documents. >>>>>>> For a clearer reference section, may we specify these in an >"Informative >>>>>>> References" section along with a list of position papers. This >would be >>>>>>> similar to RFC 8980 and RFC 9075. >>>>>>> --> >>>>>> >>>>>> Sounds good to me. >>>>>> >>>>>>> 7) <!-- [rfced] "related to gender questions" is awkward here. >Perhaps this >>>>>>> could be rephrased as "gender-related information"? >Alternatively, perhaps >>>>>>> "responses to gender-related questions" would work. >>>>>> >>>>>> gender-related information seems like the best option >>>>>> >>>>>>> Original: >>>>>>> These projects could be used to add >>>>>>> additional insights to the existing IETF statistics >>>>>>> (https://www.arkko.com/tools/docstats.html) page and the >datatracker >>>>>>> statistics (https://datatracker.ietf.org/stats/), e.g., >related to >>>>>>> gender questions, however, privacy issues andd implication of >making >>>>>>> such data publicly available were discussed as well. >>>>>>> --> >>>>>> s/annd/and >>>>>>> 8) <!-- [rfced] Are you still encouraging discussion to take >place on >>>>>>> tools-discuss@ietf.org, or should this be changed to past tense? >>>>>>> Should a qualifier be added to this sentence, for example, >questions >>>>>>> or discussion about the datatracker and possible enhancements >may >>>>>>> be sent to...? >>>>>>> Original: >>>>>>> Questions or any >>>>>>> discussion can be issued to tools-discuss@ietf.org. >>>>>>> --> >>>>>> >>>>>> questions or discussion about the datatracker and possible >enhancements may be sent to tools-discuss@ietf.org, sounds good to me. >>>>>> >>>>>>> 9) <!-- [rfced] We had trouble parsing this sentence. Please >review >>>>>>> and let us know how we may clarify. >>>>>>> Original: >>>>>>> To assess these question it >>>>>>> has ben discussed to investigate participant's affiliations >including >>>>>>> "indirect" affiliation e.g. by funding and changes in >affiliation as >>>>>>> well as the nessecarity to model company characteristics or >>>>>>> stakeholder groups. >>>>>>> Perhaps: >>>>>>> To assess these questions, investigating participant >affiliations, >>>>>>> including "indirect" affiliations (e.g., by tracking funding >and >>>>>>> changes in affiliation) was discussed. The need to model >company >>>>>>> characteristics or stakeholder groups was also discussed. >>>>>>> --> >>>>>> >>>>>> Agreed with proposal. >>>>>> >>>>>>> 10) <!-- [rfced] Would "highlighted" or "emphasized" be more >clear >>>>>>> than "stressed" here? >>>>>>> Original: >>>>>>> The human element of the community and diversity was >stressed, in >>>>>>> order to understand the IETF community's diversity it is >important to >>>>>>> talk to people (beyond text analysis) and in order to ensure >>>>>>> inclusivity individual participants must make an effort to, >as one >>>>>>> participant recounted, tell them their participation is >valuable. >>>>>>> Current: >>>>>>> The human element of the community and diversity was >stressed. In >>>>>>> order to understand the IETF community's diversity, it is >important >>>>>>> to talk to people (beyond text analysis). ... >>>>>>> --> >>>>>> >>>>>> s/stressed/highlighted >>>>>> >>>>>>> 11) <!-- [rfced] This document seems to use "draft" generically >and to >>>>>>> refer to Internet-Drafts in some places. Please review and >consider >>>>>>> whether the text should refer specifically to Internet-Drafts in >some >>>>>>> places for clarity. >>>>>>> --> >>>>>> >>>>>> Agreed >>>>>> >>>>>>> 12) <!-- [rfced] Have these questions already been answered or >does >>>>>>> analysis need to be completed to identify the answers? >>>>>>> Original: >>>>>>> Answers to these questions come from analysis of IETF emails, >RFCs >>>>>>> and Internet-Drafts, meeting minutes, recordings, Github >data, and >>>>>>> external data such as surveys, etc. >>>>>>> Perhaps: >>>>>>> Analysis of data such as IETF emails, RFCs and >Internet-Drafts, >>>>>>> meeting minutes, recordings, Github data, and external data >(e.g., surveys) >>>>>>> may help answer these questions. >>>>>>> --> >>>>>> >>>>>> Agreed with proposal, perhaps add a comma as follows: >>>>>> >>>>>> Analysis of data, such as IETF emails, RFCs and >Internet-Drafts, >>>>>> meeting minutes, recordings, Github data, and external data >(e.g., surveys) >>>>>> may help answer these questions. >>>>>> >>>>>> >>>>>>> 13) <!-- [rfced] Note that we changed "CO2 emissions" to "carbon >emissions" >>>>>>> here to match use in the rest of the paragraph. Please let us >know if >>>>>>> corrections are needed. >>>>>>> Original (the whole paragraph is provided for context): >>>>>>> Discussion started by considering how sustainable are IETF >meetings, >>>>>>> focussing on how much CO2 emissions are IETF meetings >responsible for >>>>>>> and how can we make the IETF more sustainable. Analysis >looked at >>>>>>> the home locations of participants, meeting locations, and >carbon >>>>>>> footprint of air travel and remote attendance, to estimate >the carbon >>>>>>> costs of an IETF meeting. Initial results suggest that the >costs of >>>>>>> holding multiple in-person IETF meetings per year are likely >>>>>>> unsustainable in terms of carbon emission, although the >analysis is >>>>>>> ongoing. >>>>>>> --> >>>>>> >>>>>> I think we should be using the scientifically correct terms (not >the colloquial ones), which would be: C02 emissions or carbon dioxide >emissions. >>>>>> >>>>>> But we can leave carbon footprint in the text imho. >>>>>> >>>>>>> 14) <!-- [rfced] This text was difficult to follow. Please >consider >>>>>>> our suggested text and and let us know if it captures your >intended meaning: >>>>>>> Original: >>>>>>> Discussion also considered to what extent are climate impacts >>>>>>> considered in the development and standardization of Internet >>>>>>> protocols? It reviewed the text of RFCs and active working >group >>>>>>> drafts, looking for relevant keywords to highlight the extent >to >>>>>>> which climate change, energy efficiency, and related topics >are >>>>>>> considered in the design of Internet protocols, to show the >limited >>>>>>> extent to which these topics have been considered. Ongoing >work is >>>>>>> considering meeting minutes and mail archives, to get a >fuller >>>>>>> picture, but initial results show only limited consideration >of these >>>>>>> important issues. >>>>>>> Current: >>>>>>> The extent to which climate impacts are >>>>>>> considered during the development and standardization of >Internet >>>>>>> protocols was discussed. RFCs and Internet-Drafts of active >working >>>>>>> groups were reviewed for relevant keywords to highlight the >extent to >>>>>>> which climate change, energy efficiency, and related topics >were >>>>>>> considered in the design of Internet protocols. This review >revealed >>>>>>> the limited extent to which these topics have been >considered. There >>>>>>> is ongoing work to get a fuller picture by reviewing meeting >minutes >>>>>>> and mail archives as well, but initial results show only >limited >>>>>>> consideration of these important issues. >>>>>>> --> >>>>>> >>>>>> Agreed with the proposal. >>>>>> >>>>>>> 15) <!-- [rfced] Would it be helpful for readers to include a >reference >>>>>>> for the IETF gather.town area? >>>>>>> Original: >>>>>>> All groups had their own work space and >>>>>>> could use their own communication methods and channels, or >use IETF's >>>>>>> gather.town. >>>>>>> --> >>>>>> >>>>>> Agreed. >>>>>> >>>>>>> 16) <!-- [rfced] Please confirm that asking participants to >"submit groups" >>>>>>> is correct, as this reads "asking participants to submit groups >to facilitate >>>>>>> the formation of groups". Perhaps "groups" could be ommitted? >>>>>>> Original: >>>>>>> Future workshops that choose to integrate a hackathon could >consider >>>>>>> to ask participants to submit groups, issues, and questions >>>>>>> beforehand (potentially as part of the positions paper or the >sign-up >>>>>>> process) to facilitate the formation of groups. >>>>>>> --> >>>>>> >>>>>> Agreed, so it would be as follows: >>>>>> >>>>>> Future workshops that choose to integrate a hackathon could >consider >>>>>> to ask participants to submit issues, and questions >>>>>> beforehand (potentially as part of the positions paper or the >sign-up >>>>>> process) to facilitate the formation of groups. >>>>>> >>>>>> >>>>>>> 17) <!-- [rfced] Sections 4.1 - 4.5: While possibly a bit >redundant, it may be >>>>>>> helpful to the reader to include text to introduce the position >papers and >>>>>>> subject matter. Please provide text if you would like to make >updates. >>>>>>> --> >>>>>> >>>>>> Not necessary imho >>>>>> >>>>>>> 18) <!-- [rfced] Concerning the titles of the two position >papers discussed below, please consider whether any updates are >desired. >>>>>>> a) Don Le's paper originally was named "Position Paper" in the >reference. >>>>>>> We have updated this to “Article 19” to match what we see at the >URL provided. >>>>>>> However, perhaps "Analysing IETF Data Position Paper [ARTICLE >19]" as shown in >>>>>>> the page info would be more informative? >>>>>> >>>>>>> Original: >>>>>>> Don Le Position Paper (https://www.iab.org/wp-content/IAB- >>>>>>> uploads/2021/11/Le.pdf) >>>>>> >>>>>> Agreed with proposed title ("Analysing IETF Data Position Paper >[ARTICLE 19]") >>>>>> >>>>>>> b) Mark McFadden's paper is named "Position Paper" in the >reference and the >>>>>>> paper itself has no title. Perhaps we can use the title >provided via >>>>>>> page info: IAB Workshop Proposal? Alternatively, perhaps "A >position paper by Mark McFadden" would work?> Original: >>>>>>> Mark McFadden Position Paper >(https://www.iab.org/wp-content/IAB- >>>>>>> uploads/2021/11/McFadden.pdf) >>>>>>> --> >>>>>> >>>>>> Agreed with: "A position paper by Mark McFadden" >>>>>> >>>>>>> 19) <!-- [rfced] Note that the Acknowledgements section was >updated >>>>>>> so that two paragraphs about support for Niels ten Oever appear >>>>>>> closer together. >>>>>>> --> >>>>>> >>>>>> I think the last paragraph should mention Colin Perkins: >>>>>> >>>>>> Efforts in the organization of this workshop by Colin Perkins >were >>>>>> supported in part by the UK Engineering and Physical Sciences >>>>>> Research Council under grant EP/S036075/1. >>>>>> >>>>>>> 20) <!-- [rfced] Please review the "Inclusive Language" portion >of the online >>>>>>> Style Guide ><https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>>> and let us know if any changes are needed. Note that our script >did not >>>>>>> flag any words or phrases of concern. --> >>>>>> >>>>>> Thanks - nothing found. >>>>>> >>>>>> Best, >>>>>> >>>>>> Niels >>>>>>> Thank you. >>>>>>> RFC Editor >>>>>>> On Aug 22, 2022, at 11:57 PM, rfc-editor@rfc-editor.org wrote: >>>>>>> *****IMPORTANT***** >>>>>>> Updated 2022/08/22 >>>>>>> RFC Author(s): >>>>>>> -------------- >>>>>>> Instructions for Completing AUTH48 >>>>>>> Your document has now entered AUTH48. Once it has been reviewed >and >>>>>>> approved by you and all coauthors, it will be published as an >RFC. >>>>>>> If an author is no longer available, there are several remedies >>>>>>> available as listed in the FAQ >(https://www.rfc-editor.org/faq/). >>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>> (e.g., Contributors or Working Group) as necessary before >providing >>>>>>> your approval. >>>>>>> Planning your review >>>>>>> --------------------- >>>>>>> Please review the following aspects of your document: >>>>>>> * RFC Editor questions >>>>>>> Please review and resolve any questions raised by the RFC >Editor >>>>>>> that have been included in the XML file as comments marked as >>>>>>> follows: >>>>>>> <!-- [rfced] ... --> >>>>>>> These questions will also be sent in a subsequent email. >>>>>>> * Changes submitted by coauthors >>>>>>> Please ensure that you review any changes submitted by your >>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>> agree to changes submitted by your coauthors. >>>>>>> * Content >>>>>>> Please review the full content of the document, as this >cannot >>>>>>> change once the RFC is published. Please pay particular >attention to: >>>>>>> - IANA considerations updates (if applicable) >>>>>>> - contact information >>>>>>> - references >>>>>>> * Copyright notices and legends >>>>>>> Please review the copyright notice and legends as defined in >>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>> (TLP – https://trustee.ietf.org/license-info/). >>>>>>> * Semantic markup >>>>>>> Please review the markup in the XML file to ensure that >elements of >>>>>>> content are correctly tagged. For example, ensure that ><sourcecode> >>>>>>> and <artwork> are set correctly. See details at >>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>> * Formatted output >>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>> formatted output, as generated from the markup in the XML >file, is >>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>> limitations compared to the PDF and HTML. >>>>>>> Submitting changes >>>>>>> ------------------ >>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ >as all >>>>>>> the parties CCed on this message need to see your changes. The >parties >>>>>>> include: >>>>>>> * your coauthors >>>>>>> * rfc-editor@rfc-editor.org (the RPC team) >>>>>>> * other document participants, depending on the stream >(e.g., >>>>>>> IETF Stream participants are your working group chairs, >the >>>>>>> responsible ADs, and the document shepherd). >>>>>>> * auth48archive@rfc-editor.org, which is a new >archival mailing list >>>>>>> to preserve AUTH48 conversations; it is not an active >discussion >>>>>>> list: >>>>>>> * More info: >>>>>>> >https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>> * The archive itself: >>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>> * Note: If only absolutely necessary, you may temporarily >opt out >>>>>>> of the archiving of messages (e.g., to discuss a >sensitive matter). >>>>>>> If needed, please add a note at the top of the message >that you >>>>>>> have dropped the address. When the discussion is >concluded, >>>>>>> auth48archive@rfc-editor.org will be re-added to the CC >list and >>>>>>> its addition will be noted at the top of the message. >>>>>>> You may submit your changes in one of two ways: >>>>>>> An update to the provided XML file >>>>>>> — OR — >>>>>>> An explicit list of changes in this format >>>>>>> Section # (or indicate Global) >>>>>>> OLD: >>>>>>> old text >>>>>>> NEW: >>>>>>> new text >>>>>>> You do not need to reply with both an updated XML file and an >explicit >>>>>>> list of changes, as either form is sufficient. >>>>>>> We will ask a stream manager to review and approve any changes >that seem >>>>>>> beyond editorial in nature, e.g., addition of new text, deletion >of text, >>>>>>> and technical changes. Information about stream managers can be >found in >>>>>>> the FAQ. Editorial changes do not require approval from a >stream manager. >>>>>>> Approving for publication >>>>>>> -------------------------- >>>>>>> To approve your RFC for publication, please reply to this email >stating >>>>>>> that you approve this RFC for publication. Please use ‘REPLY >ALL’, >>>>>>> as all the parties CCed on this message need to see your >approval. >>>>>>> Files >>>>>>> ----- >>>>>>> The files are available here: >>>>>>> https://www.rfc-editor.org/authors/rfc9307.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9307.html >>>>>>> https://www.rfc-editor.org/authors/rfc9307.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9307.txt >>>>>>> Diff file of the text: >>>>>>> https://www.rfc-editor.org/authors/rfc9307-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9307-rfcdiff.html (side >by side) >>>>>>> Diff of the XML: >>>>>>> https://www.rfc-editor.org/authors/rfc9307-xmldiff1.html >>>>>>> The following files are provided to facilitate creation of your >own >>>>>>> diff files of the XML. >>>>>>> Initial XMLv3 created using XMLv2 as input: >>>>>>> https://www.rfc-editor.org/authors/rfc9307.original.v2v3.xml >>>>>>> XMLv3 file that is a best effort to capture v3-related format >updates >>>>>>> only: >>>>>>> https://www.rfc-editor.org/authors/rfc9307.form.xml >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9307 >>>>>>> Please let us know if you have any questions. >>>>>>> Thank you for your cooperation, >>>>>>> RFC Editor >>>>>>> -------------------------------------- >>>>>>> RFC9307 (draft-iab-aid-workshop-01) >>>>>>> Title : Report from the IAB Workshop on Analyzing >IETF Data (AID), 2021 >>>>>>> Author(s) : N. Oever, C. Cath, M. Kühlewind, C. Perkins >>>>>>> WG Chair(s) : >>>>>>> Area Director(s) : >>>>>> >>>>>> -- >>>>>> Niels ten Oever, PhD >>>>>> Postdoctoral Researcher - Media Studies Department - University >of Amsterdam >>>>>> Affiliated Faculty - Digital Democracy Institute - Simon Fraser >University >>>>>> Non-Resident Fellow 2022-2023 - Center for Democracy & Technology >>>>>> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação >Getúlio Vargas >>>>>> Research Fellow - Centre for Internet and Human Rights - European >University Viadrina >>>>>> >>>>>> Vice chair - Global Internet Governance Academic Network >(GigaNet) >>>>>> >>>>>> W: https://nielstenoever.net >>>>>> E: mail@nielstenoever.net >>>>>> T: @nielstenoever >>>>>> P/S/WA: +31629051853 >>>>>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 >>>>>> >>>>>> Read my latest article on understanding power in standardization >in the Journal of Standardisation here: >https://journals.open.tudelft.nl/jos/article/view/6205/5361 >>>>>> >>>> >>>> -- >>>> Niels ten Oever, PhD >>>> Postdoctoral Researcher - Media Studies Department - University of >Amsterdam >>>> Affiliated Faculty - Digital Democracy Institute - Simon Fraser >University >>>> Non-Resident Fellow 2022-2023 - Center for Democracy & Technology >>>> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação >Getúlio Vargas >>>> Research Fellow - Centre for Internet and Human Rights - European >University Viadrina >>>> >>>> Vice chair - Global Internet Governance Academic Network (GigaNet) >>>> >>>> W: https://nielstenoever.net >>>> E: mail@nielstenoever.net >>>> T: @nielstenoever >>>> P/S/WA: +31629051853 >>>> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 >>>> >>>> Read my latest article on understanding power in standardization in >the Journal of Standardisation here: >https://journals.open.tudelft.nl/jos/article/view/6205/5361 >>>> >> >> -- >> Niels ten Oever, PhD >> Postdoctoral Researcher - Media Studies Department - University of >Amsterdam >> Affiliated Faculty - Digital Democracy Institute - Simon Fraser >University >> Non-Resident Fellow 2022-2023 - Center for Democracy & Technology >> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação >Getúlio Vargas >> Research Fellow - Centre for Internet and Human Rights - European >University Viadrina >> >> Vice chair - Global Internet Governance Academic Network (GigaNet) >> >> W: https://nielstenoever.net >> E: mail@nielstenoever.net >> T: @nielstenoever >> P/S/WA: +31629051853 >> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 >> >> Read my latest article on understanding power in standardization in >the Journal of Standardisation here: >https://journals.open.tudelft.nl/jos/article/view/6205/5361 >>
- [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