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

Alessandro Vesely <> Mon, 18 April 2016 11:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EACEE12D880 for <>; Mon, 18 Apr 2016 04:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.298
X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 QC8eVMEgWlri for <>; Mon, 18 Apr 2016 04:21:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47A2712D899 for <>; Mon, 18 Apr 2016 04:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; t=1460978476; bh=JEDQp/MkrA9VajbjAOVZOw7SPJhivAuyNLbQlJf1C70=; l=2522; h=To:References:Cc:From:Date:In-Reply-To; b=UtLisfZ+nrrwTsm86xnu19UVMFaB9ILBcjlvMiCndFqtSCq9URPHD9hNt2WOH4oFd GVzirgkm5S5/wNfwOQ8rio7xYWd2EJgWp6yqBfsxTqIHf5SgQdXvpcVZ+4JdgeJYiu F3NnwmvYeoWVJYAjA3D3bjbtf9T44mc/DZfuDyH4=
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA; Mon, 18 Apr 2016 13:21:16 +0200 id 00000000005DC033.000000005714C32C.000060D5
To: Scott Kitterman <>, "Murray S. Kucherawy" <>
References: <> <> <> <> <> <> <> <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Mon, 18 Apr 2016 13:21:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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: Mon, 18 Apr 2016 11:21:22 -0000

On Sat 16/Apr/2016 18:10:47 +0200 Scott Kitterman wrote:
> On April 16, 2016 11:38:24 AM EDT, "Murray S. Kucherawy" <> wrote:
>> On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely <> wrote:
>>> 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 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
> 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.

I guess you mean the paragraph:

   The result is reported using a ptype of "policy" (as this is not part
   of any established protocol) and a property of "iprev".

That looks like an explanation of the naming, it doesn't seem to mandate that
every ptype must be "policy" unless the related property belongs to an
established protocol.  The definition of "policy" in Section 2.4 differs.

Would a name like, say, client.ip= have been an equally valid 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.

>From that definition it is not clear if or why a method is bound to use at most
one ptype.

My understanding was that RFC7410 allowed to add new ptypes as needed without
having to update the A-R header field name definition each time.  Can you
envisage what kind of change would be required in order to call A DNS zone