Network Working Group S. Bradner
`Request for Comments: 2418 Editor
`Obsoletes: 1603 Harvard University
`BCP: 25 September 1998
`Category: Best Current Practice
`
` IETF Working Group
` Guidelines and Procedures
`
`Status of this Memo
`
` This document specifies an Internet Best Current Practices for the
` Internet Community, and requests discussion and suggestions for
` improvements. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1998). All Rights Reserved.
`
`Abstract
`
` The Internet Engineering Task Force (IETF) has responsibility for
` developing and reviewing specifications intended as Internet
` Standards. IETF activities are organized into working groups (WGs).
` This document describes the guidelines and procedures for formation
` and operation of IETF working groups. It also describes the formal
` relationship between IETF participants WG and the Internet
` Engineering Steering Group (IESG) and the basic duties of IETF
` participants, including WG Chairs, WG participants, and IETF Area
` Directors.
`
`Table of Contents
`
` Abstract ......................................................... 1
` 1. Introduction .................................................. 2
` 1.1. IETF approach to standardization .......................... 4
` 1.2. Roles within a Working Group .............................. 4
` 2. Working group formation ....................................... 4
` 2.1. Criteria for formation .................................... 4
` 2.2. Charter ................................................... 6
` 2.3. Charter review & approval ................................. 8
` 2.4. Birds of a feather (BOF) .................................. 9
` 3. Working Group Operation ....................................... 10
` 3.1. Session planning .......................................... 11
` 3.2. Session venue ............................................. 11
` 3.3. Session management ........................................ 13
` 3.4. Contention and appeals .................................... 15
`
`Bradner Best Current Practice [Page 1]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 1
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` 4. Working Group Termination ..................................... 15
` 5. Rechartering a Working Group .................................. 15
` 6. Staff Roles ................................................... 16
` 6.1. WG Chair .................................................. 16
` 6.2. WG Secretary .............................................. 18
` 6.3. Document Editor ........................................... 18
` 6.4. WG Facilitator ............................................ 18
` 6.5. Design teams .............................................. 19
` 6.6. Working Group Consultant .................................. 19
` 6.7. Area Director ............................................. 19
` 7. Working Group Documents ....................................... 19
` 7.1. Session documents ......................................... 19
` 7.2. Internet-Drafts (I-D) ..................................... 19
` 7.3. Request For Comments (RFC) ................................ 20
` 7.4. Working Group Last-Call ................................... 20
` 7.5. Submission of documents ................................... 21
` 8. Review of documents ........................................... 21
` 9. Security Considerations ....................................... 22
` 10. Acknowledgments .............................................. 23
` 11. References ................................................... 23
` 12. Editor’s Address ............................................. 23
` Appendix: Sample Working Group Charter .......................... 24
` Full Copyright Statement ......................................... 26
`
`1. Introduction
`
` The Internet, a loosely-organized international collaboration of
` autonomous, interconnected networks, supports host-to-host
` communication through voluntary adherence to open protocols and
` procedures defined by Internet Standards. There are also many
` isolated interconnected networks, which are not connected to the
` global Internet but use the Internet Standards. Internet Standards
` are developed in the Internet Engineering Task Force (IETF). This
` document defines guidelines and procedures for IETF working groups.
` The Internet Standards Process of the IETF is defined in [1]. The
` organizations involved in the IETF Standards Process are described in
` [2] as are the roles of specific individuals.
`
` The IETF is a large, open community of network designers, operators,
` vendors, users, and researchers concerned with the Internet and the
` technology used on it. The primary activities of the IETF are
` performed by committees known as working groups. There are currently
` more than 100 working groups. (See the IETF web page for an up-to-
` date list of IETF Working Groups - http://www.ietf.org.) Working
` groups tend to have a narrow focus and a lifetime bounded by the
` completion of a specific set of tasks, although there are exceptions.
`
`Bradner Best Current Practice [Page 2]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 2
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` For management purposes, the IETF working groups are collected
` together into areas, with each area having a separate focus. For
` example, the security area deals with the development of security-
` related technology. Each IETF area is managed by one or two Area
` Directors (ADs). There are currently 8 areas in the IETF but the
` number changes from time to time. (See the IETF web page for a list
` of the current areas, the Area Directors for each area, and a list of
` which working groups are assigned to each area.)
`
` In many areas, the Area Directors have formed an advisory group or
` directorate. These comprise experienced members of the IETF and the
` technical community represented by the area. The specific name and
` the details of the role for each group differ from area to area, but
` the primary intent is that these groups assist the Area Director(s),
` e.g., with the review of specifications produced in the area.
`
` The IETF area directors are selected by a nominating committee, which
` also selects an overall chair for the IETF. The nominations process
` is described in [3].
`
` The area directors sitting as a body, along with the IETF Chair,
` comprise the Internet Engineering Steering Group (IESG). The IETF
` Executive Director is an ex-officio participant of the IESG, as are
` the IAB Chair and a designated Internet Architecture Board (IAB)
` liaison. The IESG approves IETF Standards and approves the
` publication of other IETF documents. (See [1].)
`
` A small IETF Secretariat provides staff and administrative support
` for the operation of the IETF.
`
` There is no formal membership in the IETF. Participation is open to
` all. This participation may be by on-line contribution, attendance
` at face-to-face sessions, or both. Anyone from the Internet
` community who has the time and interest is urged to participate in
` IETF meetings and any of its on-line working group discussions.
` Participation is by individual technical contributors, rather than by
` formal representatives of organizations.
`
` This document defines procedures and guidelines for the formation and
` operation of working groups in the IETF. It defines the relations of
` working groups to other bodies within the IETF. The duties of working
` group Chairs and Area Directors with respect to the operation of the
` working group are also defined. When used in this document the key
` words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
` "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
` interpreted as described in RFC 2119 [6]. RFC 2119 defines the use
` of these key words to help make the intent of standards track
` documents as clear as possible. The same key words are used in this
`
`Bradner Best Current Practice [Page 3]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 3
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` document to help smooth WG operation and reduce the chance for
` confusion about the processes.
`
`1.1. IETF approach to standardization
`
` Familiarity with The Internet Standards Process [1] is essential for
` a complete understanding of the philosophy, procedures and guidelines
` described in this document.
`
`1.2. Roles within a Working Group
`
` The document, "Organizations Involved in the IETF Standards Process"
` [2] describes the roles of a number of individuals within a working
` group, including the working group chair and the document editor.
` These descriptions are expanded later in this document.
`
`2. Working group formation
`
` IETF working groups (WGs) are the primary mechanism for development
` of IETF specifications and guidelines, many of which are intended to
` be standards or recommendations. A working group may be established
` at the initiative of an Area Director or it may be initiated by an
` individual or group of individuals. Anyone interested in creating an
` IETF working group MUST obtain the advice and consent of the IETF
` Area Director(s) in whose area the working group would fall and MUST
` proceed through the formal steps detailed in this section.
`
` Working groups are typically created to address a specific problem or
` to produce one or more specific deliverables (a guideline, standards
` specification, etc.). Working groups are generally expected to be
` short-lived in nature. Upon completion of its goals and achievement
` of its objectives, the working group is terminated. A working group
` may also be terminated for other reasons (see section 4).
` Alternatively, with the concurrence of the IESG, Area Director, the
` WG Chair, and the WG participants, the objectives or assignment of
` the working group may be extended by modifying the working group’s
` charter through a rechartering process (see section 5).
`
`2.1. Criteria for formation
`
` When determining whether it is appropriate to create a working group,
` the Area Director(s) and the IESG will consider several issues:
`
` - Are the issues that the working group plans to address clear and
` relevant to the Internet community?
`
` - Are the goals specific and reasonably achievable, and achievable
` within a reasonable time frame?
`
`Bradner Best Current Practice [Page 4]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 4
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` - What are the risks and urgency of the work, to determine the level
` of effort required?
`
` - Do the working group’s activities overlap with those of another
` working group? If so, it may still be appropriate to create the
` working group, but this question must be considered carefully by
` the Area Directors as subdividing efforts often dilutes the
` available technical expertise.
`
` - Is there sufficient interest within the IETF in the working
` group’s topic with enough people willing to expend the effort to
` produce the desired result (e.g., a protocol specification)?
` Working groups require considerable effort, including management
` of the working group process, editing of working group documents,
` and contributing to the document text. IETF experience suggests
` that these roles typically cannot all be handled by one person; a
` minimum of four or five active participants in the management
` positions are typically required in addition to a minimum of one
` or two dozen people that will attend the working group meetings
` and contribute on the mailing list. NOTE: The interest must be
` broad enough that a working group would not be seen as merely the
` activity of a single vendor.
`
` - Is there enough expertise within the IETF in the working group’s
` topic, and are those people interested in contributing in the
` working group?
`
` - Does a base of interested consumers (end-users) appear to exist
` for the planned work? Consumer interest can be measured by
` participation of end-users within the IETF process, as well as by
` less direct means.
`
` - Does the IETF have a reasonable role to play in the determination
` of the technology? There are many Internet-related technologies
` that may be interesting to IETF members but in some cases the IETF
` may not be in a position to effect the course of the technology in
` the "real world". This can happen, for example, if the technology
` is being developed by another standards body or an industry
` consortium.
`
` - Are all known intellectual property rights relevant to the
` proposed working group’s efforts issues understood?
`
` - Is the proposed work plan an open IETF effort or is it an attempt
` to "bless" non-IETF technology where the effect of input from IETF
` participants may be limited?
`
`Bradner Best Current Practice [Page 5]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 5
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` - Is there a good understanding of any existing work that is
` relevant to the topics that the proposed working group is to
` pursue? This includes work within the IETF and elsewhere.
`
` - Do the working group’s goals overlap with known work in another
` standards body, and if so is adequate liaison in place?
`
` Considering the above criteria, the Area Director(s), using his or
` her best judgement, will decide whether to pursue the formation of
` the group through the chartering process.
`
`2.2. Charter
`
` The formation of a working group requires a charter which is
` primarily negotiated between a prospective working group Chair and
` the relevant Area Director(s), although final approval is made by the
` IESG with advice from the Internet Architecture Board (IAB). A
` charter is a contract between a working group and the IETF to perform
` a set of tasks. A charter:
`
` 1. Lists relevant administrative information for the working group;
` 2. Specifies the direction or objectives of the working group and
` describes the approach that will be taken to achieve the goals;
` and
` 3. Enumerates a set of milestones together with time frames for their
` completion.
`
` When the prospective Chair(s), the Area Director and the IETF
` Secretariat are satisfied with the charter form and content, it
` becomes the basis for forming a working group. Note that an Area
` Director MAY require holding an exploratory Birds of a Feather (BOF)
` meeting, as described below, to gage the level of support for a
` working group before submitting the charter to the IESG and IAB for
` approval.
`
` Charters may be renegotiated periodically to reflect the current
` status, organization or goals of the working group (see section 5).
` Hence, a charter is a contract between the IETF and the working group
` which is committing to meet explicit milestones and delivering
` specific "products".
`
` Specifically, each charter consists of the following sections:
`
` Working group name
` A working group name should be reasonably descriptive or
` identifiable. Additionally, the group shall define an acronym
` (maximum 8 printable ASCII characters) to reference the group in
` the IETF directories, mailing lists, and general documents.
`
`Bradner Best Current Practice [Page 6]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 6
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` Chair(s)
` The working group may have one or more Chairs to perform the
` administrative functions of the group. The email address(es) of
` the Chair(s) shall be included. Generally, a working group is
` limited to two chairs.
`
` Area and Area Director(s)
` The name of the IETF area with which the working group is
` affiliated and the name and electronic mail address of the
` associated Area Director(s).
`
` Responsible Area Director
` The Area Director who acts as the primary IESG contact for the
` working group.
`
` Mailing list
` An IETF working group MUST have a general Internet mailing list.
` Most of the work of an IETF working group will be conducted on the
` mailing list. The working group charter MUST include:
`
` 1. The address to which a participant sends a subscription request
` and the procedures to follow when subscribing,
`
` 2. The address to which a participant sends submissions and
` special procedures, if any, and
`
` 3. The location of the mailing list archive. A message archive
` MUST be maintained in a public place which can be accessed via
` FTP or via the web.
`
` As a service to the community, the IETF Secretariat operates a
` mailing list archive for working group mailing lists. In order
` to take advantage of this service, working group mailing lists
` MUST include the address "wg_acronym-archive@lists.ietf.org"
` (where "wg_acronym" is the working group acronym) in the
` mailing list in order that a copy of all mailing list messages
` be recorded in the Secretariat’s archive. Those archives are
` located at ftp://ftp.ietf.org/ietf-mail-archive. For
` robustness, WGs SHOULD maintain an additional archive separate
` from that maintained by the Secretariat.
`
` Description of working group
` The focus and intent of the group shall be set forth briefly. By
` reading this section alone, an individual should be able to decide
` whether this group is relevant to their own work. The first
` paragraph must give a brief summary of the problem area, basis,
` goal(s) and approach(es) planned for the working group. This
` paragraph can be used as an overview of the working group’s
`
`Bradner Best Current Practice [Page 7]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 7
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` effort.
`
` To facilitate evaluation of the intended work and to provide on-
` going guidance to the working group, the charter must describe the
` problem being solved and should discuss objectives and expected
` impact with respect to:
`
` - Architecture
` - Operations
` - Security
` - Network management
` - Scaling
` - Transition (where applicable)
`
` Goals and milestones
` The working group charter MUST establish a timetable for specific
` work items. While this may be renegotiated over time, the list of
` milestones and dates facilitates the Area Director’s tracking of
` working group progress and status, and it is indispensable to
` potential participants identifying the critical moments for input.
` Milestones shall consist of deliverables that can be qualified as
` showing specific achievement; e.g., "Internet-Draft finished" is
` fine, but "discuss via email" is not. It is helpful to specify
` milestones for every 3-6 months, so that progress can be gauged
` easily. This milestone list is expected to be updated
` periodically (see section 5).
`
` An example of a WG charter is included as Appendix A.
`
`2.3. Charter review & approval
`
` Proposed working groups often comprise technically competent
` participants who are not familiar with the history of Internet
` architecture or IETF processes. This can, unfortunately, lead to
` good working group consensus about a bad design. To facilitate
` working group efforts, an Area Director may assign a Consultant from
` among the ranks of senior IETF participants. (Consultants are
` described in section 6.) At the discretion of the Area Director,
` approval of a new WG may be withheld in the absence of sufficient
` consultant resources.
`
` Once the Area Director (and the Area Directorate, as the Area
` Director deems appropriate) has approved the working group charter,
` the charter is submitted for review by the IAB and approval by the
` IESG. After a review period of at least a week the proposed charter
` is posted to the IETF-announce mailing list as a public notice that
` the formation of the working group is being considered. At the same
` time the proposed charter is also posted to the "new-work" mailing
`
`Bradner Best Current Practice [Page 8]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 8
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` list. This mailing list has been created to let qualified
` representatives from other standards organizations know about pending
` IETF working groups. After another review period lasting at least a
` week the IESG MAY approve the charter as-is, it MAY request that
` changes be made in the charter, or MAY decline to approve chartering
` of the working group
`
` If the IESG approves the formation of the working group it remands
` the approved charter to the IETF Secretariat who records and enters
` the information into the IETF tracking database. The working group
` is announced to the IETF-announce a by the IETF Secretariat.
`
`2.4. Birds of a Feather (BOF)
`
` Often it is not clear whether an issue merits the formation of a
` working group. To facilitate exploration of the issues the IETF
` offers the possibility of a Birds of a Feather (BOF) session, as well
` as the early formation of an email list for preliminary discussion.
` In addition, a BOF may serve as a forum for a single presentation or
` discussion, without any intent to form a working group.
`
` A BOF is a session at an IETF meeting which permits "market research"
` and technical "brainstorming". Any individual may request permission
` to hold a BOF on a subject. The request MUST be filed with a relevant
` Area Director who must approve a BOF before it can be scheduled. The
` person who requests the BOF may be asked to serve as Chair of the
` BOF.
`
` The Chair of the BOF is also responsible for providing a report on
` the outcome of the BOF. If the Area Director approves, the BOF is
` then scheduled by submitting a request to agenda@ietf.org with copies
` to the Area Director(s). A BOF description and agenda are required
` before a BOF can be scheduled.
`
` Available time for BOFs is limited, and BOFs are held at the
` discretion of the ADs for an area. The AD(s) may require additional
` assurances before authorizing a BOF. For example,
`
` - The Area Director MAY require the establishment of an open email
` list prior to authorizing a BOF. This permits initial exchanges
` and sharing of framework, vocabulary and approaches, in order to
` make the time spent in the BOF more productive.
`
` - The Area Director MAY require that a BOF be held, prior to
` establishing a working group (see section 2.2).
`
` - The Area Director MAY require that there be a draft of the WG
` charter prior to holding a BOF.
`
`Bradner Best Current Practice [Page 9]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 9
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` - The Area Director MAY require that a BOF not be held until an
` Internet-Draft describing the proposed technology has been
` published so it can be used as a basis for discussion in the BOF.
`
` In general, a BOF on a particular topic is held only once (ONE slot
` at one IETF Plenary meeting). Under unusual circumstances Area
` Directors may, at their discretion, allow a BOF to meet for a second
` time. BOFs are not permitted to meet three times. Note that all
` other things being equal, WGs will be given priority for meeting
` space over BOFs. Also, occasionally BOFs may be held for other
` purposes than to discuss formation of a working group.
`
` Usually the outcome of a BOF will be one of the following:
`
` - There was enough interest and focus in the subject to warrant the
` formation of a WG;
`
` - While there was a reasonable level of interest expressed in the
` BOF some other criteria for working group formation was not met
` (see section 2.1).
`
` - The discussion came to a fruitful conclusion, with results to be
` written down and published, however there is no need to establish
` a WG; or
`
` - There was not enough interest in the subject to warrant the
` formation of a WG.
`
`3. Working Group Operation
`
` The IETF has basic requirements for open and fair participation and
` for thorough consideration of technical alternatives. Within those
` constraints, working groups are autonomous and each determines most
` of the details of its own operation with respect to session
` participation, reaching closure, etc. The core rule for operation is
` that acceptance or agreement is achieved via working group "rough
` consensus". WG participants should specifically note the
` requirements for disclosure of conflicts of interest in [2].
`
` A number of procedural questions and issues will arise over time, and
` it is the function of the Working Group Chair(s) to manage the group
` process, keeping in mind that the overall purpose of the group is to
` make progress towards reaching rough consensus in realizing the
` working group’s goals and objectives.
`
` There are few hard and fast rules on organizing or conducting working
` group activities, but a set of guidelines and practices has evolved
` over time that have proven successful. These are listed here, with
`
`Bradner Best Current Practice [Page 10]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 10
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` actual choices typically determined by the working group participants
` and the Chair(s).
`
`3.1. Session planning
`
` For coordinated, structured WG interactions, the Chair(s) MUST
` publish a draft agenda well in advance of the actual session. The
` agenda should contain at least:
`
` - The items for discussion;
` - The estimated time necessary per item; and
` - A clear indication of what documents the participants will need to
` read before the session in order to be well prepared.
`
` Publication of the working group agenda shall include sending a copy
` of the agenda to the working group mailing list and to
` agenda@ietf.org.
`
` All working group actions shall be taken in a public forum, and wide
` participation is encouraged. A working group will conduct much of its
` business via electronic mail distribution lists but may meet
` periodically to discuss and review task status and progress, to
` resolve specific issues and to direct future activities. IETF
` Plenary meetings are the primary venue for these face-to-face working
` group sessions, and it is common (though not required) that active
` "interim" face-to-face meetings, telephone conferences, or video
` conferences may also be held. Interim meetings are subject to the
` same rules for advance notification, reporting, open participation,
` and process, which apply to other working group meetings.
`
` All working group sessions (including those held outside of the IETF
` meetings) shall be reported by making minutes available. These
` minutes should include the agenda for the session, an account of the
` discussion including any decisions made, and a list of attendees. The
` Working Group Chair is responsible for insuring that session minutes
` are written and distributed, though the actual task may be performed
` by someone designated by the Working Group Chair. The minutes shall
` be submitted in printable ASCII text for publication in the IETF
` Proceedings, and for posting in the IETF Directories and are to be
` sent to: minutes@ietf.org
`
`3.2. Session venue
`
` Each working group will determine the balance of email and face-to-
` face sessions that is appropriate for achieving its milestones.
` Electronic mail permits the widest participation; face-to-face
` meetings often permit better focus and therefore can be more
` efficient for reaching a consensus among a core of the working group
`
`Bradner Best Current Practice [Page 11]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 11
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` participants. In determining the balance, the WG must ensure that
` its process does not serve to exclude contribution by email-only
` participants. Decisions reached during a face-to-face meeting about
` topics or issues which have not been discussed on the mailing list,
` or are significantly different from previously arrived mailing list
` consensus MUST be reviewed on the mailing list.
`
` IETF Meetings
` If a WG needs a session at an IETF meeting, the Chair must apply for
` time-slots as soon as the first announcement of that IETF meeting is
` made by the IETF Secretariat to the WG-chairs list. Session time is
` a scarce resource at IETF meetings, so placing requests early will
` facilitate schedule coordination for WGs requiring the same set of
` experts.
`
` The application for a WG session at an IETF meeting MUST be made to
` the IETF Secretariat at the address agenda@ietf.org. Some Area
` Directors may want to coordinate WG sessions in their area and
` request that time slots be coordinated through them. If this is the
` case it will be noted in the IETF meeting announcement. A WG
` scheduling request MUST contain:
`
` - The working group name and full title;
` - The amount of time requested;
` - The rough outline of the WG agenda that is expected to be covered;
` - The estimated number of people that will attend the WG session;
` - Related WGs that should not be scheduled for the same time slot(s);
` and
` - Optionally a request can be added for the WG session to be
` transmitted over the Internet in audio and video.
`
` NOTE: While open discussion and contribution is essential to working
` group success, the Chair is responsible for ensuring forward
` progress. When acceptable to the WG, the Chair may call for
` restricted participation (but not restricted attendance!) at IETF
` working group sessions for the purpose of achieving progress. The
` Working Group Chair then has the authority to refuse to grant the
` floor to any individual who is unprepared or otherwise covering
` inappropriate material, or who, in the opinion of the Chair is
` disrupting the WG process. The Chair should consult with the Area
` Director(s) if the individual persists in disruptive behavior.
`
` On-line
` It can be quite useful to conduct email exchanges in the same manner
` as a face-to-face session, with published schedule and agenda, as
` well as on-going summarization and consensus polling.
`
`Bradner Best Current Practice [Page 12]
`
`Petitioner Apple Inc. - Exhibit 1034, p. 12
`Mangrove and Apple v. VirnetX
`Trial IPR2015-01047
`
`

`
`
`RFC 2418 Working Group Guidelines September 1998
`
` Many working group participants hold that mailing list discussion is
` the best place to consider and resolve issues and make decisions. The
` choice of operational style is made by the working group itself.