Subject: [radext] #100: Gen-ART Review

From: "radext issue tracker" <[email-masked]>
Date: Sat, 04 Jun 2011 21:30:58 -0000

#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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>