Multicast Security (MSEC) Group Key Management Architecture
draft-ietf-msec-gkmarch-08

[Ballot discuss]
There was an unfortunate lack of communication of between the reliable multicast transport
working group and msec about the progress on protocols in RMT.  Although the works on
FEC based large scale and Nack-based reliable based reliable multicast are not standards track,
they are approved with Statements of Intent to go to Proposed Standard, and I think it would
be reasonable to include pointers to this work rather than stating that there's a great need,
showing implosion and scalability as a major problem, and implying that there's no consensus
and a vacuum of work.

Informative references to add:

RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation. M.
    Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. December 2002

B. Adamon, C. Bormann, M. Handley, J. Macker,
  NACK-Oriented Reliable Multicast Protocol (NORM),
  draft-ietf-rmt-pi-norm-10.txt


Text to modify:

                        However, there are no standard reliable
        multicast protocols at the present time.  Thus, this document makes
        no recommendation for use of a particular reliable multicast
        protocol or set of protocols for the purposes group key management.


  Reliable multicast protocols have not been brought into the standards track
  at this time, though IETF consensus has been reached on two protocols that are
  intended to go into the standards track [cite].  Currently this document does not
  recommend a particular reliable multiple protocol or set of protocols for the
  purpose of group key management.

[Ballot discuss]
There was an unfortunate lack of communication of between the reliable multicast transport
working group and msec about the progress on protocols in RMT.  Although the works on
FEC based large scale and Nack-based reliable based reliable multicast are not standards track,
they are approved with Statements of Intent to go to Proposed Standard, and I think it would
be reasonable to include pointers to this work rather than stating that there's a great need,
showing implosion and scalability as a major problem, and implying that there's no consensus
and a vacuum of work.

Informative references to add:

RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation. M.
    Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. December 2002

B. Adamon, C. Bormann, M. Handley, J. Macker,
  NACK-Oriented Reliable Multicast Protocol (NORM),
  draft-ietf-rmt-pi-norm-10.txt

[Ballot comment]
The "Comments on this document should be sent to msec@securemulticast.org" text at the end of the abstract should be removed.

Section 5.5
The "If all or even many members contact the GCKS at about the same time, the GCKS cannot handle all those messages" text sounds too absolute to me because there are ways to provide reliable service with load balancing, fast processors, etc.  It might be better phrased as "If all or even many members contact the GCKS at about the same time, there is a risk that the GCKS will be unable to process all of the messages".  This could also be addressed in section 7.

References should be split normative/informative.