Subject: Re: [TLS] Fwd: Last Call: draft-rescorla-tls-suiteb (Suite B Cipher Suites for TLS) to Informational RFC

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Oct 2008 13:42:26 -0700

>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Suite B Cipher Suites for TLS '
>   <draft-rescorla-tls-suiteb-06.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[email-masked] mailing lists by 2008-10-23. Exceptionally,
>comments may be sent to [email-masked] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.

These are comments on the current (-09) draft.

1) Profile naming

The document defines a "compliant profile" and a "interoperability profile". As anyone who works with compliance and interoperability testing knows, these two words are often confused in the marketplace. It would take a reader a great deal of effort to figure out why the "compliant profile" didn't also lead to interoperability, and vice versa.

Reading more carefully, it becomes clear that the "interoperability profile" is probably for a transition mechanism between current implementations and fully compliant mechanisms. That is, it allows interoperability with today's implementations (with restrictions), but helps lead to fully compliant implementations over time.

If this is true, it would be *much* clearer if the two profiles were called "compliant profile" and "transition profile". This would make it much easier for an implementer to understand, and to prevent confusion when a vendor wants to say that their implementation interoperates with another.

2) Document organization

The definitions for the two profiles are mixed in Section 4. While this saves a bit of text (and probably paper...), it makes it hard to interpret. Further, some of the material in Section 4 is not at all about the  interoperability^Wtransition profile; for example, the security levels discussion is not related to the situation where one has for interoperability reasons chosen TripleDES. Section 4 should really should be just about the compliant profile and a new stand-alone section (new section 5) should be for the interoperability^Wtransition profile. Otherwise, someone reading the subsections of Section 4 won't be able to determine what part of the text at the beginning of the section it applies to.

3) Other

Not really a nit: the document consists of two profiles, but the Abstract says "a profile".

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf