Skip to main content

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