[Gen-art] Gen-ART review of draft-ietf-tls-rfc4347-bis-04.txt
I have been selected as the General Area Review Team (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 comments you may receive. Document: draft-ietf-tls-rfc4347-bis-04.txt Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com Review Date: 12-12-2010 IETF LC End Date: 14-12-2010 IESG Telechat date: (if known) Summary: The document is ready for publication as a standards track RFC. A well written and clear document. Congratulations to the authors. I have a question and a couple of nits. Question: - Section 4.1, previous last paragraph on page 8. The sentence requires implementations to compute the TCP maximum segment lifetime. If an implementation runs DTLS over UDP, how can it compute the TCP maximum segment lifetime, which is a parameter for a different protocol? I suspect DTLS implementations running over UDP (or even SCTP) will not have a clue of what is the TCP maximum segment lifetime. The sentence I am referring to is: In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime. Nits/editorial comments: - Section 1, 4th paragraph. Missing dot separating sentences: This document introduces a new version of DTLS, DTLS 1.2, which is defined as a series of deltas to TLS 1.2 [TLS12] There is no DTLS 1.1. - Section 3, bullet point 1, I don't understand what IV means in this sentence: [Note that prior to TLS 1.1, there was no explicit IV and so decryption would also fail.] - Expand acronyms at first usage. This includes MSL, PMTU, MAC - An informative reference to RC4 is needed in Section 4.1.2.2, 2nd paragraph. - At least in my copy, there is a strange formatting in the first paragraph of Section 4.1.2.7, including many white spaces in every line. - There is a repeated paragraph within the same section 4.2.4. I think this might be a mistake. The paragraph appears both under Figure 2 (on page 20) and then towards the end of page 22. This is the paragraph: Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-tls-ssl2-must-not-03
Hi, I also reviewed this draft (looks like both of us got to do the Gen-ART review). I agree with Richards editorial comment. Thanks Roni Even -Original Message- From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of Richard L. Barnes Sent: Saturday, December 11, 2010 7:18 PM To: gen-art@ietf.org; draft-ietf-tls-ssl2-must-...@tools.ietf.org Subject: [Gen-art] Gen-ART review of draft-ietf-tls-ssl2-must-not-03 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-ssl2-must-not-03 Reviewer: Richard Barnes Review Date: 11 Dec 2010 IETF LC End Date: IESG Telechat date: (if known) Summary: This document is ready for publication as a Standards Track RFC. Major issues: Minor issues: Nits/editorial comments: [Section3] This section seems like could benefit from a little more explanation and clarificatio. For instance, you might explicitly deprecate the recommendations in Appendix E of the three TLS RFCs, with the exception of accepting SSLv2 CLIENT-HELLO messages. (Might also be worthwhile to reinforce that even after accepting the SSLv2 CLIENT- HELLO, the server MUST NOT send any further SSLv2 messages.) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2010-12-16 IESG Teleconference
HI folks, I apologize that I have not yet had a chance to do the assignments for thursday's telechat. I thought I could get to it over the weekend, but was not able to obviously. I will get the s/s updated and assignments LCs out by the end of the day tomorrow. But, until if folks could check and see the docs that are on the telechat in case there are new versions. Thanks, Mary. -- Forwarded message -- From: IESG Secretary iesg-secret...@ietf.org Date: Thu, Dec 9, 2010 at 5:08 PM Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2010-12-16 IESG Teleconference To: iesg-agenda-d...@ietf.org INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2010-12-16 IESG Teleconference This agenda was generated at 2010-12-09 15:07:44 PST Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of Past Telechats 1.4 List of Remaining Action Items from Last Telechat OUTSTANDING TASKS Last updated: December 6, 2010 o Jari Arkko to add guidance on multi-Area work to the wiki. o Michelle Cotton to provide draft of -bis document for RFC 4020 Allocation procedures. o Tim Polk to update the IESG statement on choosing between Informational and Experimental status. o Alexey Melnikov to draft an IESG Statement on MIME Type Registrations from other SDOs, to include a statement on the stability of references in Media Type Registrations. o Sean Turner to determine if it is safe to use the old and new protocol numbers in the same port [IANA #404374]. 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-mpls-fastreroute-mib-15 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute (Proposed Standard) Note: Loa Andersson (l...@pi.nu) is the document shepherd. Token: Adrian Farrel o draft-ietf-httpstate-cookie-19 HTTP State Management Mechanism (Proposed Standard) Token: Peter Saint-Andre o draft-ietf-sipcore-event-rate-control-05 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (Proposed Standard) Note: Adam Roach (a...@nostrum.com) is the document shepherd. Token: Robert Sparks Was deferred by Cindy Morgan on 2010-12-02 o draft-ietf-morg-list-specialuse-05 IMAP LIST extension for special-use mailboxes (Proposed Standard) Note: Timo Sirainen t...@iki.fi is the document shepherd. Token: Alexey Melnikov o draft-ietf-roll-trickle-06 The Trickle Algorithm (Proposed Standard) Note: JP Vasseur (j...@cisco.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-tls-ssl2-must-not-03 Prohibiting SSL Version 2.0 (Proposed Standard) Note: Joe Salowey (jsalo...@cisco.com) is the document shepherd. Token: Alexey Melnikov o draft-ietf-avt-rtp-svc-24 RTP Payload Format for Scalable Video Coding (Proposed Standard) Note: Roni Even is the document shepherd (even.r...@huawei.com) Token: Gonzalo Camarillo o draft-ietf-xmpp-address-07 Extensible Messaging and Presence Protocol (XMPP): Address Format (Proposed Standard) Note: Ben Campbell (b...@nostrum.com) is the document shepherd. Token: Gonzalo Camarillo Was deferred by Cindy Morgan on 2010-12-02 o draft-ietf-sieve-notify-presence-03 Sieve Notification Using Presence Information (Proposed Standard) Note: Cyrus Daboo is the document shepherd. Token: Alexey Melnikov Was deferred by Robert Sparks on 2010-12-01 o draft-ietf-mpls-ip-options-05 Requirements for Label Edge Router Forwarding of IPv4 Option Packets (Proposed Standard) Note: George Swallow (swal...@cisco.com) is the Document Shepherd. Token: Adrian Farrel o draft-ietf-v6ops-3177bis-end-sites-00 IPv6 Address Assignment to End Sites (BCP) Note: Fred Baker (f...@cisco.com) is the document shepherd. Token: Ron Bonica o draft-ietf-morg-fuzzy-search-03 IMAP4 Extension for Fuzzy Search (Proposed Standard) Note: Barry Leiba (one of the MORG chairs) is the document shepherd. Token: Alexey Melnikov o draft-ietf-tcpm-tcp-timestamps-02 Reducing the TIME-WAIT state using TCP timestamps (BCP) Note: Wesley Eddy (wesley.m.e...@nasa.gov) is the document shepherd. Token: Lars Eggert 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items o draft-cheshire-dnsext-dns-sd-07 DNS-Based Service Discovery (Proposed Standard) Token: Ralph Droms o draft-cheshire-dnsext-multicastdns-12 Multicast DNS (Proposed Standard) Token: Ralph Droms 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-ipfix-mediators-framework-09 IPFIX Mediation: Framework (Informational) Note: Juergen Quittek is the document shepherd Token: Dan Romascanu o draft-ietf-opsec-protect-control-plane-04 Protecting The
Re: [Gen-art] review of draft-ietf-tcpm-tcp-timestamps-02.txt
Hi, Francis, Thanks so much for your feedback! Please find my comments inline Nits/editorial comments: - ToC page 2 and 7 page 8: Acknowledgements - Acknowledgments (BTW the american for honour is honor too, ask the RFC Editor to change honour spelling if he wants) These have been published as is in previous RFCs I have authored... - 1 page 3: in The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP to include a timestamp value in its segments, that can be used to perhaps there is a missing word (like speaker) after TCP? The term a TCP is usually employed as a short form for a TCP instance - 2 pages 4 and 5: I don't understand where the difference between these two texts comes from: the Sequence Number of the incoming SYN segment is larger than the last sequence number seen on the previous incarnation of the connection (for that direction of the data transfer), then honour the connection request (creating a connection in the SYN-RECEIVED state). the Sequence Number of the incoming SYN segment is larger than the last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer), then honour the incoming connection request (even if the sequence number of the incoming SYN segment falls within the receive window of the previous incarnation of the connection). i.e., I can easily tell whether the small variations between similar specifications are just to make reading less boring or are about real differences. Fair enough. I will update the text on page 5 as follows, such to avoid the minor differences with the text in page 4: * If TCP timestamps would be enabled for the new incarnation of the connection, honour the incoming connection request (creating a connection in the SYN-RECEIVED state). * If TCP timestamps would not be enabled for the new incarnation of the connection, but the Sequence Number of the incoming SYN segment is larger than the last sequence number seen on the previous incarnation of the connection (for the same direction of the data transfer), then honour the incoming connection request (creating a connection in the SYN-RECEIVED state). Better? - 2 page 6: KB/s - kbytes/s or kilobytes/s (at least K (Kelvin) - k (kilo) and B - bytes in letters) I will change it to kilobytes/second. - 4 page 7: I guess it is a typo: [CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme which results in monotonically-increasing timestamps across ^^ ISNs You're right. Thanks for catching this one! -- Will fix it. connections that are not easily-predictable by an off-path attacker. - 8.2 page 9 [INFOCOM-99] and [Silbersack]]: ' .' - '.' These will be fixed by the RFC-Ed... (they usually play xml tricks to make the output look nicer) Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
