From nobody Wed Sep 2 14:29:48 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 D44AF3A1028 for ; Wed, 2 Sep 2020 14:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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] 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 oI_9FaZ5oGWP for ; Wed, 2 Sep 2020 14:29:44 -0700 (PDT) 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 920DA3A1026 for ; Wed, 2 Sep 2020 14:29:44 -0700 (PDT) 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 082LS5He051887 for ; Wed, 2 Sep 2020 14:29:43 -0700 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=KzxvgNUrBziKUxVnASJLsmFfHQYjPyrwnjdNg2CIg/I=; b=WioEiwDKonFNMARWqLJ+KFmb9LdNfmozQj1IdjmvSo7IyoXqTO7xCun3v4iaNzTroWA/ YnP0laey1aF8w9WwBxSZ90N++NHcL+U8XooKDSwR9doL3t86Rb0xaJ/yBDNNqJgA3dqg N9wUeICQ8Y0yKMYwkHTnApDNZPiB9jC8xrR7tdRuRi8tVYIrxprnbtGvkj5QYACdQNAg Flbw8uC/Xuy8dhu2UuLODXe/MMZ2qBMRdFQNQy10E/uQDpnFe6vXGvVkDyZ4G9DDb6pX svAYjGWxWDnT6UPu4uyGAESYb7vyFDzvpmUBeLzxeqYiw2MnHKuE7hyU0toI/avsJUVv SQ== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 337kptnmtn-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 02 Sep 2020 14:29:43 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) 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 <0QG100VSUVPIKP20@rn-mailsvcp-mta-lapp02.rno.apple.com> for edm@iab.org; Wed, 02 Sep 2020 14:29:42 -0700 (PDT) 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 <0QG100700VNDAJ00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for edm@iab.org; Wed, 02 Sep 2020 14:29:42 -0700 (PDT) X-Va-A: X-Va-T-CD: 1af8597529a643bc4f908cf463616f6c X-Va-E-CD: c9c789a5b9de651c4615698e511f23f8 X-Va-R-CD: 6862b837fbf8351ebb357a25580dc5b5 X-Va-CD: 0 X-Va-ID: c2b0ac97-2dfc-4e8d-b201-5ac1e453e72c X-V-A: X-V-T-CD: 1af8597529a643bc4f908cf463616f6c X-V-E-CD: c9c789a5b9de651c4615698e511f23f8 X-V-R-CD: 6862b837fbf8351ebb357a25580dc5b5 X-V-CD: 0 X-V-ID: c59eed8a-9295-437a-9612-66c4967c4cd3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-02_17:2020-09-02, 2020-09-02 signatures=0 Received: from localhost.localdomain (unknown [17.235.46.144]) 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 <0QG1009OPVPHTH00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for edm@iab.org; Wed, 02 Sep 2020 14:29:42 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_D2BD0653-4C5C-4CE0-8BA3-A5B53CDB250A" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Message-id: <4E5BA462-DC3E-4DC4-8921-7B45810F9D7C@apple.com> Date: Wed, 02 Sep 2020 14:29:41 -0700 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.235, 18.0.687 definitions=2020-09-02_17:2020-09-02, 2020-09-02 signatures=0 Archived-At: Subject: [Edm] September 1 meeting notes posted 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, 02 Sep 2020 21:29:46 -0000 --Apple-Mail=_D2BD0653-4C5C-4CE0-8BA3-A5B53CDB250A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks to those who joined us for the call yesterday! We have meeting = notes and a recording posted. Thanks to Mirja for taking notes! Meeting notes: = https://github.com/intarchboard/edm/blob/master/Materials/Sept-1-2020-Note= s.txt = Meeting recording (started shortly after the beginning of the call): = https://www.youtube.com/watch?v=3DAhquVW1m_6k = The two actions we had coming out of the meeting were: 1. Review and start working on updates to draft-iab-use-it-or-lose-it = (https://github.com/intarchboard/use-it-or-lose-it = ) 2. Work with the hackathon team and tools team to see if we can add more = connections from data tracker or documents back to the hackathon = implementations and interop tests Best, Tommy= --Apple-Mail=_D2BD0653-4C5C-4CE0-8BA3-A5B53CDB250A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks to those who joined us for the call yesterday! We have = meeting notes and a recording posted. Thanks to Mirja for taking = notes!

Meeting notes: https://github.com/intarchboard/edm/blob/master/Materials/Sept-= 1-2020-Notes.txt
Meeting recording (started shortly = after the beginning of the call): https://www.youtube.com/watch?v=3DAhquVW1m_6k

The two actions we had = coming out of the meeting were:

1. Review and start working on updates = to draft-iab-use-it-or-lose-it (https://github.com/intarchboard/use-it-or-lose-it)
2. Work with the hackathon team and tools team to see if we = can add more connections from data tracker or documents back to the = hackathon implementations and interop tests

Best,
Tommy
= --Apple-Mail=_D2BD0653-4C5C-4CE0-8BA3-A5B53CDB250A-- From nobody Sun Sep 6 00:41: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 CFF353A0112 for ; Sun, 6 Sep 2020 00:41:14 -0700 (PDT) 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, 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=mnot.net header.b=LjAQ9xc0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jN4dE87E 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 yurY8IAedkrA for ; Sun, 6 Sep 2020 00:41:12 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E383A0141 for ; Sun, 6 Sep 2020 00:41:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 857E6BDC for ; Sun, 6 Sep 2020 03:32:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 06 Sep 2020 03:32:53 -0400 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= fm3; bh=8tGX3LtTM3p9oSJZAF5ldaieA3SerFDKy9sjScA+zds=; b=LjAQ9xc0 1V+O5T6nRLZFm2c6sXWLMGjoh8sNRh+0vMdqWhDmstTWwz6B4KP6U//rNqApRv9b SLhbwmfgLwUVj4a7ArDByo2hxeUtUSLvnvD0jeutKUWh9X6fPOuTCMALpQVeNtmr 4610fiLvjPWGeHBueM3enMublqX1FxetV+nzqOT9wZoqhPGvQv157swYcqBe10VT /uSLqFOQ5T+I+qSS0NwvmfEzRv592G1mRZwIFcYZWk9ko6RJ3WJFTXsl+eaPtmQn 708BuE8pxReGCjykFOA56XaM/uReqdq1W6ePaIYlfd1V6huxO7HdzAByIrUQoKyF /aKg7H+DJyQYUQ== 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=fm3; bh=8tGX3LtTM3p9oSJZAF5ldaieA3Ser FDKy9sjScA+zds=; b=jN4dE87ET0XgYbioeixJanRPL95he2SS/1MzE6mjCnJgk IbHKdMFfqbuYMWHgxBBcXIBX91aQSIiUI1T4z+GPJjye5X4Ld6D/BqIKjEpxzTMJ iP2+SEL/16jS6ZrtgWDRX8BGzA2sldes3g7+/W86llMgCzm8YiJobsJJimNFhLZp wgxEPGKfZ7hYT44+wJIOTlEf4yclZoeMZUkGAD5I/W26k+8FAT0zyk+OJgCdiAgo p5fZ+BSSUeYJt1999ssUM6dXRzDna2VEv9ygwCdH0y+eiqe2iFYhtq+l21Fc5yMo wVUVeWjwsJQXYRxK8UpyrhWNVNbF9Ph37Em7hOXAw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegiedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvtdefrd dujedunecuufhprghmkfhppfgvthifohhrkhepgedtrdeihedrvddtfedrudejudenucev lhhushhtvghrufhiiigvpeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhoth gprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60.internal.cloudapp.net (unknown [40.65.203.171]) by mail.messagingengine.com (Postfix) with ESMTPA id DCFB43280059 for ; Sun, 6 Sep 2020 03:32:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3474877215754644900==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: edm@iab.org Message-Id: <20200906073252.DCFB43280059@mailuser.nyi.internal> Date: Sun, 6 Sep 2020 03:32:52 -0400 (EDT) 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, 06 Sep 2020 07:41:15 -0000 --===============3474877215754644900== 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=AC12) 2 issues received 12 new comments: - #3 What extension mechanisms are successful? (4 by cabo, martinthomson) https://github.com/intarchboard/edm/issues/3 [evolvability]=20 - #1 Approaches to tracking implementation interop and deployment (8 by a= retana, cabo, tfpauly) https://github.com/intarchboard/edm/issues/1 [deployability]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/edm --===============3474877215754644900== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (EDM Activity Summary)

Sunday September 06, 2020

Issues

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

2 issues received 12 new comments:

Repositories tracked by this digest:

--===============3474877215754644900==-- From nobody Sun Sep 6 16:52:07 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 563703A0C82 for ; Sun, 6 Sep 2020 16:52:06 -0700 (PDT) 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 PMPlDq5pr2zS for ; Sun, 6 Sep 2020 16:52:04 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 2906D3A0C6C for ; Sun, 6 Sep 2020 16:52:04 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id w1so11073190edr.3 for ; Sun, 06 Sep 2020 16:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PtZLSVMT0an9cZM+8kUICGT6U1kBoxjBZ7xAw4ii82I=; b=kkryf+Ntx+csxFxAUhiL99UF54hz3Yef7i5UyK+qdcPNUJ/ffD9OCLdLUNVXaHffDN DDtdLtIkD8rhpr+Wp2Ms9ffVvGN3yL2bnf7s3Ae/oKK0QS0U2oo/utM8LYvZJLrWP7dF VJh9PErvWruUx1fIgie6Y1DDdVxA/PgLNp+lRbahbB0YjyFrY65h+5RmLnn/5R/FzT6o 44XOlMrt3AsJcqRNXniFlYySbl0ELJvvVLV7rZqCh3ygIpXS+7vCdpv9p8eCwwxI1SdZ ngjZuUzfG+bdE2Wmr09FlBhl3jx/feFIijDMy+/L2M0knjwtvrR3Bcy+p+9PNrbnnI/x P7ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PtZLSVMT0an9cZM+8kUICGT6U1kBoxjBZ7xAw4ii82I=; b=lnGMYaw+/6paa4Ko1L+oKk5epK3Gvz8d7ptHAMSmtpYdmaD3PN4d8MNn8cfAbsWf2W GEJ6sUMhEQ90Oeb+64PWGaOSGY4T3hj+S1oSociLFpD91S8+mbdPw7oBAVyvyls6DwqU zm5nhiDiW3mk6Tzmbux4oRft2roLpOpukG54k24sQTd+i07mf5aWBG1qrMldauoHO7Uy oisi7YjFC9WHFgkVXj8M3yKDgSTjmrzg9ICFkb/v6iWe9O8lki8QMGOn7xnCKhsZl82D tR5ZGIX63BVVwAdRRwmRnADjKLKqs1EPvU7uIaBa2pRZf9cuXdlneZQ3UPKUFDrUnJ/d AG3w== X-Gm-Message-State: AOAM5336IWuuSH/JUJ4oEX7UvsWbOcezInk2p3MZdLIkBXEDd6byti1P XtzH3VblE2hqLPC3GHI5PTkQIh681mRz3yo9aXlhNaVI9TQ= X-Google-Smtp-Source: ABdhPJzaf/nBWTIbcb3gfC+l50ncEUOml3dqy3fPZUJxvFg4uZhj3G1uSHcH2SFns6tYZfJIbcrecObXJ8w/BaQypT8= X-Received: by 2002:aa7:de91:: with SMTP id j17mr19285638edv.85.1599436322026; Sun, 06 Sep 2020 16:52:02 -0700 (PDT) MIME-Version: 1.0 From: Vijay Gurbani Date: Sun, 6 Sep 2020 18:51:43 -0500 Message-ID: To: edm@iab.org Content-Type: multipart/alternative; boundary="000000000000d0b97405aeadc9b9" Archived-At: Subject: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 06 Sep 2020 23:52:06 -0000 --000000000000d0b97405aeadc9b9 Content-Type: text/plain; charset="UTF-8" Dear Tommy, Mirja, all: Thank you for organizing the virtual meeting on Tue, Sep 1. As the instigator of the IETF WG Chairs list thread on archiving implementations [1], I have some thoughts, but unfortunately due to a conflict with meetings on my calendar, I had to leave early before the second half of the meeting on last Tue when this issue was discussed. Thank you for considering this thread of enough interest to put it on the EDM agenda. My main question in the IETF Working Group Chair thread was simple: How do the larger set of R&D folks who use the protocols we create find relevant code and other accoutrements that are of interest to them without wading into the IETF arcana? (As a definition, "IETF arcana" is the collective knowledge we, on this list, have gathered from participating in the organization for a sustained period. We know what a datatracker is, what the difference between an individual submission versus a WG submission is, we know where Wikis related to WG pages are, we know what WG deliverables are, etc. This collected knowledge is not readily available to the many people who want to use our protocols, and it is not clear to me that this knowledge would be of use to them unless they want to participate in the IETF to the extent that we do. They need to implement a standardized protocol, for the most part, that is their primary concern.) What is the most visible output of the IETF? Perhaps unarguably, it is an RFC. Even someone who has at best, a foggy idea of what the IETF is, knows what a RFC does. When I talk to developers at companies and students at universities, if they have heard of IETF at all, it is mostly through knowing that some organization called IETF produces these things called RFCs. That's it. Perhaps for them that is enough. And if you buy that argument, then the corollary is that we should do everything that we can to make sure that the implementers have all of the information they need to implement the protocol from the RFC itself. The primary artifact of the protocol is the code that implements it. Not all code is equal. Some, like a SIP server, a QUIC implementation, a HTTP Server, a TLS implementation are complex and it is a foregone conclusion that we can simply park some code in an archive that implements such complex protocols. However, we also produce routing protocols, hashing functions, best practices on how to handle dual IP stacks, ALTO entities that use HTTP and JSON to converse with each other, and so on. Such code is small, perhaps modular, stand-alone and often can easily be made available in a repository much more readily than complex systems like QUIC, SIP, TLS, or HTTP. For the more complex protocols and their implementations, wikis and GitHub repositories that point the new implementer to the community of interest is sufficient. For the less complex protocols that do not need a large community of interest, a simple code archival mechanism appears to be reasonable. To the extent that the archive should be IETF owned, it makes sense to home the archive under ietf.org, as some of the IETF wikis are. So, the next question is how to let the implementer know of these resources when they read a RFC or an I-D? RFC 7942 is an excellent start. It suggests having an Implementation Section in an I-D, but requests the removal of such a section from an RFC-to-be. This implementation section can be used to document the datatrackers, wikis, and GitHub repositories for the more complex code and a link to the archival area for the less complex code. (I realize that IETF does not have authority over links like GitHub that are not under the ietf.org administrative domain, but perhaps for large projects, it is adequate that they stay in repositories like GitHub.) Perhaps RFC 7942 can be updated so that the Implementation Section is not removed when the I-D becomes an RFC, and perhaps verbiage can be added to it during the update that essentially says "caveat emptor", but in more words and with appropriate constraints. But the basic concern of making an RFC self contained such that it has links to implementations is adequately accomplished by an updated RFC 7492. Thank you for reading so far, and thank you again for considering this of enough interest to put it on the EDM agenda. I look forward to your thoughts on this. [1] A quick recap and restatement of the need for a stable archival area controlled by the IETF is in https://mailarchive.ietf.org/arch/msg/wgchairs/He68KsKijRg2FAIpxRFi5MyJGis/ That link contains other links to the original thread for those of you who want to catch up with the discussion. Cheers, - vijay --000000000000d0b97405aeadc9b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Tommy, Mirja, all: Thank you for organizing the virtu= al meeting on Tue, Sep 1.

As the instigator of the IETF WG Chairs li= st thread on archiving implementations [1], I have some thoughts, but unfor= tunately due to a conflict with meetings on my calendar, I had to leave ear= ly before the second half of the meeting on last Tue when this issue was di= scussed.=C2=A0 Thank you for considering this thread of enough interest to = put it on the EDM agenda.

My main question in the IETF Working Grou= p Chair thread was simple: How do the larger set of R&D folks who use t= he protocols we create find relevant code and other accoutrements that are = of interest to them without wading into the IETF arcana? =C2=A0(As a defini= tion, "IETF arcana" is the collective knowledge we, on this list,= have gathered from participating in the organization for a sustained perio= d.=C2=A0 We know what a datatracker is, what the difference between an indi= vidual submission versus a WG submission is, we know where Wikis related to= WG pages are, we know what WG deliverables are, etc.=C2=A0 This collected = knowledge is not readily available to the many people who want to use our p= rotocols, and it is not clear to me that this knowledge would be of use to = them unless they want to participate in the IETF to the extent that we do.= =C2=A0 They need to implement a standardized protocol, for the most part, t= hat is their primary concern.)

What is the most visible output of th= e IETF?=C2=A0 Perhaps unarguably, it is an RFC.=C2=A0 Even someone who has = at best, a foggy idea of what the IETF is, knows what a RFC does.=C2=A0 Whe= n I talk to developers at companies and students at universities, if they h= ave heard of IETF at all, it is mostly through knowing that some organizati= on called IETF produces these things called RFCs.=C2=A0 That's it. Perh= aps for them that is enough.=C2=A0 And if you buy that argument, then the c= orollary is that we should do everything that we can to make sure that the = implementers have all of the information they need to implement the protoco= l from the RFC itself.

The primary artifact of the protocol is the c= ode that implements it.=C2=A0 Not all code is equal.=C2=A0 Some, like a SIP= server, a QUIC implementation, a HTTP Server, a TLS implementation are com= plex and it is a foregone conclusion that we can simply park some code in a= n archive that implements such complex protocols.=C2=A0 However, we also pr= oduce routing protocols, hashing functions, best practices on how to handle= dual IP stacks, ALTO entities that use HTTP and JSON to converse with each= other, and so on.=C2=A0 Such code is small, perhaps modular, stand-alone a= nd often can easily be made available in a repository much more readily tha= n complex systems like QUIC, SIP, TLS, or HTTP.

For the more complex= protocols and their implementations, wikis and GitHub repositories that po= int the new implementer to the community of interest is sufficient.=C2=A0 F= or the less complex protocols that do not need a large community of interes= t, a simple code archival mechanism appears to be reasonable.=C2=A0 To the = extent that the archive should be IETF owned, it makes sense to home the ar= chive under ietf.org, as some of the IETF w= ikis are.

So, the next question is how to let the implementer know o= f these resources when they read a RFC or an I-D?=C2=A0 RFC 7942 is an exce= llent start.=C2=A0 It suggests having an Implementation Section in an I-D, = but requests the removal of such a section from an RFC-to-be.=C2=A0 This im= plementation section can be used to document the datatrackers, wikis, and G= itHub repositories for the more complex code and a link to the archival are= a for the less complex code. =C2=A0(I realize that IETF does not have autho= rity over links like GitHub that are not under the ietf.org administrative domain, but perhaps for large projects, it = is adequate that they stay in repositories like GitHub.) Perhaps RFC 7942 c= an be updated so that the Implementation Section is not removed when the I-= D becomes an RFC, and perhaps verbiage can be added to it during the update= that essentially says "caveat emptor", but in more words and wit= h appropriate constraints.=C2=A0 But the basic concern of making an RFC sel= f contained such that it has links to implementations is adequately accompl= ished by an updated RFC 7492.

Thank you for reading so far, and than= k you again for considering this of enough interest to put it on the EDM ag= enda.=C2=A0 I look forward to your thoughts on this.

[1] A quic= k recap and restatement of the need for a stable archival area controlled b= y the IETF is in https://mailarchive.ietf.org/arch/msg/wgchair= s/He68KsKijRg2FAIpxRFi5MyJGis/ =C2=A0That link contains other links to = the original thread for those of you who want to catch up with the discussi= on.

Cheers,

- vijay<= br>
--000000000000d0b97405aeadc9b9-- From nobody Tue Sep 8 17:44:43 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 C900B3A0C57 for ; Tue, 8 Sep 2020 17:44:41 -0700 (PDT) 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 jE36ZU8Ueo33 for ; Tue, 8 Sep 2020 17:44:39 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 A59303A0C51 for ; Tue, 8 Sep 2020 17:44:39 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id x10so631931ybj.13 for ; Tue, 08 Sep 2020 17:44:39 -0700 (PDT) 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=h0MWkcacLE0SmuU9W6vqDxDxmc0aPH80myoQd8bVk9s=; b=YkQkyRS1+OJNpfxRSXqKLsVoTgqDcevCtsYh8OdIWAeDU0/4ZfO6sEyUtf5QPI4uDF zuEvvzp1JBtj2dszzDda+KUOXIvXQjAL0SLx+vRabpSr0SCG+dwdbUF0rFzJP24a9V/V dqrfibTeKdBn+q6bV8ku2ibnAZ0yY4Y50eIZ4LbYC5y2pj1mZ/tw0C34futzDV2TldX+ gx0xSlleZIpqMm8wwUetxUi+Vmty6ZnA51y6j14Ssr1OZEYFNMogTTYfJaPTfAqdMai0 BHx/RskXI43fhzovsnEOw/iTcrsr6cKIATo2zgQzwgsM4hvXdPhkzjBjcOXsIpgALUfA sgaw== 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=h0MWkcacLE0SmuU9W6vqDxDxmc0aPH80myoQd8bVk9s=; b=nu8DEkBk5awvIvQyEV9tcpIm3lkoeftQUe2Xf92s8kvNS3JA5jmVce1XaEbXH6vJO1 01dULXeVOF36ytgdVxc1ht3Uy+bi3NPMEkVgjFq1B1y95KQrtwZkvgKJuavbBW0EVsK/ c5w1J4cEJguRQkukwLG8sgFdfQG7474F8Ni8pJUhbE70Shynw1tuu/uI0j2lxlfOVOlJ qdGHAqANG0G2FSHTyfEXaTAxHHNlfsVRO95SZXSmepZ5k27C2LTl3D4NY/Fu/JtehfIX STIFbDssUJAqEWs7EsLIvjoYhRk9Wl+6HcY06lT8seiimKVwVwXrd4NTXt276tGe0t0s 9upg== X-Gm-Message-State: AOAM533uZjOynKHC7EXeVG6NGqIS1joGc/Tk2ALpyApPIh6QDfhxM2iN Lz1rdMFE56s5girLDB7WuAfJGKBWetVxFWKGgTg= X-Google-Smtp-Source: ABdhPJxDpfC+qIXoKiEpu412wuWHxsLKSIivdivZMaRgto//WLjj1ps0gxaP0fskDenrUSQPUqQQMRumv4BHvp+2hIk= X-Received: by 2002:a25:2649:: with SMTP id m70mr2293672ybm.380.1599612278753; Tue, 08 Sep 2020 17:44:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 8 Sep 2020 19:44:12 -0500 Message-ID: To: Vijay Gurbani Cc: edm@iab.org Content-Type: multipart/alternative; boundary="000000000000a74eb105aed6c12e" Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 09 Sep 2020 00:44:42 -0000 --000000000000a74eb105aed6c12e Content-Type: text/plain; charset="UTF-8" Hi, Vijay, On Sun, Sep 6, 2020 at 6:52 PM Vijay Gurbani wrote: > Dear Tommy, Mirja, all: Thank you for organizing the virtual meeting on > Tue, Sep 1. > > As the instigator of the IETF WG Chairs list thread on archiving > implementations [1], I have some thoughts, but unfortunately due to a > conflict with meetings on my calendar, I had to leave early before the > second half of the meeting on last Tue when this issue was discussed. > Thank you for considering this thread of enough interest to put it on the > EDM agenda. > > My main question in the IETF Working Group Chair thread was simple: How do > the larger set of R&D folks who use the protocols we create find relevant > code and other accoutrements that are of interest to them without wading > into the IETF arcana? (As a definition, "IETF arcana" is the collective > knowledge we, on this list, have gathered from participating in the > organization for a sustained period. We know what a datatracker is, what > the difference between an individual submission versus a WG submission is, > we know where Wikis related to WG pages are, we know what WG deliverables > are, etc. This collected knowledge is not readily available to the many > people who want to use our protocols, and it is not clear to me that this > knowledge would be of use to them unless they want to participate in the > IETF to the extent that we do. They need to implement a standardized > protocol, for the most part, that is their primary concern.) > > What is the most visible output of the IETF? Perhaps unarguably, it is an > RFC. Even someone who has at best, a foggy idea of what the IETF is, knows > what a RFC does. When I talk to developers at companies and students at > universities, if they have heard of IETF at all, it is mostly through > knowing that some organization called IETF produces these things called > RFCs. That's it. Perhaps for them that is enough. And if you buy that > argument, then the corollary is that we should do everything that we can to > make sure that the implementers have all of the information they need to > implement the protocol from the RFC itself. > > The primary artifact of the protocol is the code that implements it. Not > all code is equal. Some, like a SIP server, a QUIC implementation, a HTTP > Server, a TLS implementation are complex and it is a foregone conclusion > that we can simply park some code in an archive that implements such > complex protocols. However, we also produce routing protocols, hashing > functions, best practices on how to handle dual IP stacks, ALTO entities > that use HTTP and JSON to converse with each other, and so on. Such code > is small, perhaps modular, stand-alone and often can easily be made > available in a repository much more readily than complex systems like QUIC, > SIP, TLS, or HTTP. > > For the more complex protocols and their implementations, wikis and GitHub > repositories that point the new implementer to the community of interest is > sufficient. For the less complex protocols that do not need a large > community of interest, a simple code archival mechanism appears to be > reasonable. To the extent that the archive should be IETF owned, it makes > sense to home the archive under ietf.org, as some of the IETF wikis are. > > So, the next question is how to let the implementer know of these > resources when they read a RFC or an I-D? RFC 7942 is an excellent start. > It suggests having an Implementation Section in an I-D, but requests the > removal of such a section from an RFC-to-be. This implementation section > can be used to document the datatrackers, wikis, and GitHub repositories > for the more complex code and a link to the archival area for the less > complex code. (I realize that IETF does not have authority over links like > GitHub that are not under the ietf.org administrative domain, but perhaps > for large projects, it is adequate that they stay in repositories like > GitHub.) Perhaps RFC 7942 can be updated so that the Implementation Section > is not removed when the I-D becomes an RFC, and perhaps verbiage can be > added to it during the update that essentially says "caveat emptor", but in > more words and with appropriate constraints. But the basic concern of > making an RFC self contained such that it has links to implementations is > adequately accomplished by an updated RFC 7492. > ISTM that it's worth considering what's possible without revising RFC 7942. Everyone may already know this, but the RFC Editor now has a way of inlining errata - for example, check https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html. * If we can figure out how to track "what's worth pointing to", perhaps the RFC editor could also inline pointers, rather than dorking with the RFC text itself. Best, Spencer * I believe Adam Roach did the heavy lifting on proving this was feasible when he was on the IESG. I'm not sure where the actual code used today came from, but I do want to give credit when I can. > Thank you for reading so far, and thank you again for considering this of > enough interest to put it on the EDM agenda. I look forward to your > thoughts on this. > > [1] A quick recap and restatement of the need for a stable archival area > controlled by the IETF is in > https://mailarchive.ietf.org/arch/msg/wgchairs/He68KsKijRg2FAIpxRFi5MyJGis/ > That link contains other links to the original thread for those of you who > want to catch up with the discussion. > > Cheers, > > - vijay > -- > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm > --000000000000a74eb105aed6c12e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Vijay,

On Sun, Sep 6, 2020 at 6:52 PM = Vijay Gurbani <vijay.gurbani@= gmail.com> wrote:
Dear Tommy, Mirja, all: Thank you for organizin= g the virtual meeting on Tue, Sep 1.

As the instigator of the IETF W= G Chairs list thread on archiving implementations [1], I have some thoughts= , but unfortunately due to a conflict with meetings on my calendar, I had t= o leave early before the second half of the meeting on last Tue when this i= ssue was discussed.=C2=A0 Thank you for considering this thread of enough i= nterest to put it on the EDM agenda.

My main question in the IETF W= orking Group Chair thread was simple: How do the larger set of R&D folk= s who use the protocols we create find relevant code and other accoutrement= s that are of interest to them without wading into the IETF arcana? =C2=A0(= As a definition, "IETF arcana" is the collective knowledge we, on= this list, have gathered from participating in the organization for a sust= ained period.=C2=A0 We know what a datatracker is, what the difference betw= een an individual submission versus a WG submission is, we know where Wikis= related to WG pages are, we know what WG deliverables are, etc.=C2=A0 This= collected knowledge is not readily available to the many people who want t= o use our protocols, and it is not clear to me that this knowledge would be= of use to them unless they want to participate in the IETF to the extent t= hat we do.=C2=A0 They need to implement a standardized protocol, for the mo= st part, that is their primary concern.)

What is the most visible ou= tput of the IETF?=C2=A0 Perhaps unarguably, it is an RFC.=C2=A0 Even someon= e who has at best, a foggy idea of what the IETF is, knows what a RFC does.= =C2=A0 When I talk to developers at companies and students at universities,= if they have heard of IETF at all, it is mostly through knowing that some = organization called IETF produces these things called RFCs.=C2=A0 That'= s it. Perhaps for them that is enough.=C2=A0 And if you buy that argument, = then the corollary is that we should do everything that we can to make sure= that the implementers have all of the information they need to implement t= he protocol from the RFC itself.

The primary artifact of the protoco= l is the code that implements it.=C2=A0 Not all code is equal.=C2=A0 Some, = like a SIP server, a QUIC implementation, a HTTP Server, a TLS implementati= on are complex and it is a foregone conclusion that we can simply park some= code in an archive that implements such complex protocols.=C2=A0 However, = we also produce routing protocols, hashing functions, best practices on how= to handle dual IP stacks, ALTO entities that use HTTP and JSON to converse= with each other, and so on.=C2=A0 Such code is small, perhaps modular, sta= nd-alone and often can easily be made available in a repository much more r= eadily than complex systems like QUIC, SIP, TLS, or HTTP.

For the mo= re complex protocols and their implementations, wikis and GitHub repositori= es that point the new implementer to the community of interest is sufficien= t.=C2=A0 For the less complex protocols that do not need a large community = of interest, a simple code archival mechanism appears to be reasonable.=C2= =A0 To the extent that the archive should be IETF owned, it makes sense to = home the archive under ietf.o= rg, as some of the IETF wikis are.

So, the next question is how = to let the implementer know of these resources when they read a RFC or an I= -D?=C2=A0 RFC 7942 is an excellent start.=C2=A0 It suggests having an Imple= mentation Section in an I-D, but requests the removal of such a section fro= m an RFC-to-be.=C2=A0 This implementation section can be used to document t= he datatrackers, wikis, and GitHub repositories for the more complex code a= nd a link to the archival area for the less complex code. =C2=A0(I realize = that IETF does not have authority over links like GitHub that are not under= the ietf.org administrat= ive domain, but perhaps for large projects, it is adequate that they stay i= n repositories like GitHub.) Perhaps RFC 7942 can be updated so that the Im= plementation Section is not removed when the I-D becomes an RFC, and perhap= s verbiage can be added to it during the update that essentially says "= ;caveat emptor", but in more words and with appropriate constraints.= =C2=A0 But the basic concern of making an RFC self contained such that it h= as links to implementations is adequately accomplished by an updated RFC 74= 92.

ISTM that it's worth cons= idering what's possible without revising RFC 7942.=C2=A0

=
Everyone may already know this, but the RFC Editor now has a way= of inlining errata - for example, check=C2=A0https://www.rfc-editor.org/rfc/inl= ine-errata/rfc3261.html. *

If we can figure ou= t how to track "what's worth pointing to", perhaps the RFC ed= itor could also inline pointers, rather than dorking with the RFC text itse= lf.=C2=A0

Best,

Spencer

* I believe Adam Roach did the heavy lifting on pro= ving this was feasible when he was on the IESG. I'm not sure where the = actual code used today came from, but I do want to give credit when I can.= =C2=A0
=C2=A0
Thank you for reading so far, and thank you again for = considering this of enough interest to put it on the EDM agenda.=C2=A0 I lo= ok forward to your thoughts on this.

[1] A quick recap and rest= atement of the need for a stable archival area controlled by the IETF is in= https://mailarchive.ietf.org/arch/msg/wgcha= irs/He68KsKijRg2FAIpxRFi5MyJGis/ =C2=A0That link contains other links t= o the original thread for those of you who want to catch up with the discus= sion.

Cheers,

- vija= y
--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm
--000000000000a74eb105aed6c12e-- From nobody Wed Sep 9 08:07:03 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 376D93A0CF2 for ; Wed, 9 Sep 2020 08:07:01 -0700 (PDT) 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 Yn-DqzLzLq8d for ; Wed, 9 Sep 2020 08:06:58 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 339603A0CF0 for ; Wed, 9 Sep 2020 08:06:58 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id c10so3011110edk.6 for ; Wed, 09 Sep 2020 08:06:58 -0700 (PDT) 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=YhLwKmVNeWie4aMCXHiyJvJUXKjTW4IumHh18gTbRnA=; b=FUQoaSd0H0Ha8Du3ockf5+VJxzCTuZLRVUKItsSOw6i4sRH/3rgv+ntGMFEv/3vcba 3gqOYlzhfa6MIw5dAoelql3JSpP7NhfGGXanwVmzQmTIwldukZDZWVwyoqJYA7KMLU6d PEquCoL+fzsZkzbVWHG5z8s6FFXChV+Q+bQrDSj0XPuXdJC/QMc4jadZC9YnsGtRhV1y Feiv9eQmWBe+H1mCkywUhlDZtNjQyO0Ln6OWaWWHec9//L9HxIwPFTGzGWXrL9B37fUR Qy21N4cfUQOUbTJ5HSjSW8tt/aEKyGMlMk4PmLUHCf2erKbaSIHOptOnngMX0S1GEKEb KHRA== 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=YhLwKmVNeWie4aMCXHiyJvJUXKjTW4IumHh18gTbRnA=; b=Y0FG8G3O/RmF2R/9b0U6C9YKVN20pe34g8Q4hy30cGb+fQVsoQF5og25Q/loLf8tLZ IjIlSnGihwRlBqGCxBQQgo9ZTfglgc4zwLWvaFWjdK0RP3KViGOB9PlDjGtr0xLx/HND ZUMq3x+3cc5vKMGx9q8ivn5rqUhP4DZs2EGiFHmc7MR0klgVpG7m3uIjEaq/2fYnHN6y cUpzwdq/PwUGhix4bg5NAm5xvk1vrIBXDjDsksv09z4OM78YC1b+htudlMDviUOIr0oa fT/DO+8ko902ThPy1z8qnMtKLhom+8p3gXkfrC4CRMS2UJIgYxFO7mWvCOezWgMG2FL2 dp6w== X-Gm-Message-State: AOAM532Nqr657ab6YGnzcNDcepnYfih00CIIwsdajE9lS0pVpxqUTKAh X8ScrDMmu9SKKKxJ6P3jvZwNHfLQMEf8ruzTk1o= X-Google-Smtp-Source: ABdhPJwI6ck42RrgwuIna5Pj5Ld0ZHBDf/JlYx35Dmvv9eJ0MDngcA5gw6OgvHc9+rMv/X/FtaEQQgX9bZ7M1oLjywE= X-Received: by 2002:aa7:de91:: with SMTP id j17mr4560426edv.85.1599664016695; Wed, 09 Sep 2020 08:06:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijay Gurbani Date: Wed, 9 Sep 2020 10:06:37 -0500 Message-ID: To: Spencer Dawkins at IETF Cc: edm@iab.org Content-Type: multipart/alternative; boundary="00000000000079a5d205aee2cd50" Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 09 Sep 2020 15:07:01 -0000 --00000000000079a5d205aee2cd50 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 8, 2020 at 7:44 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Vijay, > > [...] > ISTM that it's worth considering what's possible without revising RFC > 7942. > > Everyone may already know this, but the RFC Editor now has a way of > inlining errata - for example, check > https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html. * > > If we can figure out how to track "what's worth pointing to", perhaps the > RFC editor could also inline pointers, rather than dorking with the RFC > text itself. > Dear Spencer: Nice to hear from you, and thank you for your comment. I am all for considering what's possible without revising RFC 7942, no problem, as long as we can redirect the interested parties to the appropriate code archives. The work you cited that Adam has done on RFC 3261 for errata looks very neat. This could be a potential way to proceed if IAB/IETF decided not to go the route of updating RFC 7942 or inserting some other text in the RFC-to-be. Some issues to consider if we go the inlining route would be (a) how to aesthetically present the information on the RFC masthead, (b) what is the expectation when someone prints the RFC with such inling? Will the inline text show up? (In the case of RFC 3261 with inlined errata, I note that all expanded errata are printed, non expanded errata appear as green text in the generated PDF. By "expanded" I mean that if I click on one of the errata, it expands into a rectangle at the appropriate place in the RFC, and that entire rectangle is then printed in the generated PDF.) Thanks, - vijay --00000000000079a5d205aee2cd50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 8, 2020 at 7:44 PM Spencer Da= wkins at IETF <spencerd= awkins.ietf@gmail.com> wrote:
Hi, Vijay,

[...]
ISTM that= it's worth considering what's possible without revising RFC 7942.= =C2=A0

Everyone may already know this, but the RFC= Editor now has a way of inlining errata - for example, check=C2=A0https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html. *

If we can figure out how to track "what's wor= th pointing to", perhaps the RFC editor could also inline pointers, ra= ther than dorking with the RFC text itself.

Dear Spencer: Nice to hear from you, and thank you = for your comment.

I am all for considering what= 9;s possible without revising RFC 7942, no problem, as long as we can redir= ect the interested parties to the appropriate code archives.
=
The work you cited that Adam has done on RFC 3261 for errata= looks very neat.=C2=A0 This could be a potential way to proceed if IAB/IET= F decided not to go the route of updating RFC 7942 or inserting some other = text in the RFC-to-be.=C2=A0 Some issues to consider if we go the inlining = route would be (a) how to aesthetically present the information on the RFC = masthead, (b) what is the expectation when someone prints the RFC with such= inling?=C2=A0 Will the inline text show up?=C2=A0 (In the case of RFC 3261= with inlined errata, I note that all expanded errata are printed, non expa= nded errata appear as green text in the generated PDF.=C2=A0 By "expan= ded" I mean that if I click on one of the errata, it expands into a re= ctangle at the appropriate place in the RFC, and that entire rectangle is t= hen printed in the generated PDF.)

Thanks,

- vijay
--00000000000079a5d205aee2cd50-- From nobody Thu Sep 10 09:40:45 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 19CD13A0138 for ; Thu, 10 Sep 2020 09:40:44 -0700 (PDT) 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 ny7soqG4VK8L for ; Thu, 10 Sep 2020 09:40:42 -0700 (PDT) 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 BA1263A03ED for ; Thu, 10 Sep 2020 09:40:34 -0700 (PDT) Received: from p200300dee7459100edafe8308d1409da.dip0.t-ipconnect.de ([2003:de:e745:9100:edaf:e830:8d14:9da]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kGPce-0007f9-8v; Thu, 10 Sep 2020 18:40:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 10 Sep 2020 18:40:31 +0200 Cc: Spencer Dawkins at IETF , edm@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> References: To: Vijay Gurbani X-Mailer: Apple Mail (2.3608.120.23.2.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1599756034;026ea0aa; X-HE-SMSGID: 1kGPce-0007f9-8v Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 10 Sep 2020 16:40:44 -0000 Hi Vijay, Thanks for moving this discussion forward. To focus on the formal bits for a second: RFC7942 doesn=E2=80=99t = actually require that the section is removed. This says "Authors are = requested to=E2=80=9D but I guess it=E2=80=99s for the authors/wg to = decide. Also this is an IETF-consensus document which I think was = AD-sponsored. So the way to update it is =E2=80=9Csimply=E2=80=9D to = write a bis-draft and bring it to gendisptach these days. More to the actually point: I understand your motivation about people = only knowing RFCs but none of the IETF process but I=E2=80=99m not sure = putting this information in an RFC is the right tool. I bed it=E2=80=99s = actually not very hard to find some suitable code on GitHub these days, = especially as you said if this is about larger projects (which in the = best case are actively maintained). For smaller code snippets we often = put pseudo code in the document of appendix. So that=E2=80=99s another = option. Mirja > On 9. Sep 2020, at 17:06, Vijay Gurbani = wrote: >=20 > On Tue, Sep 8, 2020 at 7:44 PM Spencer Dawkins at IETF = wrote: > Hi, Vijay, >=20 > [...] > ISTM that it's worth considering what's possible without revising RFC = 7942.=20 >=20 > Everyone may already know this, but the RFC Editor now has a way of = inlining errata - for example, check = https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html. * >=20 > If we can figure out how to track "what's worth pointing to", perhaps = the RFC editor could also inline pointers, rather than dorking with the = RFC text itself.=20 >=20 > Dear Spencer: Nice to hear from you, and thank you for your comment. >=20 > I am all for considering what's possible without revising RFC 7942, no = problem, as long as we can redirect the interested parties to the = appropriate code archives. >=20 > The work you cited that Adam has done on RFC 3261 for errata looks = very neat. This could be a potential way to proceed if IAB/IETF decided = not to go the route of updating RFC 7942 or inserting some other text in = the RFC-to-be. Some issues to consider if we go the inlining route = would be (a) how to aesthetically present the information on the RFC = masthead, (b) what is the expectation when someone prints the RFC with = such inling? Will the inline text show up? (In the case of RFC 3261 = with inlined errata, I note that all expanded errata are printed, non = expanded errata appear as green text in the generated PDF. By = "expanded" I mean that if I click on one of the errata, it expands into = a rectangle at the appropriate place in the RFC, and that entire = rectangle is then printed in the generated PDF.) >=20 > Thanks, >=20 > - vijay > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm From nobody Thu Sep 10 10:49:55 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 5C81B3A0ADC for ; Thu, 10 Sep 2020 10:49:54 -0700 (PDT) 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 XEp9ZkA3VzJg for ; Thu, 10 Sep 2020 10:49:52 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 9166D3A0AE0 for ; Thu, 10 Sep 2020 10:49:50 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id z23so9954266ejr.13 for ; Thu, 10 Sep 2020 10:49:50 -0700 (PDT) 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=Zjsry2zgn2E4H5FXmIybqxcmNc+OGo9WYbxOLGS38wY=; b=Ib0F/vDbfk6B6V1YJQYmCyVzcgmwmfNdW8f66XekLMdVmL4Yujjjj+FRvbjAvvTFp4 hL0km/ri79U0kbeog+oA8fRJ2fvEPhxzILzFNIK+sS+7GKCCmnDHZF5HW+ZXfSByC+jQ lg7xSSQa+8NYm6s3LBxFGPYIoISEtyllHUE2o8c5oij7tkw6APzW8OfKxu7C/E93dCnw YJlWaZYEGxhJ2V/dvJuUDGN3Wb8rhkuuV06vQjCFCH/XTE1AFLK/fi91Nlp94MlFCr4V 5I20E1PE8Vh8ihsGnozRfdLeDxsvMplPncNP/tDmJkY8qdcflmAwFTVkWYTE+I5HIBEo X2DA== 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=Zjsry2zgn2E4H5FXmIybqxcmNc+OGo9WYbxOLGS38wY=; b=UVSAk+veH2y0Kwvi9Yuk5irrsWVsXCZhgzfd5PaaK20+W+WSP+EV16O9v4w+AiGPgW ga15yeBWAmUKEJkBxSNy017m2ll8WOeAVbp45xvJ0wi8PrrEI8XfmouBnxN6a86qJbTC XXcEwBQOu+G8cayRgraar1p2KlLIrjzTbhBozSur9aOs66iYgnI++3n+1XH9QExnTgF5 kTn6ls6A8bNHPNn+J/n1OQbpVmKB+ZaOUSoQ/IOWOSMn0Yc+TeLep1It69GiicPVagSd WLYD2Uiyyogtpa6eb/eLr39hfz7rjB9GRrpIeZp0M4T1Ihaq/+j/OWSewahdTvDdsybG xEkA== X-Gm-Message-State: AOAM530EXNhgsvfl7fkbMw7epyd9NF+jYTwmnZjweUOCf4vQqwcCzx4T foouX72ETf6p/odfVo1wP/6y6yHF+Nh8a5h4epk= X-Google-Smtp-Source: ABdhPJyaIbm5m9iyeoufA9OhKLuyROU8/t6PtI22BH54NnhtpRHZfrP1QqNZtSfBjOdkjx8nfZf5SGdtrS8qEwo1NE4= X-Received: by 2002:a17:906:2962:: with SMTP id x2mr9845084ejd.188.1599760189032; Thu, 10 Sep 2020 10:49:49 -0700 (PDT) MIME-Version: 1.0 References: <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> In-Reply-To: <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> From: Vijay Gurbani Date: Thu, 10 Sep 2020 12:49:28 -0500 Message-ID: To: Mirja Kuehlewind Cc: Spencer Dawkins at IETF , edm@iab.org Content-Type: multipart/alternative; boundary="000000000000cb101205aef93132" Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 10 Sep 2020 17:49:54 -0000 --000000000000cb101205aef93132 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 10, 2020 at 11:40 AM Mirja Kuehlewind wrote: > Hi Vijay, > > Thanks for moving this discussion forward. > Dear Mirja: Thank you for your time and your comments. More inline. > To focus on the formal bits for a second: RFC7942 doesn=E2=80=99t actuall= y require > that the section is removed. This says "Authors are requested to=E2=80=9D= but I > guess it=E2=80=99s for the authors/wg to decide. Also this is an IETF-con= sensus > document which I think was AD-sponsored. So the way to update it is > =E2=80=9Csimply=E2=80=9D to write a bis-draft and bring it to gendisptach= these days. > I agree that RFC 7942 only "requests" not "mandates" that the section be removed. However, the practical effect of this request is that most authors will simply ask for the section to be removed. That was the case in a particular draft that I was reviewing for Gen-Art (which actually resulted in the thread I opened up on the WG Chairs list). Furthermore, to be frank, before I reviwed the draft in question for Gen-ART, I was not even aware of RFC 7942. Certainly, it is fairly new (having been minted in 2016), but none of the I-Ds or RFCs I have read post-2016 even mention an Implementation Status section. It certainly does not portend well that we are not eating our own dog food. I looked at two active WGs --- quic and httpbis --- to see if an RFC 7942 section is present in any of the active I-Ds. Of the 24 I-Ds in these groups, I could not find such a section [1]. Apologies, I am not picking on these groups, just trying to get some objective data points by looking at a couple of active WGs. The irony is that the base protocol document for QUIC [2] has a "Note to Readers" section that provides the very information --- where to find the GitHub repository --- that we are seeking to institutionalise. I am not sure what will happen to this note when QUIC becomes an RFC. > More to the actually point: I understand your motivation about people onl= y > knowing RFCs but none of the IETF process but I=E2=80=99m not sure puttin= g this > information in an RFC is the right tool. I bed it=E2=80=99s actually not = very hard > to find some suitable code on GitHub these days, especially as you said i= f > this is about larger projects (which in the best case are actively > maintained). For smaller code snippets we often put pseudo code in the > document of appendix. So that=E2=80=99s another option. > I understand and respect your view that putting this information in an RFC is not the right thing to do. I am trying to convince you that it is, and I hope that I succeed in some measure. The proposal we are considering --- i.e., putting some text in RFCs to guide legions of implementers not familiar with "IETF arcana" --- is already being used loosely as I pointed out above for QUIC. It seems to me that we can do better by institutionalising it in some manner that RFC 7942 did not. Perhaps as you suggest, the answer is to simply write a RFC 7942-bis draft. If you think this is an avenue we should explore, I am happy to spin up a rfc7942-bis so to provide more structure to the conversation. [1] I will like to point out that of the 24 I-Ds, not all deal with specific protocol/algorithmic issues, so please account for that reality. [2] https://www.ietf.org/id/draft-ietf-quic-transport-30.txt Thanks, - vijay --000000000000cb101205aef93132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 10, 2020 at 11:40 AM Mirja Ku= ehlewind <ietf@kuehlewind.net= > wrote:
Hi Vijay,

Thanks for moving this discussion forward.

<= div>Dear Mirja: Thank you for your time and your comments.=C2=A0 More inlin= e.
=C2=A0
To focus on the formal bits for a second: RFC7942 doesn=E2=80=99t actually = require that the section is removed. This says "Authors are requested = to=E2=80=9D but I guess it=E2=80=99s for the authors/wg to decide. Also thi= s is an IETF-consensus document which I think was AD-sponsored. So the way = to update it is =E2=80=9Csimply=E2=80=9D to write a bis-draft and bring it = to gendisptach these days.

I agree that= RFC 7942 only "requests" not "mandates" that the secti= on be removed.=C2=A0 However, the practical effect of this request is that = most authors will simply ask for the section to be removed.=C2=A0 That was = the case in a particular draft that I was reviewing for Gen-Art (which actu= ally resulted in the thread I opened up on the WG Chairs list).=C2=A0 Furth= ermore, to be frank, before I reviwed the draft in question for Gen-ART, I = was not even aware of RFC 7942.=C2=A0 Certainly, it is fairly new (having b= een minted in 2016), but none of the I-Ds or RFCs I have read post-2016 eve= n mention an Implementation Status section.=C2=A0

=
It certainly does not portend well that we are not eating our own dog = food.=C2=A0 I looked at two active WGs --- quic and httpbis --- to see if a= n RFC 7942 section is present in any of the active I-Ds.=C2=A0 Of the 24 I-= Ds in these groups, I could not find such a section [1].=C2=A0 Apologies, I= am not picking on these groups, just trying to get some objective data poi= nts by looking at a couple of active WGs.=C2=A0 The irony is that the base = protocol document for QUIC [2] has a "Note to Readers" section th= at provides the very information --- where to find the GitHub repository --= - that we are seeking to institutionalise.=C2=A0 I am not sure what will ha= ppen to this note when QUIC becomes an RFC.
=C2=A0
More to the actually point: I understand your motivation about people only = knowing RFCs but none of the IETF process but I=E2=80=99m not sure putting = this information in an RFC is the right tool. I bed it=E2=80=99s actually n= ot very hard to find some suitable code on GitHub these days, especially as= you said if this is about larger projects (which in the best case are acti= vely maintained). For smaller code snippets we often put pseudo code in the= document of appendix. So that=E2=80=99s another option.

I understand and respect your view that putting this info= rmation in an RFC is not the right thing to do.=C2=A0 I am trying to convin= ce you that it is, and I hope that I succeed in some measure.=C2=A0

The proposal we are considering --- i.e., putting so= me text in RFCs to guide legions of implementers not familiar with "IE= TF arcana" --- is already being used loosely as I pointed out above fo= r QUIC.=C2=A0 It seems to me that we can do better by institutionalising it= in some manner that RFC 7942 did not. Perhaps as you suggest, the answer i= s to simply write a RFC 7942-bis draft.=C2=A0 If you think this is an avenu= e we should explore, I am happy to spin up a rfc7942-bis=C2=A0 so to provid= e more structure to the conversation.

[1] I wi= ll like to point out that of the 24 I-Ds, not all deal with specific protoc= ol/algorithmic issues, so please account for that reality.=C2=A0
[2] h= ttps://www.ietf.org/id/draft-ietf-quic-transport-30.txt

<= /div>
Thanks,

- vijay
--000000000000cb101205aef93132-- From nobody Thu Sep 10 11:33:16 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 A56D83A0BE6 for ; Thu, 10 Sep 2020 11:33:12 -0700 (PDT) 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 p8-wqWXWrvFd for ; Thu, 10 Sep 2020 11:33:10 -0700 (PDT) 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 A85B53A0C17 for ; Thu, 10 Sep 2020 11:33:10 -0700 (PDT) Received: from p200300dee7459100edafe8308d1409da.dip0.t-ipconnect.de ([2003:de:e745:9100:edaf:e830:8d14:9da]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kGRNc-0003T5-2c; Thu, 10 Sep 2020 20:33:08 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 10 Sep 2020 20:33:07 +0200 Cc: edm@iab.org, Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <68D31D1A-334A-4577-AB93-37D4DD5B369B@kuehlewind.net> References: <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> To: Vijay Gurbani X-Mailer: Apple Mail (2.3608.120.23.2.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1599762790;d953f7dd; X-HE-SMSGID: 1kGRNc-0003T5-2c Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 10 Sep 2020 18:33:13 -0000 Just very quickly some points. Having read all RFCs that we have = published in the four years of my AD time I can tell you that RFC7942 is = used form time to time. However, it also addresses a different problem = then what you ask for, namely how do people in the wg know about = existing implementations. QUIC decides to use another tool for this = purpose; I guess for several reason, one being that many implementors in = QUIC who have been new to the IETF are actually more familiar with = GitHub than any IETF procedures. My expectation is that note you = mentioned for QUIC will be removed before publication as RFC. > On 10. Sep 2020, at 19:49, Vijay Gurbani = wrote: >=20 > On Thu, Sep 10, 2020 at 11:40 AM Mirja Kuehlewind = wrote: > Hi Vijay, >=20 > Thanks for moving this discussion forward. >=20 > Dear Mirja: Thank you for your time and your comments. More inline.=20= > =20 > To focus on the formal bits for a second: RFC7942 doesn=E2=80=99t = actually require that the section is removed. This says "Authors are = requested to=E2=80=9D but I guess it=E2=80=99s for the authors/wg to = decide. Also this is an IETF-consensus document which I think was = AD-sponsored. So the way to update it is =E2=80=9Csimply=E2=80=9D to = write a bis-draft and bring it to gendisptach these days. >=20 > I agree that RFC 7942 only "requests" not "mandates" that the section = be removed. However, the practical effect of this request is that most = authors will simply ask for the section to be removed. That was the = case in a particular draft that I was reviewing for Gen-Art (which = actually resulted in the thread I opened up on the WG Chairs list). = Furthermore, to be frank, before I reviwed the draft in question for = Gen-ART, I was not even aware of RFC 7942. Certainly, it is fairly new = (having been minted in 2016), but none of the I-Ds or RFCs I have read = post-2016 even mention an Implementation Status section. =20 >=20 > It certainly does not portend well that we are not eating our own dog = food. I looked at two active WGs --- quic and httpbis --- to see if an = RFC 7942 section is present in any of the active I-Ds. Of the 24 I-Ds = in these groups, I could not find such a section [1]. Apologies, I am = not picking on these groups, just trying to get some objective data = points by looking at a couple of active WGs. The irony is that the base = protocol document for QUIC [2] has a "Note to Readers" section that = provides the very information --- where to find the GitHub repository = --- that we are seeking to institutionalise. I am not sure what will = happen to this note when QUIC becomes an RFC. > =20 > More to the actually point: I understand your motivation about people = only knowing RFCs but none of the IETF process but I=E2=80=99m not sure = putting this information in an RFC is the right tool. I bed it=E2=80=99s = actually not very hard to find some suitable code on GitHub these days, = especially as you said if this is about larger projects (which in the = best case are actively maintained). For smaller code snippets we often = put pseudo code in the document of appendix. So that=E2=80=99s another = option. >=20 > I understand and respect your view that putting this information in an = RFC is not the right thing to do. I am trying to convince you that it = is, and I hope that I succeed in some measure. =20 >=20 > The proposal we are considering --- i.e., putting some text in RFCs to = guide legions of implementers not familiar with "IETF arcana" --- is = already being used loosely as I pointed out above for QUIC. It seems to = me that we can do better by institutionalising it in some manner that = RFC 7942 did not. Perhaps as you suggest, the answer is to simply write = a RFC 7942-bis draft. If you think this is an avenue we should explore, = I am happy to spin up a rfc7942-bis so to provide more structure to the = conversation. >=20 > [1] I will like to point out that of the 24 I-Ds, not all deal with = specific protocol/algorithmic issues, so please account for that = reality.=20 > [2] https://www.ietf.org/id/draft-ietf-quic-transport-30.txt >=20 > Thanks, >=20 > - vijay > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm From nobody Thu Sep 10 11:50: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 7DD863A0F85 for ; Thu, 10 Sep 2020 11:49:57 -0700 (PDT) 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 lyGyTKU1UO1M for ; Thu, 10 Sep 2020 11:49:55 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 5FF063A0F69 for ; Thu, 10 Sep 2020 11:49:52 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id gr14so10297496ejb.1 for ; Thu, 10 Sep 2020 11:49:52 -0700 (PDT) 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=SBpaAEfvJY2XhjWd/S5zCPGeebiFI5ZoM+83To1Ow5Y=; b=lHWatTdAZjVXk/e/RPKmAeT7cOC7Tp6l4js3i1IWsIPgUz4Ova6JGVi5/o0QWQQg+Y zEnzNtlRHENIe8YbWiJv/UDqtgR8afTnPAwd9VRCcEPEmYxllV/3UZkxRdvT5hei442a rsILV4E0LNKbfoDk9vj7jPaoajcSpe7KqSfox3MeaIAnW9vMyoR+IGA4gl4YXnbqR6I/ fK8A5+p0pLrFVUgVa6Y71DfjcTNOXFmapPjXTfl+XtWJrd/mjZuRfVcnFvNnby9vGrXI 5s5BMQ8Qo09j4NxmbP9hMjWTE9wAVmruBKBct/MyC6BYBDbAJUe3J9EH1ev5/IEOkjJn 1ocA== 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=SBpaAEfvJY2XhjWd/S5zCPGeebiFI5ZoM+83To1Ow5Y=; b=PgV2nW+NBHaU992+MlSsynyrHjFmIb1nVum1JXNUhs6/iNnlZZj/tRrPrjBXHml70H esXrHM2mV4DKaQPsUTp7zTPuK5lJlPGs3LhXzHz/pz5oZr3tlKe3lEnE/E0FYDVeAW5t C8RFMD0ZPcoMxbk+JAeM3JIyJXOyeGRpRT9h8GGD6Tl3w4Kbiu9LDk57UxiCH3Zgt/pS e/kOntQsmWsYfrPyg50CHaqz6+kUkTA5+ao9XenaqrtwUKwSvLTOJ4Sx7uQK67zmolM5 hzfv9Q9rZoNrRAyNSMIrHtglzPN9F2rFNvkDxNSgKFiHgV/iFYpvOLqB91DohKq6mpc6 3rTw== X-Gm-Message-State: AOAM531uHjXBlqUKx88qXvlxkb6EA2gYl70bVLXoxt/0t1sqSOi34A/w 2T2ATJFhaaixHClsWgQwTWb4sUVyWE9sF3IsobY= X-Google-Smtp-Source: ABdhPJxJJe6pNXoFNZ5WYvXzbVIlkfL819z1S7idD+/VdPgvYykXv1AINoKu4NEjhwlNE+imEp7Cj4ZOtXB/ZwEQx/8= X-Received: by 2002:a17:906:edc4:: with SMTP id sb4mr10149542ejb.144.1599763790922; Thu, 10 Sep 2020 11:49:50 -0700 (PDT) MIME-Version: 1.0 References: <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> <68D31D1A-334A-4577-AB93-37D4DD5B369B@kuehlewind.net> In-Reply-To: <68D31D1A-334A-4577-AB93-37D4DD5B369B@kuehlewind.net> From: Vijay Gurbani Date: Thu, 10 Sep 2020 13:49:30 -0500 Message-ID: To: Mirja Kuehlewind Cc: edm@iab.org, Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="0000000000007b870e05aefa0899" Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 10 Sep 2020 18:50:01 -0000 --0000000000007b870e05aefa0899 Content-Type: text/plain; charset="UTF-8" Dear Mirja: Thanks for your time. More inline. On Thu, Sep 10, 2020 at 1:33 PM Mirja Kuehlewind wrote: > Just very quickly some points. Having read all RFCs that we have published > in the four years of my AD time I can tell you that RFC7942 is used form > time to time. However, it also addresses a different problem then what you > ask for, namely how do people in the wg know about existing > implementations. OK, it is good to know that we are eating our own dog food, albeit in small portions. If RFC7942 is in the ballpark, but addresses a slightly different problem, then perhaps we can see what can be salvaged by an rfc7942-bis. The problem of people in the WG knowing about existing implementations is (I believe) easily solved by anyone participating in a WG meeting (or list), most should quickly pick up where the most promising implementations are. The bigger problem is what about others that do not participate in the WG deliberations, and more importantly, how to highlight implementations that tracked the I-D to when it became an RFC, but all of a sudden, in the post RFC world, there is no clear path for newcomers on how to find the code. QUIC decides to use another tool for this purpose; I guess for several > reason, one being that many implementors in QUIC who have been new to the > IETF are actually more familiar with GitHub than any IETF procedures. Right, and the fact that QUIC put this GitHub URL in the I-D itself underscores my point on why it is important to maintain such links to help non-IETF implementers by providing them information in the RFC itself. Especially after the I-D becomes an RFC. > My expectation is that note you mentioned for QUIC will be removed before > publication as RFC. > That would be a tremendous loss of information for the non-IETF development community. I am sure some will stumble on the QUIC GitHub, and I am equally sure that many will not. I am arguing to make such an informal tie-in more explicit and institutionalized. Thanks, - vijay --0000000000007b870e05aefa0899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Mirja: Thanks for your time.=C2=A0 More inline.<= br>

On Thu, Sep 10, 2020 at 1:33 PM Mi= rja Kuehlewind <ietf@kuehlewind.n= et> wrote:
Just very quickly some points. Having read all= RFCs that we have published in the four years of my AD time I can tell you= that RFC7942 is used form time to time. However, it also addresses a diffe= rent problem then what you ask for, namely how do people in the wg know abo= ut existing implementations.

OK, it is goo= d to know that we are eating our own dog food, albeit in small portions.=C2= =A0 If RFC7942 is in the ballpark, but addresses a slightly different probl= em, then perhaps we can see what can be salvaged by an rfc7942-bis.=C2=A0 T= he problem of people in the WG knowing about existing implementations is (I= believe) easily solved by anyone participating in a WG meeting (or list), = most should quickly pick up where the most promising implementations are.= =C2=A0 The bigger problem is what about others that do not participate in t= he WG deliberations, and more importantly, how to highlight implementations= that tracked the I-D to when it became an RFC, but all of a sudden, in the= post RFC world, there is no clear path for newcomers on how to find the co= de.

QUIC decides to use another tool for this purpose; I guess for several r= eason, one being that many implementors in QUIC who have been new to the IE= TF are actually more familiar with GitHub than any IETF procedures.

Right, and the fact that QUIC put this GitHub URL= in the I-D itself underscores my point on why it is important to maintain = such links to help non-IETF implementers by providing them information in = the RFC itself.=C2=A0 Especially after the I-D becomes an RFC.
=C2=A0
My expectat= ion is that note you mentioned for QUIC will be removed before publication = as RFC.

That would be a tremendous loss= of information for the non-IETF development community.=C2=A0 I am sure som= e will stumble on the QUIC GitHub, and I am equally sure that many will not= .=C2=A0 I am arguing to make such an informal tie-in more explicit and ins= titutionalized.

Thanks,

- vijay
--0000000000007b870e05aefa0899-- From nobody Thu Sep 10 13:45: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 9DC123A0E04 for ; Thu, 10 Sep 2020 13:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 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, NICE_REPLY_A=-0.948, 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 GdsF37q7kz3s for ; Thu, 10 Sep 2020 13:44:59 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 652303A0E03 for ; Thu, 10 Sep 2020 13:44:59 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id gf14so605728pjb.5 for ; Thu, 10 Sep 2020 13:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=DyEIBG1fZgU278IgejMaa63hlFisC+u5byE1PZsHWC0=; b=RIHhDv0Z2Io1LJT4tWBnqfjCz3Rwuo2tIDhgQFZUlTQAq7Hv4GiIbA11dMXRUeA5rt 9anfamAA8xb/gdLBqz+CgjVUdOZ1UJHCyVFb7MfhkJG6AdrbVVqR6cYCtcC01Um9vu8/ wVa/uQNfM/x8u4Mvlk5gN/QXKtjCq4aOGHE9koSK0Wxcuu6wIuW3XxztucaGWoV2Kn0L aQ0rs/kPaDMJRUiRa6fAHBfISGP2JcFl9w5NZLO+ZhjJOKiMaOYdnnYnIXp0mlKbILAK vaGQUBFApJzSpI17C1yThR107c54ZzxEi3+ZJ7fIYYm1bqkehLhxhIwdflCjEH5IdsDU C4Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DyEIBG1fZgU278IgejMaa63hlFisC+u5byE1PZsHWC0=; b=QvvmQFpl4glqtzoJ0d0AKW1tdo/f3oW4oyN4rZ/FPvLgahTCeUIJIaffuwo8cadEoV OP340GdZZQR7wUJArqahQmeQtRr3hAXyBpZXjrSCFfsHglv07gOz0B+7n4QSe+qu5rm2 F6JPAeEJinMGZ/NZD6RMtPDKNc3MJkiEgJI5plZdYA2Q7oCZztjwu3O0Ds5HDyJN7m19 wHIZY1reIw6mbZqSgZC0BnIW2k8hneQSDwKUdTVqN02ykjluXvn9i4TggwvraeLSomQ3 ri+i3yGL11dwHm0HS2VqSXIcBB5U7Xn63BL1EWZLuWKZh5atxm/2YZ32j0HeMEOusRVL ObCA== X-Gm-Message-State: AOAM530OKBX+k6NGmydWDn+WnwQDMFSloVpPPkGtI6E3tP4kbuSGxV0k hEovDbP8P4wb+YoyeORYD4tkGcDHr+0= X-Google-Smtp-Source: ABdhPJy88Ucp3vCmyXVAiyNyJYaSsyJltbfzff8qFd8fEPGKjCWbbDdiOCtXG4/UGjT2HO4TC5vR2Q== X-Received: by 2002:a17:90a:ca17:: with SMTP id x23mr1589830pjt.96.1599770698346; Thu, 10 Sep 2020 13:44:58 -0700 (PDT) Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id x5sm5828244pgf.65.2020.09.10.13.44.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Sep 2020 13:44:57 -0700 (PDT) To: edm@iab.org References: <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> <68D31D1A-334A-4577-AB93-37D4DD5B369B@kuehlewind.net> From: Brian E Carpenter Message-ID: <667ebc5c-7c85-a024-7cab-23b2b83862f3@gmail.com> Date: Fri, 11 Sep 2020 08:44:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 10 Sep 2020 20:45:01 -0000 Hi, I too think that RFC7942 is sadly under-used; it's very rare that I see i= t during Gen-ART reviews and I would like to see more. I have used it myself in a = few drafts. However, I think it would be a serious mistake to include such informatio= n in RFCs. RFCs are archival documents with an infinite lifetime. Do we rea= lly want them to contain URLs for GitHub repositories of prototype implementa= tions? Or what amounts to advertising for specific products? Should RFC 2460 inc= lude a pointer to the first commercial IPv6 implementation (IBM AIX 4.3)? A dogfood wiki on the IETF site would be the best place for an ongoing (b= ut surely not permanent) record of implementations, IMHO. Regards Brian Carpenter On 11-Sep-20 06:49, Vijay Gurbani wrote: > Dear Mirja: Thanks for your time.=C2=A0 More inline. >=20 > On Thu, Sep 10, 2020 at 1:33 PM Mirja Kuehlewind > wrote: >=20 > Just very quickly some points. Having read all RFCs that we have pu= blished in the four years of my AD time I can tell you that RFC7942 is us= ed form time to time. However, it also addresses a different problem then= what you ask for, namely how do people in the wg know about existing imp= lementations.=20 >=20 >=20 > OK, it is good to know that we are eating our own dog food, albeit in s= mall portions.=C2=A0 If RFC7942 is in the ballpark, but addresses a sligh= tly different problem, then perhaps we can see what can be salvaged by an= rfc7942-bis.=C2=A0 The problem of people in the WG knowing about existin= g implementations is (I believe) easily solved by anyone participating in= a WG meeting (or list), most should quickly pick up where the most promi= sing implementations are.=C2=A0 The bigger problem is what about others t= hat do not participate in the WG deliberations, and more importantly, how= to highlight implementations that tracked the I-D to when it became an R= FC, but all of a sudden, in the post RFC world, there is no clear path fo= r newcomers on how to find the code. >=20 > QUIC decides to use another tool for this purpose; I guess for seve= ral reason, one being that many implementors in QUIC who have been new to= the IETF are actually more familiar with GitHub than any IETF procedures= =2E=20 >=20 >=20 > Right, and the fact that QUIC put this GitHub URL in the I-D itself und= erscores my point on why it is important to maintain such links to help n= on-IETF implementers by providing them information in the RFC itself.=C2=A0= Especially after the I-D becomes an RFC. > =C2=A0 >=20 > My expectation is that note you mentioned for QUIC will be removed = before publication as RFC. >=20 >=20 > That would be a tremendous loss of information for the non-IETF develop= ment community.=C2=A0 I am sure some will stumble on the QUIC GitHub, and= I am equally sure that many will not.=C2=A0 I am arguing to make such an= informal tie-in more explicit and institutionalized. >=20 > Thanks, >=20 > - vijay >=20 From nobody Thu Sep 10 14:24:41 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 0224B3A08D4 for ; Thu, 10 Sep 2020 14:24:40 -0700 (PDT) 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, 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] 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 LdaXaycR1AQO for ; Thu, 10 Sep 2020 14:24:37 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 F10333A0823 for ; Thu, 10 Sep 2020 14:24:36 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id ay8so7821823edb.8 for ; Thu, 10 Sep 2020 14:24:36 -0700 (PDT) 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=QPfLQHBQAoWhKHIYXjyvxEd8a6qKBLzkzmU3Ir7pUHQ=; b=tI0AGXKbvK82NOOUPYf86+5xjJOmUK0DtqdcLEhG0bWHtfZAvybMFiJi/2mGvuFt5/ dFy1LkCBIFtGfU4/Tjx4J/eGsJT49K0PzPJ3Slr7KlUlHXMCcedZ7H/XqrFpnGfvKwsV BgKaG116WAXbgnN5Kcf0yImeqXlL02xzZl3YFPbFvwNIo7THySVptDju+BuMQx5djaeK JQ+pSUjfKMafbEVylDSdcY/pTA7GMpSBAK7MjOUHTo3ouOJhr4+0poetWmKCQoX0fHvs cj9Il0T0Zzt4f8t9oqFoTQrVv6ba98IsRxibrvIH6pqFVnSQCWZjUJJ/hPxkVKqDGeR2 l9OA== 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=QPfLQHBQAoWhKHIYXjyvxEd8a6qKBLzkzmU3Ir7pUHQ=; b=TbRd0xUl/nuYkMB1NvJvskbHW4W6pc34Ys7n6TH3nRIC7CxCkOd7LWb9hjmjmSl01u dhva9R1cZ1NjaTJftuoAPHbEEZimLZH0UNpUPq7Heoqh9NI299Qh9KXLFN+IZoVcBexL vvhAt/XhOFOz9NT5dIkObl/vzwu48Y+1R6EXTWhuCMp5OxRm+QAsGAG+NIPPD9PXcWgu gEFDhZDlWlrcRkqCQEMuDyJw4iiwaNdenLhEcjaGbxtExqm05R+hubYZwVdbFtGp6adx ooiFXsTRqTjOcePIplWdI6O+lr/8XbXOn5EETeuEYq7jIk7dfs5vhAdH3KF/AwWCtfct KMJw== X-Gm-Message-State: AOAM53207sGyN5KZ6kN9PDQcHs3LETrDTuXldJwIDtbgC123YNkz7uzx lXgjytXZ1EDIgZFh2Wu0omyg4Ap6fPQtFFrClZM= X-Google-Smtp-Source: ABdhPJz7xXz4aWpnYXe32/oMfU0IUNDe+0U/qN0Q2dtybGE7zeD2QGuBjCozYQ4YkmdbMd2q4R0hGho7hQqdhMfxZ8Q= X-Received: by 2002:a50:e80a:: with SMTP id e10mr11613540edn.4.1599773075390; Thu, 10 Sep 2020 14:24:35 -0700 (PDT) MIME-Version: 1.0 References: <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> <68D31D1A-334A-4577-AB93-37D4DD5B369B@kuehlewind.net> <667ebc5c-7c85-a024-7cab-23b2b83862f3@gmail.com> In-Reply-To: <667ebc5c-7c85-a024-7cab-23b2b83862f3@gmail.com> From: Vijay Gurbani Date: Thu, 10 Sep 2020 16:24:14 -0500 Message-ID: To: Brian E Carpenter Cc: edm@iab.org Content-Type: multipart/alternative; boundary="000000000000e1463405aefc3131" Archived-At: Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1 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, 10 Sep 2020 21:24:40 -0000 --000000000000e1463405aefc3131 Content-Type: text/plain; charset="UTF-8" Dear Brian: Thank you for your comments! Having co-authored one RFC with you, I value your experience and judgment. Please see inline. On Thu, Sep 10, 2020 at 3:45 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > I too think that RFC7942 is sadly under-used; it's very rare that I see it > during Gen-ART reviews and I would like to see more. I have used it myself > in a few drafts. > > However, I think it would be a serious mistake to include such information > in RFCs. RFCs are archival documents with an infinite lifetime. Do we > really want them to contain URLs for GitHub repositories of prototype > implementations? > Indeed, RFCs are archival documents with an infinite lifetime, but RFCs are also scientific documents, and as any scientific document, sometimes their content is absolute (Shannon's "Mathematical Theory of Communications" paper, for instance), and sometimes their content can be updated (the hundreds of documents the scientific community is producing now on Covid-19). IEEE and ACM are encouraging scientific papers to contain links to datasets and experiments that are hosted for archival by these institutions. Why can't we? In the extreme case, if you read a peer-reviewed scientific publication in a top quality journal and click on an expired link in that journal, the act of not finding the contents at the end of the link likely should not invalidate the entire research. I think that we are doing a disservice to the future readers (and implementers) of RFCs by assuming that they will not pay attention to the "caveat emptor" text associated with any GitHub repositories, especially if these warnings are in a section that screams that the contents of the GitHub repository were current as of the publication date of this RFC and that no endorsement of the GitHub repository is made by the IETF beyond the publication date of the RFC. I really see no harm, I see a lot of benefit. Or what amounts to advertising for specific products? Should RFC 2460 > include a pointer to the first commercial IPv6 implementation (IBM AIX 4.3)? > These are good questions; they have answers that would require us to come to consensus on. I will certainly give you my answer to this and hope that it changes your mind, or if not, at least incentivize you to explore the issue from a different angle. In my association with the IETF, I have come to appreciate the communal way in which we develop our protocols. This is inspite of the fact that each one of us --- at least a majority --- work for corporations that fund us to attend the meetings and conduct the work. If because of this prevelant communal zeitgeist in the IETF, we don't have a "Company-X version of Procol P", or a "Company-Y version of Protocol P", why do we assume the community will tacitly endorse implementations that amount to advertising for specific products? Surely, we have come beyond that, no? We have guardrails in place (WG chairs, AD, IESG, perhaps ISOC and IAB) to make sure that this does not happen. So what are we reticient about? Regarding whether RFC 2460 should have included a pointer to the first commercial implementation of IPv6 from IBM, well sure, with a constraint: as long as IBM was willing to make the code available openly (as happens in GitHubs now), and allows others to experiment with it and make it better, I don't see the harm. Of course, if IBM was not willing to make the code available publicly, then this line of thinking is moot. Thank you much! Cheers, - vijay --000000000000e1463405aefc3131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Brian: Thank you for your comments!=C2=A0 Having= co-authored one RFC with you, I value your experience and judgment.
<= div>
Please see inline.

On Thu, Sep 10, 2020 at 3:45 PM Br= ian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,

I too think that RFC7942 is sadly under-used; it's very rare that I see= it during Gen-ART reviews and I would like to see more. I have used it mys= elf in a few drafts.

However, I think it would be a serious mistake to include such information = in RFCs. RFCs are archival documents with an infinite lifetime. Do we reall= y want them to contain URLs for GitHub repositories of prototype implementa= tions?

Indeed, RFCs are archival docume= nts with an infinite lifetime, but RFCs are also scientific documents, and = as any scientific document, sometimes their content is absolute (Shannon= 9;s "Mathematical Theory of Communications" paper, for instance),= and sometimes their content can be updated (the hundreds of documents the = scientific community is producing now on Covid-19).=C2=A0 IEEE and ACM are = encouraging scientific papers to contain links to datasets and experiments = that are hosted for archival by these institutions.=C2=A0 Why can't we?=

In the extreme case, if you read a peer-revi= ewed scientific publication in a top quality journal and click on an expire= d link in that journal, the act of not finding the contents at the end of t= he link likely should not invalidate the entire research. I think that we a= re doing a disservice to the future readers (and implementers) of RFCs by a= ssuming that they will not pay attention to the "caveat emptor" t= ext associated with any GitHub repositories, especially if these warnings a= re in a section that screams that the contents of the GitHub repository wer= e current as of the publication date of this RFC and that no endorsement of= the GitHub repository is made by the IETF beyond the publication date of t= he RFC.=C2=A0 I really see no harm, I see a lot of benefit.
<= br>
Or what amounts to advertising for specific products? Should RFC 2460 inclu= de a pointer to the first commercial IPv6 implementation (IBM AIX 4.3)?
=

These are good questions; they have answer= s that would require us to come to consensus on.=C2=A0 I will certainly giv= e you my answer to this and hope that it changes your mind, or if not, at l= east incentivize you to explore the issue from a different angle.=C2=A0 In = my association with the IETF, I have come to appreciate the communal way in= which we develop our protocols.=C2=A0 This is inspite of the fact that eac= h one of us --- at least a majority --- work for corporations that fund us = to attend the meetings and conduct the work.=C2=A0 If because of this preve= lant communal zeitgeist in the IETF, we don't have a "Company-X ve= rsion of Procol P", or a "Company-Y version of Protocol P", = why do we assume the community will tacitly endorse implementations that am= ount to advertising for specific products?=C2=A0 Surely, we have come beyon= d that, no?=C2=A0 We have guardrails in place (WG chairs, AD, IESG, perhaps= ISOC and IAB) to make sure that this does not happen.=C2=A0 So what are we= reticient about?

Regarding whether RFC 2460 s= hould have included a pointer to the first commercial implementation of IPv= 6 from IBM, well sure, with a constraint:=C2=A0 as long as IBM was willing = to make the code available openly (as happens in GitHubs now), and allows o= thers to experiment with it and make it better, I don't see the harm.= =C2=A0 Of course, if IBM was not willing to make the code available publicl= y, then this line of thinking is moot.

Thank y= ou much!

Cheers,

- vijay<= br>
--000000000000e1463405aefc3131-- From nobody Sun Sep 13 00:41:28 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 2B7A83A0A1D for ; Sun, 13 Sep 2020 00:41:23 -0700 (PDT) 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, 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=mnot.net header.b=ewNHHttt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SzGXekKS 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 zh0GuvgNlz8p for ; Sun, 13 Sep 2020 00:41:21 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667233A0A22 for ; Sun, 13 Sep 2020 00:41:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3D1D15C00A2 for ; Sun, 13 Sep 2020 03:33:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 13 Sep 2020 03:33:00 -0400 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= fm3; bh=2vfb/3dBMNnwy4D7qazgmkx09c9Lo+ulHcLVurq31oM=; b=ewNHHttt snHZ1IKv9MIrM+HHQ7SMt+bg2yzU0zVRHSVvFlVWuVAMYxcpEOT1xHm5Cn+mFs1x qYfD/wNEh7ygFTPxsrkZtnJOtnm//aqNV727e/l3GwIVYUajOKqN9VLwirW1N+S8 lGdlEKIEStbNwWeA71B9Lek36ALWDjTOfVCZgk5bWe7iZiJe5Dr3rRa/GliGJDfY uPwscPg1eR9o+CAfHL8wNWWmM7JvDIBI5632rUseBtqFyYjjzg5Q3jhmNmbxfjlb Jp4/kxOPrSMi7zy52JpiJ/yds4VYofE91u8jeni3zDSi77RQ8b/amPyhrbfeCX0H 4HAhV5BNoedKJA== 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=fm3; bh=2vfb/3dBMNnwy4D7qazgmkx09c9Lo +ulHcLVurq31oM=; b=SzGXekKSGSX/j1iHrJEKs0NvGNy/quziNXu+KVgTcuw9o XtkJHfitGFUUkBvPbmdubAesAl/Faa+ULem30N4/itmSgHPN6qQlIKvJzwpHHXTn CWB4U3V2UAtaT3EdOxdAJPlSMOUWI/1cM/kPrv8sGoKXBOb3VQRAgaz0iY78T9q4 ULylOzCgp+TL2bQfauLdcmLiDSNe2T3GrBrmAjHna6ANc3C9iWTQNEZbEVlsvILn sdPREbzihIQwunXbeVzajwfsUAeY97l0rxouTfqL0bhwZg/yvf1QyHrRTkLJxx13 CWE4tWKIUCX2jcJ371LhhE4cT2s9NzPaj/+Lb4gYQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeivddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvdehhedrudegvd drvdefieenucevlhhushhtvghrufhiiigvpeehnecurfgrrhgrmhepmhgrihhlfhhrohhm peguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az52.internal.cloudapp.net (unknown [52.255.142.236]) by mail.messagingengine.com (Postfix) with ESMTPA id CF77D3280060 for ; Sun, 13 Sep 2020 03:32:59 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6317510690590568639==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: edm@iab.org Message-Id: <20200913073259.CF77D3280060@mailuser.nyi.internal> Date: Sun, 13 Sep 2020 03:32:59 -0400 (EDT) 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, 13 Sep 2020 07:41:23 -0000 --===============6317510690590568639== 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=AC3) 1 issues created: - Some implementation architectures favour extensibility (by obonaventure) https://github.com/intarchboard/edm/issues/6=20 2 issues received 3 new comments: - #5 How to organise inter-op testing (1 by obonaventure) https://github.com/intarchboard/edm/issues/5 [deployability]=20 - #3 What extension mechanisms are successful? (2 by obonaventure) https://github.com/intarchboard/edm/issues/3 [evolvability]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/edm --===============6317510690590568639== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (EDM Activity Summary)

Sunday September 13, 2020

Issues

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

1 issues created:

2 issues received 3 new comments:

Repositories tracked by this digest:

--===============6317510690590568639==--