Subject: Remaing issues on draft-ietf-radext-crypto-agility-requirements

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Sep 2011 10:36:19 -0700

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. 

[MB] - Section 4.3, 6th paragraph.  Shouldn't the "can be" be a "MAY be"?

[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) <[email-masked]>

Date: Thu, Aug 4, 2011 at 12:01 PM
Subject: FW: new version of draft-ietf-radext-crypto-agility-requirements
To: Dave Nelson <[email-masked]>
Cc: Mary Barnes <[email-masked]>, Russ Housley <[email-masked]>, "Sanchez, Mauricio (HP Networking)" <[email-masked]>, [email-masked]

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:[email-masked]] 

Sent: Wednesday, August 03, 2011 8:51 PM
To: Russ Housley
Cc: Romascanu, Dan (Dan)
Subject: Re: new version of draft-ietf-radext-crypto-agility-requirements
 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 <[email-masked]> wrote:
Mary:

Please let me know if the new version resolves you concerns.

Russ

= = = = = = = = = =

Discuss (2011-07-11) 

 The Gen-ART Review by Mary Barnes raises quire a few concerns.  It
 deserves a response.  The review can be found at:

   http://wiki.tools.ietf.org/dav/genart/reviews/

   draft-ietf-radext-crypto-agility-requirements-06-barnes.txt

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Sep 2011 14:30:54 +0200

From: Dave Nelson [mailto:[email-masked]] 

[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

[DN] I guess either approach would work.  While there are clearly
established styles for RFCs, I think that some of the "rules" can be
relaxed for an "in-house" document, such as a requirements document.

[[DR]] Actually I do not think that the IESG note approach would work.
This work is not only 'related to IETF work done in the RADEXT WG' but
is actually a result of chartered work in the WG. 

Maybe the way to go is to talk with Russ and see whether he stands
behind the first three comments in the GenART review. Russ knows well
the history and the background of this work, and he may have an opinion
whether including the history of the document and the WG road
information is useful. 

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Sep 2011 15:23:49 +0200

I suggest that Bernard (as document shepherd) sends a version of his
query mail to Russ truncated to the first three issues. 

Regards,

Dan

From: Dave Nelson [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2011 4:21 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: Remaing issues on
draft-ietf-radext-crypto-agility-requirements

On Tue, Sep 6, 2011 at 8:30 AM, Romascanu, Dan (Dan)
<[email-masked]> wrote:

	Maybe the way to go is to talk with Russ and see whether he
stands behind the first three comments in the GenART review. Russ knows
well the history and the background of this work, and he may have an
opinion whether including the history of the document and the WG road
information is useful.

That sounds like a good idea.   Who do you suggest should approach Russ?

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636