The Group Domain of Interpretation
RFC 6407
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
11 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2016-11-30
|
11 | Wesley Eddy | Closed request for Last Call review by TSVDIR with state 'Unknown' |
|
2015-10-14
|
11 | (System) | Notify list changed from msec-chairs@ietf.org, draft-ietf-msec-gdoi-update@ietf.org to (None) |
|
2013-02-23
|
(System) | Posted related IPR disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 6407 | |
|
2012-08-22
|
11 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
|
2011-10-17
|
11 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-10-14
|
11 | (System) | RFC published |
|
2011-09-09
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-09-09
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2011-09-09
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2011-08-26
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-08-26
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2011-08-25
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-08-16
|
11 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-08-15
|
11 | (System) | IANA Action state changed to In Progress |
|
2011-08-15
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2011-08-15
|
11 | Amy Vezza | IESG has approved the document |
|
2011-08-15
|
11 | Amy Vezza | Closed "Approve" ballot |
|
2011-08-15
|
11 | Amy Vezza | Approval announcement text regenerated |
|
2011-08-15
|
11 | Amy Vezza | Ballot writeup text changed |
|
2011-08-12
|
11 | (System) | New version available: draft-ietf-msec-gdoi-update-11.txt |
|
2011-08-11
|
11 | Cindy Morgan | Removed from agenda for telechat |
|
2011-08-11
|
11 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation. |
|
2011-08-10
|
11 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-09
|
11 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-09
|
11 | Stephen Farrell | [Ballot comment] (1) Shouldn't DES and other algorithms be deprecated more obviously? E.g. 5.3.2.1 doesn't say not to do this. Same question for MD5 in … [Ballot comment] (1) Shouldn't DES and other algorithms be deprecated more obviously? E.g. 5.3.2.1 doesn't say not to do this. Same question for MD5 in SIG_HASH_MD5 etc. (2) Has anything been learned about authorizing GKCS's since rfc 3547? If so, wouldn't it be good to include something about that, even if it doesn't provide a fool-proof way to authorize a host as a GKCS? (Text like that would go nicely in 3.1 I think.) |
|
2011-08-09
|
11 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-09
|
11 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-09
|
11 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-09
|
11 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-09
|
11 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-09
|
11 | Adrian Farrel | [Ballot comment] You resolved my Discuss. Thanks. |
|
2011-08-09
|
11 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
|
2011-08-08
|
10 | (System) | New version available: draft-ietf-msec-gdoi-update-10.txt |
|
2011-08-07
|
11 | Gonzalo Camarillo | [Ballot comment] The draft says it describes an "updated" version of GDOI. However, the draft seems to obsolete the previous spec, not to update it. … [Ballot comment] The draft says it describes an "updated" version of GDOI. However, the draft seems to obsolete the previous spec, not to update it. In any case, this has already been captured in Adrian's discuss. |
|
2011-08-07
|
11 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-06
|
11 | Sean Turner | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-08-06
|
11 | Adrian Farrel | [Ballot discuss] It looks to my uneducated eye that this is intended to obsolete 3547 not to update it. |
|
2011-08-06
|
11 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-08-01
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Hartman |
|
2011-08-01
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Hartman |
|
2011-08-01
|
11 | Samuel Weiler | Assignment of request for Last Call review by SECDIR to Sam Hartman was rejected |
|
2011-07-19
|
11 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
|
2011-07-19
|
11 | Sean Turner | Ballot has been issued |
|
2011-07-19
|
11 | Sean Turner | Created "Approve" ballot |
|
2011-07-19
|
11 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-07-18
|
11 | Amanda Baber | IANA has questions related to the IANA Actions contained in this document. IANA understands that, upon approval of this document, there are twenty IANA Actions … IANA has questions related to the IANA Actions contained in this document. IANA understands that, upon approval of this document, there are twenty IANA Actions which need to be completed. First, in the SA KEK Payload Values - SIG_HASH_ALGORITHM subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the following new values should be registered: Registry Value Algorithm Type Reference ---------- --------------------------- ------------ TBD-2 SIG_HASH_SHA256 [ RFC-to-be ] TBD-3 SIG_HASH_SHA384 [ RFC-to-be ] TBD-4 SIG_HASH_SHA512 [ RFC-to-be ] Second, in the SA KEK Payload Values - SIG_ALGORITHM subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the following new values should be registered: Registry Value Algorithm Type Reference ---------- --------------------------- ------------ TBD-7 SIG_ALG_ECDSA-256 [ RFC-to-be ] TBD-8 SIG_ALG_ECDSA-384 [ RFC-to-be ] TBD-9 SIG_ALG_ECDSA-521 [ RFC-to-be ] IANA QUESTION -- Shouild the Algorithm Type really be named SIG_ALG_ECDSA-521? Should it be SIG_ALG_ECDSA-512? Third, in the SA TEK Payload Values - Protocol-ID subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the following new value should be registered: Value Protocol ID Reference ---------- -------------------------- --------- TBD-5 GDOI_PROTO_IPSEC_AH [ RFC-to-be ] Fourth, in the Next Payload Types subregistry of the "Magic Numbers" for ISAKMP Protocol registry located at: http://www.iana.org/assignments/isakmp-registry the following new value should be registered: Value Next Payload Type Reference -------- ---------------------------------- --------- TBD-1 SA Group Associated Policy (GAP) [ RFC-tobe ] Fifth, in the Key Download Type Values subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads a new value should be registered as follows: Registry: Value Key Download Type Reference -------- ------------------------ --------- TBD-6 SID [ RFC-to-be ]. Sixth,IANA will create a new registry called "GAP Payload Policy Attributes" in the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads The initial values for this registry will be: Attribute Type Value Type ---- ----- ---- RESERVED 0 ACTIVATION_TIME_DELAY 1 B DEACTIVATION_TIME_DELAY 2 B SENDER_ID_REQUEST 3 B Standards Action 4-127 Private Use 128-255 Unassigned 256-32767 The registration procedures Standards Action and Private Use are as defined in RFC 5226. Seventh, in the IPSEC Security Association Attributes registry located in the "Magic Numbers" for ISAKMP Protocol registry located at: http://www.iana.org/assignments/isakmp-registry a new Security Association Attribute is to be added as follows: Registry: Value Type Class Reference ------------ ---- ----------------------------------- --------- TBD-10 B Address Preservation [ RFC-to-be ] For this new attribute, a new subregistry is to be created as follows: Sub-registry: Address Preservation Values (Value TBD-10) Reference: [ RFC-to-be ] Registry: Value Name Reference ------------ ---------------------------- --------- 0 Reserved [ RFC-to-be ] 1 None [ RFC-to-be ] 2 Source-Only [ RFC-to-be ] 3 Destination-Only [ RFC-to-be ] 4 Source-And-Destination [ RFC-to-be ] 5-61439 Standards Action [ RFC-to-be ] 61440-65535 Private Use [ RFC-to-be ] The registration procedures Standards Action and Private Use are as defined in RFC 5226. Eigth, in the IPSEC Security Association Attributes registry located in the "Magic Numbers" for ISAKMP Protocol registry located at: http://www.iana.org/assignments/isakmp-registry a new Security Association Attribute is to be added as follows: Registry: Value Type Class Reference ------------ ---- ----------------------------------- --------- TBD-11 B SA Direction [ RFC-to-be ] For this new attribute, a new subregistry is to be created as follows: Sub-registry: SA Direction Values (Value TBD-11) Reference: [ RFC-to-be ] Registry: Value Name Reference ------------ ---------------------------- --------- 0 Reserved [ RFC-to-be ] 1 Sender-Only [ RFC-to-be ] 2 Receiver-Only [ RFC-to-be ] 3 Symmetric [ RFC-to-be ] 4-61439 Standards Action [ RFC-to-be ] 61440-65535 Private Use [ RFC-to-be ] The registration procedures Standards Action and Private Use are as defined in RFC 5226. Ninth, IANA will create a new subregistry of the registry called "Key Download Type values" in the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads Sub-registry: SID Download Types Reference: [ RFC-to-be ] Registration Procedures: Standards Action Registry: Value KEK Class Type Reference -------- ------------------------ ----- --------- 0 RESERVED 1 NUMBER_OF_SID_BITS B [ RFC-to-be ] 2 SID_VALUE V [ RFC-to-be ] 3-128 Standards Action [ RFC-to-be ] 129-255 Private Use [ RFC-to-be ] 256-32767 Unassigned [ RFC-to-be ] Tenth, in the SA KEK Payload Values - POP Algorithm subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 4-127 are to be have their registration procedure set to Standards Action. Values 256-32767 are to be added and designated Unassigned. Eleventh, in the SA KEK Payload Values - KEK Attributes subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 9-127 are to added and have their registration procedure set to Standards Action. The values 128-255 are to be added and designated Private Use. The values 256-32767 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] Twelveth, in the SA KEK Payload Values - KEK_MANAGEMENT_ALGORITHM subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 2-127 are to have their registration procedure set to Standards Action. Values 256-65535 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] Thirteenth, in the SA KEK Payload Values - KEK_ALGORITHM subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 4-127 are to have their registration procedures set to Standards Action. Values 256-65535 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] Fourteenth, in the SA KEK Payload Values - SIG_HASH_ALGORITHM subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 3-127 are to have their registration procedures set to Standards Action. Values 256-65535 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] Fifteenth, in the SSA KEK Payload Values - SIG_ALGORITHM subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 4-127 are to have their registration procedures set to Standards Action. Values 256-65535 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] Sixteenth, in the SA TEK Payload Values - Protocol-ID subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 2-127 are to have their registration procedures set to Standards Action. Each with a reference of [ RFC-to-be ] Seventeenth, in the Key Download Type Values subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 4-127 are to have their registration procedures set to Standards Action. Each with a reference of [ RFC-to-be ] Eighteenth, in the TEK Download Type subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 4-127 are to have their registration procedures set to Standards Action. Values 128-255 are to be added and designated Private Use. Values 256-32767 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] Nineteenth, in the KEK Download Type subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 3-127 are to have their registration procedures set to Standards Action. Values 128-255 are to be added and designated Private Use. Values 256-32767 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] Twentieth, in the LKH Download Type subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at: http://www.iana.org/assignments/gdoi-payloads the values 4-127 are to have their registration procedures set to Standards Action. Values 256-32767 are to be added and designated Unassigned. Each with a reference of [ RFC-to-be ] IANA understands that these twenty actions are all that are required to be completed upon approval of this document. |
|
2011-07-09
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Hartman |
|
2011-07-09
|
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Hartman |
|
2011-07-06
|
11 | Wesley Eddy | Request for Last Call review by TSVDIR is assigned to Fernando Gont |
|
2011-07-06
|
11 | Wesley Eddy | Request for Last Call review by TSVDIR is assigned to Fernando Gont |
|
2011-07-05
|
11 | Sean Turner | Placed on agenda for telechat - 2011-08-11 |
|
2011-07-05
|
11 | Sean Turner | Status Date has been changed to 2011-07-05 from None |
|
2011-07-05
|
11 | Amy Vezza | Last call sent |
|
2011-07-05
|
11 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <msec@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-msec-gdoi-update-09.txt> (The Group Domain of Interpretation) to Proposed Standard The IESG has received a request from the Multicast Security WG (msec) to consider the following document: - 'The Group Domain of Interpretation' <draft-ietf-msec-gdoi-update-09.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an updated version of the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. DOWNREFs This specification contains three normative references to obsoleted RFCs: RFC 2407, RFC 2408, and RFC 2409. This specification contains three normative references to informational RFCs: RFC 2627, RFC 3447, and RFC 5093. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/ No IPR declarations have been submitted directly on this I-D. |
|
2011-07-05
|
11 | Sean Turner | Last Call was requested |
|
2011-07-05
|
11 | (System) | Ballot writeup text was added |
|
2011-07-05
|
11 | (System) | Last call text was added |
|
2011-07-05
|
11 | (System) | Ballot approval text was added |
|
2011-07-05
|
11 | Sean Turner | State changed to Last Call Requested from Publication Requested. |
|
2011-07-05
|
11 | Sean Turner | Last Call text changed |
|
2011-07-05
|
11 | Sean Turner | Ballot writeup text changed |
|
2011-07-05
|
11 | Amy Vezza | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Vincent Roca is the shepherd. I have personally reviewed this document and believes it's ready for IESG consideration. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by the MSEC WG three times: - a very preliminary version (-01) went through WGLC in Feb 2007: => no comment sent to the list Then the work entered in standby mode till 2010... - July 2010 WGLC for the -06 version: follows a several comments sent by Yoav Nir for the -05 version and that have been addressed in -06. He's okay with this version. Comment from Mark Baugher. Addressed in -07 version - comments for -07 version by Vincent Roca - April 2011 WGLC for the -08 version => comments from Yoav Nir, Sean Turner, Lewis Chen, and Suresh Melam (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Good consensus. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? IdNits returns: -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2627 ** Downref: Normative reference to an Informational RFC: RFC 3447 ** Downref: Normative reference to an Informational RFC: RFC 5903 See (1.h)... (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has both normative and informative documents. Among the normative references are 3 documents that have been obsoleted by the IPsec-v3 RFCs (RFC 4301, etc.). These RFCs were made obsolete by the publication of IKEv2, without regard for the fact that although IKEv1 was directly obsoleted by IKEv2, other RFCs relying on those protocol definitions were not directly obsoleted by the publishing of IKEv2. WG chairs believe that updating GDOI as defined in RFC 3547 (and thus continuing to rely on these references) is necessary for interoperability. Also among the normative references are 3 "Downref" (Informational): RFC 2627, RFC 3447, and RFC 5903. These documents "must be read to understand or implement the technology", which <http://www.ietf.org/iesg/statement/normative-informative.html> defines as normative references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document includes a detailed IANA section. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? N/A (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Technical Summary This document describes an updated version of the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. Working Group Summary This document, in its initial form (2006-2007) raised little discussion in the group. Then it entered dormant mode till its revival in 2010. Since then several reviews took place and issues found have been gracefully corrected. Document Quality Cisco has a GDOI implementation. The experience gained while implementing GDOI justified recent changes to the document. |
|
2011-07-05
|
11 | Amy Vezza | Draft added in state Publication Requested |
|
2011-07-05
|
11 | Amy Vezza | [Note]: 'Vincent Roca (vincent.roca@inria.fr) is the shepherd.' added |
|
2011-07-05
|
11 | Brian Weis | Revised I-D addressed WGLC comments, forwarded to Sean for IETF LC. |
|
2011-07-05
|
11 | Brian Weis | IETF state changed to Submitted to IESG for Publication from WG Document |
|
2011-07-05
|
11 | Brian Weis | Revised I-D addressed WGLC comments, forwarded to Sean for IETF LC. |
|
2011-07-05
|
11 | Brian Weis | Annotation tag Revised I-D Needed - Issue raised by WGLC cleared. |
|
2011-07-01
|
09 | (System) | New version available: draft-ietf-msec-gdoi-update-09.txt |
|
2011-05-25
|
11 | Brian Weis | Authors waiting for a key review. |
|
2011-05-25
|
11 | Brian Weis | Annotation tag Revised I-D Needed - Issue raised by WGLC set. |
|
2011-03-14
|
08 | (System) | New version available: draft-ietf-msec-gdoi-update-08.txt |
|
2010-10-25
|
07 | (System) | New version available: draft-ietf-msec-gdoi-update-07.txt |
|
2010-07-12
|
06 | (System) | New version available: draft-ietf-msec-gdoi-update-06.txt |
|
2010-03-08
|
05 | (System) | New version available: draft-ietf-msec-gdoi-update-05.txt |
|
2009-09-10
|
11 | (System) | Document has expired |
|
2009-03-09
|
04 | (System) | New version available: draft-ietf-msec-gdoi-update-04.txt |
|
2007-09-18
|
03 | (System) | New version available: draft-ietf-msec-gdoi-update-03.txt |
|
2007-03-05
|
02 | (System) | New version available: draft-ietf-msec-gdoi-update-02.txt |
|
2006-10-20
|
01 | (System) | New version available: draft-ietf-msec-gdoi-update-01.txt |
|
2006-06-19
|
00 | (System) | New version available: draft-ietf-msec-gdoi-update-00.txt |