|
The -07 version of the Crypto-agility document (see http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-07) addressed, some, but not all of the GENART review comments.
As document shepard, I'd like to get the WG's opinion on the remaining issues. Below, find the original email from Mary Barnes (the GENART reviewer, denoted as [MB]), and my response, relating to the status of the comments (denoted as [BA]). To move forward, I'd encourage WG participants to provide their opinion on how the comments should be resolved. ================================================================================================== [MB] - 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.
[BA] The RADEXT WG
is mentioned in the document header, and in Sections 1.1 and 1.3.
I believe that these mentions were made to remind the IESG of the process that was originally agreed to. During discussion of crypto-agility, there seems to have been some confusion on the original charge, how it originated and what it covered. I believe this is why the context is provided in Section 1.1, covering where the IETF 66 discussion occurred
(e.g. in RADEXT as opposed to OPSAWG, AAA WG or DIME) so as to pinpoint the relevant proceedings and minutes.
Since the publication of crypto-agility solutions is ocurring in
RADEXT, Section 1.3 on publication procedures also mentions the RADEXT
WG.
[MB] -
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.
[BA] The mailing
list discussion is mentioned to describe how the document evolved in response to the original IESG request. Alternatively, it would be possible to cite the RFC 6218
IESG note:
IESG Note The IESG has concluded that this work is related to IETF work done in the RADEXT WG, but this relationship does not prevent publishing. The IESG recommends that the RADEXT WG proceed with the work for an interoperable modern key wrap solution using attributes from the standard space as part of its charter.
[MB] - 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. [MB] While, the author deleted this section, they just moved the text to the Introduction rather than rewording the initial problem statement/objectives. [/MB]
[BA] I believe the background is there to provide the IESG with context that may no longer be apparent.
[MB] -
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?
[BA] Due to the definition of "MAY" in the Requirements section (not the same in this document as in RFC 2119!), were a "MAY" to be added here, it would not have an effect, since "MAYs" are not used in evaluating submissions. I believe this is why the change was not made.
[BA] - Section 4.3, 4th paragraph. Shouldn't the "can omit" be a "MAY omit"?
[BA] It can be changed, but as noted above, because of the changed requirements language, this wouldn't affect the selection process.
[BA] It can be changed, but as noted above, because of the changed requirements language, this wouldn't affect the selection process. ---------- Forwarded message ---------- From: Romascanu, Dan (Dan) <dromasca@avaya.com> Date: Thu, Aug 4, 2011 at 12:01 PM Subject: FW: new version of draft-ietf-radext-crypto-agility-requirements To: Dave Nelson <dnelson@elbrys.com> Cc: Mary Barnes <mary.ietf.barnes@gmail.com>, Russ Housley <housley@vigilsec.com>, "Sanchez, Mauricio (HP Networking)" <mauricio.sanchez@hp.com>, jouni.korhonen@nsn.com Hi Dave,
It looks that there are a few more issues from the GenART review left unaddressed in the latest version. Can you please answer based on the list below, either suggest fixes or explain why you believe the issues are not a problem?
Thanks and Regards,
Dan
From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
I just reviewed the diff and not all the issues were addressed (as listed below). I don't recall seeing a response from the author as to why they were not addressed or why the author felt the recommendations were not applicable. If you'd like, I can send out an official gen-art re-review.
Regards, Mary.
The following "Minor issues" were not addressed in the -07:
- 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. [MB] While, the author deleted this section, they just moved the text to the Introduction rather than rewording the initial problem statement/objectives. [/MB]
- 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"?
On Wed, Aug 3, 2011 at 11:28 AM, Russ Housley <housley@vigilsec.com> wrote: Mary: On Aug 3, 2011, at 8:11 AM, Romascanu, Dan (Dan) wrote: > > > Hi Russ, > > A new version of draft-ietf-radext-crypto-agility-requirements was > submitted a few days ago. This version should resolve the concerns > expressed in you DISCUSS and the Gen-ART review. Can you check if you > are in the position to clear? > > Thanks and Regards, > > Dan >
-- Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 |