idnits 2.17.1 draft-elkins-ietf-remote-viewing-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 (July 3, 2017) is 2488 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: January 4, 2018 July 3, 2017 12 Remote Viewing Hubs 13 draft-elkins-ietf-remote-viewing-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. Some exist today; other types 22 may exist in the future. Each has its own characteristics. 24 - Remote Participation Hubs (future) 25 - Remote Viewing Hubs (today) 26 - Enduring Local Meetups (today) 28 This document defines a Remote Viewing Hub (RVH). 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 Viewing Hubs (RVH) . . . . . . . . . . . . . 4 70 3 Relationship to IETF Meetings . . . . . . . . . . . . . . . . . 5 71 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.3 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4 Functioning at Remote Viewing Hubs . . . . . . . . . . . . . . 5 75 4.1 Coordinators . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.2 Session Management . . . . . . . . . . . . . . . . . . . . . 6 77 4.3 Anti-Harassment 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 RVH Coordinators . . . . . 7 85 4.8 Language of the communication of RVH . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 9 99 11 Security Considerations . . . . . . . . . . . . . . . . . . . 9 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. Some exist today; other 114 types may exist in the future. Each has its own characteristics. 116 - Remote Participation Hubs (future) 117 - Remote Viewing Hubs (today) 118 - Enduring Local Meetups (today) 120 This document defines a Remote Viewing Hub (RVH). Other documents 121 will define the other types of hubs. A common structure of sections 122 will be used as far as possible for all hub types. A Remote Viewing 123 Hub is most likely be used for outreach purposes. If an attendee at 124 a Remote Viewing Hub wishes to participate in a working group 125 session, the attendee may do so as an individual remote participant. 126 A Remote Viewing Hub may evolve into an Enduring Local Meetup. 128 A Remote Participation Hub (RPH) may be defined in the future. 129 This will have many more requirements for legal, queuing, recording 130 and other restrictions. An Enduring Local Meetup is not necessarily 131 at the same time as an IETF face-to-face meeting and may do 132 activities at its own discretion. 134 1.1 Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2 Purpose of Remote Viewing Hubs (RVH) 142 The purpose of a Remote Viewing Hub (RVH) is to provide a gathering 143 space to participate in one or more Working Groups sessions, 144 Hackathons, or IETF Plenaries scheduled at an ongoing IETF meeting 145 which is being held at the same time. 147 Participation in an RVH is not functionally equivalent to attendance 148 at an IETF meeting. The purpose of Viewing hubs may be to introduce 149 people to the IETF process, discuss ongoing work at the IETF or 150 outreach to the local community. An RVH may also be a simple 151 gathering of people to remotely watch Working Group sessions. 153 Legal and session management procedures need not be followed 154 (including NOTE-WELL and blue sheets). 156 One or more onsite coordinators may be present. 158 3 Relationship to IETF Meetings 160 The RVH will be at the time of the IETF meeting. An RVH may decide 161 to have multiple rooms with multiple simultaneous sessions mirroring 162 those at the face-to-face meeting or it may choose to have a single 163 room with selected Working Group sessions. This is at the discretion 164 of the RVH. The sessions to be held at the RVH SHOULD be 165 communicated to the IETF Secretariat for posting in the Wiki. 167 It SHOULD also mention any restrictions such as: 169 1. Only employees of the hosting organization are allowed 170 2. Restrictions on carrying laptops or recording devices 171 3. Specific proof of identity required to access the premises 173 3.1 Registration 175 An attendee at an RVH MAY register and this MAY be noted by the IETF 176 Secretariat. This MAY be checked by the onsite coordinator, if any. 178 There may be an online attendance portal having blue sheets provided 179 by IETF Secretariat. The following information may be asked: 181 a. Name 182 b. Organization 183 c. Registration Number 184 d. Location 186 3.2 Cost 188 There may be a charge to attend an RVH. This may be subsidized by 189 entities wishing to do so. 191 3.3 Timing 193 An RVH SHOULD be designated at a minimum of 30 days before the IETF 194 meeting. 196 4 Functioning at Remote Viewing Hubs 198 4.1 Coordinators 200 At least one or preferably two (2) coordinators SHOULD be appointed 201 by the RVH. Contact information MUST be provided to the IETF 202 Secretariat for inclusion in the calendar / Wiki. 204 4.2 Session Management 206 Session management as described in RFC2418: IETF Working Group 207 Guidelines and Procedures [RFC2418] Section 3.3 Session Management 208 does not apply to Remote Viewing Hubs. 210 The coordinators may wish to explain the NOTE Well which is shown at 211 the start of the meeting. Mike queuing discipline and fairness do 212 not apply to an RVH. 214 4.3 Anti-Harassment Procedures 216 An RVH may wish to ensure that anti-Harassment procedures according 217 to: RFC7776: IETF Anti-Harassment Procedures [RFC7776] are followed. 218 This is in the best interests of all participants. 220 4.4 Adherence to Proper Procedures 222 Proper procedures for an RVH are not defined. They are at the 223 discretion of the participants. 225 4.5 Recording 227 Recording and archiving does not apply to an RVH. 229 4.6 Technical Functioning 231 In order for groups of individuals to remotely view meetings, there 232 are certain technical requirements that must be met to ensure a non- 233 disruptive and trouble-free meeting experience. This document 234 outlines the proper configuration for remote participation to various 235 conferences throughout the world. 237 This section is needed only for a relatively large group of viewers. 239 4.6.1 Bandwidth 241 Adequate and good quality wired bandwidth is extremely important in 242 order to have audio, video and presentations viewed with good 243 quality. 245 4.6.2 Physical Room Layout 247 The layout of the meeting room is important in order for everyone to 248 properly view the presentations. It is suggested that the 249 coordinators keep the following points in mind when selecting and 250 setting up the venue: 252 a. Allow for plenty of time to set up and test the equipment prior to 253 your first meeting. 255 b. Each attendee will need at least one power port. 257 c. Heating and cooling can be a major factor. Note that projectors 258 and TVs can add to the room's heat. 260 d. Take note of the location and quantity of the power and network 261 connection points. 263 4.6.3 Audio 265 A sound system that is properly sized to the audience is important. 266 This will allow everyone to hear the speakers. The coordinators may 267 wish to consider using a robust audio system and a qualified 268 technical person to install and operate the equipment throughout the 269 duration of the meeting. 271 4.7 Responsibilities/Functions of the RVH Coordinators 273 The RVH coordinators, if any, may wish to consider doing one or more 274 of the activities below. 276 1. To support the participants on how to participate remotely in IETF 277 meetings on an individual basis. 279 2. Take a lead in the facilitation of sessions ensuring continuity of 280 the remote session. 282 3. Take the attendance along with the IETF remote registration number 284 4. Encourage the participants to participate in Working Group email 285 lists. 287 5. Submit the count of attendees to the IETF Secretariat. 289 6. Set up the space with the appropriate furniture, equipment and 290 materials for the IETF WG session each day. 292 7. Create a documentation process through photos and keep an 293 organized archive for the sessions. 295 4.8 Language of the communication of RVH 296 The RVH may communicate in any language desired. 298 5 Remote Support Tools 300 The remote support tools used are at the discretion of the RVH. 302 5.1 Communications 304 The remote communications methods today include Jabber and MeetEcho. 305 These shall be used. If new methods arise, then they may be used as 306 well. 308 6 IETF Secretariat Support 310 6.1 Calendar 312 The IETF Secretariat will maintain a calendar of locations and times 313 for all RVHs for that IETF meeting. Historical information SHOULD 314 be kept according to the section on Metrics. 316 6.2 Wiki / Web Page 318 The IETF Secretariat will maintain a Wiki or web page indicating 319 which working group sessions are being held at the RVH. This 320 information SHOULD be kept historically according to the section on 321 Metrics. 323 6.3 Registration 325 The IETF Secretariat MAY account for all registrations at an RVH. 326 Historical information MAY be kept according to the section on 327 Metrics. 329 7 IETF Liaison 331 An IETF liaison is not needed for an RVH. 333 8 Metrics 335 The following metrics SHOULD be kept for RVHs: 337 - Location (Economy / name of country) 338 - Name 339 - Name of coordinators 340 - Number of attendees registered 341 - Number of sessions 342 - The Working Groups followed 343 - Number of participants in each session (regardless of time) 345 Metrics may Include the following questions to the RVH. Potential 346 Metrics Survey Questions may be: 348 - How many RVHs were there and in which Location? 349 - How many people participated at the RVH? 350 - What sessions did they attend? 351 - Were there other associated activities in the RVH? 352 - Did any participant ask questions or make relevant comments? 353 - Were there any difficulties experienced? 354 - How might we (IETF) make it easier? 355 - How would you suggest we acknowledge the attendance? 356 - Will there be one or more RVHs for future IETF meetings? 357 - Will there be activities in the location between two IETF meetings? 358 - If yes, what kind of activities, are planned? 360 9 Mentoring 362 The RVH will not provide special mentoring. The mentoring may be 363 provided if there is a local group willing to provide it. However, 364 the specification of that is outside the scope of this document. 366 10 Legal Issues 368 10.1 IETF Rights in Contributions 370 Participation in an RVH will not be considered a contribution to the 371 IETF. Issues of Intellectual Property Rights, confidentiality, trade 372 marks, etc. as noted by the appropriate section in RFC5378: Rights 373 Contributors Provide to the IETF Trust [RFC5378] do not apply to an 374 RVH. 376 10.2 Note Well 378 A "note well" as is commonly used at face-to-face meetings need not 379 be shown at an RVH session. 381 10.3 IETF Brand / Logo 383 The IETF logo may be used to in an RVH with the prior approval of the 384 IETF trustees. 386 11 Security Considerations 388 There are no security considerations. 390 12 IANA Considerations 392 There are no IANA considerations. 394 13 References 396 13.1 Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 402 Procedures", BCP 25, September 1998. 404 [RFC5378] Bradner, S., "Rights Contributors Provide to the IETF 405 Trust", BCP 78, November 2008 407 [RFC7776] Resnick, P., "IETF Anti-Harassment Procedures", BCP 25, 408 March 2016 410 13.2 Informative References 412 Authors' Addresses 414 Nalini Elkins 415 Inside Products, Inc. 416 36A Upper Circle 417 Carmel Valley, CA 93924 418 United States 419 Phone: +1 831 659 8360 420 Email: nalini.elkins@insidethestack.com 421 http://www.insidethestack.com 423 Harish Chowdhary 424 NIXI 425 India 426 Email: harish@nixi.in 428 T.Santhosh 429 Ministry of Electronics and Information Technology 430 Government of India 431 Electronics Niketan, 6 CGO Complex, 432 New Delhi - 110003 (India) 433 Tel: +91-11-24364741, 24301831 434 V. hegde 435 Independent 436 vinayakh@gmail.com