idnits 2.17.1 draft-chowbat-irl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2017) is 2627 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Chowdhary 3 Intended Status: Informational NIXI 4 M. Batra 5 NIXI 6 N. Elkins 7 Inside Products 8 Expires: August 19, 2017 February 15, 2017 10 Internet Research Labs 11 draft-chowbat-irl-00 13 Abstract 15 Many people learn technical concepts best in a hands-on environment, 16 and Internet protocols and standards are no exception. Internet 17 Research Labs (IRL) will facilitate a platform and encourage the 18 technical community (seasoned professionals and newcomers alike) to 19 discuss, collaborate, design and develop utilities, ideas, sample 20 code and solutions that show practical implementations (Proof of 21 Concept) of existing IETF standards. These labs may also be used by 22 the IETF Mentoring Program and/or EDU teams for hands-on training to 23 mentees or newcomers. This base draft intends to provide a high-level 24 overview of the concept of Internet Research Labs in terms of 25 objectives, requirements, challenges and deliverables without going 26 into details of a specific lab, technology or an IETF Working Group 27 (WG). After this draft matures and gains traction within the IETF 28 community, we foresee more and more Internet drafts for the specific 29 labs. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2017 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.2 IRL Terminology . . . . . . . . . . . . . . . . . . . . . . 5 72 1.2 Objectives of IRL . . . . . . . . . . . . . . . . . . . . . 5 73 2 IRL Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1 Possible Composition . . . . . . . . . . . . . . . . . . . . 6 75 2.1.1 Hardware requirements . . . . . . . . . . . . . . . . . 6 76 2.1.2 Software requirements . . . . . . . . . . . . . . . . . 7 77 2.1.3 IRL portal with WIKI pages . . . . . . . . . . . . . . . 7 78 2.2 Location . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 2.3 Mode of operation . . . . . . . . . . . . . . . . . . . . . 7 80 2.4 High Availability . . . . . . . . . . . . . . . . . . . . . 7 81 2.5 Access to IRL . . . . . . . . . . . . . . . . . . . . . . . 8 82 2.6 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 2.7 Disadvantages or Challenges . . . . . . . . . . . . . . . . 9 84 2.8 Tools used . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 2.8.1 Design Tools . . . . . . . . . . . . . . . . . . . . . . 9 86 2.8.2 Network Analysis tools . . . . . . . . . . . . . . . . . 9 87 2.8.3 Software development / POC tools . . . . . . . . . . . . 9 88 2.8.4 Cloud / Virtualization Tools . . . . . . . . . . . . . . 9 89 2.8.5 MOOC tools . . . . . . . . . . . . . . . . . . . . . . . 10 90 2.9 How to own and operate an IRL . . . . . . . . . . . . . . . 10 91 2.10 How to obtain access to an IRL . . . . . . . . . . . . . . 10 92 2.11 Next Steps for an IRL . . . . . . . . . . . . . . . . . . . 10 93 2.11.1 Mailing list . . . . . . . . . . . . . . . . . . . . . 10 94 2.11.2 Community feedback . . . . . . . . . . . . . . . . . . 10 95 2.12 Which specific IRLs to start with . . . . . . . . . . . . . 11 96 3 IRL Deliverables . . . . . . . . . . . . . . . . . . . . . . . 11 97 3.1 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . 11 98 3.2 New / Improved I-D's . . . . . . . . . . . . . . . . . . . 11 99 3.3 Highly skilled Protocol Engineers . . . . . . . . . . . . . 11 100 3.4 Bug reporting and tracking system . . . . . . . . . . . . . 11 101 3.5 New tools and softwares . . . . . . . . . . . . . . . . . . 11 102 3.6 Documentation . . . . . . . . . . . . . . . . . . . . . . . 12 103 4 IRL Future Work . . . . . . . . . . . . . . . . . . . . . . . . 12 104 5 Protection of lab IPR . . . . . . . . . . . . . . . . . . . . . 13 105 6 Relation between IRL and IETF Hackathon . . . . . . . . . . . . 13 106 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 107 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 108 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 110 9.2 Informative References . . . . . . . . . . . . . . . . . . 14 112 1 Introduction 113 For a deep understanding of Internet standards, protocols, 114 technologies and concepts (as well as latest issues and trends around 115 them), the available learning tools, resources, information base, 116 events and meetups at the disposal of the technical Internet 117 community are currently scattered in many places. Some tools / 118 resources even require payment. 120 Some of these resources are the IETF and IRTF websites, the IETF blog 121 [IETF blog], the IETF Journal [IETF Journal], videos on content 122 sharing websites like YouTube [Youtube], self-paced free and paid 123 courses on Massive Open Online Courses (MOOCs) like Coursera 124 [Coursera], Udemy [Udemy], Udacity [Udacity] and edX [edX], and last 125 but not the least: hundreds of thousands of discussion threads in the 126 IETF, IAB and IRTF mailing lists. 128 Another challenge is that IETF RFCs, whether Standards, Best Current 129 Practices (BCPs), Informational or Experimental, are often far too 130 technical and not easily digestible for novices (and sometimes even 131 for experienced professionals). Combine that with the fact that many 132 people learn technical concepts best in a hands- on environment, 133 there is a clear gap as well as opportunity for a lab environment. 134 This is where we see that Internet Research Labs (IRL) will bridge 135 the gap. 137 Internet Research Labs will facilitate a free and open source 138 platform, and encourage the technical community (seasoned 139 professionals and newcomers alike) to discuss, collaborate, design 140 and develop utilities, tools, ideas, sample code and solutions that 141 show practical implementations (Proof of Concept) of IETF standards. 142 Future IRL work may involve Internet-related standards produced by 143 other standards bodies such as IEEE [IEEE], ISO [ISO], ITU [ITU], W3C 144 [W3C], OASIA [OASIS]. 146 IRL labs are intended to be utilized by the technical Internet 147 community across the globe for hands-on learning of IETF protocols 148 either as RFCs or drafts. They will also in turn act as an enabler 149 and a playground to perform research, experimentation or prototyping 150 of "new" ideas. Such new ideas will in turn lead to new Internet 151 drafts. 153 A sample scenario for this may be hands-on implementation / testing 154 of the Internet draft for TLS [Upcoming-TLS] version (1.3) in 155 something called TLS Internet Research Lab, along with parallel 156 implementations of previous TLS versions (1.1, 1.2); testing of new 157 (1.3) protocol features, noting and documenting (e.g. in WIKI pages 158 for TLS IRL) the deviations from previous protocol versions etc. 160 To start with, each IRL lab may work under the guidance of one IETF 161 WG chair. These labs may also be used by the IETF Mentoring Program 162 and/or EDU teams for hands-on learning or training for mentees or 163 newcomers. 165 1.1 Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 1.2 IRL Terminology 173 EDU - The IETF Education (EDU) Team 175 IRL - Internet Research Labs 177 POC - Proof of Concept 179 AAA - Authentication, Authorization and Accounting 181 IPR - Intellectual Property Rights 183 UTA - Using TLS in Applications 185 CLI - Command Line Interface 187 HA - High Availability 189 GPL - GNU General Public License 191 BSD - Berkeley Software Distribution License 193 DOS / DDOS - Denial of Service / Distributed Denial of Service 195 RADIUS - Remote Authentication Dial-In User Service 197 TACACS - Terminal Access Controller Access-Control System 199 SCM - Source Code Management 201 1.2 Objectives of IRL 203 1. To facilitate a free, open source and hands-on learning platform 204 at the disposal of the Internet community in order to explore 205 "existing" Internet standards, protocols and technologies. 207 2. To facilitate a hands-on platform for research, experimentation 208 and innovation on "new" ideas or Internet Protocols; or on "improved" 209 versions of existing Internet Protocols / Standards. These labs may 210 be termed as "Next Generation IRL Labs", and may or may not be tied 211 to IETF Working Group(s). 213 3. To facilitate an environment where parallel implementations of 214 upcoming (e.g. a proposed Internet Draft) and existing protocol 215 versions can be simulated / deployed; thereby enabling the Internet 216 community to analyze similarities and differences, test new version 217 features, "report" (see section 3.4) and "document" (see section 3.5) 218 improvements, design / implementation defects, and so on. 220 4. To complement the work and mandate of the IETF Hackathon [IETF 221 Hackathon] by extending the activity "Encouraging developers to 222 discuss, collaborate and develop utilities, ideas, sample code and 223 solutions that show practical implementations of IETF standards" to 224 24 x 7 and 365. 226 5. To facilitate testbeds for researching and developing Proof-of- 227 Concepts (POCs) for IETF "Best Current Practices" series RFCs (both 228 existing and future BCPs); as well as taking protocol best practices 229 (BCPs) to a new level. POCs may be in form of sample code. 231 6. To facilitate testbeds for researching and developing POCs for 232 IETF "Experimental" series RFCs, where they can be tested, validated, 233 and used for designing new ideas or protocols. 235 7. As there are many projects and tools in the IETF, IRLs may 236 facilitate an environment to develop utilities and automate various 237 IETF activities. For example, mailing lists search, IETF datatracker 238 related activities (e.g. uploading an Internet Draft / RFC, Searching 239 an RFC, co-relating RFCs, author search etc.), perform analytics on 240 RFCs / IDs / authors and many more. 242 2 IRL Considerations 244 The devil is in the details. Here we attempt to provide a 360- 245 degree view of considerations for transforming the idea of Internet 246 Research Labs to a successful reality. 248 2.1 Possible Composition 250 We expect that each individual lab will use the items in this section 251 as a template to describe their own lab. 253 2.1.1 Hardware requirements 255 There are no specific "One size fits all" hardware requirements for 256 each of the IRL labs. Hardware will vary from lab to lab. 258 2.1.2 Software requirements 260 There are no specific "One size fits all" software requirements for 261 each of the IRL labs. Software will vary from lab to lab. 263 2.1.3 IRL portal with WIKI pages 265 A web portal (website) needs to be in place that caters to all 266 aspects of IRL labs including but not limited to topics and 267 considerations as mentioned in this Internet draft. It should be 268 decided beforehand as to whose will be responsible for operating and 269 maintaining the IRL web portal, helping and authorizing volunteer 270 organizations to start running IRL labs, moderating access to 271 requests to IRL labs, and housekeeping activities. One candidate that 272 naturally comes to mind is the ISOC [Internet Society] but other 273 options are also open. 275 The IRL web portal should also have a detailed documentation for its 276 prospective users and the Internet community at large. Further, as 277 specific IRL labs are established in due course of time, they should 278 place their respective documentation at this portal. 280 2.2 Location 282 Labs may be located at academic and/or research institutions who may 283 volunteer to run it. They may also be at and run by private 284 companies. Further, the labs may be hosted on physically 285 infrastructure (datacenter, servers, routers, switches etc.) or 286 located in the public or private clouds. For example, an IoT Internet 287 Research Lab may be hosted on Amazon Web Services IoT [AWS IoT]. 289 2.3 Mode of operation 291 To start with, each IRL lab may work under the guidance of one IETF 292 WG chair. In due course of time, when a specific lab matures with 293 regard to features, scope and users, it may be utilized by more than 294 one IETF WG (within same or possibly across IETF areas with cross- 295 functional requirements). However, the primary guide of the lab may 296 still be the original IETF WG chair. As an example, a TLS IRL lab may 297 start operating under the guidance of TLS WG chair. Later, when TLS 298 IRL lab matures, it may also be utilized by related UTA WG (under ART 299 area) via one of its chairs. 301 In a nutshell, the IETF WGs involved will be the leadership of the 302 lab via their respective chairs. The teams from IETF EDU and 303 Mentoring may be involved in overall coordination. 305 2.4 High Availability 306 A specific IRL may initially take some time in transforming from a 307 concept to reality. Hence, we expect that a specific pilot IRL will 308 be set up at a single location / single cloud volunteered by an 309 academic / research institution, or a private company. In due course 310 of time, depending upon its success and popularity, a specific IRL 311 lab dedicated to an area (e.g. TLS) may be replicated to more than 312 one physical location or even multiple clouds (e.g. AWS [AWS] or 313 Microsoft Azure [MS-Azure]). This may provide a form of High 314 Availability. But, this is a topic for a later discussion. 316 2.5 Access to IRL 318 Labs may be made available to its intended users (Internet community) 319 as a web application (website), or via software programs on popular 320 Operating Systems like Windows, Mac OS etc. Due to the ubiquitous 321 nature of web browsers and non-dependence on any particular Operating 322 System, they are also a strong and natural candidate for accessing 323 IRLs. Labs may also be made available via command line interface (for 324 Unix based systems) or via Remote Desktop (for Windows based 325 systems). A combination of above methods may also be utilized. The 326 decision is left to the designer or implementor of individual labs, 327 as well as to to the leadership of the IETF WG tied to the individual 328 labs. 330 Please see the Security considerations(section 7) on security aspects 331 of the IRLs. 333 2.6 Advantages 335 1. Deeper understanding of "existing" IETF standards and protocols in 336 a hands-on, self-paced learning and training environment. 338 2. Ready-to-use platform to research, experiment and collaborate on 339 the development, design, implementation etc. of new ideas, protocols, 340 "use-cases", utilities, Proof-of-concepts (POC) of "new / future" 341 Internet standards and protocols (Next Generation IRL Labs). 343 3. Ready-to-use platform for technical Internet community to perform 344 hawk-eye analysis, testing, "measurements", performance analysis and 345 review of proposed or under development IETF Internet drafts. 347 4. Ready-to-use platform to perform various types of testing on 348 Internet drafts proposed or under development. The types of testing 349 include but are not limited to Performance testing, Security testing, 350 Measurements testing etc. 352 5. A hands-on and practical platform to augment / complement / test 353 the discussion threads going on in specific IETF WGs. 355 6. A platform to simulate IETF Hackathon work objectives round the 356 clock throughout a year 358 7. Facilitator to develop and/or improve protocol Best Current 359 Practices or BCPs. 361 2.7 Disadvantages or Challenges 363 1. Resources need to be devoted to this effort to jump start it. 365 2. Little economic incentive or business case in volunteering for or 366 setting up an IRL by an academic / research institution or a private 367 company. For example, if IRL labs are setup in a public cloud, the 368 real challenge is "Who will pay for cloud services?" 370 2.8 Tools used 372 Many tools can be used for the IRL labs at design, development and 373 implementation levels. A non-exhaustive list is attempted below: 375 2.8.1 Design Tools 377 NS3 [NS3] or GNS3 [GNS3] tools may be used to design an IRL Routing 378 lab for some Working Group under IETF Routing area, which may be 379 utilized by the Internet community to simulate or test existing or 380 upcoming version or routing protocols like OSPF, IS-IS etc. 382 2.8.2 Network Analysis tools 384 An open source packet capture and analysis tool such as Wireshark 385 [Wireshark] may be used. The Wireshark core developers may 386 collaborate on the development and testing of new protocol dissectors 387 as was done successfully for many protocols including the TLS 1.3 388 while still in draft stage. 390 2.8.3 Software development / POC tools 392 Internet community members may collaborate on the development of open 393 source Software or POC tools, which may be hosted on distributed 394 version control and source code management (SCM) systems like 395 [Github] , [BitBucket] etc. 397 Standalone scripts or programs developed in languages like Unix 398 Shell, Python, Perl, Ruby etc. may also be used for POC of existing 399 Internet standards or Internet drafts. 401 2.8.4 Cloud / Virtualization Tools 402 In cases where IRL labs are hosted on a public cloud platform, a raw 403 Virtual Machine Instance may be continuously customized until it is 404 ready to become a template for an IRL lab. At this point, a template 405 may be created from the customized Virtual Machine instance. An 406 example of customization for a TLS 1.3 IRL lab hosted on cloud would 407 be installing Wireshark, loading custom developed protocol 408 dissectors, generating sample traces / packets etc., and then 409 creating a template. Later, as many number of VM (Virtual Machine) 410 instances can be launched from the Virtual Machine template. 412 Similarly private clouds may also be used. 414 2.8.5 MOOC tools 416 MOOC tools such as Coursera [Coursera] or eDX [eDX] may be utilized 417 by the Internet community to complement the IRL labs by facilitating 418 step-by-step self-paced videos for learning. Obviously, voluntary 419 effort needs to be put-in to develop videos that show IRL usage. 421 2.9 How to own and operate an IRL 423 A detailed step-by-step tutorial for prospective academic, research 424 or private organizations on "How to own and operate an IRL" needs be 425 made available at IRL portal WIKI as mentioned in section 2.1.3 427 2.10 How to obtain access to an IRL 429 The minimal high-level sequence of steps involved may be: 431 1. Open IRL portal 432 2. Create user profile 433 3. Choose particular IRL(s) of interest 434 4. Wait for moderator approval 435 5. Agree to IRL "terms of use" 436 6. Start using IRL(s) 438 A detailed step-by-step tutorial for technical Internet community on 439 "How to obtain access to an IRL" needs to be made available at IRL 440 portal WIKI as mentioned in section 2.1.3 442 2.11 Next Steps for an IRL 444 2.11.1 Mailing list 446 A new IETF mailing list may be created (or an existing one reused) to 447 share experiences and refine IRL labs. 449 2.11.2 Community feedback 450 Community feedback is also very important to improve the IRL lab 451 experience for its users. Feedback may be provided on IRL mailing 452 list or via feedback link on the IRL web portal. 454 2.12 Which specific IRLs to start with 456 There are many IETF WGs that may benefit from an IRL. So it all 457 depends on who (e.g. IETF WG and/or an Academic / Research institute) 458 takes on the initiative first. 460 3 IRL Deliverables 462 A non-exhaustive list of envisaged IRL deliverables is attempted 463 below. Further, the final deliverables may vary depending upon the 464 specific IRL in question. 466 3.1 Prototypes 468 A new idea or Internet protocol may be proposed / designed using 469 "Next Generation IRL labs". This may be in form of a prototype and/or 470 POCs. 472 3.2 New / Improved I-D's 474 New ideas / Internet protocols or enhancements to existing Internet 475 protocols / RFCs may be proposed as new Internet Drafts (I-D's) by 476 Internet community. 478 3.3 Highly skilled Protocol Engineers 480 Needless to say, an important deliverable for IRL labs would be 481 highly skilled protocol engineers on specific Internet protocols and 482 technologies. 484 3.4 Bug reporting and tracking system 486 An important envisaged feature of IRL labs would be a Bug reporting 487 and tracking system (like [Bugzilla]) similar to the ones utilized in 488 commercial software products. 490 Software / design bugs in an RFC / I-D as well as proposed request 491 for enhancements may be logged under this system.This model is also 492 bound to take some load off the IETF mailing lists, as well as 493 improve quality of existing (RFCs) and new (I-D) documents. 495 3.5 New tools and softwares 497 Tools are a critical mechanism through which IETF work can be done 498 with less amount of effort. Some IETF tools (e.g. datatracker, 499 xml2rfc, etc.) are at a high level of maturity and deployment. Many 500 other tools have either not yet reached a maturity suitable for wide- 501 spread use or struggle to spread knowledge of their existence and 502 use. Still other potential tools are merely partially brainstormed 503 ideas looking for others motivated to discuss, implement and try. IRL 504 aims to overcome these limitations and facilitate a platform to 505 produce new as well as refined versions of existing tools. Another 506 IRL aim is to provide a mechanism via its web portal to spread 507 knowledge of experimental tools to those interested and get feedback 508 on those tools. It also provides time and focus for finding others 509 interested in particular tool ideas and discussing how to progress 510 them. 512 3.6 Documentation 514 Finally, each IRL will document its specific working model, ways to 515 operate IRL, ways to acquire access to IRL, terms of use, related 516 IETF Working Groups and so on. This may be done under IRL portal with 517 WIKI pages (see section 2.1.3) 519 4 IRL Future Work 521 1. As mentioned in Section 1 :Introduction, IRLs will mainly focus on 522 IETF Internet standards to start with. However, future work may 523 incorporate the work of other standards bodies such as IEEE [IEEE], 524 ISO [ISO], ITU [ITU], W3C [W3C], or OASIS [OASIS]. 526 2. As mentioned in Section 2.3: IRL mode of operation, When an IRL 527 lab becomes mature with regard to features and scope, it may be 528 utilized by more than one IETF WG (possibly across IETF areas). 529 However, the primary leadership of lab may still be the starting IETF 530 WG chair. Again, in a few years, assuming success of the IRL concept, 531 an Area Director might also pitch-in for the work of IRLs. 533 3. As mentioned in section 2.4 High Availability, depending upon 534 success of pilot IRL labs, an IRL lab dedicated to an area or 535 protocol (e.g. TLS) may be replicated to more than one physical 536 location / cloud. This will provide a form of High Availability (HA). 538 4. Another possibility is to rather than implementing, testing, 539 simulating or discussing the work of an existing IETF WG, but create 540 an advanced general purpose Next Generation IRL Labs on which 541 research on almost any IETF area or WG topic or protocol can be done. 542 Obviously, creating such a big and advanced lab is a herculean effort 543 and solicits voluntary effort from a large academic, research or 544 private organization. 546 5. Initially, access to IRL labs may be via CLI. In due course of 547 time, depending on the success and popularity of the labs, access to 548 IRL labs may be provided via GUI, API / Web Services, and Mobile Apps 549 (Android, iOS, Windows, Blackberry etc.). 551 5 Protection of lab IPR 553 Legal issues around IRLs should also be taken care of and a Legal 554 framework should also be put in place to protect IRL IPR, mainly 555 copyrights. Although IRLs are intended to be open source and free of 556 cost to the Internet community, their abuse and misuse MUST be 557 protected. The IRL licensing terms may be set either using GPL or BSD 558 open licensing terms. A "terms of use" document should be created 559 that every intended user of IRL must adhere to before being provided 560 access to an IRL lab. It may be decided whether "terms of use" is 561 common for all IRL labs, or separate for each of IRL labs. 563 6 Relation between IRL and IETF Hackathon 565 IRL aims to complement the work of [IETF Hackathon] rather than 566 competing with it or duplicating it. In fact IRL builds on the 567 objective of IETF Hackathon: "To encourage developers to discuss, 568 collaborate and develop utilities, ideas, sample code and solutions 569 that show practical implementations of IETF standards." 571 This makes sense as IETF Hackathons are organized only three times 572 per year as are IETF meetings. The IRL concept goes a step further 573 because once fully implemented IRLs are "IETF hackathon 365 days a 574 year." 576 7 Security Considerations 578 The labs are specialized tools with an intended user base (technical 579 Internet community), access to whom should be moderated instead of 580 being available to anyone on Internet. Rather, a potential user 581 should be able to fill-up a form on IRL web portal (see section 2.11) 582 furnishing his/her details and affiliation to an organization / 583 institution, and justification/motivation for requesting access to 584 specific IRL lab(s). Based on the user's request, IRL moderator may 585 or may not provide access to the lab(s). 587 Access to IRL labs may be directly via the Internet or via a VPN. 588 However, if no VPN is employed, strong security controls 589 (authentication / authorization / accounting) must be in place to use 590 IRL, and cryptographic protocols e.g. SSH may be used to access IRL 591 resources. A firewall may be in place to control access to IRL 592 resources and should implement access control lists, DOS / DDOS 593 protection etc. 2-factor authentication may also be employed to 594 further secure access to the IRL labs after user registration. 596 All access to IRLs must be logged. A RADIUS / TACACS server may be 597 employed for Authentication, Authorization and Accounting (AAA) 598 purposes. 600 Another important security consideration for IRLs is that if the IRL 601 access portal and/or specific IRLs are implemented as Web 602 Applications, their web pages should not be indexable by search 603 engines. This may effectively make the IRL web portal available to 604 only its intended user community. 606 8 IANA Considerations 608 There are no IANA considerations. 610 9 References 612 9.1 Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, DOI 616 10.17487/RFC2119, March 1997 618 9.2 Informative References 620 [IETF blog] "IETF blog", https://www.ietf.org/blog 622 [IETF Journal] "IETF Journal", https://www.ietfjournal.org 624 [Youtube] "Youtube", https://www.youtube.com 626 [Coursera] "Coursera | Online Courses From Top Universities. Join for 627 Free", https://www.coursera.org 629 [Udemy] "Udemy Online Courses - Learn Anything, On Your Schedule", 630 . 632 [Udacity] "Udacity - Free Online Classes & Nanodegrees", 633 https://www.udacity.com 635 [edX] "edX | Free online courses from the world's best universities", 636 https://www.edx.org 638 [IEEE] "IEEE - The world's largest technical professional 639 organization dedicated to advancing technology for the benefit of 640 humanity.", https://www.ieee.org 642 [ISO] "ISO - International Organization for Standardization", 643 http://www.iso.org 645 [ITU] "ITU: Committed to connecting the world", http://www.itu.int 647 [W3C] "World Wide Web Consortium (W3C)", https://www.w3.org 649 [OASIS] "OASIS | Advancing open standards for the information 650 society", https://www.oasis-open.org . 652 [Upcoming-TLS] "The Transport Layer Security (TLS) Protocol Version 653 1.3", https://datatracker.ietf.org/doc/draft-ietf-tls-tls13 . 655 [IETF Hackathon] "IETF Hackathon", https://www.ietf.org/hackathon 657 [Internet Society] "Internet Society | Internet Issues, Technology, 658 Standards, Policy, Leadership", http://www.internetsociety.org 660 [AWS IoT] "AWS IoT - Amazon Web Services", https://aws.amazon.com/iot 662 [AWS] "Amazon Web Services (AWS) - Cloud Computing Services", 663 https://aws.amazon.com 665 [MS-Azure] "Microsoft Azure: Cloud Computing Platform & Services", 666 http://azure.microsoft.com 668 [NS3] "ns-3", https://www.nsnam.org 670 [GNS3] "GNS3 | The software that empowers network professionals", 671 https://www.gns3.com 673 [Wireshark] "Wireshark - Go Deep.", https://www.wireshark.org 675 [Github] "How people build software - GitHub", https://github.com 677 [BitBucket] "Bitbucket | The Git solution for professional teams", 678 https://bitbucket.org 680 [Bugzilla] "Home :: Bugzilla :: bugzilla.org", 681 https://www.bugzilla.org 683 Authors' Addresses 685 Harish Chowdhary 686 National Internet Exchange of India (NIXI) 687 India 688 Email: harish@nixi.in 689 Mohit Batra 690 National Internet Exchange of India (NIXI) 691 India 692 Email: mohit@nixi.in, mohit4677@gmail.com 694 Nalini Elkins 695 Inside Products, Inc. 696 U.S.A. 697 Email: nalini.elkins@insidethestack.com