Subject: Re: [lamps] Opsdir last call review of draft-ietf-lamps-rfc5751-bis-07

From: Jim Schaad <[email-masked]>
Date: Wed, 2 May 2018 11:54:22 -0700

I have published a -08 with these changes.

> -----Original Message-----
> From: Zitao Wang <[email-masked]>
> Sent: Sunday, April 15, 2018 11:14 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Opsdir last call review of draft-ietf-lamps-rfc5751-bis-07
> 
> Reviewer: Zitao Wang
> Review result: Has Nits
> 
> I have reviewed this document as part of the Operational directorate’s
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written with the intent of improving the operational
> aspects of the IETF drafts. Comments that are not addressed in last call may
> be included in AD reviews during the IESG review.  Document editors and
> WG chairs should treat these comments just like any other last call
> comments.
> 
> Document reviewed:  draft-ietf-lamps-rfc5751-bis-07
> 
> Summary:
> 
> This document defines Secure/Multipurpose Internet Mail Extensions
> (S/MIME) version 4.0.  S/MIME provides a consistent way to send and
> receive secure MIME data.  Digital signatures provide authentication,
> message integrity, and non-repudiation with proof of origin. Encryption
> provides data confidentiality.
>  Compression can be used to reduce data size.  This document obsoletes RFC
> 5751.
> 
> Firstly, this document list a set of encryption algorithm, but a lot of them miss
> references, it difficult to understanding, especially for the reader who may
> lack of the encryption knowledges. For example:
> 
>  Section 1.5:
> 
>  s/key wrapping algorithm/key wrapping algorithm[rfc3394]
> 
>  s/Diffie-Hellman (DH) algorithm/Diffie-Hellman (DH) algorithm [rfc2631]
> 
>  s/RSA public key algorithm/RSA public key algorithm [RFC3447]  Section 2.2:
> 
>  s/RSA PKCS#1 v1.5/RSA PKCS#1 v1.5 [RFC2313]

All except the first is done.  I think that the text is sufficiently descriptive.

> 
> And there are some terminologies or abbreviations which are used without
> explaining, especially for some first appear. For example:
> 
>   Section 2.2.
> 
>   s/ECDSA/Elliptic Curve Digital Signature Algorithm (ECDSA)

This is on the RFC abbreviation list

> 
>   s/EdDSA/Edwards-curve Digital Signature Algorithm (EdDSA)

Changed, although I left DSA along as it is on the RFC list.

> 
> Other nits:
> 
>   Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865)

Should have been 2183

> 
>   Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838
Fixed

Jim