Document: draft-ietf-msec-gsakmp-sec-08.txt Review: John Loughney Date: 31 mars 2005 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.