[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #100: Gen-ART Review
#100: Gen-ART Review
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,...
--
----------------------------------------+-----------------------------------
Reporter: mary.ietf.barnes@â | Owner:
Type: defect | Status: new
Priority: minor | Milestone: milestone1
Component: Crypto-Agility | Version: 1.0
Severity: Submitted WG Document | Keywords:
----------------------------------------+-----------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/100>
radext <http://tools.ietf.org/radext/>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>