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

Mukund Sivaraman <muks@isc.org> Mon, 23 November 2015 20:40 UTC

Return-Path: <muks@isc.org>
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 8CC4F1B38B4 for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 12:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 qijtm_e65P5Y for <dnsop@ietfa.amsl.com>; Mon, 23 Nov 2015 12:40:12 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id A86971B3927 for <dnsop@ietf.org>; Mon, 23 Nov 2015 12:40:12 -0800 (PST)
Received: from jurassic.l0.malgudi.org (unknown [115.118.222.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 5B7792BA0E28; Mon, 23 Nov 2015 20:40:10 +0000 (GMT)
Date: Tue, 24 Nov 2015 02:10:07 +0530
From: Mukund Sivaraman <muks@isc.org>
To: "Wessels, Duane" <dwessels@verisign.com>
Message-ID: <20151123204007.GA4943@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> <6FFF2953-612E-4BC3-BB94-A77E9AF8E478@verisign.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
In-Reply-To: <6FFF2953-612E-4BC3-BB94-A77E9AF8E478@verisign.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/F78c2hQgyexhDCfbkD5r9HuWQeQ>
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 20:40:13 -0000

Hi Duane

On Mon, Nov 23, 2015 at 08:25:29PM +0000, Wessels, Duane wrote:
> TCP preserves the order of delivery, so if the messages are received
> in the order above, it is an AXFR/IXFR protocol violation by the
> server.  The server must send Message4 last.

Because 5966bis talks about reordering, if reordering of individual AXFR
messages were possible, the above would not hold. That's the concern
that I ask to be addressed explicitly in 5966bis, and also the point
about multiplexing other DNS messages with individual AXFR messages.

5966bis currently talks about reordering replies, not individual
messages, so it isn't incorrect. It is worth adding text stating what
happens with transfers clearly.

		Mukund