IDESG Baseline Process Use Case

From IDESG Wiki
Jump to navigation Jump to search


In Memory of Jonathan B. Postel: RIP my friend RFC 2468 "I Remember IANA"


Please note, that this is not a Use Case, but at this time the IDESG do not have a process for documents like this one. Hopefully this document can change this.


Title: IDESG Baseline Process Use Case (Example: IDBL - 0.2468)

Use Case Description: “How to keep track of all submitted Use Cases and IDESG Draft documents."

This describes the process used by the IDESG Ecosystem for establishing a Baseline document lifecycle process. It defines the lifecycle stages for the Baseline process, the requirements for moving a document between stages and the types of documents used during this process.

This contains a snapshot of the state of IDESG Baselines used in the IDESG Ecosystem, as determined by the IDESG Ecosystem Working Group.


Use Case Category: IDESG approved baseline process requirements


Contributor: Scott Stephenson info@trustedinternetidprovider

Very few items included in this document are original thought from myself.  This is a copy & paste, find & replace function of already existing excellent public works contributed by IEEE and IETF working groups. Reference:  IEEE | IETF


Use Case Details

Actors: Submitter – Any IDESG individual, entity or organization wishing to submit, modify or withdraw an IDESG Baseline process.

Non-IDESG – Any individual, entity or organization that is not associated with the IDESG, wishing to submit, modify or withdraw an IDESG Baseline process.

IDESG Document Administrator – Administers the lifecycle and issues the codify tracking number for all IDESG Use Cases and Formal Drafts developed by Submitters.

Use Case – In software and systems engineering, a use case is a list of steps, defining interactions between a actor(s) and a system(s), to complete a process.

Formal Draft – Any document that is developed by an individual, entity or organization that will be sent to Plenary for a vote.


Baseline categories: 

   Use Case (UC)
   Formal Draft (FD)
   Proposed Baseline (PBL)
   IDESG Active Baseline (IDBL)
   Inactive – Superseded (IS)
   Inactive – Reserved (IR)
   Inactive – Withdrawn (IW)


Assumptions: "Baselines never die, they are superseded."

1. Use Case & Formal Draft: Each Use Case & Formal Draft are assigned a static sequential number that can only be used once (Ex: .0001). Each Use Case & Formal Draft number will include the abbreviation of the document’s Submitter (Ex: BA - .0001).

If a Use Case or Formal Draft becomes a Baseline (BL), the Use Case & Formal Draft. When a Baseline is updated, the Baseline’s number stays the same while the Use Case number is changed to reflect the new Use Case.

2. Proposed Baseline: Approved by an IDESG Plenary vote. The entry-level maturity for the Baselines track is "Proposed Baseline". A specific action by the IDESG is required to move a specification onto the Baselines track at the "Proposed Baseline" level.

A Proposed Baseline specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances.

Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Baseline. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Baseline designation.

The IDESG may require implementation and/or operational experience prior to granting Proposed Baseline status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet.

A Proposed Baseline should have no known technical omissions with respect to the requirements placed upon it. However, the IDESG may waive this requirement in order to allow a specification to advance to the Proposed Baseline state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementers should treat Proposed Baselines as immature specifications.

It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Baselines may be changed if problems are found or better solutions are identified, deploying implementations of such Baselines into a disruption-sensitive environment is not recommended.

3. IDESG Active Baseline: Approved by an IDESG Plenary vote. An IDESG Baseline (BL), which may simply be referred to as a Baseline. Is characterized by a high degree of maturity and by a generally held belief that the specified process provides significant benefit to the IDESG Ecosystem.

A specification that reaches the status of Baseline is assigned a number in the BL series while retaining its Use Case number.

4. Inactive-Superseded Baseline: Approved by an IDESG Plenary vote. A Baseline that has been replaced with a revised version of the Baseline.

5. Inactive-Reserved Baseline: Approved by an IDESG Plenary vote. A Baseline that has been removed from active status through an administrative process for Baselines that have not undergone a revision process within 5 years.

6. Inactive-Withdrawn Baseline: Approved by an IDESG Plenary vote. A Baseline that has been removed from active status due to no longer being a valid Baseline.

7. Baseline Group Numbers Use Case number = .xxxx

IDESG Committees

Baseline Codify
Document Administration

 BL – 0.xxxx

Financial Services

 BL – 1.xxxx

Healthcare

 BL – 2.xxxx

International Coordination 

 BL – 3.xxxx

Trust Framework and Trustmark

 BL – 4.xxxx

Policy Coordination

 BL – 5.xxxx

Privacy Coordination

 BL – 6.xxxx

Security

 BL – 7.xxxx

Standards Coordination

 BL – 8.xxxx

User Experience

 BL – 9.xxxx

Security Committee: Attributes AHG

 BL – 10.xxxx

Security Committee: Functional Model AHG

 BL – 11.xxxx

Standards Committee: Standards Wiki AHG

 BL – 12.xxxx

Security & Standards Committees: Taxonomy AHG

 BL – 13.xxxx

Standards Committee: Use Case AHG

 BL – 14.xxxx

Non-IDESG (catch all)

 BL – 15.xxxx


Baseline Process Flow

Use Cases:
The Document Administrator Group will have permission to change the Use Case number.

  1. Use Case has been submitted to the IDESG Document Administrator (DA). (Via online Portal)
    1. The Use Case will initially display on a webpage call Use Case Purgatory until the Use Case is indorsed by 5 working group members. 
  2. When the Use Case has been indorsed by 5 working group members, the Use Case is assigned a number by the Document Administrator: 
    1. Use Case is assigned the number:  UC-0001. 
  3. Use Case is readied for IDESG committee review: CR-0001 
    1. Working group members will be allowed to post comments for the Use Case.
  4. When the Use Case is approved by SSC process, Use Case becomes a Proposed Baseline:  PBL-0001
  5. Proposed Baseline is voted on by the IDESG Plenary. 
    1. If the Proposed Baseline is NOT approved, the PBL is sent back to the Submitter.  When the reasons for the PBL not being approved are addressed, the PBL can be resubmitted to the Plenary for a new vote or the PBL can be withdrawn.
    2. If the Proposed Baseline is approved, it becomes a IDESG Active Baseline and can be assigned to one or more committee group(s):  IDBL–4.0001 & 7.0001 (reads, TFTM & Security approved Baseline # 0001)
    3. The ownership/control of the Use Case remains with the Submitter until the Use Case has become a Baseline.
  6. IDESG Active Baseline is published.
  7. IDESG Active Baseline requires modification.
  8. The original IDESG Active Baseline can be modified by an Amendment and resubmitted or a brand new Use Case can be submitted to the Document Administrator.

a.       If IDBL-4.0001 & 7.0001 needs to be modified or corrected by an Amendment.  The Amendment will be the next available alphabet letter, FD-0001a.  

    1. If there are large modifications required to the IDESG Active Baseline, a new Use Case should be submitted and assigned a new number:  FD-0004
  1. Return to step # 3 and repeat.

If UC–0002 is approved by the Plenary to replace IDBL–4.0001 & 7.0001. 
IDBL – 4.0001 & 7.0001 becomes superseded IS – 4.0001.0002 & 7.0001.0002 (reads, TFTM & Security approved Baseline # 0001 has been superseded by # 0002)

If UC–0001a is approved by the Plenary to replace IDBL–4.0001 & 7.0001. 
IDBL – 4.0001 & 7.0001 becomes IDBL – 4.0001a & 7.0001a (reads, TFTM & Security approved Baseline # 0001 has been superseded by # 0001a)

Formal Draft:

The Document Administrator group will have permission to change the Formal Draft number.

  1. Formal Draft has been submitted to the IDESG Document Administrator (DA). (Via online Portal)
    1. The Formal Draft will initially display on a webpage call Formal Draft Purgatory until the Formal Draft is indorsed by 5 working group members. 
  2. When the Formal Draft has been indorsed by 5 working group members, the Formal Draft is assigned a number by the Document Administrator: 
    1. Formal Draft is assigned the number:  FD-0003. 
  3. Formal Draft is readied for IDESG committee review: CR-0003 
    1. Working group members will be allowed to post comments for the Formal Draft.
  4. Formal Draft is approved by SSC process, Formal Draft becomes a Proposed Baseline:  PBL-0003
  5. Proposed Baseline is voted on by the IDESG Plenary. 
    1. If the Proposed Baseline is NOT approved, the PBL is sent back to the Submitter.  When the reasons for the PBL not being approved are addressed, the PBL can be resubmitted to the Plenary for a new vote or the PBL can be withdrawn.
    2. If the Proposed Baseline is approved, it becomes a IDESG Active Baseline and can be assigned to one or more committee group(s):  IDBL–4.0003 & 7.0003 (reads, TFTM & Security approved Baseline # 0001)
    3. The ownership/control of the Formal Draft remains with the Submitter until the Formal Draft has become a Baseline.
  6. IDESG Active Baseline is published.
  7. IDESG Active Baseline requires modification.
  8. The original IDESG Active Baseline can be modified by an Amendment and resubmitted or a brand new Formal Draft can be submitted to the Document Administrator.

a.       If IDBL-4.0003 & 7.0003 needs to be modified or corrected by an Amendment.  The Amendment will be the next available alphabet letter, FD-0003a.  

    1. If there are large modifications required to the IDESG Active Baseline, a new Formal Draft should be submitted and assigned a new number:  FD-0004
  1. Return to step # 3 and repeat.

If UC–0004 is approved by the Plenary to replace IDBL–4.0003 & 7.0003. 
IDBL–4.0003 & 7.0003 becomes superseded IS–4.0003.0004 & 7.0003.0004 (reads, TFTM & Security approved Baseline # 0003 has been superseded by # 0004)

If UC–0003a is approved by the Plenary to replace IDBL–4.0003 & 7.0003. 
IDBL–4.0003 & 7.0003 becomes IDBL–4.0003a & 7.0003a (reads, TFTM & Security approved Baseline # 0003 has been superseded by # 0003a)

References and Citations

IEEE: FAQs: Maintenance of IEEE Standards
http://standards.ieee.org/faqs/reaff.html  
IETF: Best Current Practice
http://tools.ietf.org/html/rfc6410</a>


Retrieved from "https://wiki.idesg.org/index.php?title=IDESG_Baseline_Process_Use_Case&oldid=2647"