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
