From nobody Sat Nov 7 20:40:35 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F213A03F2 for ; Sat, 7 Nov 2020 20:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=apple.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 eCzwSYbrAip0 for ; Sat, 7 Nov 2020 20:40:32 -0800 (PST) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E553A03EC for ; Sat, 7 Nov 2020 20:40:31 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0A84eOuS036526; Sat, 7 Nov 2020 20:40:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=Kh4Z1jzeY+jOggRi0MoQcCn9hfdVmjbKbRKSetQMXNU=; b=Yg5/oZr9pkVq2Otz9TIp6qwoxuqPavv+qX1BOw3iA4p+ixhzJiAkipJWXiHAW4BFav2R oBXdCyn7tZvnspNGvIVZ4cmneAQ27oUuoyQXGlOrJuctvgfFa9CBOHWsZNU1g+cI44Ly DflMaSgLfR9F5hJrAFgKlu4EHu1qpRjrf8A+1PX4DMAo2KxIqlsgw5iB6vLha6WQkTk7 7zfY7YCLjd4AGayytmUP2Xc2Nhm2VA0N/gO2ktzDO2G+/YBrf3AEbpqrwuHByOZx6WW7 1rczma9z2Xjk9RynXqC478wbuXR9rRqnggtoUCWTHsv+rV+KJ19CkSo3q7wY6fItQ9k1 Ag== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp03.apple.com with ESMTP id 34ns06w8gm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 07 Nov 2020 20:40:30 -0800 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJG002ERNNIRW90@rn-mailsvcp-mta-lapp01.rno.apple.com>; Sat, 07 Nov 2020 20:40:30 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJG00I00MYQA000@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 07 Nov 2020 20:40:30 -0800 (PST) X-Va-A: X-Va-T-CD: e05e48b703e8c4fcb2d0af9a0cbbeb5a X-Va-E-CD: c4681f1df7dfa3eb06bd286135609715 X-Va-R-CD: 60841d6209217f4e65748f4bac09fb92 X-Va-CD: 0 X-Va-ID: 0f1c6ccf-afa2-4239-bab9-ff066f802fbb X-V-A: X-V-T-CD: e05e48b703e8c4fcb2d0af9a0cbbeb5a X-V-E-CD: c4681f1df7dfa3eb06bd286135609715 X-V-R-CD: 60841d6209217f4e65748f4bac09fb92 X-V-CD: 0 X-V-ID: 455874db-77ab-482a-8b33-3c0ecbaab9f5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-08_01:2020-11-05, 2020-11-08 signatures=0 Received: from localhost.localdomain (unknown [17.232.195.55]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJG00MD6NN90A00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 07 Nov 2020 20:40:25 -0800 (PST) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_3E367C50-004D-4FB0-83D6-03DF28C46429" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Message-id: Date: Sat, 07 Nov 2020 20:40:19 -0800 To: edm@iab.org, Martin Thomson , Mark Nottingham X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-08_01:2020-11-05, 2020-11-08 signatures=0 Archived-At: Subject: [Edm] Thoughts on greasing mechanisms X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 04:40:34 -0000 --Apple-Mail=_3E367C50-004D-4FB0-83D6-03DF28C46429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the items I=E2=80=99d like to get kicked off for our work in the = EDM program is updating and working on draft-iab-use-it-or-lose-it, = which analyzes some problems with extension point use and makes = recommendations. One of the newer approaches it covers is = =E2=80=9Cgreasing=E2=80=9D. I filed the following issue for discussion, = and would like to hear the input of the people on this list. https://github.com/intarchboard/edm/issues/7 = Can greasing mechanisms avoid reserving or coordinating "fake" values? In TLS, GREASE (https://www.rfc-editor.org/rfc/rfc8701.html) reserves = several values in different extension code point spaces to be used for = greasing=E2=80=94that is, endpoints will randomly select some of the = reserved values to send to the peer in order to ensure that the peer can = handle unknown values. This is also described in the use-it-or-lose-it draft which EDM is = looking at = (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose= -it.html#rfc.section.4.3). The description here also refers to the = approach of reserving these values. For existing protocols like TLS, reserving values seems to be the safest = option. The downside is that these values represent only a finite subset = of possible values; it is possible to still ossify to allow reserved = greased values, but not allow others (if your implementation is = particularly obstructive). It is also necessary to choose a wide = distribution of values that ensure that the entire range of possible = values is kept from ossifying. Reservation of values is harder for other kinds of extension points. For = example, the proposed HTTP greasing = (https://tools.ietf.org/html/draft-nottingham-http-grease-01) discusses = greasing header names and values. Since these are strings and other = arbitrary values, simply reserving these ahead of time doesn't make = sense. The proposal here is to have a coordination effort where greased = values are agreed upon by the community. If we are looking at recommendations for new protocol design, I wonder = if we can come up with recommendations that achieve the goals of = greasing without needing to rely on either reservation or coordination. A goal we could have is that an endpoint can (and would) generate random = or unknown values for various extension points to prevent ossification; = but not risk causing a peer that actually does understand and handle = that value to think that the endpoint is trying to use a protocol = feature. Put another way, the random value should be indistinguishable = from a valid value to the receiver of the value that doesn't support the = valid version of the value; but a receiver that does understand the = valid version of the value should be able to distinguish a = greased/random value from an intentional value. Consider an extension point like the ones that are greased in TLS, where = the values are numbers within a range (say, 16-bit integers). Rather = than just using these as Types in a Type-Length-Value scheme, the = encoding could also include a value that proves if the sender is using a = type based on a given version of a standard, or is just sending random = data. Call this Type-Length-Hash-Value. In this case, when a given type = is reserved, it could also define a unique pattern that can be hashed = with something that changes in a message where the extension appears = (like a nonce). If the receiver also knows the same unique pattern, it = could confirm that the sender has the same understanding of the type by = calculating the hash. A receiver that doesn't understand the type = wouldn't be able to tell whether or not this was greased or valid. A similar approach could be taken when the extensible values are = strings, etc, allowing implementations to send random values without = coordination. Curious to hear people=E2=80=99s thoughts! Best, Tommy= --Apple-Mail=_3E367C50-004D-4FB0-83D6-03DF28C46429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
One of the items I=E2=80=99d like to get kicked off for our = work in the EDM program is updating and working = on draft-iab-use-it-or-lose-it, which analyzes some problems with = extension point use and makes recommendations. One of the newer = approaches it covers is =E2=80=9Cgreasing=E2=80=9D. I filed the = following issue for discussion, and would like to hear the input of the = people on this list.

https://github.com/intarchboard/edm/issues/7

Can greasing = mechanisms avoid reserving or coordinating "fake" = values?

In TLS, GREASE (https://www.rfc-editor.org/rfc/rfc8701.html) reserves = several values in different extension code point spaces to be used for = greasing=E2=80=94that is, endpoints will randomly select some of = the reserved values to send to the peer in order to ensure that the peer = can handle unknown values.

This is also described in the use-it-or-lose-it draft which = EDM is looking at (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-= it-or-lose-it.html#rfc.section.4.3). The description here also = refers to the approach of reserving these values.
For existing protocols like TLS, = reserving values seems to be the safest option. The downside is that = these values represent only a finite subset of possible values; it is = possible to still ossify to allow reserved greased values, but not = allow others (if your implementation is particularly obstructive). It is = also necessary to choose a wide distribution of values that = ensure that the entire range of possible values is kept from = ossifying.

Reservation of values is harder for other kinds of extension = points. For example, the proposed HTTP greasing (https://tools.ietf.org/html/draft-nottingham-http-grease-01= ) discusses greasing header names and values. Since these are = strings and other arbitrary values, simply reserving these ahead of time = doesn't make sense. The proposal here is to have a coordination = effort where greased values are agreed upon by the community.

If we are looking at = recommendations for new protocol design, I wonder if we can come up with = recommendations that achieve the goals of greasing without needing to = rely on either reservation or coordination.

A goal we could have is that an = endpoint can (and would) generate random or unknown values for various = extension points to prevent ossification; but not risk causing a peer = that actually does understand and handle that value to think that = the endpoint is trying to use a protocol feature. Put another way, the = random value should be indistinguishable from a valid value to the = receiver of the value that doesn't support the valid version of the = value; but a receiver that does understand the valid version of the = value should be able to distinguish a greased/random value from an = intentional value.

Consider an extension point like the ones that are greased in = TLS, where the values are numbers within a range (say, 16-bit integers). = Rather than just using these as Types in a Type-Length-Value scheme, the = encoding could also include a value that proves if the sender is using a = type based on a given version of a standard, or is just sending random = data. Call this Type-Length-Hash-Value. In this case, when a given = type is reserved, it could also define a unique pattern that can be = hashed with something that changes in a message where the extension = appears (like a nonce). If the receiver also knows the same unique = pattern, it could confirm that the sender has the same understanding of = the type by calculating the hash. A receiver that doesn't = understand the type wouldn't be able to tell whether or not this was = greased or valid.

A similar approach could be taken when the extensible values = are strings, etc, allowing implementations to send random values without = coordination.

Curious to hear people=E2=80=99s thoughts!

Best,
Tommy
= --Apple-Mail=_3E367C50-004D-4FB0-83D6-03DF28C46429-- From nobody Sun Nov 8 00:02:06 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27C13A0B9D for ; Sun, 8 Nov 2020 00:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=mnot.net header.b=NB3YCUlp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c47NEH8M 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 Oe1Zyp31rFsS for ; Sun, 8 Nov 2020 00:01:59 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9043A0A3B for ; Sun, 8 Nov 2020 00:01:58 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3F86D63B for ; Sun, 8 Nov 2020 02:32:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 08 Nov 2020 02:32:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=RL3R2RmnM5k80tKuH8lrGeOSYtvlq9FDvE6QXDv+Ixo=; b=NB3YCUlp jD93ShYnQ20hy9n2X4EYoECHrgi4rAOLfKu0wNdIU6eT79EjWkYP4dJo0U43N+pr u48ESsLgWStLNDJVQVqK/oefUJ+Y3X5mzLtrYe651T4sSGU8vqnLXkuYkeJAPyKO Mscx1UDXlu+bUHUQ6UR+FGnEJgvLZuPBPWWezfEivCHrQiSc1CSWhpZKhR2/B6O8 AgnCfKr6kayR5QEgtyBuI3U5K4lLB+FfMpgZocgKpZteeAEjyAoJFhNKNJZgVG/N JfsIu+Bx2UmXLw4a5YroSJpFjw9i2KOi8UygLIwXsAKV79wNoSYEhtsbKIy9fF5P ydCOzn6LQsTyHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=RL3R2RmnM5k80tKuH8lrGeOSYtvlq 9FDvE6QXDv+Ixo=; b=c47NEH8MPLwtCWhoBQ65sIM9PHHCVl1tS3RPPxz0XeQSa 9Q5+Qz46jOvjH4542CoSIyWlqALWIkEgOvnLmH3NgHGu/zhU+bJpKahaCgz9L8Ix S2rYxSeUk2GzshmWwVdceFZ213yhlq04GKb6B9VRvbrgSSkWsf/qXZxFydGn+K1D StRSt8q+ZFT6vn0nloMKo0LBwZfDe/7DhOwNjwAaoO49FqQ5K4CE+9iU4Pv9zfGv mmSzM7noJp1grGLDWfS/TQWeSIcvixeQYGAV8q97fdadvae3FPLaSZDBQ7JKRMSr 9toB5yQ7bOURZz0mIN7gS2S0lOZ/tkg7UiALXqehA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudduvddguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudefkedrkedurd egjeenucevlhhushhtvghrufhiiigvpeeinecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az59-950.internal.cloudapp.net (unknown [52.138.81.47]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D469328005D for ; Sun, 8 Nov 2020 02:32:58 -0500 (EST) Content-Type: multipart/alternative; boundary="===============4891382932657654534==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: edm@iab.org Message-Id: <20201108073258.8D469328005D@mailuser.nyi.internal> Date: Sun, 8 Nov 2020 02:32:58 -0500 (EST) Archived-At: Subject: [Edm] Weekly github digest (EDM Activity Summary) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 08:02:01 -0000 --===============4891382932657654534== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * intarchboard/edm (+1/-0/=F0=9F=92=AC0) 1 issues created: - Can greasing mechanisms avoid reserving or coordinating "fake" values? = (by tfpauly) https://github.com/intarchboard/edm/issues/7=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/edm --===============4891382932657654534== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (EDM Activity Summary)

Sunday November 08, 2020

Issues

intarchboard/edm (+1/-0/=F0=9F=92=AC0)

1 issues created:

Repositories tracked by this digest:

--===============4891382932657654534==-- From nobody Thu Nov 12 11:07:05 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10753A0045; Thu, 12 Nov 2020 11:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XkX6wTGrP2r1; Thu, 12 Nov 2020 11:07:01 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3F93A003F; Thu, 12 Nov 2020 11:07:00 -0800 (PST) Received: from p200300dee707b600141061c179aad33d.dip0.t-ipconnect.de ([2003:de:e707:b600:1410:61c1:79aa:d33d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kdHvr-0001kF-MJ; Thu, 12 Nov 2020 20:06:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 12 Nov 2020 20:06:54 +0100 Cc: edm@iab.org, Martin Thomson , Mark Nottingham Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tommy Pauly X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1605208021;cb794178; X-HE-SMSGID: 1kdHvr-0001kF-MJ Archived-At: Subject: Re: [Edm] Thoughts on greasing mechanisms X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 19:07:04 -0000 Hm=E2=80=A6 I guess I have to say I=E2=80=99m not the biggest greasing = =E2=80=9Cfan=E2=80=9D. Greasing has proven a really useful mechanism, = e.g. in the case of TLS to actually detect broken systems, however, = I=E2=80=99m a bit sad that we need to build in the same hack into brand = new protocols as it feels to me like a waste to reserve codepoints for = that (as a German always looking for efficiency ;-) ). And what you = propose maybe feels like you just add more bits to it. Maybe we need to = consider better in protocol design that we not only make sure extension = mechanisms are available but also frequently used and tested? Just a = though=E2=80=A6 > On 8. Nov 2020, at 05:40, Tommy Pauly = wrote: >=20 > One of the items I=E2=80=99d like to get kicked off for our work in = the EDM program is updating and working on draft-iab-use-it-or-lose-it, = which analyzes some problems with extension point use and makes = recommendations. One of the newer approaches it covers is = =E2=80=9Cgreasing=E2=80=9D. I filed the following issue for discussion, = and would like to hear the input of the people on this list. >=20 > https://github.com/intarchboard/edm/issues/7 >=20 > Can greasing mechanisms avoid reserving or coordinating "fake" values? >=20 > In TLS, GREASE (https://www.rfc-editor.org/rfc/rfc8701.html) reserves = several values in different extension code point spaces to be used for = greasing=E2=80=94that is, endpoints will randomly select some of the = reserved values to send to the peer in order to ensure that the peer can = handle unknown values. >=20 > This is also described in the use-it-or-lose-it draft which EDM is = looking at = (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose= -it.html#rfc.section.4.3). The description here also refers to the = approach of reserving these values. >=20 > For existing protocols like TLS, reserving values seems to be the = safest option. The downside is that these values represent only a finite = subset of possible values; it is possible to still ossify to allow = reserved greased values, but not allow others (if your implementation is = particularly obstructive). It is also necessary to choose a wide = distribution of values that ensure that the entire range of possible = values is kept from ossifying. >=20 > Reservation of values is harder for other kinds of extension points. = For example, the proposed HTTP greasing = (https://tools.ietf.org/html/draft-nottingham-http-grease-01) discusses = greasing header names and values. Since these are strings and other = arbitrary values, simply reserving these ahead of time doesn't make = sense. The proposal here is to have a coordination effort where greased = values are agreed upon by the community. >=20 > If we are looking at recommendations for new protocol design, I wonder = if we can come up with recommendations that achieve the goals of = greasing without needing to rely on either reservation or coordination. >=20 > A goal we could have is that an endpoint can (and would) generate = random or unknown values for various extension points to prevent = ossification; but not risk causing a peer that actually does understand = and handle that value to think that the endpoint is trying to use a = protocol feature. Put another way, the random value should be = indistinguishable from a valid value to the receiver of the value that = doesn't support the valid version of the value; but a receiver that does = understand the valid version of the value should be able to distinguish = a greased/random value from an intentional value. >=20 > Consider an extension point like the ones that are greased in TLS, = where the values are numbers within a range (say, 16-bit integers). = Rather than just using these as Types in a Type-Length-Value scheme, the = encoding could also include a value that proves if the sender is using a = type based on a given version of a standard, or is just sending random = data. Call this Type-Length-Hash-Value. In this case, when a given type = is reserved, it could also define a unique pattern that can be hashed = with something that changes in a message where the extension appears = (like a nonce). If the receiver also knows the same unique pattern, it = could confirm that the sender has the same understanding of the type by = calculating the hash. A receiver that doesn't understand the type = wouldn't be able to tell whether or not this was greased or valid. >=20 > A similar approach could be taken when the extensible values are = strings, etc, allowing implementations to send random values without = coordination. >=20 > Curious to hear people=E2=80=99s thoughts! >=20 > Best, > Tommy > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm From nobody Thu Nov 12 14:26:21 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B573A0A06 for ; Thu, 12 Nov 2020 14:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SAmRO9k5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ByB+Bfk5 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 vI9Hve5hs33E for ; Thu, 12 Nov 2020 14:26:17 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CF73A0E72 for ; Thu, 12 Nov 2020 14:26:17 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 75A05ED6; Thu, 12 Nov 2020 17:26:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 12 Nov 2020 17:26:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=t mkGGrpVePLBUu8Oi65eIBkoXzP3tow866NkViAqHbE=; b=SAmRO9k5JST6XNuWD TGsf+gHw4DgG+GPgW5eAonK7g8CV1d0RsRXLH9nZnJkL5/mbTL1f2WRvm4iny0PU w8qtccTLdXQ8sns3R8jDn2ra6nw5oFzGpduvoLkTcxN6u7bDtE26tWKN0vk+11Sb e8xhBZj4CB1BbchX8kUwHl7DRwzd1A8zjmdyeGPGSJzb+p64oEVTHbAv01YLtCkL jnILjFdPUME+BmOxu7pZ6XLaK+c1KJKeA8NFAkNWjZC2DkfzYataasRbu7b7NqcZ JlptewMOPqKkdOjdoXXLUO52qhf4dQeFeaXDLc3okQZ1pI/HbffmJtNOWG3OzA97 m1+4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=tmkGGrpVePLBUu8Oi65eIBkoXzP3tow866NkViAqH bE=; b=ByB+Bfk5NJkSJZoasjVxpqybRaMtD7oAh5EeOiPByXnh0rjErsBfenImq mlUb8LddtJH8dQhYXcy3FRvbpi5hf2jnd7ZjtPrdxGKoNghvKZQXykmiH/IaTrUi ihYWbjC8lLr1QoUqm8PHDtlwkM7keAzeOyFBKBhnzyLGG5ycVXfffRH6FjCp/CHn qxbEUxWNysn5S2d/hGjOv80GiRao19VkpLz9UtMvxd7EWJ7Jbi3WDdFdI8UIiX6N pgThOfr1hPi+BLAYRX8ehuKAKbHgm8O3LXeUyJOnwZNYKGHJwUuNX+6nM09a+d8s KnJ4hD7hoxpUJR/rbvWwCK0jH+hZA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvfedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpegtggfuhfgjfffgkfhf vffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomh hnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepheetvdejjefgfeffgfet iedtgfevhfekgfdvgeehvdejffeufeegudeguefhudeinecuffhomhgrihhnpehgihhthh husgdrtghomhdprhhftgdqvgguihhtohhrrdhorhhgpdhgihhthhhusgdrihhopdhivght fhdrohhrghdpihgrsgdrohhrghdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrud ehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 95CE93068FC8; Thu, 12 Nov 2020 17:26:12 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mark Nottingham In-Reply-To: Date: Fri, 13 Nov 2020 09:26:10 +1100 Cc: Tommy Pauly , edm@iab.org, Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: <515CABD7-FC05-443E-8DB1-8C34DB47A394@mnot.net> References: To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Edm] Thoughts on greasing mechanisms X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 22:26:20 -0000 > On 13 Nov 2020, at 6:06 am, Mirja Kuehlewind = wrote: >=20 > Hm=E2=80=A6 I guess I have to say I=E2=80=99m not the biggest greasing = =E2=80=9Cfan=E2=80=9D. Greasing has proven a really useful mechanism, = e.g. in the case of TLS to actually detect broken systems, however, = I=E2=80=99m a bit sad that we need to build in the same hack into brand = new protocols as it feels to me like a waste to reserve codepoints for = that (as a German always looking for efficiency ;-) ). And what you = propose maybe feels like you just add more bits to it. Why are new protocols different? Once they get deployed, they become = not-new protocols, so why should our expectations change regarding = ossification?=20 > Maybe we need to consider better in protocol design that we not only = make sure extension mechanisms are available but also frequently used = and tested? Just a though=E2=80=A6 I think that's exactly what greasing is -- exercising extension points = artificially to assure that they maintain flexibility.=20 >> On 8. Nov 2020, at 05:40, Tommy Pauly = wrote: >>=20 >> One of the items I=E2=80=99d like to get kicked off for our work in = the EDM program is updating and working on draft-iab-use-it-or-lose-it, = which analyzes some problems with extension point use and makes = recommendations. One of the newer approaches it covers is = =E2=80=9Cgreasing=E2=80=9D. I filed the following issue for discussion, = and would like to hear the input of the people on this list. >>=20 >> https://github.com/intarchboard/edm/issues/7 >>=20 >> Can greasing mechanisms avoid reserving or coordinating "fake" = values? >>=20 >> In TLS, GREASE (https://www.rfc-editor.org/rfc/rfc8701.html) reserves = several values in different extension code point spaces to be used for = greasing=E2=80=94that is, endpoints will randomly select some of the = reserved values to send to the peer in order to ensure that the peer can = handle unknown values. >>=20 >> This is also described in the use-it-or-lose-it draft which EDM is = looking at = (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose= -it.html#rfc.section.4.3). The description here also refers to the = approach of reserving these values. >>=20 >> For existing protocols like TLS, reserving values seems to be the = safest option. The downside is that these values represent only a finite = subset of possible values; it is possible to still ossify to allow = reserved greased values, but not allow others (if your implementation is = particularly obstructive). It is also necessary to choose a wide = distribution of values that ensure that the entire range of possible = values is kept from ossifying. >>=20 >> Reservation of values is harder for other kinds of extension points. = For example, the proposed HTTP greasing = (https://tools.ietf.org/html/draft-nottingham-http-grease-01) discusses = greasing header names and values. Since these are strings and other = arbitrary values, simply reserving these ahead of time doesn't make = sense. The proposal here is to have a coordination effort where greased = values are agreed upon by the community. >>=20 >> If we are looking at recommendations for new protocol design, I = wonder if we can come up with recommendations that achieve the goals of = greasing without needing to rely on either reservation or coordination. >>=20 >> A goal we could have is that an endpoint can (and would) generate = random or unknown values for various extension points to prevent = ossification; but not risk causing a peer that actually does understand = and handle that value to think that the endpoint is trying to use a = protocol feature. Put another way, the random value should be = indistinguishable from a valid value to the receiver of the value that = doesn't support the valid version of the value; but a receiver that does = understand the valid version of the value should be able to distinguish = a greased/random value from an intentional value. >>=20 >> Consider an extension point like the ones that are greased in TLS, = where the values are numbers within a range (say, 16-bit integers). = Rather than just using these as Types in a Type-Length-Value scheme, the = encoding could also include a value that proves if the sender is using a = type based on a given version of a standard, or is just sending random = data. Call this Type-Length-Hash-Value. In this case, when a given type = is reserved, it could also define a unique pattern that can be hashed = with something that changes in a message where the extension appears = (like a nonce). If the receiver also knows the same unique pattern, it = could confirm that the sender has the same understanding of the type by = calculating the hash. A receiver that doesn't understand the type = wouldn't be able to tell whether or not this was greased or valid. >>=20 >> A similar approach could be taken when the extensible values are = strings, etc, allowing implementations to send random values without = coordination. >>=20 >> Curious to hear people=E2=80=99s thoughts! >>=20 >> Best, >> Tommy >> --=20 >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Fri Nov 13 00:34:19 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25CD3A164E; Fri, 13 Nov 2020 00:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dxiPoaakCyDD; Fri, 13 Nov 2020 00:34:16 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAFB3A1648; Fri, 13 Nov 2020 00:34:15 -0800 (PST) Received: from p200300dee707b600088b61e08819d0e9.dip0.t-ipconnect.de ([2003:de:e707:b600:88b:61e0:8819:d0e9]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kdUX2-0000LH-Na; Fri, 13 Nov 2020 09:34:08 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <515CABD7-FC05-443E-8DB1-8C34DB47A394@mnot.net> Date: Fri, 13 Nov 2020 09:34:06 +0100 Cc: edm@iab.org, Tommy Pauly , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: References: <515CABD7-FC05-443E-8DB1-8C34DB47A394@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1605256456;9d1ad855; X-HE-SMSGID: 1kdUX2-0000LH-Na Archived-At: Subject: Re: [Edm] Thoughts on greasing mechanisms X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 08:34:18 -0000 > On 12. Nov 2020, at 23:26, Mark Nottingham wrote: >=20 >=20 >=20 >> On 13 Nov 2020, at 6:06 am, Mirja Kuehlewind = wrote: >>=20 >> Hm=E2=80=A6 I guess I have to say I=E2=80=99m not the biggest = greasing =E2=80=9Cfan=E2=80=9D. Greasing has proven a really useful = mechanism, e.g. in the case of TLS to actually detect broken systems, = however, I=E2=80=99m a bit sad that we need to build in the same hack = into brand new protocols as it feels to me like a waste to reserve = codepoints for that (as a German always looking for efficiency ;-) ). = And what you propose maybe feels like you just add more bits to it. >=20 > Why are new protocols different? Once they get deployed, they become = not-new protocols, so why should our expectations change regarding = ossification?=20 I=E2=80=99m still hoping we can be smarter than this for new = protocols=E2=80=A6 As I said greasing is a good way to detect = ossification. Not sure if it really will avoid ossification. >=20 >> Maybe we need to consider better in protocol design that we not only = make sure extension mechanisms are available but also frequently used = and tested? Just a though=E2=80=A6 >=20 > I think that's exactly what greasing is -- exercising extension points = artificially to assure that they maintain flexibility.=20 The difference might be the word artificial. >=20 >=20 >=20 >>> On 8. Nov 2020, at 05:40, Tommy Pauly = wrote: >>>=20 >>> One of the items I=E2=80=99d like to get kicked off for our work in = the EDM program is updating and working on draft-iab-use-it-or-lose-it, = which analyzes some problems with extension point use and makes = recommendations. One of the newer approaches it covers is = =E2=80=9Cgreasing=E2=80=9D. I filed the following issue for discussion, = and would like to hear the input of the people on this list. >>>=20 >>> https://github.com/intarchboard/edm/issues/7 >>>=20 >>> Can greasing mechanisms avoid reserving or coordinating "fake" = values? >>>=20 >>> In TLS, GREASE (https://www.rfc-editor.org/rfc/rfc8701.html) = reserves several values in different extension code point spaces to be = used for greasing=E2=80=94that is, endpoints will randomly select some = of the reserved values to send to the peer in order to ensure that the = peer can handle unknown values. >>>=20 >>> This is also described in the use-it-or-lose-it draft which EDM is = looking at = (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose= -it.html#rfc.section.4.3). The description here also refers to the = approach of reserving these values. >>>=20 >>> For existing protocols like TLS, reserving values seems to be the = safest option. The downside is that these values represent only a finite = subset of possible values; it is possible to still ossify to allow = reserved greased values, but not allow others (if your implementation is = particularly obstructive). It is also necessary to choose a wide = distribution of values that ensure that the entire range of possible = values is kept from ossifying. >>>=20 >>> Reservation of values is harder for other kinds of extension points. = For example, the proposed HTTP greasing = (https://tools.ietf.org/html/draft-nottingham-http-grease-01) discusses = greasing header names and values. Since these are strings and other = arbitrary values, simply reserving these ahead of time doesn't make = sense. The proposal here is to have a coordination effort where greased = values are agreed upon by the community. >>>=20 >>> If we are looking at recommendations for new protocol design, I = wonder if we can come up with recommendations that achieve the goals of = greasing without needing to rely on either reservation or coordination. >>>=20 >>> A goal we could have is that an endpoint can (and would) generate = random or unknown values for various extension points to prevent = ossification; but not risk causing a peer that actually does understand = and handle that value to think that the endpoint is trying to use a = protocol feature. Put another way, the random value should be = indistinguishable from a valid value to the receiver of the value that = doesn't support the valid version of the value; but a receiver that does = understand the valid version of the value should be able to distinguish = a greased/random value from an intentional value. >>>=20 >>> Consider an extension point like the ones that are greased in TLS, = where the values are numbers within a range (say, 16-bit integers). = Rather than just using these as Types in a Type-Length-Value scheme, the = encoding could also include a value that proves if the sender is using a = type based on a given version of a standard, or is just sending random = data. Call this Type-Length-Hash-Value. In this case, when a given type = is reserved, it could also define a unique pattern that can be hashed = with something that changes in a message where the extension appears = (like a nonce). If the receiver also knows the same unique pattern, it = could confirm that the sender has the same understanding of the type by = calculating the hash. A receiver that doesn't understand the type = wouldn't be able to tell whether or not this was greased or valid. >>>=20 >>> A similar approach could be taken when the extensible values are = strings, etc, allowing implementations to send random values without = coordination. >>>=20 >>> Curious to hear people=E2=80=99s thoughts! >>>=20 >>> Best, >>> Tommy >>> --=20 >>> Edm mailing list >>> Edm@iab.org >>> https://www.iab.org/mailman/listinfo/edm >>=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm From nobody Fri Nov 13 11:00:01 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DC33A10A3 for ; Fri, 13 Nov 2020 10:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 adD2ima_jfsJ for ; Fri, 13 Nov 2020 10:59:49 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1B73A108C for ; Fri, 13 Nov 2020 10:59:47 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0ADIx1gM051934; Fri, 13 Nov 2020 10:59:46 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=fGamFYsmBEx/3xymCAo8caLhMi55Sf9Ld+oXEu0AyrM=; b=XfmsDf2lWXEf3O71OCaqr9NMZQZ9d+gE8XVhW8+jh5MP5JfMU0SLyyro6fdroW3laCvK u6lXVZJ6GkdgZbMZHQI51Ggw9OTin73acHbfl+nYFVAQtE9dgvC4V2PtNejYTAnUYxT9 n6g/28P1PnyaTPwM0f9ry4FUPYA1/ZiOw+O3xS0IN9XHDwlztt6GKOJriNxXVP4HCP6u wKv6HcwDdvq9A1K60YhtKQ4R8VuNOMT4+2geOP3csgvPr5E8kKGNBWubZ+2+xp7Z5UM7 6VaDnCcsEG7DvEg+ibe1WbW1ft6dEujaOyifGfklru6MCSncBJLKHa3KrE5OChqloPHH Qw== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 34ns520gnv-66 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Nov 2020 10:59:46 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJR00G8P0RL9A21@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 13 Nov 2020 10:59:45 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJR00S000JRTG00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 13 Nov 2020 10:59:45 -0800 (PST) X-Va-A: X-Va-T-CD: e9d67ce7285e94c14859feadb7d3c5c8 X-Va-E-CD: 0c7d4d1d92843a5b7a3ab26b0fb51783 X-Va-R-CD: ff8bd99ea4d6c3c3ce6a5e087244dd2c X-Va-CD: 0 X-Va-ID: c730d214-54a9-4851-ab60-408f75c64747 X-V-A: X-V-T-CD: e9d67ce7285e94c14859feadb7d3c5c8 X-V-E-CD: 0c7d4d1d92843a5b7a3ab26b0fb51783 X-V-R-CD: ff8bd99ea4d6c3c3ce6a5e087244dd2c X-V-CD: 0 X-V-ID: 1fd24df8-f6b0-45b0-b65d-b1ef2b308f76 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 Received: from localhost.localdomain (unknown [17.234.122.131]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJR00Z410RFZF00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 13 Nov 2020 10:59:44 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_817DDBCE-F369-479B-9266-12CFAD2227D9" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Fri, 13 Nov 2020 10:59:37 -0800 In-reply-to: Cc: Mark Nottingham , edm@iab.org, Martin Thomson To: Mirja Kuehlewind References: <515CABD7-FC05-443E-8DB1-8C34DB47A394@mnot.net> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 Archived-At: Subject: Re: [Edm] Thoughts on greasing mechanisms X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 18:59:59 -0000 --Apple-Mail=_817DDBCE-F369-479B-9266-12CFAD2227D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2020, at 12:34 AM, Mirja Kuehlewind = wrote: >=20 >=20 >=20 >> On 12. Nov 2020, at 23:26, Mark Nottingham wrote: >>=20 >>=20 >>=20 >>> On 13 Nov 2020, at 6:06 am, Mirja Kuehlewind = wrote: >>>=20 >>> Hm=E2=80=A6 I guess I have to say I=E2=80=99m not the biggest = greasing =E2=80=9Cfan=E2=80=9D. Greasing has proven a really useful = mechanism, e.g. in the case of TLS to actually detect broken systems, = however, I=E2=80=99m a bit sad that we need to build in the same hack = into brand new protocols as it feels to me like a waste to reserve = codepoints for that (as a German always looking for efficiency ;-) ). = And what you propose maybe feels like you just add more bits to it. >>=20 >> Why are new protocols different? Once they get deployed, they become = not-new protocols, so why should our expectations change regarding = ossification?=20 >=20 > I=E2=80=99m still hoping we can be smarter than this for new = protocols=E2=80=A6 As I said greasing is a good way to detect = ossification. Not sure if it really will avoid ossification. I think if a protocol can grease (or do an equivalent) from the start, = it actually does have a better chance of avoiding ossification. Mirja, I entirely sympathize with the desire to not reserve code points = forever for greasing=E2=80=94both for efficiency, and to avoid = implementations ossifying for the non-reserved values. That=E2=80=99s = partly why I=E2=80=99m trying to dig into the idea of how a new protocol = would be able to design its extensibility in a way that allows = =E2=80=9Cgreasing" without needing to strictly reserve codepoints. >=20 >>=20 >>> Maybe we need to consider better in protocol design that we not only = make sure extension mechanisms are available but also frequently used = and tested? Just a though=E2=80=A6 >>=20 >> I think that's exactly what greasing is -- exercising extension = points artificially to assure that they maintain flexibility.=20 >=20 > The difference might be the word artificial. Yes, I think this is what the intent of greasing is. I think what = we=E2=80=99ve seen so far is how we fit greasing into existing protocols = like TLS, but there are opportunities to have a design that bakes the = principles into the protocol itself. There could still be some = =E2=80=9Cartificial=E2=80=9D exercising of the extension mechanism, = without necessarily needing to pre-allocated =E2=80=9Cartificial=E2=80=9D = values. Fundamentally, it seems like what we need to do to defend against = ossifying a new extension mechanism is: - Ensure that implementations often see and must ignore unknown values = without adverse effects - Ensure that implementations can=E2=80=99t simply filter out a range of = unknown values and still mishandle values that will later be allocated - Ensure that an implementation can block or filter out values it knows = about that it doesn=E2=80=99t want to support on purpose (like = deprecated older values), without allowing it to block new values it = doesn=E2=80=99t understand Does that seem like the right list of goals? Tommy >=20 >>=20 >>=20 >>=20 >>>> On 8. Nov 2020, at 05:40, Tommy Pauly = wrote: >>>>=20 >>>> One of the items I=E2=80=99d like to get kicked off for our work in = the EDM program is updating and working on draft-iab-use-it-or-lose-it, = which analyzes some problems with extension point use and makes = recommendations. One of the newer approaches it covers is = =E2=80=9Cgreasing=E2=80=9D. I filed the following issue for discussion, = and would like to hear the input of the people on this list. >>>>=20 >>>> https://github.com/intarchboard/edm/issues/7 >>>>=20 >>>> Can greasing mechanisms avoid reserving or coordinating "fake" = values? >>>>=20 >>>> In TLS, GREASE (https://www.rfc-editor.org/rfc/rfc8701.html) = reserves several values in different extension code point spaces to be = used for greasing=E2=80=94that is, endpoints will randomly select some = of the reserved values to send to the peer in order to ensure that the = peer can handle unknown values. >>>>=20 >>>> This is also described in the use-it-or-lose-it draft which EDM is = looking at = (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose= -it.html#rfc.section.4.3). The description here also refers to the = approach of reserving these values. >>>>=20 >>>> For existing protocols like TLS, reserving values seems to be the = safest option. The downside is that these values represent only a finite = subset of possible values; it is possible to still ossify to allow = reserved greased values, but not allow others (if your implementation is = particularly obstructive). It is also necessary to choose a wide = distribution of values that ensure that the entire range of possible = values is kept from ossifying. >>>>=20 >>>> Reservation of values is harder for other kinds of extension = points. For example, the proposed HTTP greasing = (https://tools.ietf.org/html/draft-nottingham-http-grease-01) discusses = greasing header names and values. Since these are strings and other = arbitrary values, simply reserving these ahead of time doesn't make = sense. The proposal here is to have a coordination effort where greased = values are agreed upon by the community. >>>>=20 >>>> If we are looking at recommendations for new protocol design, I = wonder if we can come up with recommendations that achieve the goals of = greasing without needing to rely on either reservation or coordination. >>>>=20 >>>> A goal we could have is that an endpoint can (and would) generate = random or unknown values for various extension points to prevent = ossification; but not risk causing a peer that actually does understand = and handle that value to think that the endpoint is trying to use a = protocol feature. Put another way, the random value should be = indistinguishable from a valid value to the receiver of the value that = doesn't support the valid version of the value; but a receiver that does = understand the valid version of the value should be able to distinguish = a greased/random value from an intentional value. >>>>=20 >>>> Consider an extension point like the ones that are greased in TLS, = where the values are numbers within a range (say, 16-bit integers). = Rather than just using these as Types in a Type-Length-Value scheme, the = encoding could also include a value that proves if the sender is using a = type based on a given version of a standard, or is just sending random = data. Call this Type-Length-Hash-Value. In this case, when a given type = is reserved, it could also define a unique pattern that can be hashed = with something that changes in a message where the extension appears = (like a nonce). If the receiver also knows the same unique pattern, it = could confirm that the sender has the same understanding of the type by = calculating the hash. A receiver that doesn't understand the type = wouldn't be able to tell whether or not this was greased or valid. >>>>=20 >>>> A similar approach could be taken when the extensible values are = strings, etc, allowing implementations to send random values without = coordination. >>>>=20 >>>> Curious to hear people=E2=80=99s thoughts! >>>>=20 >>>> Best, >>>> Tommy >>>> --=20 >>>> Edm mailing list >>>> Edm@iab.org >>>> https://www.iab.org/mailman/listinfo/edm >>>=20 >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> --=20 >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >=20 --Apple-Mail=_817DDBCE-F369-479B-9266-12CFAD2227D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 13, 2020, at 12:34 AM, Mirja Kuehlewind <ietf@kuehlewind.net>= wrote:



On 12. Nov 2020, at 23:26, Mark Nottingham <mnot@mnot.net> wrote:



On 13 Nov 2020, at 6:06 am, Mirja Kuehlewind = <ietf@kuehlewind.net> wrote:

Hm=E2=80=A6 I guess I have to say I=E2=80=99m not the biggest = greasing =E2=80=9Cfan=E2=80=9D. Greasing has proven a really useful = mechanism, e.g. in the case of TLS to actually detect broken systems, = however, I=E2=80=99m a bit sad that we need to build in the same hack = into brand new protocols as it feels to me like a waste to reserve = codepoints for that (as a German always looking for efficiency ;-) ). = And what you propose maybe feels like you just add more bits to it.

Why are new protocols different? = Once they get deployed, they become not-new protocols, so why should our = expectations change regarding ossification?

I=E2=80=99m still hoping we can = be smarter than this for new protocols=E2=80=A6 As I said greasing is a = good way to detect ossification. Not sure if it really will avoid = ossification.

I think if a protocol can grease (or do an = equivalent) from the start, it actually does have a better chance of = avoiding ossification.

Mirja, I = entirely sympathize with the desire to not reserve code points forever = for greasing=E2=80=94both for efficiency, and to avoid implementations = ossifying for the non-reserved values. That=E2=80=99s partly why I=E2=80=99= m trying to dig into the idea of how a new protocol would be able to = design its extensibility in a way that allows =E2=80=9Cgreasing" without = needing to strictly reserve codepoints.



Maybe we need to consider better in protocol = design that we not only make sure extension mechanisms are available but = also frequently used and tested? Just a though=E2=80=A6

I think that's exactly what = greasing is -- exercising extension points artificially to assure that = they maintain flexibility.

The = difference might be the word artificial.

Yes, = I think this is what the intent of greasing is. I think what we=E2=80=99ve= seen so far is how we fit greasing into existing protocols like TLS, = but there are opportunities to have a design that bakes the principles = into the protocol itself. There could still be some =E2=80=9Cartificial=E2= =80=9D exercising of the extension = mechanism, without necessarily needing to pre-allocated =E2=80=9Cartificia= l=E2=80=9D values.

Fundamentally,= it seems like what we need to do to defend against ossifying a new = extension mechanism is:

- Ensure = that implementations often see and must ignore unknown values without = adverse effects
- Ensure that implementations can=E2=80=99t = simply filter out a range of unknown values and still mishandle values = that will later be allocated
- Ensure that an = implementation can block or filter out values it knows about that it = doesn=E2=80=99t want to support on purpose (like deprecated older = values), without allowing it to block new values it doesn=E2=80=99t = understand

Does that = seem like the right list of goals?

Tommy





On 8. Nov 2020, at 05:40, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

One of the items I=E2=80=99d like to get = kicked off for our work in the EDM program is updating and working on = draft-iab-use-it-or-lose-it, which analyzes some problems with extension = point use and makes recommendations. One of the newer approaches it = covers is =E2=80=9Cgreasing=E2=80=9D. I filed the following issue for = discussion, and would like to hear the input of the people on this = list.

https://github.com/intarchboard/edm/issues/7

Can greasing mechanisms avoid reserving or = coordinating "fake" values?

In TLS, GREASE = (https://www.rfc-editor.org/rfc/rfc8701.html) reserves several values in = different extension code point spaces to be used for greasing=E2=80=94that= is, endpoints will randomly select some of the reserved values to send = to the peer in order to ensure that the peer can handle unknown = values.

This is also described in the = use-it-or-lose-it draft which EDM is looking at = (https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose= -it.html#rfc.section.4.3). The description here also refers to the = approach of reserving these values.

For = existing protocols like TLS, reserving values seems to be the safest = option. The downside is that these values represent only a finite subset = of possible values; it is possible to still ossify to allow reserved = greased values, but not allow others (if your implementation is = particularly obstructive). It is also necessary to choose a wide = distribution of values that ensure that the entire range of possible = values is kept from ossifying.

Reservation = of values is harder for other kinds of extension points. For example, = the proposed HTTP greasing = (https://tools.ietf.org/html/draft-nottingham-http-grease-01) discusses = greasing header names and values. Since these are strings and other = arbitrary values, simply reserving these ahead of time doesn't make = sense. The proposal here is to have a coordination effort where greased = values are agreed upon by the community.

If = we are looking at recommendations for new protocol design, I wonder if = we can come up with recommendations that achieve the goals of greasing = without needing to rely on either reservation or coordination.

A goal we could have is that an endpoint can = (and would) generate random or unknown values for various extension = points to prevent ossification; but not risk causing a peer that = actually does understand and handle that value to think that the = endpoint is trying to use a protocol feature. Put another way, the = random value should be indistinguishable from a valid value to the = receiver of the value that doesn't support the valid version of the = value; but a receiver that does understand the valid version of the = value should be able to distinguish a greased/random value from an = intentional value.

Consider an extension = point like the ones that are greased in TLS, where the values are = numbers within a range (say, 16-bit integers). Rather than just using = these as Types in a Type-Length-Value scheme, the encoding could also = include a value that proves if the sender is using a type based on a = given version of a standard, or is just sending random data. Call this = Type-Length-Hash-Value. In this case, when a given type is reserved, it = could also define a unique pattern that can be hashed with something = that changes in a message where the extension appears (like a nonce). If = the receiver also knows the same unique pattern, it could confirm that = the sender has the same understanding of the type by calculating the = hash. A receiver that doesn't understand the type wouldn't be able to = tell whether or not this was greased or valid.

A similar approach could be taken when the extensible values = are strings, etc, allowing implementations to send random values without = coordination.

Curious to hear people=E2=80=99= s thoughts!

Best,
Tommy
--
Edm mailing list
Edm@iab.orghttps://www.iab.org/mailman/listinfo/edm


--
Mark Nottingham   https://www.mnot.net/

--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm


= --Apple-Mail=_817DDBCE-F369-479B-9266-12CFAD2227D9-- From nobody Fri Nov 13 11:58:02 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7078D3A03EC for ; Fri, 13 Nov 2020 11:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 cDvspfCEt6di for ; Fri, 13 Nov 2020 11:57:59 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107E53A02BD for ; Fri, 13 Nov 2020 11:57:58 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0ADJqaaR013974 for ; Fri, 13 Nov 2020 11:57:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=BPoU6J/elZt4WPOHX9l5rxuFxLYYtxvWNYS5lCf8iGY=; b=wGLUH9ZnK5gduTzVoS49KaOQNzlB1qLcF+E/5Dzo1GhCfjUXQ6dqIHkl8ydAdtcLnXOz eHgI12ul+xtVIbEuIzK9nsLzbuK0BgBhXKs8hJgPpNa2IMf7hPowqSBSqr749WuP4Qkp H1CDjGMk60xQg5Nb93m6PofNWyERzsSCUfEC+FfozwC/zOXoho+z5yN8pgTe+/KGWFTS zP+0propXtkCJGfEeQGnJ4SGuzX3tzMfOiFOPCQC3NbDxYAFOtPa2plIWcxQ8HHASlLp N72CmEEGr7DkUvaK22RC+51zRG+s3T4a5GjPTJKTxwy2vUV3gFt462xJWTRbfyt0z72f jg== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 34nuf51jd0-21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 13 Nov 2020 11:57:57 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJR00YNL3GLGCF0@rn-mailsvcp-mta-lapp01.rno.apple.com> for edm@iab.org; Fri, 13 Nov 2020 11:57:57 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJR008002MTBC00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for edm@iab.org; Fri, 13 Nov 2020 11:57:57 -0800 (PST) X-Va-A: X-Va-T-CD: 1af8597529a643bc4f908cf463616f6c X-Va-E-CD: 9d848f6a4cf93d27093ca9616db4ba9e X-Va-R-CD: 703e9cfadd4af05d04de7ea8994da503 X-Va-CD: 0 X-Va-ID: 680dd050-4181-46b6-8983-8b3268b9e64e X-V-A: X-V-T-CD: 1af8597529a643bc4f908cf463616f6c X-V-E-CD: 9d848f6a4cf93d27093ca9616db4ba9e X-V-R-CD: 703e9cfadd4af05d04de7ea8994da503 X-V-CD: 0 X-V-ID: 884b91e7-cf00-4d99-9e74-cb6d27f4e90f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_17:2020-11-13, 2020-11-13 signatures=0 Received: from localhost.localdomain (unknown [17.234.122.131]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJR00IM53GIYN00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for edm@iab.org; Fri, 13 Nov 2020 11:57:56 -0800 (PST) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_4410E881-A524-4A52-A230-CAAEFDA7A4FE" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Message-id: Date: Fri, 13 Nov 2020 11:57:52 -0800 To: edm@iab.org X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_17:2020-11-13, 2020-11-13 signatures=0 Archived-At: Subject: [Edm] Scheduling virtual EDM program calls X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 19:58:00 -0000 --Apple-Mail=_4410E881-A524-4A52-A230-CAAEFDA7A4FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello EDM, I=E2=80=99d like to schedule a call for December, after IETF 109, for = this group to discuss next steps on progressing documents on = extensibility, ossification, greasing, etc. I=E2=80=99ve set up a Doodle here to figure out which dates work best = for people: https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&utm_medium=3Dli= nk = For that meeting, I=E2=80=99d appreciate if people can review Martin=E2=80= =99s use-it-or-lose-it draft, and file any issues that come up during = your review. Document: = https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose-= it.html = Issues: https://github.com/intarchboard/use-it-or-lose-it/issues = I=E2=80=99d also like to hear from people about what cadence for virtual = discussions they=E2=80=99d be interested in. At a minimum, I think we = should have a call roughly once per main IETF meeting. Best, Tommy= --Apple-Mail=_4410E881-A524-4A52-A230-CAAEFDA7A4FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= EDM,

I=E2=80=99d = like to schedule a call for December, after IETF 109, for this group to = discuss next steps on progressing documents on extensibility, = ossification, greasing, etc.

I=E2=80=99ve set up a Doodle here to = figure out which dates work best for people:

https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&= utm_medium=3Dlink

For that meeting, I=E2=80=99d appreciate if people can review = Martin=E2=80=99s use-it-or-lose-it draft, and file any issues that come = up during your review.

Document: https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-= it-or-lose-it.html
Issues: https://github.com/intarchboard/use-it-or-lose-it/issues

I=E2=80=99d also = like to hear from people about what cadence for virtual discussions = they=E2=80=99d be interested in. At a minimum, I think we should have a = call roughly once per main IETF meeting.

Best,
Tommy
= --Apple-Mail=_4410E881-A524-4A52-A230-CAAEFDA7A4FE-- From nobody Sun Nov 15 00:11:10 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782A63A0D85 for ; Sun, 15 Nov 2020 00:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=WBzHEuQr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NnpLr1gc 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 p35ZV1NUd-jn for ; Sun, 15 Nov 2020 00:11:02 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4456F3A0D86 for ; Sun, 15 Nov 2020 00:11:02 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 992E7A21 for ; Sun, 15 Nov 2020 02:32:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 15 Nov 2020 02:32:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=9hm13PZolRcPBkHJxis9NSxMp6OFC3XImt1J6nA5DgI=; b=WBzHEuQr 9kSEtFKW4QAWrBlG1yI/CDJECxP9bM2GvUn+iuPLKp3aQNWdfp2Odba2rjqXQ/Nl cRbC785n7v1x9PYjaeB6P4tGk5Jy70jeRxryoUhKjq+UsMDHh1WPL4pbYBdSyPEf H9763xHXci1jD8oG61/ZT86o3u4zE8QUIxUL6IkNaZQeGEPoXH8x/VEiQ54R2D2K L/PvmXRxql8LH/aOYn4dB3o6tOG7cwA0gLxY3fENj7oMpu81nEae4UfyvSbghuHD VJN9YOD55pewtUNzVj4FvPhl9/BWSZ9GpFJlOVfv6kozoNPpcYADTCJpp/dOsxHJ XYqd5ngETbVL7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=9hm13PZolRcPBkHJxis9NSxMp6OFC 3XImt1J6nA5DgI=; b=NnpLr1gc345xeoOEy66IpBPN5OehqZQP2R0KS+mJuoGcS K2FGU+zTzyx8kHPRQr8lbsQzQtJXFE5uNnS72HlgQgnPWqa+gnwtMRJ3NRsivMk9 1AJDlbLzwVm2rk85VXnyl+6/5cMa0Y27y13Oc638NVv+cn413G9/M6iEL+FaCba9 MBaQZdT42XnKWVhxYhKNpCvB352KXrVZTjm+ggjNJ2XlI/q/+Y2Dk0xmocM807NM 8peD0PaZu9Kb26lkUo7gk6ih+c4qUe1xxs1R1Y5F116AQPoH3fpvKTaVlxX4TElm MD0QUbFTsokvWDK34u2BcFDNJxTqWcNSmPD/ah/nw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedutdegrddvtdelrddufe elrdduheejnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhho mhepughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-705.internal.cloudapp.net (unknown [104.209.139.157]) by mail.messagingengine.com (Postfix) with ESMTPA id CAF41328005E for ; Sun, 15 Nov 2020 02:32:48 -0500 (EST) Content-Type: multipart/alternative; boundary="===============5065465087041062904==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: edm@iab.org Message-Id: <20201115073248.CAF41328005E@mailuser.nyi.internal> Date: Sun, 15 Nov 2020 02:32:48 -0500 (EST) Archived-At: Subject: [Edm] Weekly github digest (EDM Activity Summary) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 08:11:07 -0000 --===============5065465087041062904== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * intarchboard/edm (+0/-0/=F0=9F=92=AC3) 1 issues received 3 new comments: - #7 Can greasing mechanisms avoid reserving or coordinating "fake" value= s? (3 by martinthomson, mnot) https://github.com/intarchboard/edm/issues/7=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/edm --===============5065465087041062904== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (EDM Activity Summary)

Sunday November 15, 2020

Issues

intarchboard/edm (+0/-0/=F0=9F=92=AC3)

1 issues received 3 new comments:

Repositories tracked by this digest:

--===============5065465087041062904==-- From nobody Sun Nov 15 16:00:33 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655523A1134 for ; Sun, 15 Nov 2020 16:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 t-t7muOqP_zO for ; Sun, 15 Nov 2020 16:00:29 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 9FA5D3A1136 for ; Sun, 15 Nov 2020 16:00:29 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id t33so14169482ybd.0 for ; Sun, 15 Nov 2020 16:00:29 -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=okjTwkmD8RtFRDWP8iUkQJXsYkzzYOtTokTVAHcbmac=; b=lLDh4uPNvbykqkT5yCjyfw0xpdkiO8VC+PfI8IbGL3wSUo4j4LAhT+wGWft8wxpxDd d4eHCG45bpEDuQVRuxj+ba3wsFuEodSDTmVrat4SEXQJLUq44tUb8eEbAFZwZiSaD7lO SghUEl/ohQhrMzL2CdGCTl9kp0HYPyPiUpNfi8P5/IoO+a5+PT1EIu8L86TcAc96CC9p kYLXHIUBFlsII549GoBsj669ypPs2H9iPfRUa7OsJTtHNzOBPFoZasZLt1y/72Yh9OLa QuKsvkBQdDD7gxqSpFg1W98JsfoE9aBwq+I8rZE1CwNnXMB3Mk9ev5AGwv0clsqn0SHi e1wQ== 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=okjTwkmD8RtFRDWP8iUkQJXsYkzzYOtTokTVAHcbmac=; b=uJTwW8KSdlN1X5oyHywkM4wEWP7oGXXfIp7tx5XmBc4GKIWLoYBfpDtyOZLSwr8Ka7 2M4WdLv0r9y4I9Y2J0RUbIBAToldmkX2jnjITUWoPXzc/7xdEKgoFonfGF6wWMPK0t+0 8NJqpVH+DIKVgIF+gJTc8zMiDHIEnt+9DHXRGb+52fjddZLbj1LIziCBsWFqXBQS11WY vPMjmSe1ej7L++tfDVrcGUtn4wkmm/yCmzD1sJqn0+q0SLIUkoDbMFB8TiqLu+Qnyy6d LJLvGrR/tU8JDFbnorE/m5pzXIl7INBDj8XX2Q/kvHtcu5T0FFuJOpzwRzRFlPqSuL/B suSg== X-Gm-Message-State: AOAM53350lDaXrUu0g02koT0e1VGP5kpl0GsPVmrXI8QbfLRi8plhVWV rScfIUcEwSarc/M0JBF72+u+awUvFGgUB73gGNw= X-Google-Smtp-Source: ABdhPJzLud9J7q/g2X9ar0kgDgJu9p5jH5nHrVU+XTFdyEwcvGvcF2ES84qkqQ+c5dLO9dbH5So6G1zTEi1u3Ut0G4s= X-Received: by 2002:a25:d94:: with SMTP id 142mr15690607ybn.258.1605484828789; Sun, 15 Nov 2020 16:00:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vijay Gurbani Date: Sun, 15 Nov 2020 17:59:52 -0600 Message-ID: To: Tommy Pauly Cc: edm@iab.org Content-Type: multipart/alternative; boundary="000000000000e9917805b42e10f5" Archived-At: Subject: Re: [Edm] Scheduling virtual EDM program calls X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 00:00:31 -0000 --000000000000e9917805b42e10f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tommy, all: Any interest in the archiving implementations thread [1]. There appears to be a reasonably robust discussion on this topic. There is no specific document yet, but I could prepare one for the post IETF 109 meeting if we want to discuss this more. Thanks, - vijay [1] https://mailarchive.ietf.org/arch/msg/edm/1AV0yGy5cetLjmP6aOu0xyD2kHE/ On Fri, Nov 13, 2020 at 1:58 PM Tommy Pauly wrote: > Hello EDM, > > I=E2=80=99d like to schedule a call for December, after IETF 109, for thi= s group > to discuss next steps on progressing documents on extensibility, > ossification, greasing, etc. > > I=E2=80=99ve set up a Doodle here to figure out which dates work best for= people: > > https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&utm_medium=3Dl= ink > > For that meeting, I=E2=80=99d appreciate if people can review Martin=E2= =80=99s > use-it-or-lose-it draft, and file any issues that come up during your > review. > > Document: > https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose= -it.html > Issues: https://github.com/intarchboard/use-it-or-lose-it/issues > > I=E2=80=99d also like to hear from people about what cadence for virtual > discussions they=E2=80=99d be interested in. At a minimum, I think we sho= uld have a > call roughly once per main IETF meeting. > > Best, > Tommy > -- > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm > --000000000000e9917805b42e10f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tommy, all: Any interest in the archiving implementat= ions thread [1].=C2=A0 There appears to be a reasonably robust discussion o= n this topic.=C2=A0 There is no specific document yet, but I could prepare = one for the post IETF 109 meeting if we want to discuss this more.

Thanks,

- vijay


On Fri, Nov 13, 2020 at 1:58 PM Tommy Paul= y <tpauly=3D40apple.com@dm= arc.ietf.org> wrote:
Hello EDM,

I=E2=80=99d like to schedule a call for December, after IETF 109, = for this group to discuss next steps on progressing documents on extensibil= ity, ossification, greasing, etc.

I=E2=80=99ve set= up a Doodle here to figure out which dates work best for people:
<= br>

<= /div>
For that meeting, I=E2=80=99d appreciate if people can review Mar= tin=E2=80=99s use-it-or-lose-it draft, and file any issues that come up dur= ing your review.

I=E2=80=99d also like to hear from people about what cadence fo= r virtual discussions they=E2=80=99d be interested in. At a minimum, I thin= k we should have a call roughly once per main IETF meeting.
=
Best,
Tommy
-- =
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm
--000000000000e9917805b42e10f5-- From nobody Tue Nov 17 21:40:31 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D05A3A1463 for ; Tue, 17 Nov 2020 21:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 uhvw3kBrP1Zu for ; Tue, 17 Nov 2020 21:40:28 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007A73A145E for ; Tue, 17 Nov 2020 21:40:27 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0AI5dMxp035319 for ; Tue, 17 Nov 2020 21:40:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=G/VlY2oGjap47h3Bx2TT/MhUoQDuiUKJX3m/5CKVWVw=; b=oHacoQOUPnZbBcwbNCn72xPmJPpbWImHy2vzP6Lx+kaey3IwWA/z2XxcpiOWaPxLLSLZ HFzzZllhoDXeriIpBuWixIY68SLsPs71+e+Jd6mB69SxUrLmu9w+cz2GXBRk5fIAAoaa yrcIg+ilX8UBbykmOuRUWYjeegaHdZrdphJ0TpkxFUYpNN4U2YD5VhfDkeEzdFkcwAgH NfSZ1bnUo2QZb2Nsq17ovz1d7uDOwG7OnVuHemg8sPMdySwML/rlI0X+MRoo7pvxLwCi 0DUyMFJsJlm3Ban1E/TIwPlMaaxXsD3jLq8nR+z0qM5RVh+3xnRbX6UfFAPELrp5xxcl /Q== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 34tf413aft-14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 17 Nov 2020 21:40:26 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJZ00BYV93EUOB0@rn-mailsvcp-mta-lapp01.rno.apple.com> for edm@iab.org; Tue, 17 Nov 2020 21:40:26 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJZ00Y007WVBZ00@rn-mailsvcp-mmp-lapp03.rno.apple.com> for edm@iab.org; Tue, 17 Nov 2020 21:40:26 -0800 (PST) X-Va-A: X-Va-T-CD: 1af8597529a643bc4f908cf463616f6c X-Va-E-CD: 3fd80ed4547b2312c1e54a36e2b54126 X-Va-R-CD: b93bb405bb1f7f642c9807388b9dd4fa X-Va-CD: 0 X-Va-ID: ea0c4cc3-c208-4a0c-9c93-71023c12e4c3 X-V-A: X-V-T-CD: 1af8597529a643bc4f908cf463616f6c X-V-E-CD: 3fd80ed4547b2312c1e54a36e2b54126 X-V-R-CD: b93bb405bb1f7f642c9807388b9dd4fa X-V-CD: 0 X-V-ID: 4caf073b-3b4a-49b7-a705-c55eec37a589 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_01:2020-11-17, 2020-11-18 signatures=0 Received: from localhost.localdomain (unknown [17.234.72.15]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJZ00N05939TG00@rn-mailsvcp-mmp-lapp03.rno.apple.com> for edm@iab.org; Tue, 17 Nov 2020 21:40:24 -0800 (PST) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_42743093-09CA-4B14-BFD2-87C2E845C997" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Message-id: Date: Tue, 17 Nov 2020 21:40:20 -0800 To: edm@iab.org X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_01:2020-11-17, 2020-11-18 signatures=0 Archived-At: Subject: [Edm] Experiments for reporting implementation and interop results X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 05:40:29 -0000 --Apple-Mail=_42743093-09CA-4B14-BFD2-87C2E845C997 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi EDM, As I mentioned in the IABOPEN meeting, a few of us worked on some = experiments during last week=E2=80=99s hackathon to report = implementation and interop test results. What we used was: - A library for presenting a webpage of results that can show different = requirements or tests per draft, and show results per implementation. = This is based on Mark Nottingham=E2=80=99s HTTP cache tests site. - Annotation for markdown (kramdown) drafts to add test requirements = inline, with a script to generate a file that gets dropped into the = webpage source The goal is to make a generic template that can be added to draft = repositories to easily generate and track tests for different versions = of drafts, which will inform testing and WG evaluation. Here=E2=80=99s an example of the library in a GitHub repo for a draft: = https://github.com/tfpauly/quic-proxy/tree/main/interop = The results and tests folders are the parts that will change per = document. The drafts are currently annotated with tags like this: {::options req-id=3D=E2=80=9Cexample-test-id" req-type=3D"must" = req=3D=E2=80=9CExample description" /} =E2=80=A6where the types are =E2=80=9Cmust=E2=80=9D/=E2=80=9Cshould=E2=80=9D= /=E2=80=9Csupported=E2=80=9D (for indicating if a feature is supported), = and the req-id is a tag for which each implementation reports a = true/false result. What do people think about this kind of approach? What would you like to = see? How could such templates and tools help inform our protocol = development? Best, Tommy --Apple-Mail=_42743093-09CA-4B14-BFD2-87C2E845C997 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi EDM,

As I mentioned in the IABOPEN meeting, a few of us worked on = some experiments during last week=E2=80=99s hackathon to = report implementation and interop test results.

What we used was:
- A library for presenting a webpage of = results that can show different requirements or tests per draft, and = show results per implementation. This is based on Mark Nottingham=E2=80=99= s HTTP cache tests site.
- Annotation for markdown (kramdown) drafts = to add test requirements inline, with a script to generate a file = that gets dropped into the webpage source

The goal is to make a generic template that can be added to = draft repositories to easily generate and track tests for different = versions of drafts, which will inform testing and WG = evaluation.

Here=E2=80=99s an example of the library in a GitHub repo for = a draft: https://github.com/tfpauly/quic-proxy/tree/main/interopThe results and tests folders are the parts that will change per = document.

The drafts are = currently annotated with tags like this:

{::options = req-id=3D=E2=80=9Cexample-test-id" req-type=3D"must" req=3D=E2=80=9CExampl= e description" /}

=E2=80=A6where = the types are =E2=80=9Cmust=E2=80=9D/=E2=80=9Cshould=E2=80=9D/=E2=80=9Csup= ported=E2=80=9D (for indicating if a feature is supported), and the = req-id is a tag for which each implementation reports a true/false = result.

What do people think about this kind = of approach? What would you like to see? How could such templates and = tools help inform our protocol development?

Best,
Tommy

= --Apple-Mail=_42743093-09CA-4B14-BFD2-87C2E845C997-- From nobody Fri Nov 20 12:42:01 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6861A3A1141 for ; Fri, 20 Nov 2020 12:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 skwr1lJhTeFD for ; Fri, 20 Nov 2020 12:41:57 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EC93A113E for ; Fri, 20 Nov 2020 12:41:57 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0AKKbrwS043693 for ; Fri, 20 Nov 2020 12:41:56 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=YPqkLSc+2cja5a2G6Qg67GDLiFuCEbAtg7ijsXuVLk4=; b=Xx77hbUnOMu6MqzmeFARJ1awBhj1XU5OelPadl4StUMmS2+QC6umg2XdzSmKf0NHs0vG MpjeZ3NwkSfD37Z/iB0QAkmwWup46mQts2l4KcFwnLyS44lRgpP87M6kUrQX0mgvKBkN LTsqr31jlr2SFIeLQbOuRV46v6Wme60kC1NV/6/xcPCFIs4gsLlpE/GMKvZS0WqiLrAs lUFQLuqF5f5qLveJ/bScG1UR5t8Ke89KHssK5LX1d1kiyJ6fGqjVQ9vsSkUfA0+kofgy wKG/Cmwt5esFCXhDpt/vUL05cbYNBlIJIUBjvYEeF3LscmTKlKtlobBNmLh92FmKJytQ JA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 34wdw8csru-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 20 Nov 2020 12:41:56 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QK400ASW45TLOD0@rn-mailsvcp-mta-lapp03.rno.apple.com> for edm@iab.org; Fri, 20 Nov 2020 12:41:55 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QK400Y00410HD00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for edm@iab.org; Fri, 20 Nov 2020 12:41:53 -0800 (PST) X-Va-A: X-Va-T-CD: 1af8597529a643bc4f908cf463616f6c X-Va-E-CD: 73ffb737eca3e03a3e2304a3b48eae5b X-Va-R-CD: 2bb7f1b45b15dee70976762ea2451b8e X-Va-CD: 0 X-Va-ID: 01a0c1e8-0a97-4088-be18-ac1a818f2d2c X-V-A: X-V-T-CD: 1af8597529a643bc4f908cf463616f6c X-V-E-CD: 73ffb737eca3e03a3e2304a3b48eae5b X-V-R-CD: 2bb7f1b45b15dee70976762ea2451b8e X-V-CD: 0 X-V-ID: 37ced661-6d34-490e-9470-33d3257b4761 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-20_13:2020-11-20, 2020-11-20 signatures=0 Received: from localhost.localdomain (unknown [17.235.39.161]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QK400EGX45P8V00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for edm@iab.org; Fri, 20 Nov 2020 12:41:53 -0800 (PST) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_19C0E0F5-FD7D-479E-B16E-C4BE0E99D8A9" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Fri, 20 Nov 2020 12:41:48 -0800 References: To: edm@iab.org In-reply-to: Message-id: <840788FB-F934-4A5D-BBD4-13612BD764A3@apple.com> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-20_13:2020-11-20, 2020-11-20 signatures=0 Archived-At: Subject: Re: [Edm] Scheduling virtual EDM program calls X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 20:41:59 -0000 --Apple-Mail=_19C0E0F5-FD7D-479E-B16E-C4BE0E99D8A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for your responses! It looks like one of the best times for us to = meet is December 10, 21:30-22:30 UTC (13:30-14:30 PST). WebEx details to follow. Hope everyone had a good IETF week! Best, Tommy > On Nov 13, 2020, at 11:57 AM, Tommy Pauly = wrote: >=20 > Hello EDM, >=20 > I=E2=80=99d like to schedule a call for December, after IETF 109, for = this group to discuss next steps on progressing documents on = extensibility, ossification, greasing, etc. >=20 > I=E2=80=99ve set up a Doodle here to figure out which dates work best = for people: >=20 > = https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&utm_medium=3Dli= nk = >=20 > For that meeting, I=E2=80=99d appreciate if people can review = Martin=E2=80=99s use-it-or-lose-it draft, and file any issues that come = up during your review. >=20 > Document: = https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose-= it.html = > Issues: https://github.com/intarchboard/use-it-or-lose-it/issues = >=20 > I=E2=80=99d also like to hear from people about what cadence for = virtual discussions they=E2=80=99d be interested in. At a minimum, I = think we should have a call roughly once per main IETF meeting. >=20 > Best, > Tommy > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm --Apple-Mail=_19C0E0F5-FD7D-479E-B16E-C4BE0E99D8A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks for your responses! It looks like one of the best = times for us to meet is December 10, 21:30-22:30 UTC = (13:30-14:30 PST).

WebEx details to follow.

Hope everyone had a good IETF = week!

Best,
Tommy

On Nov 13, 2020, at 11:57 AM, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

Hello EDM,

I=E2=80=99d like to = schedule a call for December, after IETF 109, for this group to discuss = next steps on progressing documents on extensibility, ossification, = greasing, etc.

I=E2=80=99ve set up a Doodle here to figure out which dates = work best for people:

https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&= utm_medium=3Dlink

For that meeting, I=E2=80=99d appreciate if people can review = Martin=E2=80=99s use-it-or-lose-it draft, and file any issues that come = up during your review.

Document: https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-= it-or-lose-it.html
Issues: https://github.com/intarchboard/use-it-or-lose-it/issues

I=E2=80=99d also = like to hear from people about what cadence for virtual discussions = they=E2=80=99d be interested in. At a minimum, I think we should have a = call roughly once per main IETF meeting.

Best,
Tommy
--
Edm = mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

= --Apple-Mail=_19C0E0F5-FD7D-479E-B16E-C4BE0E99D8A9-- From nobody Fri Nov 20 12:45:11 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CB63A1175 for ; Fri, 20 Nov 2020 12:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 bmY_OITOBMLQ for ; Fri, 20 Nov 2020 12:45:07 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D603A115C for ; Fri, 20 Nov 2020 12:45:07 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.43/8.16.0.42) with SMTP id 0AKKdnUt038313; Fri, 20 Nov 2020 12:45:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=lkKraHZc77EQ6vhrkk/3+cXcbXL/qJSdpLzDac6rDQI=; b=v0+4B6u2uRNxazGxVHDuQlRyRCGOGqOk4iqnDXnf9gK4kS3lm7hvg5CeVtkvSw7DbkNn w1YGVl50v1OcgGwgf/wDXLYBaJd7rgTArIXsXsxyEcxElH91ZNNL82YVLD0LXXOqTIMf wiGpuDx2tRVF8RyelP1YReM7w/Y0m0pxrNdjudSASYpdXmRgWbLqf1wA3VQ/VbJly2S3 rEjPe53JWNDjAKZLjGrKfrzY8HHh/R+9ETEQtjEpdKq1Qck1vCTGuFeeO/7VU7j8RTxL IS0Yrxt13U+btU8PyArbGwgzj8l6V4hrV5IL4A5kI8QTW+x767duyHIUsawwEe815peN BQ== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by nwk-aaemail-lapp02.apple.com with ESMTP id 34tcpqwba0-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 Nov 2020 12:45:06 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QK400EZE4B5UCR0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Fri, 20 Nov 2020 12:45:05 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QK4003003K9ZX00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 20 Nov 2020 12:45:05 -0800 (PST) X-Va-A: X-Va-T-CD: d3d7d3c5f6e88e1efd50052fb8185312 X-Va-E-CD: a2d32b1f83817993666045d5ff4d1702 X-Va-R-CD: 184566a9e8468b0cc43b889dc6211498 X-Va-CD: 0 X-Va-ID: 63a62303-6dd7-4f0d-b500-cc29e777431d X-V-A: X-V-T-CD: d3d7d3c5f6e88e1efd50052fb8185312 X-V-E-CD: a2d32b1f83817993666045d5ff4d1702 X-V-R-CD: 184566a9e8468b0cc43b889dc6211498 X-V-CD: 0 X-V-ID: 284a61a8-60ea-490f-9139-c19edfd03458 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-20_13:2020-11-20, 2020-11-20 signatures=0 Received: from localhost.localdomain (unknown [17.235.39.161]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QK400WA94B3KI00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Fri, 20 Nov 2020 12:45:05 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_04A3D5FF-2D92-4148-929D-DAE5F5875E7F" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Fri, 20 Nov 2020 12:45:03 -0800 In-reply-to: Cc: Tommy Pauly , edm@iab.org To: Vijay Gurbani References: X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-20_13:2020-11-20, 2020-11-20 signatures=0 Archived-At: Subject: Re: [Edm] Implementations (was Scheduling virtual EDM program calls) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 20:45:09 -0000 --Apple-Mail=_04A3D5FF-2D92-4148-929D-DAE5F5875E7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vijay, I=E2=80=99d like to keep this next call focused on the document and = topics around greasing, etc. However, I do want to continue discussing = and looking at the topic of implementation tracking more. If you could prepare a proposal draft as you suggest, and share it with = this list, we can have list discussion and then a call around that topic = later. Would that work? I think this also dovetails with the work I shared on the list about = annotating implementation requirements and tracking implementation = status for test results; perhaps that kind of documentation on an = ongoing basis can help. Best, Tommy=20 > On Nov 15, 2020, at 3:59 PM, Vijay Gurbani = wrote: >=20 > Tommy, all: Any interest in the archiving implementations thread [1]. = There appears to be a reasonably robust discussion on this topic. There = is no specific document yet, but I could prepare one for the post IETF = 109 meeting if we want to discuss this more. >=20 > Thanks, >=20 > - vijay >=20 > [1] = https://mailarchive.ietf.org/arch/msg/edm/1AV0yGy5cetLjmP6aOu0xyD2kHE/ = > On Fri, Nov 13, 2020 at 1:58 PM Tommy Pauly = > wrote: > Hello EDM, >=20 > I=E2=80=99d like to schedule a call for December, after IETF 109, for = this group to discuss next steps on progressing documents on = extensibility, ossification, greasing, etc. >=20 > I=E2=80=99ve set up a Doodle here to figure out which dates work best = for people: >=20 > = https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&utm_medium=3Dli= nk = >=20 > For that meeting, I=E2=80=99d appreciate if people can review = Martin=E2=80=99s use-it-or-lose-it draft, and file any issues that come = up during your review. >=20 > Document: = https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose-= it.html = > Issues: https://github.com/intarchboard/use-it-or-lose-it/issues = >=20 > I=E2=80=99d also like to hear from people about what cadence for = virtual discussions they=E2=80=99d be interested in. At a minimum, I = think we should have a call roughly once per main IETF meeting. >=20 > Best, > Tommy > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm = > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm --Apple-Mail=_04A3D5FF-2D92-4148-929D-DAE5F5875E7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Vijay,

I=E2=80=99d = like to keep this next call focused on the document and topics around = greasing, etc. However, I do want to continue discussing and looking at = the topic of implementation tracking more.

If you could prepare a proposal draft = as you suggest, and share it with this list, we can have list discussion = and then a call around that topic later. Would that work?

I think this also = dovetails with the work I shared on the list about annotating = implementation requirements and tracking implementation status for test = results; perhaps that kind of documentation on an ongoing basis can = help.

Best,
Tommy 

On Nov = 15, 2020, at 3:59 PM, Vijay Gurbani <vijay.gurbani@gmail.com> wrote:

Tommy, all: Any interest in the archiving = implementations thread [1].  There appears to be a reasonably = robust discussion on this topic.  There is no specific document = yet, but I could prepare one for the post IETF 109 meeting if we want to = discuss this more.

Thanks,

- vijay

[1] https://mailarchive.ietf.org/arch/msg/edm/1AV0yGy5cetLjmP6aOu0x= yD2kHE/

On Fri, Nov 13, 2020 at 1:58 PM Tommy = Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
Hello EDM,

I=E2=80=99d like to schedule a call for = December, after IETF 109, for this group to discuss next steps on = progressing documents on extensibility, ossification, greasing, = etc.

I=E2=80=99v= e set up a Doodle here to figure out which dates work best for = people:

https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&= utm_medium=3Dlink

For that meeting, I=E2=80=99d appreciate if people can review = Martin=E2=80=99s use-it-or-lose-it draft, and file any issues that come = up during your review.

Document: https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-= it-or-lose-it.html
Issues: https://github.com/intarchboard/use-it-or-lose-it/issues

I=E2=80=99d also = like to hear from people about what cadence for virtual discussions = they=E2=80=99d be interested in. At a minimum, I think we should have a = call roughly once per main IETF meeting.

Best,
Tommy
--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm
--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

= --Apple-Mail=_04A3D5FF-2D92-4148-929D-DAE5F5875E7F-- From nobody Tue Nov 24 16:10:14 2020 Return-Path: X-Original-To: edm@iab.org Delivered-To: edm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8C3A0992; Tue, 24 Nov 2020 16:10:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: edm@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160626300843.3099.4898565290348221172@ietfa.amsl.com> Date: Tue, 24 Nov 2020 16:10:08 -0800 Archived-At: Subject: [Edm] Evolvability, Deployability, & Maintainability (edm) PROGRAM Virtual Meeting: 2020-12-10 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 00:10:09 -0000 The Evolvability, Deployability, & Maintainability (edm) Program will hold a virtual interim meeting on 2020-12-10 from 13:30 to 14:30 America/Los_Angeles (21:30 to 22:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=me719430c7594fc941add4a7ae8c456fa Meeting number: 178 282 2655 Password: iTs49SuciJ5 b747e9cbcf2b4bfa92c165acdfeb2b51 Join by video system Dial 1782822655@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 178 282 2655 From nobody Wed Nov 25 10:20:05 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE823A151B; Wed, 25 Nov 2020 10:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 gJcPIFRAkrDy; Wed, 25 Nov 2020 10:20:02 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066353A151A; Wed, 25 Nov 2020 10:20:01 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0APIDJMp002205; Wed, 25 Nov 2020 10:20:01 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=UYVASgWiiS+kQUZHvA8aTSOs/khroTIlYpZoq9VO4LE=; b=G0v5fINnswRhaTRO1OVhWQlADvQROgm19CuZeSefkeYvHepv56+ih3cZWeBvR1A+YrxN Ar+phYcmv59L8G3BeUn074m+m5IzaFCXUxN2FS0axJctlk0KdjvWhqeZAqwDCyCJfq4t Z2grobg7VrFQ/PCPqyqNhohipIK5QU7DobZwOzPpCcpdLBR67AmX/F+Iw46GNPpdWQoQ ES/iAAycFTlAVFgySGKEBr6w3Yx/lpeNMA+ZB4UQL0iO9rGPHnUp13Khp7hMWJqSh9sx igRRjeaf3jDD9ZIYdnUgxGLEmh4RfwxOPkWZU7ynrtbC8bUG/5W9p4OFHapfg2pm5qj3 gw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 34y2e7dbfn-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Nov 2020 10:20:00 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QKD0055K6XA3280@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 25 Nov 2020 10:19:58 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QKD001006APQU00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 25 Nov 2020 10:19:58 -0800 (PST) X-Va-A: X-Va-T-CD: dfc86da510652575580ff00346bca277 X-Va-E-CD: 73ffb737eca3e03a3e2304a3b48eae5b X-Va-R-CD: 2bb7f1b45b15dee70976762ea2451b8e X-Va-CD: 0 X-Va-ID: 2af3b9c0-106d-476b-8e59-1a9cb2e92ef8 X-V-A: X-V-T-CD: dfc86da510652575580ff00346bca277 X-V-E-CD: 73ffb737eca3e03a3e2304a3b48eae5b X-V-R-CD: 2bb7f1b45b15dee70976762ea2451b8e X-V-CD: 0 X-V-ID: b71320bf-d631-4c23-acd8-6daa76038d61 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-25_11:2020-11-25, 2020-11-25 signatures=0 Received: from localhost.localdomain (unknown [17.234.120.119]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QKD006CA6X38R00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 25 Nov 2020 10:19:57 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_B937BBA4-E103-4640-84C8-CF7637E04CD5" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Date: Wed, 25 Nov 2020 10:19:50 -0800 In-reply-to: <840788FB-F934-4A5D-BBD4-13612BD764A3@apple.com> Cc: edm@iab.org To: Tommy Pauly References: <840788FB-F934-4A5D-BBD4-13612BD764A3@apple.com> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-25_11:2020-11-25, 2020-11-25 signatures=0 Archived-At: Subject: Re: [Edm] Scheduling virtual EDM program calls X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 18:20:04 -0000 --Apple-Mail=_B937BBA4-E103-4640-84C8-CF7637E04CD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 20, 2020, at 12:41 PM, Tommy Pauly = wrote: >=20 > Thanks for your responses! It looks like one of the best times for us = to meet is December 10, 21:30-22:30 UTC (13:30-14:30 PST). >=20 > WebEx details to follow. As a follow-up, this has been scheduled: The Evolvability, Deployability, & Maintainability (edm) Program will = hold a virtual interim meeting on 2020-12-10 from 13:30 to 14:30 = America/Los_Angeles (21:30 to 22:30 UTC). Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=3Dme719430c7594fc941add4a7ae8c456fa= Meeting number: 178 282 2655 Password: iTs49SuciJ5 b747e9cbcf2b4bfa92c165acdfeb2b51 Join by video system Dial 1782822655@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 178 282 2655 Best, Tommy >=20 > Hope everyone had a good IETF week! >=20 > Best, > Tommy >=20 >> On Nov 13, 2020, at 11:57 AM, Tommy Pauly = > wrote: >>=20 >> Hello EDM, >>=20 >> I=E2=80=99d like to schedule a call for December, after IETF 109, for = this group to discuss next steps on progressing documents on = extensibility, ossification, greasing, etc. >>=20 >> I=E2=80=99ve set up a Doodle here to figure out which dates work best = for people: >>=20 >> = https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&utm_medium=3Dli= nk = >>=20 >> For that meeting, I=E2=80=99d appreciate if people can review = Martin=E2=80=99s use-it-or-lose-it draft, and file any issues that come = up during your review. >>=20 >> Document: = https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-lose-= it.html = >> Issues: https://github.com/intarchboard/use-it-or-lose-it/issues = >>=20 >> I=E2=80=99d also like to hear from people about what cadence for = virtual discussions they=E2=80=99d be interested in. At a minimum, I = think we should have a call roughly once per main IETF meeting. >>=20 >> Best, >> Tommy >> --=20 >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm --Apple-Mail=_B937BBA4-E103-4640-84C8-CF7637E04CD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Nov 20, 2020, at 12:41 PM, Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

Thanks = for your responses! It looks like one of the best times for us to meet = is December 10, 21:30-22:30 UTC (13:30-14:30 = PST).

WebEx = details to follow.

As a follow-up, this has been scheduled:

The Evolvability, Deployability, & = Maintainability (edm) Program will hold
a virtual interim meeting on 2020-12-10 = from 13:30 to 14:30 America/Los_Angeles (21:30 to 22:30 = UTC).

Information about remote participation:

Meeting = number: 178 282 2655
Password: iTs49SuciJ5
b747e9cbcf2b4bfa92c165acdfeb2b51

Join by video = system
You can also dial 173.243.2.68 and enter = your meeting number.

Join by phone
1-650-479-3208 Call-in toll number = (US/Canada)
Access = code: 178 282 2655

Best,
Tommy

Hope everyone had a good IETF = week!

Best,
Tommy

On Nov 13, 2020, at 11:57 AM, Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

Hello EDM,

I=E2=80=99d like to = schedule a call for December, after IETF 109, for this group to discuss = next steps on progressing documents on extensibility, ossification, = greasing, etc.

I=E2=80=99ve set up a Doodle here to figure out which dates = work best for people:

https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&= utm_medium=3Dlink

For that meeting, I=E2=80=99d appreciate if people can review = Martin=E2=80=99s use-it-or-lose-it draft, and file any issues that come = up during your review.

Document: https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-= it-or-lose-it.html
Issues: https://github.com/intarchboard/use-it-or-lose-it/issues

I=E2=80=99d also = like to hear from people about what cadence for virtual discussions = they=E2=80=99d be interested in. At a minimum, I think we should have a = call roughly once per main IETF meeting.

Best,
Tommy
--
Edm = mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

-- =
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

= --Apple-Mail=_B937BBA4-E103-4640-84C8-CF7637E04CD5-- From nobody Wed Nov 25 11:24:49 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4193A1B8E for ; Wed, 25 Nov 2020 11:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 WKaqTNG-bzd4 for ; Wed, 25 Nov 2020 11:24:46 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 1DF793A1B91 for ; Wed, 25 Nov 2020 11:24:46 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id t33so746045ybd.0 for ; Wed, 25 Nov 2020 11:24:45 -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=Bqi+tAWg2WEiLewqgHTWwM9Zx6BU5t+9YopL126CENM=; b=aPz6if3vcJ7RUk42NhVk22rVehpc+cT7WJN3nrP14PgSFIxLFhSV3ECgNhjLEd77Tb xQw12YzJxsI8X6OnfMK7qO+j4KGm9uk5tVdGylgE2hq3OxXiZ5boYgtk9Grr6KaHB7k4 B1OowXy4aY1wVSzZ+X+osxLhp9M35SIKM57WkpNrcNbQ0goj1eD+I2hHUWgTuDim5bb1 AKmYPKznV2VdXs1BL9uEUot1rNb1g9sBGMPGzk3zRAI2uKCh6kI2yk1/rMaWkW7ufwiL tLs3T4hUUebW5kdS8n0axbvcPxMgj8fw3YXWpUY0K4xS+UsVvjz0bHJmDd8CNGP0GrbN +QEw== 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=Bqi+tAWg2WEiLewqgHTWwM9Zx6BU5t+9YopL126CENM=; b=nB3oLjcta2AfeNzvcI2X8B6H9yu/DVmfSg7g+GgWyKuPMz7Wj9LLp1tqKS9H+fNTI8 X1OhCM/7dEu0drF5gRuNLn/bapmRAmhuhxa0VHM0cY01o9u7VD1adKYCaVVAhBpSKIdC DRusfNuQhjsKC+XSVo2RNXcVrZVZp5GgvGo9lwia4PNz7TFZyq2v3AlBWNkFHTNl6R/B EGA0qoKNjrWVMsrktL938VLucMDsD2uBvUIz7tI5W1WOlJCL8EZZu5dc5KurEm8XkbvN HvIDZLwoxKr9n8gnQDtk2xZBzdC0HdV8JEHQ9XTB2srakxoHobfr1fOGJ4MmFXP9SVoB IJXg== X-Gm-Message-State: AOAM530GO69v1GmWPZf37QjlQ6LfwrByIMqN7ot1RJiUQIZzmZfdnJUv awQ+pOxD7OAduXg+yA+eKDgZKRHhyepSvH4DuVc= X-Google-Smtp-Source: ABdhPJwKzV/bO1uM3O3knNlma16AsnrzwPCMfNCSHdgDqJmz9HIFi4JxqtcbwZGJbekpjkQxIG+mRL/upM2S859woGU= X-Received: by 2002:a25:50ca:: with SMTP id e193mr5854440ybb.433.1606332285177; Wed, 25 Nov 2020 11:24:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vijay Gurbani Date: Wed, 25 Nov 2020 13:24:05 -0600 Message-ID: To: Tommy Pauly Cc: Tommy Pauly , edm@iab.org Content-Type: multipart/alternative; boundary="0000000000003fd3f505b4f36167" Archived-At: Subject: Re: [Edm] Implementations (was Scheduling virtual EDM program calls) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:24:48 -0000 --0000000000003fd3f505b4f36167 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Tommy, that sounds good. I will prepare an I-D and share when ready. Thanks, - vijay On Fri, Nov 20, 2020 at 2:45 PM Tommy Pauly wrote: > Hi Vijay, > > I=E2=80=99d like to keep this next call focused on the document and topic= s around > greasing, etc. However, I do want to continue discussing and looking at t= he > topic of implementation tracking more. > > If you could prepare a proposal draft as you suggest, and share it with > this list, we can have list discussion and then a call around that topic > later. Would that work? > > I think this also dovetails with the work I shared on the list about > annotating implementation requirements and tracking implementation status > for test results; perhaps that kind of documentation on an ongoing basis > can help. > > Best, > Tommy > > On Nov 15, 2020, at 3:59 PM, Vijay Gurbani > wrote: > > Tommy, all: Any interest in the archiving implementations thread [1]. > There appears to be a reasonably robust discussion on this topic. There = is > no specific document yet, but I could prepare one for the post IETF 109 > meeting if we want to discuss this more. > > Thanks, > > - vijay > > [1] https://mailarchive.ietf.org/arch/msg/edm/1AV0yGy5cetLjmP6aOu0xyD2kHE= / > > On Fri, Nov 13, 2020 at 1:58 PM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> Hello EDM, >> >> I=E2=80=99d like to schedule a call for December, after IETF 109, for th= is group >> to discuss next steps on progressing documents on extensibility, >> ossification, greasing, etc. >> >> I=E2=80=99ve set up a Doodle here to figure out which dates work best fo= r people: >> >> https://doodle.com/poll/8zv4tanmqnk44tis?utm_source=3Dpoll&utm_medium=3D= link >> >> For that meeting, I=E2=80=99d appreciate if people can review Martin=E2= =80=99s >> use-it-or-lose-it draft, and file any issues that come up during your >> review. >> >> Document: >> https://intarchboard.github.io/use-it-or-lose-it/draft-iab-use-it-or-los= e-it.html >> Issues: https://github.com/intarchboard/use-it-or-lose-it/issues >> >> I=E2=80=99d also like to hear from people about what cadence for virtual >> discussions they=E2=80=99d be interested in. At a minimum, I think we sh= ould have a >> call roughly once per main IETF meeting. >> >> Best, >> Tommy >> -- >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >> > -- > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm > > > --0000000000003fd3f505b4f36167 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Tommy, that sounds good.=C2=A0 I will prepare an= I-D and share when ready.
Thanks,
- vijay

On = Fri, Nov 20, 2020 at 2:45 PM Tommy Pauly <tpauly@apple.com> wrote:
Hi Vijay,
I=E2=80=99d like to keep this next call focused on the do= cument and topics around greasing, etc. However, I do want to continue disc= ussing and looking at the topic of implementation tracking more.
=
If you could prepare a proposal draft as you suggest, and sh= are it with this list, we can have list discussion and then a call around t= hat topic later. Would that work?

I think this als= o dovetails with the work I shared on the list about annotating implementat= ion requirements and tracking implementation status for test results; perha= ps that kind of documentation on an ongoing basis can help.

<= /div>
Best,
Tommy=C2=A0

On Nov 15, 2020, at 3:59 PM, Vijay Gurbani <vijay.gurbani@gmail.com> wrot= e:

Tommy, all: Any interest in the arch= iving implementations thread [1].=C2=A0 There appears to be a reasonably ro= bust discussion on this topic.=C2=A0 There is no specific document yet, but= I could prepare one for the post IETF 109 meeting if we want to discuss th= is more.

Thanks,

- vi= jay

<= br>
On Fri,= Nov 13, 2020 at 1:58 PM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> w= rote:
Hello= EDM,

I=E2=80=99d like to schedule a call for December, = after IETF 109, for this group to discuss next steps on progressing documen= ts on extensibility, ossification, greasing, etc.

--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm
--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

--0000000000003fd3f505b4f36167--