> On Apr 07, 2016, at 09:40, Roni Even <ron.even.tlv@xxxxxxxxx> wrote: > > 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-tls-chacha20-poly1305-04 > > Reviewer: Roni Even > > Review Date:2016–3-28 > > IETF LC End Date: 2016–4-9 > > IESG Telechat date: > > > Summary: This draft is almost ready for publication as a standard track RFC. > > > > Major issues: > I am wondering why this is a standard track document and not informational since the registration requirements are specification required. (RFC5246) I’m not sure I agree that Specification Required implies informational track. Specification Required permits registrations from informational/experimental drafts, but it certainly doesn’t require informational/experimental. Also note, the registry rules are: 0-191 Standards Action Refers to value of first byte 192-254 Specification Required Refers to value of first byte 255 Reserved for Private Use Refers to value of first byte > I am also wondering why this document updates RFC5246 and RFC6347. Reading the document it looked to me that the registration document is used also to endorse this cypher suite by the IETF and if this is the case my view is that there should be two documents, one Informational for registration and the will be standard track and update RFC5246 and RFC6347 > For Example the following text from section 1 “Therefore, a new stream cipher to replace RC4 and address all the previous issues is needed. “ provides what may look as a normative recommendation. As far as the updates header: The RC4 stream cipher which was in TLS1.0-1.2 is now prohibited [RFC7465] (note not deprecated it’s prohibited) and ChaCha20-Poly1305-based ciphers are the replacement. So, we do in fact want folks who were using RC4 to switch to ChaCha20-Poly1305, hence the updates header. As far as splitting the registrations/updates: What you’re suggesting is certainly one way to do it, but the way we’ve been doing it for years in the security area (e.g., TLS, IPSec, S/MIME, PKIX) is as follows (there have, of course, been exceptions): - (if needed) Informational RFC for algorithm - Standards track RFC for how to use algorithm with security protocol. This is how AES, Camellia, etc. were documented for TLS. Also in play here is the need to avoid a bunch of DOWNREFs because two of the ChaCha20-Poly1305 suites are SHOULDs in the draft TLS1.3. DOWNREFs aren’t anything to be scared of, but where we can avoid them I think we should. I guess I’d rather not devise new process and just keep on doing what we’ve been doing. spt PS we are currently in the process of discussing a change to make the entire range (minus the reserved) specification required, but that won’t complete for a while and the implementers want this now (technically yesterday).