BEST CURRENT OPERATIONAL PRACTICES – Development Process (BCOP-DP)
DRAFT – DRAFT – DRAFT
v0.4.1
NOTE: This document/draft has been modeled after previously authored policy development efforts such as ARIN’s PDP ( & IETF’s RFC 2026 sec 1.2 ( & Wikipedia itself.
The content here within is intended to be original content authored by the Global Network Engineering Community (GNEC) “at-large” in an organized, democratic, “bottoms-up” approach that will yield multiple BCOP documents into perpetuity.
PART TWO – THE BCOP DEVELOPMENT PROCESS (BCOP-DP)
This section provides the details of the Global Network Engineering Community’s (GNEC) Best Current Operational Practices Development Process (BCOP-DP).
1. The BCOP Development Process (BCOP-DP)
Anyone may request, thru an Appeal, to have a BCOP document written. The entire process is open, transparent, bottoms-up and on-going, and is for the GNEC at large or anyone just interested in Internet Protocol Best Current Operational Practices (e.g, Academia, etc.). The BCOP Development Process (BCOP-DP), detailed in this section, will be a set of steps that are defined herewith in and have been approved in the very same manner. The steps shall be as follows:
1. Appeal
The BCOP-DP begins with the identification of a need for documentation of a BCOP or the revision or elimination of an existing BCOP. This need is usually determined by a change in technology, a change in the operational environment of the Internet, or the result of the experience of the implementation of an existing BCOP.
2. Discussion
Once an Appeal is submitted to the GNCE thru the BCOP website/list-serv, the community commences discussion on said Appeal and determines if it shall move to next step. If there is support for the Appeal, the BCOP community shall nominate Subject Matter Experts (SMEs) and a shepherd who shall drive the BCOP thru the remaining phases.
3. Outline
Once the Subject, Shepard and the SMEs are agreed upon with no objection from the GNEC, the Shepard and SMEs shall draft an Outline of the BCOP Appeal. Once the Outline is drafted (should we put in here some wiki like structure?) and agreed upon by the GNEC, it shall proceed to Draft
4. Draft
When the BCOP moves from Outline to Draft, the Draft shall be the elongated and fleshed out version of the Outline consisting of details and graphics for said Appeal’s Outline.
5. Debate
? – shall Debate be limited to the SMEs and/or community? Clearly more hands in the stew makes for a long process – need the debate phase, just not sure how to make efficient.[CLG1]
6. Finalization
Post Debate, the near complete DRAFT shall be open to all GNEC and comments for a set period of time.
7. Published
Once time has expired during Finalization, and any significant concerns have been documented and addressed, the BCOP shall be published to the BCOP website (TBD) and available to any and all.[CLG2]
8. Update
An update can be initiated thru any inquiry to the BCOP website (TBD). If determined by BCOP SMEs that update is necessary, the update(s) shall proceed thru the cycle from the phase appropriate to the level of development of the proposed changes (appeal, discussion, outline, draft), and will be carried thru to Published if warranted.[CLG3]
2. Taking the first Step: Appeal
Anyone may make an Appeal to the BCOP community to commence efforts to author a BCOP. Every “legitimate’ Appeal shall be logged & indexed. Once an Appeal is received and logged (all Appeals shall be indexed and available), the BCOP community shall be alerted via email, Twitter (others?) [CLG4]and the BCOP-DCP process commences.
2.1. Submission of Appeal
An Appeal may be made to the BCOP community in any format ranging from email to requests at forums (e.g., NANOG) to simply filling the Appeal form on the BCOP website (TBD). The Appeal shall be documented and indexed on the BCOP website (TBD). The Appeal shall follow a format that is uniform and captures the following:
- Date
- Name of Requestor
- Subject
- Suggested Subject Matter Expert’s (for consultation)
- Comments / Suggestions / Other
2.2. Appeal Notification & Evaluation
The BCOP community shall be notified and evaluate any Appeal submitted and index that Appeal. The community shall determine if the Appeal is appropriate and if so determined, the Appeal shall be transferred to the next phase, Discussion
2.2.1. Appeal Submission
Once a properly formatted Appeal is received, the BCOP community shall be alerted via email & Twitter. The BCOP community shall place the Appeal online in a forum – all discussion surrounding the Appeal shall be captured (e.g., chat history) to be indexed with said appeal so that all steps are documented and searchable. The BCOP website shall have Wiki-like functionality with forms and formats already setup to capture any and all Appeals. Once an Appeal is made, it shall be a part of the BCOP community and subject to their desire to move forward or not. Person making the Appeal can choose to participate or not during the process, however, the Appeal, once made, cannot be rescinded unless done so by the BCOP community.
2.2.2 Evaluation Timeframe
The Evaluation shall not take more than 2 business weeks to complete – time enough for all community members to participate. During said time, the Appeal may be altered and/or edited to suit the broader community’s needs.
2.2.3 Evaluation – Yes or No
A “yes” or “no” shall finalize each Appeal. If “yes”, the BCOP-DP moves to step 2, Discussion. (need to flesh out how to do this online – voting? Ranking? Both?). In either case, the entire dialogue surrounding the Evaluation shall be captured and indexed on the BCOP website maintaining complete openness and transparency (not sure how to do that yet). If yes, the BCOP shall move forward, if not, BCOP Appeal shall be marked DEPRECATED and stored/indexed on the website (TBD).
3. Discussion(2 Weeks)
Once an Appeal is approved to move forward, the Discussion phase commences. The BCOP community shall be alerted via email & Twitter (we should have all social media leveraged) that an Appeal has been approved. Discussions shall last no longer than 2 business weeks and culminate with the following:
- Summary[CLG5] of BCOP (1-2 sentence abstract)
- Suggested Subject Matter Expert(s) (SMEs)
- Suggested “Shepard(s)”
- Approval of BCOP community to go to next phase (shall this be simply a majority vote?)[CLG6]
3.1. Summary of BCOP
The Subject of the BCOP shall be a 1-2 sentence abstract that shall discuss, at a high level, the content of the BCOP. Anyone may participate in this phase and it is encouraged that the submitter of the Appeal participate.
3.2. Subject Matter Expert
Subject Matter Experts are those individuals possessing depth of knowledge about the subject of the BCOP. The BCOP shall benefit from those people who have “real world”, hands on knowledge pertaining to the BCOP subject versus academic knowledge – this is the intent of the BCOP as the “Practice” implies a working knowledge of the subject at hand. The BCOP may have one or many SMEs.
3.3. Shepard
A Shepard shall be the “steward” of the BCOP thru its lifecycle. While not required to be an SME, it is possible that an SME & Shepard may be one and the same person. There shall be only one Shepard, however, per BCOP. The Shepard shall be responsible for the BCOP until Published. Once Published, the Shepard’s responsibility is over. In the event that a BCOP is revisited to be edited, a new Shepard will be named for said update.
3.4. Approval to move forward
A simple online vote shall take place once the Subject, SME, & Shepard are identified (all captured in the Discussion Form). If simple majority is in favor[CLG7], the Shepard shall then take over process and begin the next phase, Outline. If the majority is not in favor, BCOP Outline shall be marked DEPRECATED and stored/indexed accordingly.
4. Outline (2 Weeks)
The Outline phase is the phase where by the Shepard and SME(s) shall take the 1-2 sentence BCOP Subject and develop a proper outline to explain the subject. The Outline shall be a bulleted format (TBD). The Outline shall contain and follow this structure:
- Subject
- Section Headers
- History (I am putting in here as I think it relevant to ensure that we know where these came from – for example, many people don’t realize NAT was actually invented to prolong IPv4 space and not as an end to itself.)
- Current
- Future
- Appendices
- Footnotes
The Outline phase shall last no longer than 2 Business Weeks and shall be available online via the website. It can be, much like a Wiki, edited by anyone (a log file shall be kept though – possibly we use a sign in here to ensure we can track who participates?). While the principle participants shall be the SME & Sheppard, the entire process is open and transparent.
Once the Outline is completed and ready to push to next phase, the Sheppard shall announce to the community a 48hr review [CLG8]of Outline (last 2 days of this phase) such that any last BCOP community comments are captured. If no opposition is noted, the BCOP Outline shall move forward to Draft.
5. DRAFT (6 Weeks)
The DRAFT phase is where the Sheppard and SMEs get to filling in the Outline with the details of the BCOP. The process is open to anyone with BCOP credentials (registered member – membership is open and free) to participate, however, all participation will be tracked and logged.
5.1. Subject
The Subject shall have been written by this point, however, it is subject to editing as per the Sheppard and SMEs. The Subject should only be 1-2 sentences.
5.2. Section Headers
A very simple writing formula is prepared to make the process very easy to follow.
5.2.1. Background / History
The History shall encapsulate the understanding of any of the BCOPs history. For example, when discussing Network Address Translation (NAT), it is useful knowledge that NAT was invented as a way in which to prolong the IPv4 address pool as it was finite in nature. The History section may also include the understanding of why the BCOP was Appealed for in the first place – basically, anything that is pertinent background information[CLG9] pertaining to the BCOP. There is no limit to its length.
5.2.2. Current[CLG10]
This section may in turn contain many sub-sections pertinent to the BCOP. This will be the “meat” section diving into detail about the BCOPs subject. There is no limit to its length. (any thoughts as to graphics encouraged or not?)
5.2.3. Future[CLG11]
This section is optional, however, it would be very useful, since all BCOPs are subject to review and edit based on new knowledge, to try to look forward to things that may have an affect on said BCOP. For example, in the realm of IPv6 security, due to its lack of use today, it would be helpful to the community at large to hear/read the thoughts of “future” concerns or ideas relating to IPv6 security by the SMEs authoring the BCOP.
5.3. Appendices[CLG12]
All work pertaining to the BCOP but not relevant in the aforementioned sections maybe introduced in the Appendices. There is no limit to the Appendices nor length limitations.
5.4. Footnotes[CLG13]
All work shall be properly annotated, cited and then footnoted.
Once the draft work is complete, the Sheppard shall make an announcement to the BCOP via email & Twitter that the Draft is now in the Finalization phase.
5. FINALIZATION (4 Weeks)
Finalization will consist of a set time period (4 weeks) for the BCOP community at large to view, comment and discuss the BCOP Draft. The Shepard shall be responsible for commencing and closing this phase thru proper notifications to the BCOP community. A working document, much like Wikipedia or Google Docs, shall be employed to allow for multi-user access. The Finalization stage, while open to anyone to read, can only be commented upon and altered by registered BCOP members (participation is open and free, but you have to have registered). Again, all actions shall be tracked and logged by user. Once time has expired, a vote shall be made available to publish said BCOP – a simple majority shall trigger the BCOPs [CLG14]publication and the vote shall stay open for 48hrs at the end of the four weeks.
6. PUBLISHED
Once published, the BCOP shall remain closed to editing UNLESS an update is requested. While all content to be made available on the public facing part of the website shall be downloadable, the published BCOPs contained there within shall not be editable.
7. UPDATE
An update can be made in the same format as an Appeal. Each Published BCOP shall have an “update” request button and the “update” shall be treated much like an Appeal. If the Update is voted upon to move forward, the process for the Published BCOP shall go thru the same steps (shorter time frames – need to work this up).
Richard Donaldson
[CLG1]This phase is not included below. I am not sure it is needed, except as a sub-step to the Draft phase.
[CLG2]Do we need a safety valve where a ‘bad’ BCOP can be sent back to a previous phase? Or should they just be deprecated? Either way, it should be documented here I think.
[CLG3]This whole section is a duplicate of part 1 – is it needed here? If so, we need to ensure version synch between the two parts.
[CLG4]“..all currently relevant Internet-based mass-communication methods…” or some-such?
[CLG5]The template calls it a summary att
[CLG6]Is “rough consensus” better than simple majority? Does a 6-5 vote really show a need to move forward? Do weneed someone to judge majority/consensus – ARIN has the AC, the IETF has WG chairs and Ads, etc…
[CLG7]Again, majority of whom? If only one person votes is that ok? What if it’s the person who requested the BCOP?
[CLG8]Any restrictions here regarding weekends or holidays?
[CLG9]References? Other relevant BCOPS? RFCs? Etc…
[CLG10]Called BCOP in the template
[CLG11]Not in current template – template does include “Conclusion” not listed here
[CLG12]Not in current template
[CLG13]Not in current template
[CLG14]Again, simple majority vs consensus, etc…