<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>


<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no"?>
<!-- Start each main section on a new page -->
<?rfc subcompact="no"?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-haleplidis-eodir-edu-processes-use-cases-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->
  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

  <title>IETF/IRTF Educational Processes</title>
    <!-- add 'role="editor"' below for the editors if appropriate -->

	<author fullname="Evangelos Haleplidis" initials="E.H." surname="Haleplidis">
			<organization>University of Piraeus</organization>
			<address>
				<postal>
					<street>Department of Digital Systems</street>
					<!-- Reorder these if your country does things differently -->
					<city>Piraeus</city>
					<region/>
					<code>18534</code>
					<country>Greece</country>
				</postal>
				<email>ehalep@unipi.gr</email>
				<!-- uri and facsimile elements may also be added -->
			</address>
		</author>
	<author fullname="Ignacio Castro" initials="I.C." surname="Castro">
			<organization>Queen Mary University of London</organization>
			<address>
				<postal>
					<street/>
					<!-- Reorder these if your country does things differently -->
					<city>London</city>
					<region/>
					<code/>
					<country>United Kingdom</country>
				</postal>
				<email>i.castro@qmul.ac.uk</email>
				<!-- uri and facsimile elements may also be added -->
			</address>
		</author>
  <author fullname="Dirk Kutscher" initials="D.K" surname="Kutscher">
    <organization>The Hong University of Science and Technology (Guangzhou)</organization>
    <address>
      <postal>
        <street/>
        <!-- Reorder these if your country does things differently -->
        <city>Guangzhou</city>
        <region/>
        <code/>
        <country>China</country>
      </postal>
      <email>ietf@dkutscher.net</email>
      <uri>https://dirk-kutscher.info</uri>
				<!-- uri and facsimile elements may also be added -->
			</address>
	</author>
  <author fullname="Apostolos P. Fournaris" initials="A.P" surname="Fournaris">
    <organization>ISI, R.C. ATHENA</organization>
    <address>
      <postal>
        <street>Security and Protection of Systems, Networks and Infrastructures</street>
        <!-- Reorder these if your country does things differently -->
        <city>Patras</city>
        <region/>
        <code>26504</code>
        <country>Greece</country>
      </postal>
      <email>fournaris@isi.gr</email>
				<!-- uri and facsimile elements may also be added -->
			</address>
	</author>
	

    <date year="2025"/>

    <area>edu</area>

    <workgroup>individual</workgroup>

    <keyword>Education</keyword>
    <keyword>RFC</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
        This document describes the basic use cases for the IETF to have a series of activities specifically tailored for educational and outreach purposes. 
        These uses cases cover areas such as academia, industry, policy makers or anyone interested in learning the necessary skillset required to easily integrate into the innerworking of the IETF.
      </t>
    </abstract>
  </front>

  <middle>
<section title="Introduction">
  <t>Lowering the barrier to entry in the process of reading and authoring RFCs will allow more participants to engage in the IETF/IRTF.</t>
  <t>Increasing the IETF document literacy and developing skills in IETF protocol development can lead to more implementations and interoperability testing, better knowledge of the Internet infrastructure, more secure deployments and more participation 
    and understanding in the IETF standardization process.</t>
  <t>In addition, showcasing IRTF procedures, scope and modus operandi, more participants from academia will provide a path for new academic institutions, faculty and students to attend, participate and share research work </t>
  <t>To this end this draft proposes the development of a number of educational material that can support a number of use cases described in this document.</t>

  <section title="Terminology and Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in <xref target="RFC2119" format="default">RFC2119</xref>.</t>
  </section>
</section>
<section title="Use cases">
  <section title="Academic Teaching">
    <t>The creation of a number of courses in academic institutions would enable students to be able to read, create, implement and debug RFC documents, and as such increase IETF document literacy and development experience.
       To assist in that process, the IETF can create a number of entry level educational RFCs that can then be used by academics to develop such courses.
       These RFCs can start with simple concepts that the IETF community agree that are important for students to understand.
       There are a couple of RFC types that can support this use case:
    </t>
    <t>
      <list style="sumbols">
        <t>A series of RFCs to be implemented. These RFCs can take into account different needs based on the various areas in the IETF, as each has its own ways of writing drafts.</t>
        <t>Additional RFC templates, with extra examples to write drafts.</t>
        <t>Drafts with errors that the students need to read, identify and provide solutions.</t>
        <t>Interoperability testing by providing RFCs with the code and requiring students to comply with existing code.</t>
      </list>
    </t>
  </section>
  <section title="Tutorial material">
    <t>Alongside academia, educational content can also be used by companies for internal training in the IETF and RFC process. 
       More complex educational RFCs, or even a curated list of RFCs, such as one provided in https://wiki.ietf.org/en/group/iab/RFC_Readability, 
       can be utilized alongside a number of targeted tutorial workshops to provide hands-on experience. These educational tutorials can focus on:
    </t>
    <t>
      <list style="symbols">
        <t>Training on implementation and interoperability of RFCs.</t>
        <t>Training on security for protocols.</t>
        <t>Training and emulation on the process of writing and discussing drafts, such as writing drafts, consensus mechanisms and the general IETF process.</t>
      </list>
    </t>
  </section>
  <section title="Policy material">
    <t>IETF processes can seem complex for new or non IETF members and can
   lead to misunderstanding on how and why some decisions are taken in IETF working
   groups. To address this, high-level overviews of the IETF could be complemented 
   with toy-examples of easy-to-understand cases of protocol development to highlight 
   the complexity, variety of design options and highlight how consensus can emerge 
   and the challenges in converging on to it.
    </t>
  </section>
  <section title="Summer schools">
    <t>
     This effort could help to prepare and conduct "summer school"-like training	
 	   events that include lecture material, practical work such as	
 	   implementing protocols and testing them in (virtualized) testbeds,	
 	   and training for authoring protocol specifications.	
    </t>
  </section>
  <section title="Research in the IETF">
    <t>ANRW has been successful into inviting researchers and research results in the IETF/IRTF and rasprg has conducted research on IETF processes and outcomes.</t>
    <t>The activities defined in this draft, could provide additional outreach efforts that showcase how research is performed in the IRTF, the scope of IRTF, drafts and RFC authoring for research in the IRTF process.</t>
  </section>
</section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request to IANA</t> 
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>While security considerations is a critical skill that is needed for a draft author, this document does not specify a new protocol and therefore has no need for security considerations.</t>
    </section>

   
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
    </references>
    <references title="Informative References">
      &RFC2119;
    </references>
    
  </back>
</rfc>
