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

Scott Kitterman <> Mon, 18 April 2016 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9BC412E281 for <>; Mon, 18 Apr 2016 09:36:58 -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 QBCswt-k9pHU for <>; Mon, 18 Apr 2016 09:36:57 -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 3EFBD12E27B for <>; Mon, 18 Apr 2016 09:36:57 -0700 (PDT)
Received: from kitterma-e6430.localnet ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4776DC4023D for <>; Mon, 18 Apr 2016 11:36:55 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=201409; t=1460997415; bh=bRDLgS1VXjIsBWYtF4TeDpXSACgyr88ojpqIZz5bfIk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A/RTmwp1qDww3MTGMhIUKmF4Ux77EM6IIFiih69fsoipbRP7mLoOLNqkc++dlgXOE QZx/7d+ygFHhi/T/5bm4GV4gJEIonxl5LZuMXugGupNVx2GtDkj6pcOxlcYOVhKrbK 2jNIkcZ5DXGdZzkBgfQDDkiab+Ap1KMSpwaEcjEM=
From: Scott Kitterman <>
To: AppsAWG <>
Date: Mon, 18 Apr 2016 12:36:54 -0400
Message-ID: <1549185.XWxuN1SgMG@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
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 16:36:59 -0000

On Monday, April 18, 2016 01:21:16 PM Alessandro Vesely wrote:
> 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 <> 
> >>> 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

The definition of ptype includes:

   The "ptype" in the ABNF above indicates the general type of property
   being described by the result being reported, upon which the reported
   result was based.  Coupled with the "property", which is more
   specific, they indicate from which particular part of the message the
   reported data were extracted.

The exception to ptype + property indicating which particular part of the 
message from which the data is extracted is policy.  Iprev falls into policy 
specifically because (IMO) there is nothing extracted from the message.  All 
the information is from the IP connection (i.e. the address) and from DNS (the 
rdns lookup).  

This is exactly the same situation as your DNSWL proposal, so I see no reason 
to treat it differently.  Furthermore, I think that paragraph would need to be 
changed (and not via errata) to broaden the ptype definition to do what you 
propose, so even if I thought a dns ptype was appropriate, it couldn't just be 
added to the registry.

Iprev is connect IP plus DNS lookup.  Perhaps if you could explain why you 
think your DNSWL proposal is somethine else, it would help?

Scott K