Re: [DNSOP] Last Call: <draft-ietf-dnsop-5966bis-04.txt> (DNS Transport over TCP - Implementation Requirements) to Internet Standard

神明達哉 <jinmei@wide.ad.jp> Mon, 23 November 2015 18:31 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD3A1ACD4E for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 10:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hco4CepkHNCI for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 10:31:24 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C765C1ACD4A for <dnsop@ietf.org>; Mon, 23 Nov 2015 10:31:23 -0800 (PST)
Received: by igcph11 with SMTP id ph11so57003189igc.1 for <dnsop@ietf.org>; Mon, 23 Nov 2015 10:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ls6/8pMvNqTWEPkl7qAI8i5IRi2qqYUa+R61RuPKSZE=; b=HGYkDtHWdM+ypjTTRypQAIlGQLrLnzyTORbc6SfFuVideLi55j5DUL9pFam62v0Pny Cl0w+re+Tuhlksf19B/hGtrBxPIY4eKPwM19troy/ETkiWEzEPzAxjflSH/Ov6mV/BjI bYzXrhuVGn7KQ3VcCNgVZLxKhe8zcSQTNHm0DUjiko43/5GsJjqQlxrthCtUTucguyaj SvH757gce1zo/qG7q0oDsprVux+4tdbNSGf7me67mOoOkAlgatMh5Kqb3qQflkmKoWZn pR6iuF3UU6OUgvKvQ4bUO5davDL2rQ24qfoGQji9W9vwHMUvPG+ty0wIWTm1mhvodv9d a5+g==
MIME-Version: 1.0
X-Received: by 10.50.155.33 with SMTP id vt1mr14117669igb.64.1448303483186; Mon, 23 Nov 2015 10:31:23 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.47.217 with HTTP; Mon, 23 Nov 2015 10:31:23 -0800 (PST)
In-Reply-To: <20151123160748.GA3031@jurassic.l0.malgudi.org>
References: <20151123135808.2730.32721.idtracker@ietfa.amsl.com> <20151123160748.GA3031@jurassic.l0.malgudi.org>
Date: Mon, 23 Nov 2015 10:31:23 -0800
X-Google-Sender-Auth: Nu31WXRmZzR91N9Llr6lD4m4gE4
Message-ID: <CAJE_bqc4=_s0rioJdOORJQaXDOrBXcy0yFJc9n0UZbRcuHsy+Q@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Mukund Sivaraman <muks@isc.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/MN918RUCO-tYDKqXK4e3YRyICUY>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-5966bis-04.txt> (DNS Transport over TCP - Implementation Requirements) to Internet Standard
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 23 Nov 2015 18:31:24 -0000

At Mon, 23 Nov 2015 21:37:48 +0530,
Mukund Sivaraman <muks@isc.org> wrote:

> While looking at a bug last week in an implementation of 5966bis and
> AXFR, I found that there's no explicit mention of AXFR and out-of-order
> replies. AXFR replies [RFC 5936] can arrive in several messages over
> TCP. While 5966bis speaks only about re-ordering replies and not
> individiual messages (and so, is not incorrect), I feel that explicitly
> describing ordering in the AXFR case would avoid confusion.
>
> It seems that AXFR messages would have to be sent in order to avoid
> confusion at the client about when a transfer correctly completed
> vs. when it timed out. While they can be multiplexed with other DNS
> messages, the individual messages of a single transfer must not be sent
> out of order.

I'm not sure if I understand the concern...do you mean, for example,
if an AXFR consists of the following 3 messages:

Message1: beginning SOA and some RRs
Message2: some intermediate RRs
Message3: some more intermediate RRs
Message4: some more RRs and ending SOA

the client side of AXFR receives them in the order of, e.g., Message2,
Message3, Message4, and then Message1?  That is, Message1 is not
necessarily sent/received first and/or Message4 is not necessarily
sent/received last?

--
JINMEI, Tatuya