(Logo Tech-invite)  

a Portal devoted to SIP and Security technologies

  (World Map)    
    Search Home Site Map Contact
 SIP/IMS Standardization
> IETF Standardization Process
> RFCs related to SIP (4 p.) o
> SIP-SIPPING-SIMPLE... I-Ds (22 p.) o
> Audio-Video Transport RFCs (2 p.)
> 3GPP Specifications (12 p.)
> OMA Specifications related to SIP
> TISPAN NGN Specifications (3 p.) o
> SIP Topics
> IMS Topics
 SIP/IMS Call Flows
> RFC3261's Example
> Basic -- RFC3665
> SIP PSTN -- RFC3666 (3 p.)
> SIP Service Examples (19 p.)
> IMS Signaling Flows (35 p.)
 SIP/IMS Architecture
> SIP Protocol Structure
> Dialogs & Routing
> UMTS Network Evolution
 Security
> PKIX-TLS-SMIME... Standards (20 p.) o
> Cryptography Basics
> ASN.1 for PKI Certificate & CRL Profile
> ASN.1 for CMS
> RFC3280's Certificate Examples (4)
> RFC4134's CMS-S/MIME Examples (14)
> RFC4474's SIP Authentication Service
> SSL/TLS Time-Diagrams
> IPSec Guides
 ABNF Grammars
> ABNF Notation & Rules
> URI Generic Syntax
> ABNF for SIP
> SIP Messages & URIs
> SIP Header Fields
> MIME Media Types
> ABNF for SDP
> ABNF for MSRP
> ABNF for MRCPv2
> ABNF for RTSP 2.0
> Internet Message Format
 DiffServ CoS Simulation
> IPVCoSS Simulator
> IP-VPN Case Study
  o (daily updated)
  Real-time Applications & Infrastructure (RAI) area
  > SIPwg   > SIPPINGwg   > SIMPLEwg   > P2PSIPwg   > BLISSwg   > MMUSICwg   > AVTwg
  > MEDIACTRLwg   > IPTELwg   > ENUMwg   > SIGTRANwg   > XCONwg   > GEOPRIVwg   > ECRITwg
  > SPEECHSCwg   > SPEERMINTwg   > Miscellaneous        
  Security (SEC) area
  > PKIXwg   > TLSwg   > SMIMEwg   > [IPSECwg]   > [SECSHwg]   > BTNSwg   > DKIMwg
  > EMUwg   > HOKEYwg   > ISMSwg   > KEYPROVwg   > KITTENwg   > KRBwg   > LTANSwg
  > MSECwg   > NEAwg   > SASLwg   > SYSLOGwg   > Miscellaneous    
  Miscellaneous Working Groups
  > BEHAVEwg   > HTTPBISwg   > EAPwg   > [AAAwg]   > DIMEwg   > [XMPPwg]  
             
             

Internet Drafts -- IESG's I-D Tracker States

The following diagram illustrates the tracking of Internet Drafts when they are submitted by the WG Chair to the IESG (Internet Engineering Steering Group) for publication. It should be noted that the WG Chair may issue a WGLC (Working Group Last-Call) before submitting an I-D to the IESG. However, this WGLC is not to be confused with the IESG Last Call that may be requested by an AD (Area Director) when considering an I-D for publication.

 

(ID States)
Sub States
Point Raised - writeup needed
IESG discussions on the document have raised some issues that need to be brought to the attention of the authors/WG, but those issues have not been written down yet. (It is common for discussions during a telechat to result in such situations. An AD may raise a possible issue during a telechat and only decide as a result of that discussion whether the issue is worth formally writing up and bringing to the attention of the authors/WG). A document stays in the "Point Raised - Writeup Needed" state until *ALL* IESG comments that have been raised have been documented.
AD Followup
A generic substate indicating that the shepherding AD has the action item to determine appropriate next steps. In particular, the appropriate steps (and the corresponding next state or substate) depend entirely on the nature of the issues that were raised and can only be decided with active involvement of the shepherding AD. Examples include: - if another AD raises an issue, the shepherding AD may first iterate with the other AD to get a better understanding of the exact issue. Or, the shepherding AD may attempt to argue that the issue is not serious enough to bring to the attention of the authors/WG. - if a documented issue is forwarded to a WG, some further iteration may be needed before it can be determined whether a new revision is needed or whether the WG response to an issue clarifies the issue sufficiently. - when a new revision appears, the shepherding AD will first look at the changes to determine whether they believe all outstanding issues have been raised satisfactorily, prior to asking the ADs who raised the original issues to verify the changes.
External Party
The document is awaiting review or input from an external party (i.e, someone other than the shepherding AD, the authors, or the WG). See the "note" field for more details on who has the action.
Revised ID Needed
An updated ID is needed to address the issues that have been raised.
Main States
I-D Exists
Initial (default) state for all internet drafts. Such documents are not being tracked by the IESG as no request has been made of the IESG to do anything with the document.
Publication Requested
A formal request has been made to advance/publish the document. The request could be from a WG chair, from an individual through the RFC Editor, etc. (The Secretariat is copied on these requests to ensure that the request makes it into the ID tracker.) A document in this state has not (yet) been reviewed by an AD nor has any official action been taken on it yet (other than to note that its publication has been requested.
AD is watching
An AD is aware of the document and has chosen to place the document in a separate state in order to keep a closer eye on it (for whatever reason). Documents in this state are still not being actively tracked in the sense that no formal request has been made to publish or advance the document. The sole difference between this state and "I-D Exists" is that an AD has chosen to put it in a separate state, to make it easier to keep track of (for his or her own reasons).
AD Evaluation
A specific AD (e.g., the "Area Advisor" for the WG) has begun their review of the document to verify that it is ready for advancement. The shepherding AD is responsible for doing any necessary review before starting an IETF Last Call or sending the document directly to the IESG as a whole.
IESG Evaluation
The document is now (finally!) being formally reviewed by the entire IESG. Documents are discussed in email or during a bi-weekly IESG telechat. In this phase, each AD reviews the document and airs any issues they may have. Unresolvable issues are documented as "discuss" comments that can be forwarded to the authors/WG. See the description of substates for additional details about the current state of the IESG discussion.
Last Call Requested
The AD has requested that the Secretariat start an IETF Last Call, but the the actual Last Call message has not been sent yet.
In Last Call
The document is currently waiting for IETF Last Call to complete. Last Calls for WG documents typically last 2 weeks.
Waiting for Writeup
Before a standards-track or BCP document is formally considered by the entire IESG, the AD must write up a protocol action. The protocol action is included in the approval message that the Secretariat sends out when the document is approved for publication as an RFC.
Waiting for AD Go-Ahead
As a result of the IETF Last Call, comments may need to be responded to and a revision of the ID may be needed as well. The AD is responsible for verifying that all Last Call comments have been adequately addressed and that the (possibly revised) document is in the ID directory and ready for consideration by the IESG as a whole.
Expert Review
An AD sometimes asks for an external review by an outside party as part of evaluating whether a document is ready for advancement. MIBs, for example, are reviewed by the "MIB doctors". Other types of reviews may also be requested (e.g., security, operations impact, etc.) Documents stay in this state until the review is complete and possibly until the issues raised in the review are addressed. See the "note" field for specific details on the nature of the review.
IESG Evaluation - Defer
During a telechat, one or more ADs requested an additional 2 weeks to review the document. A defer is designed to be an exception mechanism, and can only be invoked once, the first time the document comes up for discussion during a telechat.
Approved-announcement to be sent
The IESG has approved the document for publication, but the Secretariat has not yet sent out on official approval message.
Approved-announcement sent
The IESG has approved the document for publication, and the Secretariat has sent out the official approval message to the RFC editor.
RFC Ed Queue
The document is in the RFC editor Queue (as confirmed by http://www.rfc-editor.org/queue.html)
RFC Published
The ID has been published as an RFC.
DNP-waiting for AD note
Do Not Publish: The IESG recommends against publishing the document, but the writeup explaining its reasoning has not yet been produced. DNPs apply primarily to individual submissions received through the RFC editor. See the "note" field for more details on who has the action item.
DNP-announcement to be sent
The IESG recommends against publishing the document, the writeup explaining its reasoning has been produced, but the Secretariat has not yet sent out the official "do not publish" recommendation message.
Dead
Document is "dead" and is no longer being tracked. (e.g., it has been replaced by another document with a different name, it has been withdrawn, etc.)
  
Last update: February 7, 2008 
  
(to top) © 2005-2008 Joël Repiquet, All Rights Reserved.