Skip to main content

Last Call Review of draft-ietf-v6ops-rfc6555bis-05
review-ietf-v6ops-rfc6555bis-05-opsdir-lc-wang-2017-09-26-00

Request Review of draft-ietf-v6ops-rfc6555bis-04
Requested revision 04 (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-10-03
Requested 2017-09-05
Requested by Ron Bonica
Authors David Schinazi , Tommy Pauly
Draft last updated 2017-09-26
Completed reviews Opsdir Last Call review of -05 by Zitao Wang (diff)
Opsdir Last Call review of -06 by Jon Mitchell (diff)
Secdir Last Call review of -05 by Brian Weis (diff)
Assignment Reviewer Zitao Wang
State Completed
Review review-ietf-v6ops-rfc6555bis-05-opsdir-lc-wang-2017-09-26
Reviewed revision 05 (document currently at 07)
Result Ready
Completed 2017-09-26
review-ietf-v6ops-rfc6555bis-05-opsdir-lc-wang-2017-09-26-00
Reviewer: Zitao WANG

Review result: Ready

I have reviewed draft-ietf-v6ops-rfc6555bis-05 as part of the Operational
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed in last
call may be included in AD reviews during the IESG review.

Document editors and WG chairs should treat these comments just like any other
last call comments.

"This document specifies requirements for algorithms that reduce this
user-visible delay and provides an example algorithm, and expands on "Happy
Eyeballs" [RFC6555], a technique of reducing user-visible delays on dual-stack
hosts.  Now that this approach has been deployed at scale and measured for
several years, the algorithm specification can be refined to improve its
reliability and generalization.  This document recommends an algorithm of
racing resolved addresses that has several stages of ordering and racing to
avoid delays to the user whenever possible, while preferring the use of IPv6. 
Specifically, it discusses how to handle DNS queries when starting a connection
on a dual-stack client, how to create an ordered list of destination addresses
to which to attempt connections, and how to race the connection attempts.”

My overall view of the document is 'Ready' for publication.

One small comment is that there are some id-nits, please fix it in next version:

     (See RFCs 3967 and 4897 for information about using normative references

     to lower-maturity documents in RFCs)

  == Missing Reference: 'Section 3' is mentioned on line 120, but not defined

  == Missing Reference: 'Section 4' is mentioned on line 164, but not defined

  == Missing Reference: 'Section 5' is mentioned on line 202, but not defined

  == Missing Reference: 'Section 6' is mentioned on line 169, but not defined

     Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--).