Re: [Doh] [Ext] Proposal to close off these threads

Patrick McManus <pmcmanus@mozilla.com> Mon, 11 June 2018 00:08 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AAA130DC2 for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 17:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 YrTuHtkPpeWV for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 17:08:36 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB612D7F8 for <doh@ietf.org>; Sun, 10 Jun 2018 17:08:36 -0700 (PDT)
Received: from mail-ot0-f181.google.com (mail-ot0-f181.google.com [74.125.82.181]) by linode64.ducksong.com (Postfix) with ESMTPSA id C4D0C3A01E for <doh@ietf.org>; Sun, 10 Jun 2018 20:08:35 -0400 (EDT)
Received: by mail-ot0-f181.google.com with SMTP id 101-v6so21805854oth.4 for <doh@ietf.org>; Sun, 10 Jun 2018 17:08:35 -0700 (PDT)
X-Gm-Message-State: APt69E0hDZJevoKae0qEQQ2KoIyf8yKFgcT7g2/sk9CFyn212scN8EXW u4XwUZmFyi7ZoMYk6E14NwKgylhmMNtBV1pSHd0=
X-Google-Smtp-Source: ADUXVKJm+dieuNqorBFywekuM3awPyjCXEePZf9lWzZqm+HsTXpxjHX+cLqt/74EpXDoRI7k+QP3bXmQKz5C7NQwZj4=
X-Received: by 2002:a9d:2c41:: with SMTP id f59-v6mr8217355otb.263.1528675715501; Sun, 10 Jun 2018 17:08:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 17:08:35 -0700 (PDT)
In-Reply-To: <FB8DBC78-4584-4133-AF1F-E0483C28224D@icann.org>
References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> <CAOdDvNrXpyGTFmMHcF6Vnegku0Zmiw_LFb1VKm1O2mFgB3aHEw@mail.gmail.com> <FB8DBC78-4584-4133-AF1F-E0483C28224D@icann.org>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Sun, 10 Jun 2018 19:08:35 -0500
X-Gmail-Original-Message-ID: <CAOdDvNoYYVEGC0Zsyd1m8sayuzZoW186gb4gmMojZzvYy6=6rw@mail.gmail.com>
Message-ID: <CAOdDvNoYYVEGC0Zsyd1m8sayuzZoW186gb4gmMojZzvYy6=6rw@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Patrick McManus <pmcmanus@mozilla.com>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ffd5e4056e528ce0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/n6WDs8dRGpEXB1jjZzA-RrqWveg>
Subject: Re: [Doh] [Ext] Proposal to close off these threads
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2018 00:08:39 -0000

On Sun, Jun 10, 2018 at 6:53 PM, Paul Hoffman <paul.hoffman@icann.org>
wrote:

> On Jun 10, 2018, at 4:31 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> >
> > I think we can make progress here. I'm pleased to see the text
> restricted to the media type. I don't think it should explicitly restrict
> axfr, but rather be about size.
> >
> > This both makes the reasoning clearer and hits the target more
> accurately in edge cases (doesn't apply to small axfr and does apply to a
> huge rr set of key types and txt records or something). I'm happy if we
> also mention many [ai]xfr require more than one traditional wireformat
> message and so won't fit in this media type.
>
> I would rather not mention stuff we can't back up. If a developer wants to
> do ?XFR over this transport and have others interoperate with them, it will
> probably take much less time for them to write the (hopefully very short)
> Internet Draft than it will for them to eventually have to debug and patch
> their code when someone else makes different assumptions.
>
>
I'm working very hard to keep this in the realm of concrete.

There has a been a convincing case that a > 64KB axfr responses uses 2
wireformat records in TCP today and therefore won't fit in the DoH MTI
wireformat media type. AIUI that's not because its AXFR, but because it is
>64KB, right? At the same time tale convincingly argues he has plenty of
<64KB zones that only use one message and match our MTI fine.

There are also, admittedly fringe, cases where you can create > 64KB
responses not using ?XFR at all.

Therefore, match the restriction to what the problem is.. in other words
the problem is that the MTI wireformat can only carry 64KB.

And then, as I mentioned, its useful to have non-normative text mentioning
that ?XFR is of particular concern here.



> > Its good to note, non-normatively, that a server that cannot satisfy a
> request because of this media type's size restriction can use 413 to signal
> that.
>
> "can use"? "SHOULD use" except in situation X? "MUST use"?
>
>
sorry about suggesting 413 - that's wrong as it is meant to apply to
request bodies. We're looking for 406.

"HTTP defines status code 406 for cases where the server cannot generate a
representation suitable for the client". We can probably just say that.






> --Paul Hoffman
>
> (PS: The above proves that the document authors are not carefully
> coordinating their responses off-list...)