Hi, the writeup has been updated to explain the obsolete references. - We can go ahead
> On 4. Oct 2019, at 11:20, Magnus Westerlund <[email protected]> > wrote: > > Thanks for the answers. > > I will initiate IETF last call of this draft now. > > Phillip, please update the writeup regarding the intentional reference to the > obsoleted TCP-AO. > > Cheers > > Magnus > > On Thu, 2019-09-26 at 08:01 +0000, Magnus Westerlund wrote: >> Hi, >> >> Sorry about the delay in getting the AD review done. Below are my comments >> and >> questions. Note the questions are truly questions and after answering we can >> discuss if there needed to be any changes or not. >> >> >> 1. Section 4.1: Is there a reason to use TLS 1.2 specification (RFC5246) >> rather than TLS 1.3 as the general reference? >> >> 2. Comment on the writeup: Considering that ID nits results in the below >> relevant references warning I would expect some comment in the writeup if >> they >> are intentional. If not please update the references. If they are >> intentional, >> please update the writeup to note them. >> >> >> >> -- Obsolete informational reference (is this intentional?): RFC 2385 >> (Obsoleted by RFC 5925) >> >> -- Obsolete informational reference (is this intentional?): RFC 4474 >> (Obsoleted by RFC 8224) >> >> -- Obsolete informational reference (is this intentional?): RFC 5246 >> (Obsoleted by RFC 8446) >> >> -- Obsolete informational reference (is this intentional?): RFC 7539 >> (Obsoleted by RFC 8439) >> >> 3. Section 4.1.2: Is there a point to mention that TLS forward secrecy are >> dependent on cipher suit for the key exchange and not ensured prior to 1.3? >> >> 4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS 1.3 >> draft: “(Note that this extension is only supported in >> DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)” >> >> 5. Section 4.3.3: “QUIC transport relies on UDP.” Although QUIC is targeting >> UDP as its main deployment vessel, isn’t QUIC in fact dependent on a >> unreliable datagram service. But, maybe writing UDP is more straightforward? >> >> 6. Section 4.5.4: When it comes to variants of SRTP. I think referencing RFC >> 7201 would actually be reasonable, as in the many different options hide some >> transport security options that so far is not discussed in this document. >> Like >> securing multicasted / broadcasted RTP. >> >> 7. Section 4.5.4: So are ZRTP included as variant because it provides new >> security features? Is that session continuity, or something else? >> >> 8. Section 11: There are a number of references here that I don’t think meets >> the requirement for references. These are the ones that only have a title and >> n.d. All these could include a URL a date when these pages was visited and >> contained the information you want to reference. >> >> >> Cheers >> >> Magnus Westerlund > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: [email protected] > <mailto:[email protected]> > ---------------------------------------------------------------------- AVE! Philipp S. Tiesel / phils… -- {phils}--->---([email protected])--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en | o Schr an muss hc h (Kurt Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: [email protected])----'
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
