I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-radext-crypto-agility-requirements-06.txt Reviewer: Mary Barnes Review Date: 3 June 2011 IETF LC End Date: 14 June 2011 Summary: Almost Ready. The document is well written and concise. My primary concerns (minor issues really) are the many references to the WG, mailing list, IETF meetings, that while useful context for folks deeply involved in the activity, the information is not relevant to a broader audience and clutters the document IMHO. In addition, there are a few cases where I think normative language might be required (going along with the idea that normative language is appropriate in an Informational document). Major issue: - None Minor issue: - Introduction: It's my understanding that published RFCs shouldn't reference specific WGs and this sentence includes "when approved" which doesn't fit in the body of an RFC. Also, it's my understanding that any document published by a WG reflects consensus of that WG. So, I would suggest this sentence could be better stated as follows: OLD: This memo, when approved, reflects the consensus of the RADIUS Extensions (RADEXT) Working Group of the IETF as to the features, properties and limitations of the crypto-agility work item for RADIUS. NEW: This memo describes the features, properties and limitations of the crypto-agility solution for RADIUS. - General. I don't think you need references to the RADEXT WG since it a product of that WG - it's listed in the document header and it's obvious in the tools. Folks that aren't familiar with IETF probably don't care what WG produced the document. Subsequent comments below give specific suggestions around this. - Introduction,second paragraph. I don't think this necessarily fits the context of a published RFC. In general, the content of WG documents is based on mailing list discussion. And, it's usual that an informational document is published to provide the type of information that is noted in that paragraph. So, I would think you could just delete that paragraph. - Section 1.3. I don't think the background is necessary. Certainly, the motivation for this work is useful introductory information, but I think that initial problem statement/objectives could be reworded in present tense in terms of objectives and what this document specifies. - SEction 2. You could easily strike the first sentence in the first paragraph without any loss of information. Does it really matter that the definition was offered at IETF-68? - Section 2, 4th paragraph. Why is the second part of the first sentence a SHOULD NOT? What happens if this is done? For example, does this require additional specification of how the solution is still backwards compatible? It's generally a good idea to describe what might happen if someone doesn't abide by a SHOULD or SHOULD NOT. - Section 4.2, 5th paragraph, 1st sentence. Shouldn't the "need not" be stated using normative language - i.e., stated as "OPTIONAL", something like "Support for encryption of individual RADIUS attributes is OPTIONAL for solutions that provide encryption of entire RADIUS packets". - Section 4.2, "Limit key scope" paragraph. Should the "not required" be "is OPTIONAL"? - Section 4.3, 3rd paragraph. Shouldn't the "can be" be a "MAY be"? - i.e, isn't this normative behavior in terms of describing how the requirements for backwards compatibility can be satisfied or in some cases where they can't? - Section 4.3, 4th paragraph. Shouldn't the "can omit" be a "MAY omit"? - Section 4.3, 6th paragraph. Shouldn't the "can be" be a "MAY be"? - Section 4.6. This could be reworded to remove the references to IETF-70 and just state something like the following: OLD: At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG debated whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). The working group determined that AKM was not inherently required for RADIUS based on the following points: NEW: Consideration was given as to whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). It was determined that AKM was not inherently required for RADIUS based on the following points: Nits: ----- - Section 4.6, 1st paragraph after the bulleted list: .., the same time, … -> …, at the same time,...
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art