[dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype?

Alessandro Vesely <vesely@tana.it> Mon, 11 November 2019 09:23 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BDF120897 for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 01:23:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 vdRIWEvOqWQv for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 01:23:08 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9C91201DB for <dmarc@ietf.org>; Mon, 11 Nov 2019 01:23:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573464186; bh=55SRjIEcGIdwEjqEVH4hgLwVmLY+AjppfzAkeohhSxc=; l=3150; h=To:Cc:References:From:Date:In-Reply-To; b=BEA7Jyp/71yDkozfy4+AsTgjzrr1YUtTFYH4bCPSmNkPlMJnzk2mXjkM7D8mEBs3B adqhohz71PU8ZNbKjlgU3tleC8xtOXT3xwr6T8dJY/b/RD/BhEl4Twdszzixonyv9w hSALzuffvn8CyvrrHQ2PgPba7Nf5rOeyaR1GCsZrJqFiLiKS/YSNwHJFXOqJP
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC076.000000005DC92879.00007FB2; Mon, 11 Nov 2019 10:23:05 +0100
To: "Murray S. Kucherawy" <superuser@gmail.com>, "Kurt Andersen (b)" <kboth@drkurt.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
References: <e580ada3-d9b5-0e5b-9ac3-eade41ac92d2@tana.it> <CAL0qLwa5yR5dVzkDSD48MDgpUa11+ri=KOwrNSqOxi8fB2i6PA@mail.gmail.com> <eabefc6b-7542-1a46-4272-b786433ed0b5@tana.it> <4783309.BXR8ZdE9c3@l5580> <CAL0qLwb5FAaYZ7AX_H=aeUFkv8cvY+xd1bQ5uCDp4tmrbx2CQg@mail.gmail.com> <7a21b80b-e6bb-d8b9-cf63-601a8d1e47e7@tana.it> <C1E711A8-F3A6-4A20-B71D-53FA773A61D9@kitterman.com> <aca25d30-3b01-4eaf-6d0b-3bae6f3f796b@tana.it> <CABuGu1ogeUjW181MMOv3kApZR5njMMH6_84EnHxF0tDq6bhBkA@mail.gmail.com> <db4b1289-31cc-9b9e-bb5c-01bf8d6a37b3@tana.it> <CAL0qLwZcBGL8syD8FyOUkVqMzsmj4=uYM0NaSU2O3hte02AZVg@mail.gmail.com> <e45b7175-713e-da69-cc18-d0e4b59410c3@tana.it> <CAL0qLwZEEzvdvydrUUrBRRDfB-+3_7_9HB244qRC-+361cgwSg@mail.gmail.com> <CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=dxK5w@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: preference=signencrypt
Message-ID: <c1983dac-09ed-ce16-29a9-f4a734ed64c3@tana.it>
Date: Mon, 11 Nov 2019 10:23:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=dxK5w@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/H0ZERkvNR704eNolqSQ2ip9pWXo>
Subject: [dmarc-ietf] Call for rfc8601 erratum (smtp.remote-ip), was Do is need a new ptype?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 09:23:09 -0000

On Mon 11/Nov/2019 08:48:01 +0100 Murray S. Kucherawy wrote:
> On Sun, Nov 10, 2019 at 10:30 PM Murray S. Kucherawy wrote:
>> On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote:
>>> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
>>>>

>>>>> On Fri 02/Aug/2019 19:22:50 +0200 Kurt Andersen (b) wrote:
>>>>> 
>>>>>> Note that  RFC8617 section 10.2 (
>>>>>> https://tools.ietf.org/html/rfc8617#section-10.2) does add in an
>>>>>> smtp.remote-ip method item.

>>>>> If the definition of ptype smtp were "a parameter of the SMTP
>>>>> session used to relay the message" it would be perfect.  I'd propose
>>>>> that policy.iprev be deprecated and smtp.remote-ip used instead
>>>> Given that RFC8601 was published just last month, it'll probably be a 
>>>> while before this happens.
>>> Wouldn't an accepted erratum be enough to change the wording in the IANA
>>> page?

>> That's not what the RFC Editor erratum system is for.  The document
>> reflects what the WG intended to publish at the time, so this isn't an
>> erratum, it's a new change to the specification.


Yes, as DE you could change it without an erratum.  However, an erratum would
serve as a justification to any reader who followed the definitions and noticed
a mismatch.

The ptype table was introduced by rfc7401, Section 3:

       +--------+-------------+----------------------------------------+
       | smtp   | RFC 7001    | The property being reported is a       |
       |        | Section 2.2 | parameter to an SMTP command used to   |
       |        |             | relay the message.                     |
       +--------+-------------+----------------------------------------+


Rfc7601 and rfc8601, both in Section 6.4 claim to be a complete restatement of
the definition and rules for this registry, and direct IANA to update this
registry to show their Section 2.3.  However, IANA still has the above definition.


> Just to be clear: The policy for changes to that registry is "Expert
> Review", but since the action that put it there was a document with IETF
> consensus, I'm pretty hesitant about just approving this change based on a
> formal request.  I'd rather at least see some consensus discussion about
> it, or even better, a revision/update to RFC8601.
> 
> -MSK, this time as DE


I think this group would make a better use of its time by discussing rfc7489bis
than rfc8601bis.  If group consensus can be enough for the time being, an
erratum can also serve as a reminder.  So I ask for it:

Does the WG agree to an erratum as follows:

TYPE: technical

SECTION: 2.3

ORIGINAL TEXT:

   smtp:  Indicates information that was extracted from an SMTP command
      that was used to relay the message.  The "property" indicates
      which SMTP command included the extracted content as a parameter.

CORRECTED TEXT:

   smtp:  Indicates information that was extracted from a parameter of
      the SMTP session that was used to relay the message.  The
      "property" indicates which parameter included the extracted content.

NOTES

   This change makes the "smtp" type consistent with the definition of
   smtp.remote-ip given in rfc8617 Section 10.2.


?



TIA for answers
Ale
--