[v6ops] Opsdir last call review of draft-ietf-v6ops-rfc6555bis-05

wangzitao <wangzitao@huawei.com> Tue, 26 September 2017 03:48 UTC

Return-Path: <wangzitao@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D4A98134654; Mon, 25 Sep 2017 20:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Qj2B9LXks4RO; Mon, 25 Sep 2017 20:48:45 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C224C1321B6; Mon, 25 Sep 2017 20:48:44 -0700 (PDT)
Received: from (EHLO LHREML713-CAH.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPH57332; Tue, 26 Sep 2017 03:48:43 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com ( by LHREML713-CAH.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 26 Sep 2017 04:48:42 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([]) by DGGEMM402-HUB.china.huawei.com ([]) with mapi id 14.03.0301.000; Tue, 26 Sep 2017 11:48:34 +0800
From: wangzitao <wangzitao@huawei.com>
To: "draft-ietf-v6ops-rfc6555bis.all@ietf.org" <draft-ietf-v6ops-rfc6555bis.all@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-v6ops-rfc6555bis-05
Thread-Index: AdM2ei/eNr5+iiczQaiB16FoxZShig==
Date: Tue, 26 Sep 2017 03:48:33 +0000
Message-ID: <E6BC9BBCBCACC246846FC685F9FF41EA2AEC1824@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC1824DGGEMM506MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59C9CE1B.004A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c90f4370f701f0b1b97ef8a859612b6
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VXnBT-gVymtrug1B81en6sp13F0>
Subject: [v6ops] Opsdir last call review of draft-ietf-v6ops-rfc6555bis-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Sep 2017 03:48:47 -0000

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 (--).