[DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt

"Jiankang Yao" <yaojk@cnnic.cn> Fri, 23 June 2017 08:26 UTC

Return-Path: <yaojk@cnnic.cn>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5683312EA8D for <dnsop@ietfa.amsl.com>; Fri, 23 Jun 2017 01:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AfGnvaIlfBZC for <dnsop@ietfa.amsl.com>; Fri, 23 Jun 2017 01:26:53 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn []) by ietfa.amsl.com (Postfix) with ESMTP id DDD50129B60 for <dnsop@ietf.org>; Fri, 23 Jun 2017 01:26:50 -0700 (PDT)
Received: from healthyao-PC (unknown []) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApVonG0ExZFlVdKw--.10430S2; Fri, 23 Jun 2017 16:26:46 +0800 (CST)
Date: Fri, 23 Jun 2017 16:26:33 +0800
From: "Jiankang Yao" <yaojk@cnnic.cn>
To: dnsop <dnsop@ietf.org>
Reply-To: yaojk <yaojk@cnnic.cn>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Message-ID: <20170623162604407257182@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart564116435613_=----"
X-CM-TRANSID: AQAAf0ApVonG0ExZFlVdKw--.10430S2
X-Coremail-Antispam: 1UD129KBjvJXoWxWr43tFW3KFW8WrWrtF47urg_yoWrAr1kpa 9xtrZrKa4qqr18Cr97Jw18XF4UKa93JrW7JFn5Kr10vwn0kF1qqF48KayFva47Ca4xAr9F qF1Ivw1DW3WYvFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvCb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lc2xSY4AK 67AK6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2Kf nxnUUI43ZEXa7IU5dEf7UUUUU==
X-CM-SenderInfo: x1dryyw6fq0xffof0/
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jKPg2OsLRckNnebRltXOXBBGobw>
Subject: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jun 2017 08:26:56 -0000

     Based on Seoul IETF's discussion, I refine the introduction of this document to explain the motivation and compare with other mechanisms.
the key text is here:
1.  Introduction

   Sometimes, when DNS lookup of X, an application will lookup Y if X
   fails.  For examples, the initiator may fall back to A record if the
   lookup of MX record fails.

   Some initiators do it in sequence, X and after a few seconds, then Y.
   Although it is simple, this leads to unpleasant waiting whenever X
   times out or answers negatively.

   Some initiators use concurrent X/Y lookups and a state machine to
   decide whether to use X or Y.  If an answer to Y arrives but none to
   X, the initiator needs to wait a little or else fall back to Y
   inappropriately.  Concurrent lookup is faster if the X lookup takes
   time and falling back to Y is appropriate, but rather complex, with
   four states to test, and the initiator needs to wait for an answer to
   X or a timeout before it can use Y.

   This document enables a quicker, more easily tested failover.  There
   is no need to test different answer sequences, there's no need for a
   state machine, there's no need for timeouts beyond receiving the
   reply.  This document describes a method by which DNS initiators can
   send a main question accompanying with several related questions in a
   single DNS query, and enables DNS responders place all related
   answers into a single DNS response.  This mechanism can reduce the
   number of DNS round-trips per application work-unit, by carrying
   several related queries in a single query transaction.  It has the
   following advantages compared to other solutions.

   o  Compared to sequential lookups: It's roughly as simple, but much
      faster in case a fallback to Y is necessary.

   o  Compared to the concurrent mechanism: It is slightly faster (if
      the initiator needs to wait for an X timeout) and/or prevents
      inappropriate fallback (if the answer to X arrives too late), and
      it has a simpler state machine.

   This mechanism can also be used in the scenarios when the application
   needs more records of the same domain name or its sub-domain name.
   For examples, when asking about a QTYPE=A RRset, a QTYPE=AAAA RRset
   may also be of use [RFC 5321]; When asking for some RRset of
   www.example.com about A and AAAA, records of a sub-domain name such
   as _443._tcp.www.example.com for TLSA may be of interest[RFC 6698].


Jiankang Yao

From: internet-drafts
Date: 2017-06-23 15:41
To: XiaoDong Lee; Ning Kong; Paul Vixie; Jiankang Yao; Xiaodong Li
Subject: New Version Notification for draft-yao-dnsop-accompanying-questions-03.txt

A new version of I-D, draft-yao-dnsop-accompanying-questions-03.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name: draft-yao-dnsop-accompanying-questions
Revision: 03
Title: A DNS Query including A Main Question with Accompanying Questions
Document date: 2017-06-23
Group: dnsop
Pages: 11
URL:            https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-03.txt
Status:         https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/
Htmlized:       https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-yao-dnsop-accompanying-questions-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-03

   This document enables DNS initiators to send a main question
   accompanying with several related questions in a single DNS query,
   and enables DNS responders to put the answers into a single DNS
   response.  This extension enables a range of initiators to look up
   "X, or failing that, Y" in a better way than both current
   alternatives.  This mechanism can reduce the number of DNS round-
   trips per application work-unit.


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat