Pete, Leif, +1. These are editorial improvements and we are ready to move to the next stage. Thanks a lot to everyone! Orit.
> -----Original Message----- > From: Uta [mailto:[email protected]] On Behalf Of Leif Johansson > Sent: Sunday, January 25, 2015 7:24 AM > To: [email protected] > Subject: Re: [Uta] AD Evaluation of draft-ietf-uta-tls-bcp-08 > > On 01/25/2015 02:09 AM, Pete Resnick wrote: > > Folks, > > > > At long last, I've completed my AD Evaluation of > > draft-ietf-uta-tls-bcp-08. As far as I am concerned, it is ready for > > IETF Last Call. Well done! I have a number of comments below, but they > > are all editorial in nature, as far as I am concerned. Would the chairs > > to review them, and there is anything in there that needs correction > > before Last Call, I'd ask them to let me know in the next few days. If > > the chairs would prefer to see these fixed before Last Call (just to > > clean stuff up), I'm happy to wait for that as well. > > > > I'll wait for a go-ahead from the chairs to do the Last Call. > > > > For myself this all indeed seems like minor editorial changes that can > be handled after IETF LC. > > > pr > > > > --- > > 3.1.3: > > > > Clients that "fall back" to lower versions of the protocol after the > > server rejects higher versions of the protocol MUST NOT fall back to > > SSLv3. > > > > Is it worth saying "SSLv3 or earlier"? > > > > 3.5: > > > > OLD > > we adopt the recommended countermeasures from [triple-handshake] > > NEW > > the recommended countermeasures from [triple-handshake] are > adopted: > > > > 4.1: > > > > Second sentence, strike "as time progresses". Duplicative. > > > > OLD > > We note that this guideline does not apply to DTLS, which > > specifically forbids the use of RC4. > > NEW > > Note that DTLS already specifically forbids the use of RC4. > > > > 4.3: > > > > OLD > > The use of curves of > > less than 192-bits is NOT RECOMMENDED. > > NEW > > Curves of less than 192-bits SHOULD NOT be used. > > > > 4.4: > > > > OLD > > we recommend using (in priority order): > > NEW > > the following are RECOMMENDED (in priority order): > > > > In the second to last paragraph, s/We note/Note > > > > In the last paragraph, the SHOULD in there is kind of silly. "Ought to" > > or "need to" are more appropriate. > > > > 5.1: > > > > If deployers deviate from the recommendations given in this document, > > they MUST verify that they do not need one of the foregoing security > > services. > > > > That's a very odd MUST. "Need to"? > > > > The intended audience covers those services that are most commonly > > used on the Internet. > > > > That's not quite right. Either change "The intended audience" to "This > > document", or change it to "The intended audience is > > [implementers/operators/somebodies?] of services that...". An audience > > doesn't cover services, AFAICT. > > > > You also use "audience" incorrectly in the last paragraph of 5.1. I > > think you mean "scenario". > > > > 5.2: > > > > It seems like the reference in the second paragraph should be to RFC 7435. > > > > 7.3: > > > > OLD > > We thus advocate strict use of forward-secrecy-only ciphers. > > NEW > > This document therefore advocates the strict use of > > forward-secrecy-only ciphers. > > > > 7.5: > > > > First paragraph: s/we can recommend/can be recommended > > > > 8: s/We would like to thank/The [authors/editors] would like to thank > > > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
