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

Scott Kitterman <> Sat, 16 April 2016 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3565112D717 for <>; Sat, 16 Apr 2016 09:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MfNRg6ajUQKy for <>; Sat, 16 Apr 2016 09:10:51 -0700 (PDT)
Received: from ( [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD9C912D133 for <>; Sat, 16 Apr 2016 09:10:51 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 08817C40152; Sat, 16 Apr 2016 11:10:49 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Scott Kitterman <>
Date: Sat, 16 Apr 2016 12:10:47 -0400
To: "Murray S. Kucherawy" <>, Alessandro Vesely <>
Message-ID: <>
Archived-At: <>
Cc: Matthias Leisi <>, AppsAWG <>
Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" <> wrote:
>[dropping the IANA address because it keeps creating tickets in their
>On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely <>
>> On Wed 13/Apr/2016 20:15:04 +0200 Murray S. Kucherawy wrote:
>> > On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely
>> wrote:
>> >
>> >> I still don't think it is worth publishing the I-D, but maybe
>> list
>> >> archives can be considered permanent documents, which can be
>> by
>> >> items added after Expert Review, no?
>> >
>> > That seems... unconventional at least.  I would rather see
>> > published.  Going via the ISE, if you're worried about the slog
>> 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
>what I said.  I was making a suggestion about one way to publish it,
>since you already have a draft, you're part way there.
>Yes, I rejected your proposal to use,
>> because
>> it disagrees with the only existing implementation.  When that was
>> discussed,
>> the syntax was chosen because a DNSxL is
>> 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
>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

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 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 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