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 21: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 E5A691B348C for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 13:31:08 -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 6aIsuOIX-9Ij for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 13:31:07 -0800 (PST)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 BCB3F1B348B for <dnsop@ietf.org>; Mon, 23 Nov 2015 13:31:07 -0800 (PST)
Received: by iouu10 with SMTP id u10so664701iou.0 for <dnsop@ietf.org>; Mon, 23 Nov 2015 13:31:07 -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=mMXj+wdI+Am6BaDWQyT308col+L1CAl3+h0593REHos=; b=tqAfIZHHAfJfZIH6MFJDbvnURb7FN7miCGJix1CbbCqPSpQENxaklBNZ+cUtsHJ3Ev bGbEuhhPjl88O8veZbonv021gekPJohQ4FgGw0g+t67yaVtGj+pcovjNvGqOxegNJjpb cj8gBv4+o+LKDVyB4yfY/BSdopS7ws+STKg8mox5yXuTfsY7CePTAaKZ5XDk8CNpz5zT mzkILpXcALw4xwHiYCDYZMX468q4+wGdEg3PG918dfhhBFimTPWC34SkyDjnMkE9w7oW KBDJFyPupyQLrxqb9oBNDaJB1aROZNyjBWqNHDsgneJqnq0H9MIwZpPQz4NKv/SyH4FH ytAw==
MIME-Version: 1.0
X-Received: by 10.107.184.9 with SMTP id i9mr31724929iof.4.1448314267098; Mon, 23 Nov 2015 13:31:07 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.47.217 with HTTP; Mon, 23 Nov 2015 13:31:07 -0800 (PST)
In-Reply-To: <20151123195826.GA4556@jurassic.l0.malgudi.org>
References: <20151123135808.2730.32721.idtracker@ietfa.amsl.com> <20151123160748.GA3031@jurassic.l0.malgudi.org> <CAJE_bqc4=_s0rioJdOORJQaXDOrBXcy0yFJc9n0UZbRcuHsy+Q@mail.gmail.com> <20151123195826.GA4556@jurassic.l0.malgudi.org>
Date: Mon, 23 Nov 2015 13:31:07 -0800
X-Google-Sender-Auth: Kgd5GdJCKHf-whbmH_vqoS-5_1E
Message-ID: <CAJE_bqf7mohhFyrMAw5w8a2PD-j-MpUAZsjDT885rATFmFDhtA@mail.gmail.com>
From: 神明達哉 <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/YR8eNh4nbS5IVlhzdUvKdxfRvDs>
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 21:31:09 -0000

At Tue, 24 Nov 2015 01:28:26 +0530,
Mukund Sivaraman <muks@isc.org> wrote:

> > 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?
>
> Yes. Without them being in order, it doesn't seem the client can
> determine upon timeout if all messages corresponding to the transfer
> have been received, or if the transfer is incomplete.
>
> Example:
>
> (1) Message1, Message4, Message2, Message3 received.
> Timeout complete and TCP still connected.
>
> (2) Message1, Message4, Message2 received. [Message3] not received when
> timeout complete and TCP still connected.
>
> How can client know that in (2), the whole transfer was not received?

In both cases the client should simply consider it the end of AXFR
when it sees Message4 (and the client would treat it as an error when
it sees subsequent Message2 or Message3).  To me, that's a quite obvious
consequence of the fact that an AXFR must begin and end with an SOA
and there's no required ordering in the intermediate RRs.

If there's indeed an implementation that doesn't interpret *the
obvious* that way, it might be worth noting explicitly, but from what
I heard and if I understood it correctly, that rather seems to be a
pure implementation problem than a protocol documentation issue.

--
JINMEI, Tatuya