Lots or review comments from John Loughney, but none of them look like show-stoppers:

Review of draft-ietf-msec-gsakmp-sec-08.txt

Summary:

This is generally ready for publication as a proposed standard.  The Vendor ID Payload
is my biggest open issue, however I am not sure how this should be resolved. Some nits were
found, but these could be updated if the document is revised.  The document
was well written and I appreciated the list of figures and tables.  Please note
that this is an area outside of my area of expertise, so I assume that the terminology,
etc. are well known within the documents target audience.  One general request that 
I would have would be the expansion of acronyms in section titles, such as:

 4.4.2 Creation of a PT

  - would become:

 4.4.2 Creation of a Policy Token

Just as there is a lot of acronyms and I found that I had to keep refering back to 
Chapter 2 Terminology (which doesn't contain all fo the acronyms, by the way).
  
Questions:

1) Section "3.2.3 LKH" says:

 When group policy dictates that a recovery of the group security is
 necessary after the discovery of the compromise of a GM, then GSAKMP
 relies upon a rekey capability, i.e., LKH, to enable group recovery after
 a compromise [RFC 2627].  This is optional since in many instances it may be
 better to destroy the compromised group and rebuild a secure group.

but then section "3.4 Rekey Availability"

 In addition to GSAKMP having the capability to do rekey operations, GSAKMP
 MUST also have the capability to make this rekey information highly
 available to GMs.  The necessity of GMs receiving rekey messages, requires
 the use of methods to increase the likelihood of receipt of Rekey Messages.
 These methods MAY include multiple transmissions of the rekey message,
 posting of the rekey message on a bulletin board, etc.  Compliant GSAKMP
 implementations MUST support retransmission of rekey messages.

Section 3.2.3 seems to indicate that rekeying is optional but 3.4 has a MUST for
the retransmission of rekey messaging.  My question is, is the rekeying operation
mandatory or optional?  Or is it just that after a group is compromised, it is
optional to rekey, as it may be preferable to destroy the group entirely?  The
current text is not so clear.

2) General question on Vendor-ID payload, secton 7.10:

 Writers of Internet-Drafts who wish to extend this protocol MUST define a
 Vendor ID payload to announce the ability to implement the extension in the
 Internet-Draft.  It is expected that Internet-Drafts which gain acceptance
 and are standardized will be given assigned values out of the Reserved to
 IANA range and the requirement to use a Vendor ID payload will go away.

I had a little trouble parsing this.  Does this mean that Vendor-IDs should
generally be written-up as Internet drafts?  Should there be a registry
for the vendor payloads?  Additionally, the packet format doesn't say
what the VID is.  

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                         Vendor ID (VID)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should this be using the IANA assigned "SMI Network Management Private Enterprise 
Codes"?


Small nits:

1) Shouldn't Abstract be left justified?
2) Text needs to be indented in most places.
3) Double spacing before and after section headings should be changed
   to single spacing.
4) CRL is used in section 3.1, item 8, but I couldn't find an expansion
   on what CRL is.
5) Expansion of some protocols like ISAKMP, FIPS Pub 196, LKH etc. would
   be helpful.
6) In many places, the ` is used, shouldn't ' be used instead? Also,
   `` and '' is used, but shouldn't " be used instead?

Ran idnits script and found the following nits:

idnits 1.61 
  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement  -- however, there's a paragraph with a matching beginning.
    Boilerplate error?
  * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
    Acknowledgement. 
  * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
    Acknowledgement. 
  * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
    Invitation. 
  * There are 1222 instances of too long lines in the document, the longest
    one being 8 characters in excess of 72.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about 6 months
    document validity -- however, there's a paragraph with a matching beginning.
    Boilerplate error?

  Miscellaneous warnings:

  - The "Author's Address" (or "Authors' Addresses") section title is
    misspelled.

    Run idnits with the --verbose option for more detailed information.

In 7.6.1, the draft says:

DN Data (variable length)  -- The actual UTF-8 DN value (Subject
    field) using the slash (/) character for field delimiters.  (e.g.,
    "/C=US/ST=MD/L=Somewhere/O=ACME,  
Inc./OU=DIV1/CN=user1/Email=user1@acme.com"
    without the surrounding quotes)

Would it be beneficial to add  a pointer to the specific DN format required here?
I'm thinking, for example, of the discussion we just had relative to
draft-ietf-ldapbis-dn-15.txt.

This protocol contains many optional out of band features like
eviction of members.  Similarly, finding subordinate GC/KS may be
challenging.  It will be difficult to get multiple interoperable
implementations of all these features and advance the protocol to draft
standard.

I'm surprised that the protocol mandates neither AES nor RSA.


The protocol does a good job of meeting its requirements and for
relatively high security need/high infrastructure group management
this protocol is a good fit.  I think the IETF has need of a group SA
management protocol that works in less rigorous environments.  AS an
example I don't think this protocol would be appropriate for OSPF v3
or for other routing/ops area needs.  I think that the same pressures
that required us to add EAP support to IKEV2 will require us to
provide a group management protocol that supports whatever credentials
the deployment environment happens to have.  It's not a problem with
this protocol that those needs are not met; we just have more work to
do.  Also, I realize that making a variant of this protocol that met
those needs would be relatively easy.

sent:

Sent:

Russ, Ran and Lakshminath,

The new IANA rules  make the extensibility much
more appropriate to the protocol security.  Thanks!

I've copied IANA so that the change can be flagged, since
I instigated it.

Since you have specified Expert Review for some of the fields,
I want to draw your attention to a suggestion:  it's a good
thing to appoint the Expert Reviewer (or two, a Primary and
Secondary) now, before the approval goes out, and have it
included in the IANA Note on the announcement, so this
important step gets handled very transparently (and not
forgotten).

My clearing isn't gated on it (I'm done, bye :)   

I'm suggesting you guys and IANA get this done before Russ
sends in the final approve...

Not sent:  I re-reviewed Vendor ID - it seems safe enough to me; it seems an
unscrupulous extender would not exploit it very easily.