idnits 2.17.1 draft-elkins-ietf-remote-participation-hubs-01.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 (June 15, 2017) is 2508 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 N. Elkins 3 Intended Status: Informational Inside Products 4 H. Chowdhary 5 NIXI 6 T. Santosh 7 MEITY 8 V. Hegde 9 Independent 10 Expires: December 17, 2017 June 15, 2017 12 Remote Participation Hubs 13 draft-elkins-ietf-remote-participation-hubs-01 15 Abstract 17 For many reasons, remote participation in IETF meetings has increased. 18 As the Internet grows, so does the participation by engineers worldwide. 19 Remote participation with more than one person is considered a hub. 21 Three types of remote hubs are defined. Each has its own 22 characteristics. 24 - Remote Participation Hubs 25 - Remote Viewing Hubs 26 - Enduring Local Meetups 28 This document defines a Remote Participation Hub (RPH). Other documents 29 define the other types of hubs. A common structure of sections will be 30 used as far as possible for all hub types. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering Task 38 Force (IETF), its areas, and its working groups. Note that other groups 39 may also distribute working documents as 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 material 44 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 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 Copyright and License Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the document 54 authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 57 Relating to IETF Documents (http://trustee.ietf.org/license-info) in 58 effect on the date of publication of this document. Please review these 59 documents carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this document 61 must include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2 Purpose of Remote Participation Hubs (RPH) . . . . . . . . . . 4 70 3 Relationship to IETF Meetings . . . . . . . . . . . . . . . . . 4 71 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.3 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4 Functioning at Remote Participation Hubs . . . . . . . . . . . 5 75 4.1 Coordinators . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.2 Session Management . . . . . . . . . . . . . . . . . . . . . 5 77 4.3 Anti-Harrassment Procedures . . . . . . . . . . . . . . . . 6 78 4.4 Adherence to Proper Procedures . . . . . . . . . . . . . . . 6 79 4.5 Recording . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.6 Technical Functioning . . . . . . . . . . . . . . . . . . . 6 81 4.6.1 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 6 82 4.6.2 Physical Room Layout . . . . . . . . . . . . . . . . . . 6 83 4.6.3 Audio . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 4.7 Responsibilities/Functions of the RPH Coordinators . . . . . 7 85 4.8 Language of the communication of RPH . . . . . . . . . . . . 7 86 5 Remote Support Tools . . . . . . . . . . . . . . . . . . . . . 8 87 5.1 Communications . . . . . . . . . . . . . . . . . . . . . . . 8 88 6 IETF Secretariat Support . . . . . . . . . . . . . . . . . . . . 8 89 6.1 Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 6.2 Wiki / Web Page . . . . . . . . . . . . . . . . . . . . . . 8 91 6.3 Registration . . . . . . . . . . . . . . . . . . . . . . . . 8 92 7 IETF Liaison . . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 8 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 9 Mentoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 10 Legal Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 96 10.1 IETF Rights in Contributions . . . . . . . . . . . . . . . 9 97 10.2 Note Well . . . . . . . . . . . . . . . . . . . . . . . . . 9 98 10.3 IETF Brand / Logo . . . . . . . . . . . . . . . . . . . . . 10 99 11 Security Considerations . . . . . . . . . . . . . . . . . . . 10 100 12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 101 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 102 13.1 Normative References . . . . . . . . . . . . . . . . . . . 10 103 13.2 Informative References . . . . . . . . . . . . . . . . . . 10 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 106 1 Introduction 108 For many reasons, remote participation in IETF meetings has 109 increased. As the Internet grows, so does the participation by 110 engineers worldwide. Remote participation with more than one person 111 is considered a hub. 113 Three types of remote hubs are defined. Each has its own 114 characteristics. 116 - Remote Participation Hubs (RPH) 117 - Remote Viewing Hubs (RVH) 118 - Enduring Local Meetups (ELM) 120 This document defines the nature of a Remote Participation Hub. A 121 Remote Participation Hub is functionally equivalent to an IETF face- 122 to-face meeting. A Remote Viewing Hub is less restrictive and may 123 be used for outreach purposes. If an attendee at a Remote Viewing 124 Hub wishes to participate in a working group session, the attendee 125 may do so as an individual remote participant. An Enduring Local 126 Meetup is not necessarily at the same time as an IETF face-to-face 127 meeting and may do activities at its own discretion. 129 1.1 Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2 Purpose of Remote Participation Hubs (RPH) 137 The purpose of a Remote Participation Hubs (RPH) is to provide a 138 gathering space to participate in one or more Working Groups 139 sessions, Hackathons, or IETF Plenaries scheduled at an ongoing IETF 140 meeting which is being held at the same time. 142 Participation in an RPH is to be considered as functionally 143 equivalent to attendance at an IETF meeting face-to-face. This means 144 that all legal and session management procedures must be followed 145 (including NOTE-WELL and blue sheets). The specific details will be 146 covered in the relevant section below. 148 One or more onsite coordinators MUST be present. 150 3 Relationship to IETF Meetings 152 The RPH will be at the time of the IETF meeting. An RPH may decide 153 to have multiple rooms with multiple simultaneous sessions mirroring 154 those at the face-to-face meeting or it may choose to have a single 155 room with selected Working Group sessions. This is at the discretion 156 of the RPH. The sessions to be held at the RPH must be communicated 157 to the IETF Secretariat for posting in the Wiki. 159 It SHOULD also mention any restrictions such as: 161 1. Only employees of the hosting organization are allowed 162 2. Restrictions on carrying laptops or recording devices 163 3. Specific proof of identity required to access the premises 165 3.1 Registration 167 An attendee at an RPH MUST register and this must be noted by the 168 IETF Secretariat. This MUST be checked by the onsite co-ordinator. 170 There may be an online attendance portal having blue sheets provided 171 by IETF Secretariat. The following information may be asked: 173 a. Name 174 b. Organization 175 c. Registration Number 176 d. Location 178 3.2 Cost 180 There may be a charge to attend an RPH. This may be subsidized by 181 entities wishing to do so. 183 3.3 Timing 185 An RPH MUST be designated at a minimum of 30 days before the IETF 186 meeting. 188 4 Functioning at Remote Participation Hubs 190 4.1 Coordinators 192 At least one or preferably two (2) coordinators MUST be appointed by 193 the RPH. Contact information MUST be provided to the IETF 194 Secretariat for inclusion in the calendar / Wiki. 196 4.2 Session Management 198 Session management MUST be done as described in RFC2418: IETF 199 Working Group Guidelines and Procedures [RFC2418] Section 3.3 Session 200 Management. 202 NOTE Well MUST be shown at the start of the meeting. Mike queuing 203 discipline and fairness MUST be enforced by on-site coordinator(s). 205 4.3 Anti-Harrassment Procedures 207 Anti-Harrssment procedures MUST be followed according to: RFC7776: 208 IETF Anti-Harassment Procedures [RFC7776]. 210 4.4 Adherence to Proper Procedures 212 The coordinators are responsible to maintain adherence to proper 213 legal, registration, and other procedures exactly as would be true of 214 a live IETF meeting. 216 Failing to do so will mean that the RPH may not obtain approval in 217 the next cycle. 219 4.5 Recording 221 All activity at an RPH MUST be recorded for anyone wishing to view 222 activity at a later date (and must be archived). 224 4.6 Technical Functioning 226 In order for groups of individuals to remotely participate in the 227 meetings, there are certain technical requirements that must be met 228 to ensure a non-disruptive and trouble-free meeting experience. This 229 document outlines the proper configuration for remote participation 230 to various conferences throughout the world. 232 4.6.1 Bandwidth 234 Adequate and good quality wired bandwidth is extremely important in 235 order to have audio, video and presentations properly shared in both 236 directions. 238 4.6.2 Physical Room Layout 240 The layout of the meeting room is important in order for everyone to 241 actively participate in the meeting. It is suggested that the 242 coordinators keep the following points in mind when selecting and 243 setting up the venue: 245 a. Allow for plenty of time to set up and test the equipment prior to 246 your first meeting. 248 b. Each attendee will need at least one power port. 250 c. Heating and cooling can be a major factor. Note that projectors 251 and TVs can add to the room's heat. 253 d. Take note of the location and quantity of the power and network 254 connection points. 256 4.6.3 Audio 258 A sound system that is properly sized to the audience is important. 259 This will allow everyone to hear the local and remote audiences, 260 speakers and presenters. The coordinators may wish to consider using 261 a robust audio system and a qualified technical person to install and 262 operate the equipment throughout the duration of the meeting. 264 4.7 Responsibilities/Functions of the RPH Coordinators 266 1. To Support the participants on how to utilize a remote hub. 268 2. Take a lead in the facilitation of sessions ensuring continuity of 269 the remote session. 271 3. Take the attendance along with the IETF remote registration number 273 4. Support the participants in communication with remote members, 274 regarding session and activities in a working group. 276 5. Submission of attendance to the IETF Seretriate. 278 6. Set up the space with the appropriate furniture, equipment and 279 materials for the IETF WG session each day. 281 7. Oversee the documentation process through photos and help keep an 282 organised archive for the sessions. 284 8. Co-ordinate volunteers for the participation programme. 286 9. Assist with the monitoring and evaluation of identified elements 287 of the remote participation programme and ensure that data is entered 288 onto the metric system as required. 290 4.8 Language of the communication of RPH 292 The primary language of the RPH is "ENGLISH". This must be 293 communicated to the participants in advance. The RPH may choose to 294 have a translator present for local language support. 296 5 Remote Support Tools 298 All tools MUST provide an English language interface. Optionally, 299 other languages MAY be used as convenient. 301 5.1 Communications 303 The remote communications methods today include Jabber and MeetEcho. 304 These shall be used. If new methods arise, then they may be 306 6 IETF Secretariat Support 308 6.1 Calendar 310 The IETF Secretariat will maintain a calendar of locations and times 311 for all RPH's for that IETF meeting. Historical information MUST be 312 kept according to the section on Metrics. 314 6.2 Wiki / Web Page 316 The IETF Secretariat will maintain a Wiki or web page indicating 317 which working group sessions are being held at the RPH. This 318 information MUST be kept historically according to the section on 319 Metrics. 321 6.3 Registration 323 The IETF Secretariat MUST account for all registrations at an RPH. 324 Historical information MUST be kept according to the section on 325 Metrics. 327 7 IETF Liaison 329 Two people to act as a liaison and to coordinate the RPH efforts will 330 be appointed. One will be nominated by the IAOC. One will be 331 nominated by the IAB. 333 The tasks to be performed by the liaison will be: 335 - approve the RPH, 336 - approve the coordinators for the RPH, 337 - provide training for the RPH coordinators 338 - approve the name and if the IETF logo / brand are being used 339 - discuss with the IETF trustees the use of the IETF brand / logo 340 - ensure that proper procedures are being followed at an RPH. 342 8 Metrics 344 The following metrics will be kept for RPH's: 346 - Location (Economy / name of country) 347 - Name 348 - Name of coordinators 349 - Number of attendees registered 350 - Number of sessions 351 - The Working Groups followed 352 - Number of participants in each session (regardless of time) 354 Metrics may Include the following questions to the RPH Coordinators. 355 Potential Metrics Survey Questions may be: 357 - How many RPHs were there and in which Location? 358 - How many people participated at the RPH? 359 - What sessions did they attend? 360 - Were there other associated activities in the RPH? 361 - Did any participant ask questions or make relevant comments? 362 - Were there any difficulties experienced? 363 - How might we (IETF) make it easier? 364 - How would you suggest we acknowledge the attendance? 365 - Will there be one or more RPHs for future IETF meetings? 366 - Will there be activities in the location between two IETF meetings? 367 - If yes, what kind of activities, are planned? 369 9 Mentoring 371 The RPH will not provide special mentoring. The mentoring may be 372 provided if there is a local group willing to provide it. However, 373 the specification of that is outside the scope of this document. 375 10 Legal Issues 377 10.1 IETF Rights in Contributions 379 Participation in a RPH will be considered a contribution to the IETF 380 and all issues of Intellectual Property Rights, confidentiality, 381 trade marks, etc. shall be governed by the appropriate section in 382 RFC5378: Rights Contributors Provide to the IETF Trust [RFC5378]. 384 10.2 Note Well 386 A "note well" as is commonly used at face-to-face meetings MUST be 387 shown at an RPH session. 389 10.3 IETF Brand / Logo 391 The IETF logo may be used to in an RPH with the prior approval of the 392 IETF liaison. 394 11 Security Considerations 396 There are no security considerations. 398 12 IANA Considerations 400 There are no IANA considerations. 402 13 References 404 13.1 Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 410 Procedures", BCP 25, September 1998. 412 [RFC5378] Bradner, S., "Rights Contributors Provide to the IETF 413 Trust", BCP 78, November 2008 415 [RFC7776] Resnick, P., "IETF Anti-Harassment Procedures", BCP 25, 416 March 2016 418 13.2 Informative References 420 Authors' Addresses 422 Nalini Elkins 423 Inside Products, Inc. 424 36A Upper Circle 425 Carmel Valley, CA 93924 426 United States 427 Phone: +1 831 659 8360 428 Email: nalini.elkins@insidethestack.com 429 http://www.insidethestack.com 431 Harish Chowdhary 432 NIXI 433 India 434 Email: harish@nixi.in 436 T.Santhosh 437 Ministry of Electronics and Information Technology 438 Government of India 439 Electronics Niketan, 6 CGO Complex, 440 New Delhi - 110003 (India) 441 Tel: +91-11-24364741, 24301831 443 V. hegde 444 Independent 445 vinayakh@gmail.com