Re: [DNSOP] draft-jabley-dnsop-ordered-answers

"Joe Abley" <jabley@hopcount.ca> Thu, 05 November 2015 17:42 UTC

Return-Path: <jabley@hopcount.ca>
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 4C2011B31B7 for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2015 09:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
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 jGasIZYHe4sX for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2015 09:42:48 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 061C21B31B6 for <dnsop@ietf.org>; Thu, 5 Nov 2015 09:42:48 -0800 (PST)
Received: by ykdr3 with SMTP id r3so143897746ykd.1 for <dnsop@ietf.org>; Thu, 05 Nov 2015 09:42:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; bh=KppoJ5EfbYLiafY8lIljwxf+r6Y+Cb0133mKNgwQ4oc=; b=g2ZAyuwF/o+XDPy8J1hKZFPCBWaeKPlj0oTSbd+C0O22nRizU5DTnDxYQS4U6Z2QsZ zMlzHPqatbbGd5fOR/QqSKSO7ea8sGzT3Qs4ZuRxi98zDvU8hXljOlAHbZKkRNHDkVeN Ts84r2p6M7KqDtswGv88PGvWREQkeDjM3Fl+4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=KppoJ5EfbYLiafY8lIljwxf+r6Y+Cb0133mKNgwQ4oc=; b=h29YDzs0lEcOV1b7ZbGsIXmkbJhhqAMnDbN2XCrACp6bj0+8inf6kIEZXACXO02WWi VqkMjWIlhwzP0Gl+Jndqo7diubeSWQjPUrAYpnmDyWw/FkRFkiu6npg7clbU0z/Mi0rd LjmtcxvpnzZngTkiFiXcop8x4lkkbBKkcreAWmsD0+oDZkfHRg0JAOZTr0XAf/t6YhkO nZ0FheVNEJ+DERSW327AgoyF+p1Z6MgXWIxYuPbDNLJXksgUOA08fHGqh0cgl/XHQIrH JZxAXWth84yRY6T8jHJQPy9mvBL3cKdjt6ZrKt6tdWdNEmxroXbPx6jK4Tjo3D3VHmNT O44g==
X-Gm-Message-State: ALoCoQn1Q1gioakGchfR5fkp+rkfoI7ZVWHiPBCYcheCMb9gwB69gqiecxaTVuS2mkqBc6FZ1Low
X-Received: by 10.31.173.214 with SMTP id w205mr8140405vke.95.1446745367206; Thu, 05 Nov 2015 09:42:47 -0800 (PST)
Received: from [172.19.128.14] (135-23-68-43.cpe.pppoe.ca. [135.23.68.43]) by smtp.gmail.com with ESMTPSA id b184sm5331191vkf.28.2015.11.05.09.42.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 09:42:46 -0800 (PST)
From: Joe Abley <jabley@hopcount.ca>
To: Niall O'Reilly <niall.oreilly@ucd.ie>
Date: Thu, 05 Nov 2015 12:42:45 -0500
Message-ID: <0C7A7D2B-02F8-46EE-A85D-27FB6BB483ED@hopcount.ca>
In-Reply-To: <m2mvusfnlq.wl-Niall.oReilly@ucd.ie>
References: <1E5B644E-EA0D-4287-8AB5-1907EE06BE1C@hopcount.ca> <563B58FE.50905@bellis.me.uk> <m2mvusfnlq.wl-Niall.oReilly@ucd.ie>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/DjgW_9pf_yFCj3FTobQp6BOEGUk>
Cc: dnsop@ietf.org, Ray Bellis <ray@bellis.me.uk>
Subject: Re: [DNSOP] draft-jabley-dnsop-ordered-answers
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: Thu, 05 Nov 2015 17:42:49 -0000

On 5 Nov 2015, at 10:54, Niall O'Reilly wrote:

> On Thu, 05 Nov 2015 13:26:22 +0000,
> Ray Bellis wrote:
>>
>> IMHO, if a clarification is needed, it's that a client that depends 
>> on
>> the order of the RRsets in an answer MUST NOT do so.
>
> Wouldn't it be a simpler clarification to say that a client MUST NOT
> depend on the order of the RRsets in an answer?

Sure, the solution could be any number of things.

But what I heard clearly in the room (and what I saw on the mailing 
list) is that there are multiple interpretations of the base spec, and 
that there is deployed code that breaks as a result. This to me suggests 
a need for clarification, regardless of what the clarification says.

Given that perspective, I remain confused as to why there was a strong 
hum against providing clarification. It does seem possible that people 
were humming against the specific proposal in the document, and not the 
need for clarification in general.

As I mentioned before I'm not trying to beat a dead horse, here. I just 
want to make sure I understand what question people thought they were 
being asked.


Joe