From nobody Fri Jan 17 00:06:32 2020 Return-Path: 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 E07981207FC for ; Fri, 17 Jan 2020 00:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 p9S_BZreNxMJ for ; Fri, 17 Jan 2020 00:06:24 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F24120273 for ; Fri, 17 Jan 2020 00:06:24 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id x18so14343664vsq.4 for ; Fri, 17 Jan 2020 00:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fyl1rH1TdGeq4hpj1lm7inX/fc68h4pbjFW62Qo0hHw=; b=GpUuxfPCeBDgkK3QoHTt3rcV7Locwkjsw+jSRE9J+JbDLkif/iBeM2F2M0SNVqsKRG z6nrdGu3omgfth/itG3lH2c5Syg5UqLNi+Y1pSVGlQyWM4Fa3K3dksLmRjX6XGDC8cRa BKHLPK1+p4bHn82hs0FeM9cP01XwSIOxTGs6Nb/rx83lwNOf2j9dE6LjrjbJuKA04xTG 8GtqHQ4oP4HWjENiJxNqwcBq96X38UvUsrkMXTHmkAfUeqt7oUMsbhkJgZ681OaGj1Wt FbDJNo89vprulZ56h/i4cH71Vp4aPqzO6RQumHC49wehm1oPsVgvOtbaH5wMGq8GPVnH Rkog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fyl1rH1TdGeq4hpj1lm7inX/fc68h4pbjFW62Qo0hHw=; b=L/gG+Lp4b0SFC3XqttmHcx5NFoHw1cTVGHZWhSEorW4TG5xWz003dfTiEHbdzFufOQ 3nQknxP1U/iyu05eaPa9wkYQv2fhg2OyY8z6ehgxC3oDQ0WxGPZPuBbcxEGosQPogvTL cGKsg3XHCcygUSSR4GnXB73QdksYBrS0hO2fAVHpQXSaRGyArAFCUIKJ1CN1Bh89wWfS Z9qFZig0XbuYJrwFzlt4SOYcQWk+o90fKRtDp0rZBqmXIgsuN8vNgaduUS20CyL64qRh SuQ5RXk5ySmDBufxeCnAtMm5SYaQylTopQ/gTHjRUbiqaImRzS6AAMMM6p2kL5RGgCdd 105g== X-Gm-Message-State: APjAAAVd2mvP9wgO7UfQxuapDgakOKVRksn880NmgDmvVu9ZthTJ7aAW lonDQ7y1SnHuBtSktEZr6JGPKEZ6Te5/lKwO3ck= X-Google-Smtp-Source: APXvYqzA3AI1dG0Qe144Lxm3GePpFO6aLgyVH4sjKNeIy8+OYK4msrIMzv+vHfp3bPCUlPOgmlWvI7KTe4zSo2vXJGI= X-Received: by 2002:a67:ea87:: with SMTP id f7mr3878293vso.52.1579248382984; Fri, 17 Jan 2020 00:06:22 -0800 (PST) MIME-Version: 1.0 References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> In-Reply-To: <082f2102-693c-136d-874c-1182f12a6818@gmail.com> From: "Murray S. Kucherawy" Date: Fri, 17 Jan 2020 00:06:11 -0800 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e148ae059c516a2a" Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 08:06:31 -0000 --000000000000e148ae059c516a2a Content-Type: text/plain; charset="UTF-8" On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker wrote: > The IETF does not typically -- or, as far as I recall, ever -- promote > specifications known not to scale. (While I think of this concern as > foundational to the IETF, it's a bit odd that nothing like it is included in the IETF's "Mission and principles" statement.[1]) > I'm not sure that I would reasonably expect anything labeled "Experimental" to scale, especially if it were to make very explicit claims to the contrary. Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable. But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale. > > Comparing it to the "obs" grammars of days of yore, the PSD proposal > > is much too expensive to become engrained as-is, whereas the old > > grammars were relatively easy to carry forward. > > I don't quite grok the reference to "obs", and mostly think of the > introduction of that construct in RFC 2822 as an interesting idea that, > itself, failed. (I see it as being instructive on the challenges of > designing for transition from an installed base.) > That was indeed the intended reference. All sorts of experimental specs fail. But they aren't /expected/ to > fail. And they aren't expected to be unable to scale. > This one isn't expected to fail, but its mechanism is not (as far as I can tell) intended to be permanent, nor could it become so. In terms of meeting its stated goal, we don't know the outcome yet. We have a guess, but we need data to confirm it, and everyone participating needs to agree on how to participate. That seems to me to be what an Experimental specification is for. The non-scalable component is part of the means by which participants agree on the operation of the test itself. Mostly, IETF/Experimental is used to check whether a spec is > operationally viable -- it's expected to be but the community isn't > quite sure -- or to check for community interest. The latter > constitutes market research, not technical research. > I would claim it's clear that this is the former. We're trying to assess whether this extended logic is a reasonable change to the accuracy of DMARC. Some of the supporting mechanism added in the experiment is ancillary to that goal, and is discardable. Nothing to do with market research. A pointedly friendly reading of the relevant Guidelines might seem to > support the publication under IETF/Experimental being proposed here, but > a more critical one probably doesn't and I think that this use of the > label doesn't really match common practice.[2] > The status chosen most closely reflects the intent and quality of the work, certainly as compared to something aiming for the standards track. And there's consensus to move forward, or was when WGLC ended. Quite a bit of time has now passed since then and we are no closer to getting the answers the working group needs to make progress on the core issues it's facing. Rightly, there's now a lot of grumbling going on. Since one of your core assertions is that the IETF shouldn't publish things like this, I have suggested that, as a compromise, interested parties proceed with the experiment using the document in its draft state. Unfortunately I am also regularly reminded that there are organizations wishing to participate in this experiment and related work but which simply cannot, by reason of policy, do so without this document being first approved for publication. I personally find that position peculiar -- many things from DKIM up to QUIC are implemented experimentally by very large operators during development, without an approved document -- and it's not really the IETF's responsibility to acquiesce, but nevertheless it results in some urgency for this community to find a way forward here. So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns? The real challenge for most IETF specs is community engagement, not > engineering adequacy. > Interestingly I would claim we have clearly achieved the former here, though obviously not the latter. Also, any suggestion to rely on a published list ignores the history of > problems with such lists, as well as at least requiring a careful > specification for the list and a basis for believing it will be > maintained well. > The list, as I understand its use in the specification, amounts to a list of who's participating in the experiment. When the experiment is done, the list goes away, and the concerns of its maintenance would go with it. -MSK --000000000000e148ae059c516a2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2019 at 8:44 AM Dave Crock= er <dcrocker@gmail.com> wro= te:
The IETF does not typically -- or, as far as I recall, ever = -- promote
specifications known not to scale.=C2=A0 (While I think of this concern as<= br> foundational to the IETF, it's a bit odd that nothing like it is=C2=A0<= /blockquote>
included in t= he IETF's "Mission and principles" statement.[1])

I'm not sure that I would reasonably expect an= ything labeled "Experimental" to scale, especially if it were to = make very explicit claims to the contrary.=C2=A0 Nothing I've worked on= at the IETF with such a label is something I would necessarily stand behin= d as Internet-scalable.=C2=A0 But I would probably expect something at Info= rmational probably to scale, and anything with "Standard" in it c= ertainly to scale.
=C2=A0
> Comparing it to the "obs" grammars of da= ys of yore, the PSD proposal
> is much too expensive to become engrained as-is, whereas the old
> grammars were relatively easy to carry forward.

I don't quite grok the reference to "obs", and mostly think o= f the
introduction of that construct in RFC 2822 as an interesting idea that,
itself, failed.=C2=A0 (I see it as being instructive on the challenges of designing for transition from an installed base.)

=
That was indeed the intended reference.

All sorts of experimental spe= cs fail.=C2=A0 But they aren't /expected/ to
fail.=C2=A0 And they aren't expected to be unable to scale.

This one isn't expected to fail, but its mecha= nism is not (as far as I can tell) intended to be permanent, nor could it b= ecome so.=C2=A0 In terms of meeting its stated goal, we don't know the = outcome yet.=C2=A0 We have a guess, but we need data to confirm it, and eve= ryone participating needs to agree on how to participate.=C2=A0 That seems = to me to be what an Experimental specification is for.=C2=A0 The non-scalab= le component is part of the means by which participants agree on the operat= ion of the test itself.

Mostly, IETF/Experimental is used to check whether a spec is
operationally viable -- it's expected to be but the community isn't=
quite sure -- or to check for community interest.=C2=A0 The latter
constitutes market research, not technical research.
<= br>
I would claim it's clear that this is the former.=C2=A0 W= e're trying to assess whether this extended logic is a reasonable chang= e to the accuracy of DMARC.=C2=A0 Some of the supporting mechanism added in= the experiment is ancillary to that goal, and is discardable.=C2=A0 Nothin= g to do with market research.

A pointedly friendly reading of the relevant Guidelines might seem to
support the publication under IETF/Experimental being proposed here, but a more critical one probably doesn't and I think that this use of the label doesn't really match common practice.[2]
The status chosen most closely reflects the intent and quality of the = work, certainly as compared to something aiming for the standards track.=C2= =A0 And there's consensus to move forward, or was when WGLC ended.=C2= =A0 Quite a bit of time has now passed since then and we are no closer to g= etting the answers the working group needs to make progress on the core iss= ues it's facing.=C2=A0 Rightly, there's now a lot of grumbling goin= g on.

Since one of your core assertions = is that the IETF shouldn't publish things like this, I have suggested t= hat, as a compromise, interested parties proceed with the experiment using = the document in its draft state.=C2=A0 Unfortunately I am also regularly re= minded that there are organizations wishing to participate in this experime= nt and related work but which simply cannot, by reason of policy, do so wit= hout this document being first approved for publication.=C2=A0 I personally= find that position peculiar -- many things from DKIM up to QUIC are implem= ented experimentally by very large operators during development, without an= approved document -- and it's not really the IETF's responsibility= to acquiesce, but nevertheless it results in some urgency for this communi= ty to find a way forward here.

So: Can you propose any sort of= specific restructuring of the document or the experiment that achieves the= same goal as the current version while also resolving your concerns?
=

The real challenge for most IETF specs is community engagement, not
engineering adequacy.

Interestingly I w= ould claim we have clearly achieved the former here, though obviously not t= he latter.

Also, any suggestion to rely on a published list ignores the history of problems with such lists, as well as at least requiring a careful
specification for the list and a basis for believing it will be
maintained well.

The list, as I underst= and its use in the specification, amounts to a list of who's participat= ing in the experiment.=C2=A0 When the experiment is done, the list goes awa= y, and the concerns of its maintenance would go with it.

=
-MSK
--000000000000e148ae059c516a2a-- From nobody Fri Jan 17 08:44:38 2020 Return-Path: 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 93232120018 for ; Fri, 17 Jan 2020 08:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f0lNpcOdPdHj for ; Fri, 17 Jan 2020 08:44:30 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38DD120043 for ; Fri, 17 Jan 2020 08:44:29 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id r27so23037811otc.8 for ; Fri, 17 Jan 2020 08:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=WY0tpEPOqs8lEXjOnA5q/pH2cuRT46/ChymCVO9Eyek=; b=fRUMRBPGhs1D+fe1nCVet8XfeGwHNlZFKVtao6MCGNf2GwVZFW8ZPjpaXG0sHNHHHs g5kIz6YjWVmb0YwriSm4kYGD2/dz3yx+LdINohL79ro//a2IVmmZOfuUtkhQlFtm2sAa mnnX6btIUJHirLJa06APSad0gfEPg3Y9IZQMZ5nHpv1ZhbFMC1b28cLuZpRizKqlcKH6 x4tdwJW9FP7aIz+wEoevc0x92iVfNcSEOAVWqpDUBb0fqih/M/8IfpTqpAw0CA3o45re ZWgom5I5lx0lSQZk9+bFv0gP1uK3m+r9HIFhNVq7dm3ApMxCuEHPB3v9uJJYoP4MZ/nL ZCBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=WY0tpEPOqs8lEXjOnA5q/pH2cuRT46/ChymCVO9Eyek=; b=G7MgjBomrDV9IBupoRVIKbCWrYiKO1btgz2oowbDo/3/LgsQosW3FWqc9HSMHV48Tb yGmESm6v+Qbf4pGf8zIoN1KbJ8+zN2VuhHeX2Y70alu96OtLvLCd4IrBBQiNapriqvpH pQ0x6AF10PpB99D0b1Uy4zuhT+QnGmXqDPcNDznn7T4s6w6xMr1IS1qDF1dS6V3phH6R 7EXYXVO90x3ZkunxO7SR57dGjuRKg2jrxeQvrndoayR7zbxjrVR5MIZ4iW+RdHqKfbLW 89m6mHMt6TbLeN4KVvwmMOd5XclRoF9UPzqjpLd39XS4CPQDCBscwOpWvZUfsw8CW47k NL7g== X-Gm-Message-State: APjAAAWATdMN9Q4TGtyVszW6ruxNdbYojPd/NwEuEZNd3bGoIIjqYFk+ vunSMhxtna+jXD92PUijRzE+w/kj X-Google-Smtp-Source: APXvYqzfxTwuzc4rCAknrbT7uaJR8tLmRvQuEQ5Ov4BF/6iNTaG/bqbrRp1mKZ5NKAOGliioUjUFIg== X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr6622717otr.82.1579279468923; Fri, 17 Jan 2020 08:44:28 -0800 (PST) Received: from ?IPv6:2600:1700:a3a0:4c80:649c:3df8:f4d6:1f10? ([2600:1700:a3a0:4c80:649c:3df8:f4d6:1f10]) by smtp.gmail.com with ESMTPSA id q25sm9113171otf.45.2020.01.17.08.44.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jan 2020 08:44:28 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <79b1cbe6-8a53-9157-63de-210fd2bad89a@dcrocker.net> <082f2102-693c-136d-874c-1182f12a6818@gmail.com> From: Dave Crocker Message-ID: <1aa141c4-50d8-4f2e-c72f-e1d0bf19f280@gmail.com> Date: Fri, 17 Jan 2020 08:44:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4D264ECD60FDB3CF8CE454AC" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 16:44:37 -0000 This is a multi-part message in MIME format. --------------4D264ECD60FDB3CF8CE454AC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/17/2020 12:06 AM, Murray S. Kucherawy wrote: > On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker > wrote: > > The IETF does not typically -- or, as far as I recall, ever -- promote > specifications known not to scale.  (While I think of this concern as > foundational to the IETF, it's a bit odd that nothing like it is > > included in the IETF's "Mission and principles" statement.[1]) > > > I'm not sure that I would reasonably expect anything labeled > "Experimental" to scale, especially if it were to make very explicit > claims to the contrary. As a standalone bit of thinking that sounds reasonable, but it does not match my sense of IETF history, nor my sense of application of that model in the case of X-.  What you describe makes sense for something out of the IRTF, not IETF. As for IETF history, while there certainly have been IETF Experimental RFCs that have failed, I don't recall their being /expected/ to fail.  (I'm counting inability to scale as failure. If anyone has a different view of inability to scale, there needs to be a separate discussion...) For the latter:  X- was an email header field construct design to make an explicit statement that something was /not/ a standard header field. I was added to the RFC 822 spec, though I do not remember who first suggested it, other than it wasn't me.  I thought it a fine and reasonable idea, as did many others.  Note that it was eventually deprecated. Because it did not work as intended:  People using X- fields came to rely on them, creating defacto standards. That's the danger with an IETF stream RFC, especially one coming out of a working group: Those implementing and using an IETF published specification tend to come to rely on continuing to use it. > Nothing I've worked on at the IETF with such a label is something I > would necessarily stand behind as Internet-scalable. Such as? > But I would probably expect something at Informational probably to > scale, and anything with "Standard" in it certainly to scale. Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent. > > Comparing it to the "obs" grammars of days of yore, the PSD proposal > > is much too expensive to become engrained as-is, whereas the old > > grammars were relatively easy to carry forward. > > I don't quite grok the reference to "obs", and mostly think of the > introduction of that construct in RFC 2822 as an interesting idea > that, > itself, failed.  (I see it as being instructive on the challenges of > designing for transition from an installed base.) > > > That was indeed the intended reference. I don't understand how you see benefit in citing a reasonable idea that failed -- obs- did not serve its intended purpose and was in a standards track specification: The obs- rules both weren't deprecated from later work and continue to be relied on. If anything, it validates my concern about entrenched use. > All sorts of experimental specs fail.  But they aren't /expected/ to > fail.  And they aren't expected to be unable to scale. > > > This one isn't expected to fail, If it is known that it can't scale, that's inherent failure for IETF work. > but its mechanism is not (as far as I can tell) intended to be > permanent, nor could it become so. You keep making statements that warrant this as IRTF work, not IETF work. > Since one of your core assertions is that the IETF shouldn't publish > things like this, I have suggested that, as a compromise, interested > parties proceed with the experiment using the document in its draft > state. Sounds like a fine idea, to me. > Unfortunately I am also regularly reminded that there are > organizations wishing to participate in this experiment and related > work but which simply cannot, by reason of policy, do so without this > document being first approved for publication. That should raise some very bold, very large red flags about publishing this as an IETF stream RFC. > So: Can you propose any sort of specific restructuring of the document > or the experiment that achieves the same goal as the current version > while also resolving your concerns? I'm pretty sure I've raised fundamental concerns about this work and that those concerns have not been addressed.  The simple summary is that the way to restructure this work is to go back to first principles.  But there doesn't seem to be any interest in having that sort of discussion. > > The real challenge for most IETF specs is community engagement, not > engineering adequacy. > > > Interestingly I would claim we have clearly achieved the former here, > though obviously not the latter. My sense is -- as has become common in the IETF -- an extremely small core of folk interesting in promoting this work, rather than extensive community interest. Extensive community interest is what generates serious demonstration of utility at scale. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------4D264ECD60FDB3CF8CE454AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/17/2020 12:06 AM, Murray S. Kucherawy wrote:
On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker <dcrocker@gmail.com> wrote:
The IETF does not typically -- or, as far as I recall, ever -- promote
specifications known not to scale.  (While I think of this concern as
foundational to the IETF, it's a bit odd that nothing like it is 
included in the IETF's "Mission and principles" statement.[1])

I'm not sure that I would reasonably expect anything labeled "Experimental" to scale, especially if it were to make very explicit claims to the contrary.

As a standalone bit of thinking that sounds reasonable, but it does not match my sense of IETF history, nor my sense of application of that model in the case of X-.  What you describe makes sense for something out of the IRTF, not IETF.

As for IETF history, while there certainly have been IETF Experimental RFCs that have failed, I don't recall their being /expected/ to fail.  (I'm counting inability to scale as failure. If anyone has a different view of inability to scale, there needs to be a separate discussion...)

For the latter:  X- was an email header field construct design to make an explicit statement that something was /not/ a standard header field. I was added to the RFC 822 spec, though I do not remember who first suggested it, other than it wasn't me.  I thought it a fine and reasonable idea, as did many others.  Note that it was eventually deprecated. Because it did not work as intended:  People using X- fields came to rely on them, creating defacto standards.

That's the danger with an IETF stream RFC, especially one coming out of a working group: Those implementing and using an IETF published specification tend to come to rely on continuing to use it.


Nothing I've worked on at the IETF with such a label is something I would necessarily stand behind as Internet-scalable. 

Such as?


But I would probably expect something at Informational probably to scale, and anything with "Standard" in it certainly to scale.

Laying any general expectation on an IETF Informational RFC would be a mistake, because there is so much variety in their content and intent.


> Comparing it to the "obs" grammars of days of yore, the PSD proposal
> is much too expensive to become engrained as-is, whereas the old
> grammars were relatively easy to carry forward.

I don't quite grok the reference to "obs", and mostly think of the
introduction of that construct in RFC 2822 as an interesting idea that,
itself, failed.  (I see it as being instructive on the challenges of
designing for transition from an installed base.)

That was indeed the intended reference.

I don't understand how you see benefit in citing a reasonable idea that failed -- obs- did not serve its intended purpose and was in a standards track specification: The obs- rules both weren't deprecated from later work and continue to be relied on.  If anything, it validates my concern about entrenched use.


All sorts of experimental specs fail.  But they aren't /expected/ to
fail.  And they aren't expected to be unable to scale.

This one isn't expected to fail,

If it is known that it can't scale, that's inherent failure for IETF work.


but its mechanism is not (as far as I can tell) intended to be permanent, nor could it become so. 


You keep making statements that warrant this as IRTF work, not IETF work.


Since one of your core assertions is that the IETF shouldn't publish things like this, I have suggested that, as a compromise, interested parties proceed with the experiment using the document in its draft state. 


Sounds like a fine idea, to me.


Unfortunately I am also regularly reminded that there are organizations wishing to participate in this experiment and related work but which simply cannot, by reason of policy, do so without this document being first approved for publication.


That should raise some very bold, very large red flags about publishing this as an IETF stream RFC.


So: Can you propose any sort of specific restructuring of the document or the experiment that achieves the same goal as the current version while also resolving your concerns?


I'm pretty sure I've raised fundamental concerns about this work and that those concerns have not been addressed.  The simple summary is that the way to restructure this work is to go back to first principles.  But there doesn't seem to be any interest in having that sort of discussion.



The real challenge for most IETF specs is community engagement, not
engineering adequacy.

Interestingly I would claim we have clearly achieved the former here, though obviously not the latter.

My sense is -- as has become common in the IETF -- an extremely small core of folk interesting in promoting this work, rather than extensive community interest.


Extensive community interest is what generates serious demonstration of utility at scale.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------4D264ECD60FDB3CF8CE454AC--