Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl

Scott Kitterman <scott@kitterman.com> Sat, 16 April 2016 16:10 UTC

Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3565112D717 for <apps-discuss@ietfa.amsl.com>; Sat, 16 Apr 2016 09:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com
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 MfNRg6ajUQKy for <apps-discuss@ietfa.amsl.com>; Sat, 16 Apr 2016 09:10:51 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9C912D133 for <apps-discuss@ietf.org>; Sat, 16 Apr 2016 09:10:51 -0700 (PDT)
Received: from [192.168.111.103] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 08817C40152; Sat, 16 Apr 2016 11:10:49 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1460823049; bh=zI/QO8bkOGSbHRmn7bxUBJ3YScj8bsaAvte8RZlTrdM=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=ZY/SxYIQl/DUL3poeK47ozNof/oycj8SWy8ZFn9BPEMSdUvDj30liRjHoYldn4rtd Gj9j0zWNj0uCONLpd5x47UpuVlaojsw3HUdcUGF3Z4rySLiSHlogAynotQheZZJrjH Dg9kkYGeKnLP0dbKX9NW24ytpnlB52YNb4rANndE=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAL0qLwZ5HtDFgoB-BO00zigS4sZP5mOAB+cco1dEjWO-pvHCsA@mail.gmail.com>
References: <CAL0qLwaGuz-CBMke3BhjfLwn7Bt213XobrOUe3_hAqxMZw+PKg@mail.gmail.com> <57025643.7040101@tana.it> <CAL0qLwb_8RN0w03N9P5xQsoC2aJppYTaBidmX_uuvioCJ6CaQg@mail.gmail.com> <5702946B.30307@tana.it> <CAL0qLwZAuVpWj-oDN6cyKiHmnJgpGdtyHKwMfz98v5odBOHTvw@mail.gmail.com> <570E8985.7080708@tana.it> <CAL0qLwa0FqQty+u3eDNQm7MJ_4KrveiyB80ukX3PZmpRARrnfg@mail.gmail.com> <57125854.2030307@tana.it> <CAL0qLwZ5HtDFgoB-BO00zigS4sZP5mOAB+cco1dEjWO-pvHCsA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Scott Kitterman <scott@kitterman.com>
Date: Sat, 16 Apr 2016 12:10:47 -0400
To: "Murray S. Kucherawy" <superuser@gmail.com>, Alessandro Vesely <vesely@tana.it>
Message-ID: <A213CB1A-79C1-4766-83A4-CB98A0A2CFF7@kitterman.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/ZcyLHPs1MroCvGXHprTCLUkBKgE>
Cc: Matthias Leisi <matthias@leisi.net>, AppsAWG <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2016 16:10:54 -0000


On April 16, 2016 11:38:24 AM EDT, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>[dropping the IANA address because it keeps creating tickets in their
>system]
>
>On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely <vesely@tana.it>
>wrote:
>
>> On Wed 13/Apr/2016 20:15:04 +0200 Murray S. Kucherawy wrote:
>> > On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely
><vesely@tana.it>
>> wrote:
>> >
>> >> I still don't think it is worth publishing the I-D, but maybe
>IETF's
>> list
>> >> archives can be considered permanent documents, which can be
>referenced
>> by
>> >> items added after Expert Review, no?
>> >
>> > That seems... unconventional at least.  I would rather see
>something
>> > published.  Going via the ISE, if you're worried about the slog
>through
>> the
>> > IETF Stream, seems like a perfectly viable option.
>>
>> I think that is called RFC Required, not Expert Review.
>>
>
>It would if I had asserted that you have to publish an RFC, but that's
>not
>what I said.  I was making a suggestion about one way to publish it,
>and
>since you already have a draft, you're part way there.
>
>Yes, I rejected your proposal to use policy.zone=lists.dnswl.example,
>> because
>> it disagrees with the only existing implementation.  When that was
>> discussed,
>> the syntax dns.zone=lists.dnswl.example was chosen because a DNSxL is
>a
>> zone in
>> the DNS, according to, say, RFC5782.  Nobody realized that "dns" is
>not a
>> valid
>> RFC7601 ptype (and I still don't understand why).
>>
>
>I've gone over the "why" with you at some length both at the Berlin
>meeting
>and now on a thread subsequent to your request to IANA.
>
>While I'm sympathetic to some degree with the "installed base"
>argument, I
>don't think it's reasonable to accept a registration that doesn't fit
>within the defining RFC merely because there's a single existing
>incorrect
>implementation.

While I normally give pragmatic arguments (like alignment to existing practice) a lot of weight, in this case I agree with Murray that it would be a mistake.

If you look at the discussion of iprev in http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact same ground as this proposal with regards to ptype selection.  I believe it's clear that policy is the correct choice.

In order to add the proposed new ptype, I think the ptype definition in http://tools.ietf.org/html/rfc7601#section-2.3 would have to be changed and that would require a standards track update to RFC 7601.  I don't think you want to go down that path.

Scott K