From nobody Fri Jun 1 15:59:48 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AD612E037 for ; Fri, 1 Jun 2018 15:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CQm4jAXGZUuM for ; Fri, 1 Jun 2018 15:59:45 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 F34C912DB72 for ; Fri, 1 Jun 2018 15:59:41 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id x2-v6so4952303wmh.5 for ; Fri, 01 Jun 2018 15:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=wsB4Xwv7JerPPiT4+O8y1NSdCUU/WOPXm5b9bRyRwA4=; b=ATb7pz4FMADbEgMqsrDXB8cG++lU6Z4gGm46jGrHmE2P8mOW5kMqCa3UuHzpzUa71C aNzpx854KcIc/D7HDxVA7fcPkX7KiMFMx9kMX0A1cDzm8MSH58AaEI1BDBKBHVi0HU4H KnTPOyzRuBElD4F5tmFsVLbPnLerrNnRmR/6N8DV/3BORvst+GhjZWYDWVmXRwsiBpro rnS3FLoUhM12dpUp+H5Kej5VaWa3cUFExyvEOOyVrKxZpDo+fqbgzoO6whNMTzaE5bng qMYp+LwDBIUxtnd/huNE6j141n0MfL1PLJo0tZp0mYX6YwBzfHe7WhTdsMA6gLfl5QO+ OzsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=wsB4Xwv7JerPPiT4+O8y1NSdCUU/WOPXm5b9bRyRwA4=; b=O5jZKxy8tBtaevtwN/Opx9eeudsS/W6zrsG6qWTa19xF1UnFCU60X+Y6dpw6EJfh2C F4LMFjmqiS/yi7xi685UVjuPPCsK/R0iJYnqQ3+oVUnEFqCDhHxXgWkdpbKoOqRtC8jT HRsNOI5iBs2/9KxYWePKk0jzNAi97xDHEqH2db79b6b1gvSaJTy9r/IEb58bB7xgGrFt IdzouA8rykZ3PEhlO8BJ6NEqK1AZGnGv/vOumpqOn2/osO8HBrKPg73cqhBWhgRhJoGJ 3jFTnmep8x3nT7+Dj7b1XAaBvXmNT6mbu2O1VpP5V09IGwpVxcIABWKKbxn9JS+y/e8c zhxQ== X-Gm-Message-State: APt69E3sxb7YjAq10JBlZShWD4MZ6HIukJaq+8A7faE+ZDiDZoIV/lTY 0l5oMMT258cAhD9GKHYA2VmPexAa X-Google-Smtp-Source: ADUXVKLI2JQkj3ZCTkKnkN+cJMkQz1UF+65HuPzcTWRvLBXy2qzs5J8vnrKqSSmGR/rH8IRO8UuKHA== X-Received: by 2002:a1c:d7c3:: with SMTP id o186-v6mr3685302wmg.67.1527893979350; Fri, 01 Jun 2018 15:59:39 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:f3a:59be:3d00:49c7:7b04? ([2601:647:4d01:f3a:59be:3d00:49c7:7b04]) by smtp.gmail.com with ESMTPSA id c11-v6sm18158364wri.49.2018.06.01.15.59.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 15:59:38 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_D0223378-A60F-4A2F-83BE-8E8035B44A61"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 1 Jun 2018 15:59:35 -0700 Cc: Bob Hinden To: rfcplusplus@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Rfcplusplus] Comments on "The label "RFC" (RFC++) BOF X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 22:59:47 -0000 --Apple-Mail=_D0223378-A60F-4A2F-83BE-8E8035B44A61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I do not support what is being proposed in this BOF. I have a number = of issues with the proposal. The problem the BOF says it is addressing, namely that not all RFCs are = IETF created Standards caused confusion. I note that some very basic = Internet protocols like RFC791, RFC792, and RFC793 that are essential = for the Internet are not IETF standards as they were published prior to = the IETF being created. When the IETF decided to use the RFC series it = made an active decision to do this knowing that not all RFCs were IETF = Standards. The "regrettably well spread misconception=E2=80=9D is something we are = all aware of, but is not something that can be measured. It is = anecdotal and can=E2=80=99t be measured. Other than saying "regrettably = well spread misconception=E2=80=9D, is there any data that this causes a = serious problem that is worth fixing? Especially since there have been = about 7300 RFCs published since the IETF was created. It=E2=80=99s hard = to fix the past. The notion of an experiment where there is not a clear criteria for = measuring the result (for example, how do you measure there is less = =E2=80=9Cmisconception=E2=80=9D) and proposing that the experiment runs = for three years would appear to have the result of making the change = permanent. Essentially not have an experiment at all. This seems to me = to be disingenuous. Is is not correct to call =E2=80=9CRFC=E2=80=9D a label. It=E2=80=99s = not a label, it=E2=80=99s the name of the series. There isn=E2=80=99t a = series with several labels. There is only the RFC Series. We have an = RFC Series Editor, RFC Series Production Center, and a number of RFC = defining what the series is. None of this calls it a label. This proposal also seem to me to have it backwards. Instead of making = changes to the IETF Stream, it proposes that all of the other streams = have to change. I think it would be better to make changes in the IETF = Stream to make it clearer that a specific RFC is an IETF Standard. = Several things come to mind. The header on the document could have in = large letters that clearly indicate that the RFC is an IETF Standard. = Perhaps even adding something in the header like: ***************************************** ***************************************** ****** ****** ****** IETF Standard ****** ****** ****** ***************************************** ***************************************** I suspect we could do something nicer once the new format work is = completed, like adding an image of an IETF Logo. The places where RFCs are searched for (ietf.org, rfc-editor.org, = datatracker.ietf.org, etc.) could display that an RFC is an IETF = Standard in clearer ways. Only the .txt version can=E2=80=99t change, = the pdf and html that are probably used the most these could make the = status clearer. I also think that the ambiguity between what is an IETF Standard and = what is not an IETF Standard has served the Internet well. Vendors, = operators, researchers, and individuals get benefit from this ambiguity. = Even the IETF Stream that publishes documents that are not IETF = Standards like BCP, Experimental, and Informational takes advantage of = this ambiguity. Perhaps this is a feature and not a problem. Lastly, I think this experiment will do harm. Besides harming the other = Streams that will no longer be able to use RFC series, the creation of = new series other than the RFC series will create even more confusion = over what is an IETF Standard. RFCs produced earlier before the split = happens, will now effectively all become IETF Standards. I think this = proposal will have exactly the opposite effect as was intended. Bob --Apple-Mail=_D0223378-A60F-4A2F-83BE-8E8035B44A61 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlsRz9cACgkQrut0EXfn u6jd/ggAuOw8tW1qCQMfGHQsn5BbB7vFbcCyBfxmcbvZmzTPg0Lw03uR7bSSqQtH UORAEvk5kEk9g5HVbl2xNclityPkLdHRti6oZKo8I1M2j4pqQM8YQz4Qgx9k/azB z4TD0odht540/A76k2WVT3sVYJHKw4Do+jz7u0dLTArGVNvIDkcrKmTPl87jWFLn iVY1zDe7idsQa+zhAE1gtOFAUwS9pjvlz3ylSRggf4BWaIAmXCAFoocbwDqeukRq 2CK+bsegL906uhmIF6AOl+WAli4x+b5hpZf/1OuMJVyixfBwqdXkc0jZousT8A9X 6YRvOLrS9hqyWizZ3sP/pzuU94Duiw== =xP+e -----END PGP SIGNATURE----- --Apple-Mail=_D0223378-A60F-4A2F-83BE-8E8035B44A61-- From nobody Tue Jun 5 10:07:21 2018 Return-Path: X-Original-To: rfcplusplus@ietf.org Delivered-To: rfcplusplus@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2E51310D3; Tue, 5 Jun 2018 08:55:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" Cc: martin.thomson@gmail.com, melinda.shore@gmail.com, alissa@cooperw.in, rfcplusplus@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <152821411221.19093.12542137047293021207.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2018 08:55:12 -0700 Archived-At: X-Mailman-Approved-At: Tue, 05 Jun 2018 10:07:20 -0700 Subject: [Rfcplusplus] New Non-WG Mailing List: rfcplusplus@ietf.org X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:55:13 -0000 A new IETF non-working group email list has been created. List address: rfcplusplus@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/rfcplusplus/ To subscribe: https://www.ietf.org/mailman/listinfo/rfcplusplus Purpose: For discussion of the RFC++ BoF proposal and related ideas. For additional information, please contact the list administrators. From nobody Tue Jun 5 10:07:26 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3680013110C for ; Tue, 5 Jun 2018 09:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eYXyzalQI37u for ; Tue, 5 Jun 2018 09:40:10 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 1207312D949 for ; Tue, 5 Jun 2018 09:40:10 -0700 (PDT) Received: from [10.32.60.76] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w55Gd95x092380 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 Jun 2018 09:39:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.76] From: "Paul Hoffman" To: rfcplusplus@ietf.org Date: Tue, 05 Jun 2018 09:40:07 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <2F3C548C-665A-4A0C-BCCA-4A217644B7EA@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: X-Mailman-Approved-At: Tue, 05 Jun 2018 10:07:20 -0700 Subject: Re: [Rfcplusplus] Comments on "The label "RFC" (RFC++) BOF X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 16:40:12 -0000 On 1 Jun 2018, at 15:59, Bob Hinden wrote: > I do not support what is being proposed in this BOF. I have a number > of issues with the proposal. +1 to (literally) every paragraph of Bob's message. It is easy to demonstrate that some people are confused about not all RFCs being standards. Each time this problem comes up, we ask "and what tangible damage has come of that conclusion" and I have yet to hear of a single credible instance that would mean much. In order to justify the harm to the IAB, IRTF, and ISE streams, we would need to see a reasonable set of such instances. --Paul Hoffman From nobody Tue Jun 5 11:12:25 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4D12F1AC for ; Tue, 5 Jun 2018 11:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZVw7NMYDIPWI for ; Tue, 5 Jun 2018 11:12:21 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 219A2126F72 for ; Tue, 5 Jun 2018 11:12:21 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id q13-v6so3447131qtp.4 for ; Tue, 05 Jun 2018 11:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=MqH4XScWJ/P0aVfTmXH/Gki3x0vzAERDHhHciJEUO6Y=; b=dIJExi0+UIMtUGME3rx4+AX9yI+d6dSSTQbUDSXuPPmq9WHCmKRyDV3IEtNjF30FKX bA+1Cpiykiva1MkiirQIHKlh+mBBRXbqHU5fHD1htOuKVNYnu4Zm0BVv8/vq5gvzIifB xnwWsVMsgRomnQhJEMPUQgVjM6xfMz2PmM9sUYhU7W/T+ztvFFvw1aKORPNf1fqimcIj oGgUwxMQuIZ9Prgd8O6QPgyCWQchYZvZSwutB9PuXKcfGZPcaNKPhMg4IC2eMNTSJag+ ox/F+ZKwdJf39dupmz7j9na5Qv6HR3R8a7bVphpsafKIUFDL33c/7ENOQ0DXSiVYgn4C 6ZmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=MqH4XScWJ/P0aVfTmXH/Gki3x0vzAERDHhHciJEUO6Y=; b=AiMglTiq97AF4nHJnkiIEmpgubJiah0wcb7Db/7ZVjtyLNQXjADqZVg7QQuLKUJTsL BWqytyGOKqDovelUmpDndQ+TNoIearYN2F6uuut3pCcPOb7+vy5gsYnw3jQPKFVgGMwZ TsX8C6FU2Ncm0s6Ys0+v+7X8ARRtXGMrxQgCZMad4IBZINTjuSqb5kg0MQtSOvqk6vI6 HOw80EiMvq/1xDoQob/wiirq9NLqVaj0t/FMCP9BmnBWmRUkaYkIwVYHLqcoDGaf0zdX lINM3z69/X9Qp5snIQeHeWit6xE8yJRZXBWxpu2u07lJ9e/pmUOd43DHWXbUxP9qD7Na /W8A== X-Gm-Message-State: APt69E3UbpkZkxRedIHl8jYttByfmBH+bua+v8QOxFQ9dk6UWgLHJCTt CjtmwM5fs4B32tH9nOAx9lJfLcNIQaVNuwRVxfs= X-Google-Smtp-Source: ADUXVKK0xp68XvBYOa0NOC9/VF7/lZ3gly8i9bx6bd5WQxN944mlpNU4WkRRhGQNRqP4qgCQwY0c8gQfhgiw76u8hz4= X-Received: by 2002:a0c:bfd4:: with SMTP id u20-v6mr24943275qvj.102.1528222339914; Tue, 05 Jun 2018 11:12:19 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 2002:ac8:162d:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 11:12:19 -0700 (PDT) From: Barry Leiba Date: Tue, 5 Jun 2018 14:12:19 -0400 X-Google-Sender-Auth: c-A-43AwWxh6FXE3NeFszy2DPKU Message-ID: To: rfcplusplus@ietf.org Content-Type: multipart/mixed; boundary="000000000000b5d56e056de8fd02" Archived-At: Subject: [Rfcplusplus] A related draft that I never posted X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:12:24 -0000 --000000000000b5d56e056de8fd02 Content-Type: text/plain; charset="UTF-8" I wrote a draft about this topic some while ago (you can see the date in the attached file), but never posted it because I wanted to discuss it with a couple of IAB members first. That never happened because we never found the time to get together and talk about it -- that doesn't matter, because we're all talking about it now. So I thought I'd post it here, rather than in the I-D repository for now, to kick off some discussion. Barry --000000000000b5d56e056de8fd02 Content-Type: text/plain; charset="US-ASCII"; name="draft-leiba-rfc-for-stdstrk-only-00.txt" Content-Disposition: attachment; filename="draft-leiba-rfc-for-stdstrk-only-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ji204bsd0 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEIuIExlaWJhDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEh1YXdlaSBUZWNobm9sb2dpZXMNCkludGVuZGVkIHN0YXR1czog QmVzdCBDdXJyZW50IFByYWN0aWNlICAgICAgICAgICAgICAgICAgICBBcHJpbCAwNiwgMjAxNg0K RXhwaXJlczogT2N0b2JlciAwNiwgMjAxNg0KDQogICAgICAgICAgICAgIFJGQ3MgQXJlIE9ubHkg Zm9yIFN0YW5kYXJkcyBUcmFjayBEb2N1bWVudHMNCiAgICAgICAgICAgICAgICAgIGRyYWZ0LWxl aWJhLXJmYy1mb3Itc3Rkc3Ryay1vbmx5LTAwDQoNCkFic3RyYWN0DQoNCiAgIE1hbnkgcGVvcGxl IGFyZSB1bmF3YXJlIG9mIGRpZmZlcmVuY2VzIGFtb25nIFJGQ3Mgb2YgZGlmZmVyaW5nDQogICBk b2N1bWVudCBzdGF0dXMgYW5kIGluIGRpZmZlcmVudCBzdHJlYW1zLCBhbmQgaXQgaXMgY29tbW9u IGZvciBwZW9wbGUNCiAgIHRvIGNvbnNpZGVyIGFsbCBSRkNzIHRvIGJlICJzdGFuZGFyZHMiIGF0 IHNvbWUgbGV2ZWwuICBUaGlzIGRvY3VtZW50DQogICBhZGRyZXNzZXMgdGhpcyBieSByZXNlcnZp bmcgZnV0dXJlIFJGQ3MgZm9yIFN0YW5kYXJkcyBUcmFjayBhbmQgQmVzdA0KICAgQ3VycmVudCBQ cmFjdGljZSBkb2N1bWVudHMsIGFuZCBieSBkZWZpbmluZyBuZXcgcHJlZml4ZXMgZm9yDQogICBk b2N1bWVudHMgd2l0aCBvdGhlciBzdGF0dXMgYW5kIGluIG5vbi1JRVRGIHB1YmxpY2F0aW9uIHN0 cmVhbXMuDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBp cyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBv ZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRv Y3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYp LiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LQ0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlk IGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJ dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQog ICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVz cy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAwNiwg MjAxNi4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIwMTYgSUVURiBU cnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3VtZW50IGF1dGhv cnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0 aW5nIHRvIElFVEYgRG9jdW1lbnRzIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy8NCiAgIGxpY2Vu c2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuDQogICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHksIGFzIHRo ZXkgZGVzY3JpYmUgeW91ciByaWdodHMNCiAgIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0 IHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMNCiAgIGV4dHJhY3RlZCBmcm9tIHRo aXMgZG9jdW1lbnQgbXVzdCBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dA0KICAg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25z IGFuZCBhcmUNCiAgIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMgZGVzY3JpYmVkIGluIHRo ZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCg0KDQoNCkxl aWJhICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAwNiwgMjAxNiAgICAgICAgICAg ICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUkZDcyBPbmx5IGZvciBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICBBcHJpbCAyMDE2DQoNCg0KICAgTWFueSBwZW9wbGUgYXJl IHVuYXdhcmUgb2YgZGlmZmVyZW5jZXMgYW1vbmcgUkZDcyBvZiBkaWZmZXJpbmcNCiAgIGRvY3Vt ZW50IHN0YXR1cyBhbmQgaW4gZGlmZmVyZW50IHN0cmVhbXMsIGFuZCBpdCBpcyBjb21tb24gZm9y IHBlb3BsZQ0KICAgdG8gY29uc2lkZXIgYWxsIFJGQ3MgdG8gYmUgInN0YW5kYXJkcyIgYXQgc29t ZSBsZXZlbC4gIFRoaXMgZG9jdW1lbnQNCiAgIGFkZHJlc3NlcyB0aGlzIGJ5IHJlc2VydmluZyBm dXR1cmUgUkZDcyBmb3IgU3RhbmRhcmRzIFRyYWNrIGFuZCBCZXN0DQogICBDdXJyZW50IFByYWN0 aWNlIGRvY3VtZW50cywgYW5kIGJ5IGRlZmluaW5nIG5ldyBwcmVmaXhlcyBmb3INCiAgIGRvY3Vt ZW50cyB3aXRoIG90aGVyIHN0YXR1cyBhbmQgaW4gbm9uLUlFVEYgcHVibGljYXRpb24gc3RyZWFt cy4NCiAgIFJGQ3MgcHVibGlzaGVkIHByaW9yIHRvIHRoaXMgZG9jdW1lbnQgYXJlIG5vdCBhZmZl Y3RlZCBpbiBhbnkgd2F5OyBpbg0KICAgcGFydGljdWxhciwgdGhlcmUgd2lsbCBub3QgYmUgYW55 IHJlbmFtaW5nIG9yIHJlbnVtYmVyaW5nIG9mIGVhcmxpZXINCiAgIFJGQ3MuDQoNCjIuICBSRkNz IGFuZCBOZXcgU2VyaWVzIERlc2lnbmF0aW9ucw0KDQogICBBcyBvZiB0aGUgcHVibGljYXRpb24g b2YgdGhpcyBkb2N1bWVudCwgIlJGQyIgd2lsbCBiZSByZXNlcnZlZCBvbmx5DQogICBmb3IgSUVU RiBzdHJlYW0gcHVibGljYXRpb25zIGluIHRoZSBTdGFuZGFyZHMgVHJhY2sgYW5kIHRoZSBCQ1Ag KEJlc3QNCiAgIEN1cnJlbnQgUHJhY3RpY2UpIHNlcmllcy4NCiAgIEV4YW1wbGU6IFJGQyA2Nzg5 DQoNCiAgIFtbT3BlbiBxdWVzdGlvbjogU2hvdWxkIHdlIGFiYW5kb24gIlJGQyIgYWx0b2dldGhl ciBhbmQgdXNlIHNvbWV0aGluZw0KICAgbGlrZSAiU1RYIiwgb3Igd2hhdGV2ZXI/ICBQcm86IEl0 IHNlcGFyYXRlcyBuZXcgc3R1ZmYgdW5kZXIgdGhpcyBwbGFuDQogICBlbnRpcmVseSBmcm9tIHRo ZSBvbGQgc3R1ZmYuICBDb246IHdlIGdpdmUgdXAgdGhlIGJyYW5kaW5nIHRoYXQncw0KICAgYWxy ZWFkeSB0aGVyZS4gIE15IHNlbnNlIGlzIG5vLCB3ZSBzaG91bGQgc3RpY2sgd2l0aCBSRkMuICBP bGQgUkZDcw0KICAgd2lsbCwgaW4gYW55IGNhc2UsIGNvbnRpbnVlIHRvIGhhdmUgdGhlIHByb2Js ZW0sIGFuZCB3ZSBjZXJ0YWlubHkNCiAgIGRvbid0IHdhbnQgdG8gdHJ5IHRvIHJlLW51bWJlciB0 aGUgb2xkIFJGQ3MuICBdXQ0KDQogICBEb2N1bWVudHMgaW4gdGhlIElFVEYgc3RyZWFtIHdpdGgg SW5mb3JtYXRpb25hbCBzdGF0dXMgd2lsbCBiZQ0KICAgZGVzaWduYXRlZCBieSAiSU5GTyIuDQog ICBFeGFtcGxlOiBJTkZPIDY3ODkNCg0KICAgRG9jdW1lbnRzIGluIHRoZSBJRVRGIHN0cmVhbSB3 aXRoIEV4cGVyaW1lbnRhbCBzdGF0dXMgd2lsbCBiZQ0KICAgZGVzaWduYXRlZCBieSAiRVhQIi4N CiAgIEV4YW1wbGU6IEVYUCA2Nzg5DQoNCiAgIERvY3VtZW50cyBpbiB0aGUgSUVURiBzdHJlYW0g dGhhdCBhcmUgbW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzIHdpbGwNCiAgIHJldGFpbiB0aGVpciBv cmlnaW5hbCBkZXNpZ25hdGlvbi4gIERvY3VtZW50cyBpbiB0aGUgSUVURiBzdHJlYW0gdGhhdA0K ICAgYXJlIGluaXRpYWxseSBwdWJsaXNoZWQgd2l0aCBIaXN0b3JpYyBzdGF0dXMgd2lsbCBiZSBk ZXNpZ25hdGVkIGJ5DQogICAiSU5GTyIuDQoNCiAgIFtbT3BlbiBxdWVzdGlvbjogSXMgdGhpcyBy aWdodD8gIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byB0cnkgdG8NCiAgIGRpc3Rpbmd1aXNoIEhp c3RvcmljIGRvY3VtZW50cyB3aXRoIGl0cyBvd24gcHJlZml4LCBhbmQgaXQgd291bGQgbGVhZA0K ICAgdG8gdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgd2UgcmVudW1iZXIgYSBkb2N1bWVudCB3aGVu IGl0IG1vdmVzIHRvDQogICBIaXN0b3JpYy4gIEkgdGhpbmsgd2UgZG9uJ3Qgd2FudCB0byBnbyB0 aGVyZS4gIF1dDQoNCiAgIERvY3VtZW50cyBpbiB0aGUgSVJURiBzdHJlYW0gd2lsbCBiZSBkZXNp Z25hdGVkIGJ5ICJJUlRGIi4NCiAgIEV4YW1wbGU6IElSVEYgNjc4OQ0KDQogICBEb2N1bWVudHMg aW4gdGhlIElBQiBzdHJlYW0gd2lsbCBiZSBkZXNpZ25hdGVkIGJ5ICJJQUIiLg0KICAgRXhhbXBs ZTogSUFCIDY3ODkNCg0KICAgRG9jdW1lbnRzIGluIHRoZSBJbmRlcGVuZGVudCBzdHJlYW0gd2ls bCBiZSBkZXNpZ25hdGVkIGJ5ICJJTkQiLg0KICAgRXhhbXBsZTogSU5EIDY3ODkNCg0KMy4gIElB TkEgQ29uc2lkZXJhdGlvbnMNCg0KDQpMZWliYSAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9j dG9iZXIgMDYsIDIwMTYgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgIFJGQ3MgT25seSBmb3IgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgQXByaWwgMjAx Ng0KDQoNCiAgIFRoZXJlIGFyZSBubyBJQU5BIGNvbnNpZGVyYXRpb25zIGZvciB0aGlzIGRvY3Vt ZW50Lg0KDQo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBp cyBwdXJlbHkgcHJvY2VkdXJhbCwgYW5kIHRoZXJlIGFyZSBubyByZWxhdGVkIHNlY3VyaXR5DQog ICBjb25zaWRlcmF0aW9ucy4NCg0KNS4gIFJlZmVyZW5jZXMNCg0KQXV0aG9yJ3MgQWRkcmVzcw0K DQogICBCYXJyeSBMZWliYQ0KICAgSHVhd2VpIFRlY2hub2xvZ2llcw0KICAgDQogICBQaG9uZTog KzEgNjQ2IDgyNyAwNjQ4DQogICBFbWFpbDogYmFycnlsZWliYUBjb21wdXRlci5vcmcNCiAgIFVS STogICBodHRwOi8vaW50ZXJuZXRtZXNzYWdpbmd0ZWNobm9sb2d5Lm9yZy8NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkxlaWJhICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAwNiwgMjAxNiAgICAg ICAgICAgICAgICBbUGFnZSAzXQ0K --000000000000b5d56e056de8fd02-- From nobody Tue Jun 5 11:16:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B564131119 for ; Tue, 5 Jun 2018 11:16:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, 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 MXi3WHxoiRkz for ; Tue, 5 Jun 2018 11:16:36 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 7ACFE12F1AC for ; Tue, 5 Jun 2018 11:16:36 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y4-v6so2148496qka.5 for ; Tue, 05 Jun 2018 11:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=RFnzfULPJmItZxS4pahDOAevX1kwZgeBq0JOwPnH6cI=; b=b8hb/TWcGhDFcUBgZMZJYn/7sNTimJ6JjIeIe9WX3cd3GiTd3+TploIK0VPpSxcPgj lhQuZbxz2x4J7W2jNthGkWjCtNsQC40ZPK5fm20YZaCc1kxI6jsiqTdv8R3iQESRy9/n FLZu3O9LcvO9X96IjuvanQvf4SZvO4ANm9qiSnMkE3zyznlhKYDSWJSh4kuhxXaYN5vc zIOq5nRu4VRwItV0CiX5K4NIm2xD3BZvPOaAdJtEOF+OC+xStXFPM/pxwYmLm9NYGCaq A+ES0jyoxl/NReJ1QnYssdamXHmLhIgt2rOMg+gjVUTPR4Q0rGyyxeLExBG1qKrK9bDN fVzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=RFnzfULPJmItZxS4pahDOAevX1kwZgeBq0JOwPnH6cI=; b=JPLWd6j5EJL3uT3MsxWDx7Z0/oCchMDeKBOOQNCYxffJDqHXo4AwwtNm7JnB9zDsxa s/qRT3auzHeJtguygmftm1nMSh+fBAmjeAygSr5lO+JRpIqtO5gxFi8xsHiAurgO95Au 5pV/qdiQUm9I3zPr14TwWq91GflRlm4b0zVDObfMSTnuRkVAnVf/sVcMffuDpQtWyEFa p+6yyJXnj1LyyM+bUKwQdGeKZdF2en72ucSnKXBlxKlH7bgNZBphnSurC7JfM41qjAta 6kTVlJ8Iokuk7tVX2hDOwQ76WYv/nFO7AamzbFb1Tpp+whtNN+d6r0dd4b0JX+jGpkZB 11IA== X-Gm-Message-State: APt69E3HAs/YNDbZP36dIxMyZKndUuRAJdnqAwpa9T+hrmarYiPr0kJ+ 9Bejaxw6IbObMIhm88i4RSFSTmRV/92GHoW244AB5Q== X-Google-Smtp-Source: ADUXVKIPDYd853f/ot9Y4eXxvMRhTBZvccu6RQwIMjFNJ0q004XOo5DCZbYzSIxQX+t1xYCgviboUjBz+VXYZWxftTU= X-Received: by 2002:a37:3889:: with SMTP id f131-v6mr22639088qka.408.1528222595361; Tue, 05 Jun 2018 11:16:35 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 2002:ac8:162d:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 11:16:34 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Tue, 5 Jun 2018 14:16:34 -0400 X-Google-Sender-Auth: 6fK2fAPuswZlHLyeY7VnTNPLAIM Message-ID: To: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] A related draft that I never posted X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:16:40 -0000 I'm thinking that posts with attachments might get held for moderation, so I'm re-sending this with the "attachment" pasted in instead. > I wrote a draft about this topic some while ago (you can see the date > in the attached file), but never posted it because I wanted to discuss > it with a couple of IAB members first. That never happened because we > never found the time to get together and talk about it -- that doesn't > matter, because we're all talking about it now. So I thought I'd post > it here, rather than in the I-D repository for now, to kick off some > discussion. Barry --------------------------------------------------------------------------- Network Working Group B. Leiba Internet-Draft Huawei Technologies Intended status: Best Current Practice April 06, 2016 Expires: October 06, 2016 RFCs Are Only for Standards Track Documents draft-leiba-rfc-for-stdstrk-only-00 Abstract Many people are unaware of differences among RFCs of differing document status and in different streams, and it is common for people to consider all RFCs to be "standards" at some level. This document addresses this by reserving future RFCs for Standards Track and Best Current Practice documents, and by defining new prefixes for documents with other status and in non-IETF publication streams. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 06, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Leiba Expires October 06, 2016 [Page 1] Internet-Draft RFCs Only for Standards Track April 2016 Many people are unaware of differences among RFCs of differing document status and in different streams, and it is common for people to consider all RFCs to be "standards" at some level. This document addresses this by reserving future RFCs for Standards Track and Best Current Practice documents, and by defining new prefixes for documents with other status and in non-IETF publication streams. RFCs published prior to this document are not affected in any way; in particular, there will not be any renaming or renumbering of earlier RFCs. 2. RFCs and New Series Designations As of the publication of this document, "RFC" will be reserved only for IETF stream publications in the Standards Track and the BCP (Best Current Practice) series. Example: RFC 6789 [[Open question: Should we abandon "RFC" altogether and use something like "STX", or whatever? Pro: It separates new stuff under this plan entirely from the old stuff. Con: we give up the branding that's already there. My sense is no, we should stick with RFC. Old RFCs will, in any case, continue to have the problem, and we certainly don't want to try to re-number the old RFCs. ]] Documents in the IETF stream with Informational status will be designated by "INFO". Example: INFO 6789 Documents in the IETF stream with Experimental status will be designated by "EXP". Example: EXP 6789 Documents in the IETF stream that are moved to Historic status will retain their original designation. Documents in the IETF stream that are initially published with Historic status will be designated by "INFO". [[Open question: Is this right? I don't think we need to try to distinguish Historic documents with its own prefix, and it would lead to the question of whether we renumber a document when it moves to Historic. I think we don't want to go there. ]] Documents in the IRTF stream will be designated by "IRTF". Example: IRTF 6789 Documents in the IAB stream will be designated by "IAB". Example: IAB 6789 Documents in the Independent stream will be designated by "IND". Example: IND 6789 3. IANA Considerations Leiba Expires October 06, 2016 [Page 2] Internet-Draft RFCs Only for Standards Track April 2016 There are no IANA considerations for this document. 4. Security Considerations This document is purely procedural, and there are no related security considerations. 5. References Author's Address Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.org/ Leiba Expires October 06, 2016 [Page 3] --------------------------------------------------------------------------- From nobody Tue Jun 5 13:26:32 2018 Return-Path: X-Original-To: rfcplusplus@ietf.org Delivered-To: rfcplusplus@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DC113115C; Tue, 5 Jun 2018 13:26:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, alissa@cooperw.in, rfcplusplus-chairs@ietf.org, rfcplusplus@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152823038566.19029.15968749437992095628.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2018 13:26:25 -0700 Archived-At: Subject: [Rfcplusplus] rfcplusplus - New Meeting Session Request for IETF 102 X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 20:26:30 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the rfcplusplus working group. --------------------------------------------------------- Working Group Name: The label "RFC" Area Name: General Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: iasa2, irtfopen People who must be present: Gonzalo Camarillo Alissa Cooper Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 5 20:19:26 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC18130E47 for ; Tue, 5 Jun 2018 20:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VTB-J_Et7fvC for ; Tue, 5 Jun 2018 20:19:21 -0700 (PDT) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (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 F2FAE130E43 for ; Tue, 5 Jun 2018 20:19:20 -0700 (PDT) Received: by mail-pl0-x236.google.com with SMTP id w17-v6so2855983pll.9 for ; Tue, 05 Jun 2018 20:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FldrIC2goGxWtYQIAxveBSJOW0QbwNKjKklmd1bbbGw=; b=my6BFTnFmCFxQv3Xgtu7zwqcZBzQpsnb56dRdWcqkfebYYu6D462HOPI7DALWutLD2 s2QrxoAkAtsHYqYkGYkqzdluGUiRg9Jov9fDNRjC83zLj/6TiZU/eFrqpQJwsusnSjCE zfsJXlaf3BzsT3m9oLF0l4wBA3ZlE6Jzy9TdyUk00FOmF7CZeJ2ADjXYK3gk6Za/kgF+ ieRSmBg4tPjEjwsvVkklKmkdZAUYXY3fzINZaa6sH16tnnYB169lFADfnfofCw8VwG6a hNuXJrt8FSUn9rgpWiMP8HHmpVWCm7dbGYXouyXL3Yua/Tdx4D92UFKFQngunCzB9Xlz N7pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FldrIC2goGxWtYQIAxveBSJOW0QbwNKjKklmd1bbbGw=; b=BErpssjmFaSuT6LDMkKYdya0R6RtsbnjMoeygDul5pj0MPM58CNVii9g4CdjyZVBrd qDo9cxiJw0bO4U9oUNiXbARYY3QzvW8YCPjFiGVmrjJOOI5s0VOKu/fYcqsTXLLIjTQ2 Og9R7aBhBVHeaaNZ3c6nkapLAIEk088m5M5GFhwih7QeIBpBJhepC5ZQYCZwemJZhekN CfOQnBfBcUHGAkfVgJmH1MavaVkexQCDoVk2W2D3vCwje3vbr179+l3drc2ts2yWDveb W0j9K8MQ9AM6v4sJ4gNad4P6kNEC6/fTEtZSLy2boPyt+J4pQxBpkojE3pEOWd6ZaIc5 A5tA== X-Gm-Message-State: APt69E057cck+7LMmHZyBV5XnIDfb+aLurzjJbjEiBIZXkYA4g4KCgGj flrI1fsw6sQbjH7ybrgHaplkgg== X-Google-Smtp-Source: ADUXVKLYIH16HWlM2aP/PB0l6V2ougnvPRE6vs8KhxVW6AxOZcmJnyabi6O3owHQKeYre/bLECBSEQ== X-Received: by 2002:a17:902:56e:: with SMTP id 101-v6mr1417546plf.25.1528255159820; Tue, 05 Jun 2018 20:19:19 -0700 (PDT) Received: from [10.2.0.125] ([131.203.242.18]) by smtp.gmail.com with ESMTPSA id t13-v6sm14833802pgv.43.2018.06.05.20.19.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 20:19:18 -0700 (PDT) References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> To: rfcplusplus@ietf.org From: Brian E Carpenter X-Forwarded-Message-Id: <152825497269.19360.8656508092644282096@ietfa.amsl.com> Message-ID: <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> Date: Wed, 6 Jun 2018 15:19:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152825497269.19360.8656508092644282096@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 03:19:23 -0000 -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-request-for-comments-00.txt Date: Tue, 05 Jun 2018 20:16:12 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Request for Comments Author : Brian Carpenter Filename : draft-carpenter-request-for-comments-00.txt Pages : 7 Date : 2018-06-05 Abstract: This document discusses the Internet technical community's common document series. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jun 6 00:57:45 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1D3130ECE for ; Wed, 6 Jun 2018 00:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 tOiDg2Q2k9Ny for ; Wed, 6 Jun 2018 00:57:32 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 694A0130ECA for ; Wed, 6 Jun 2018 00:57:32 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id 101-v6so6078869oth.4 for ; Wed, 06 Jun 2018 00:57:32 -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=ufMtgntDUyzAaRFQ4SCuECFpBPIruLenzN+juQAD7ZY=; b=mvpPtA9ny6Ij59Z0U0C7i9A7junTp+f6OyHdjLiQ8n8twPSCYhCikqpRxSrHtOaAn/ ZsoG/eecuNSblLPQX62hIjaOMHaNcMPyONc+6Deo2Jc1wiyiwSeKqDusrIL3mlPJKh2G oe7qOdwp/45Y2RvGvO3E/UeFvFuhL/VrGciWpMPrjDUERdqm82wbR/7a8HHyMDmNB9ZL yfYVF8DOaLgEBWFtF6sps8hYrJ/zeFc+ipOyr2BPpCw0DFO5mTVpvfbMF3fk6zVqr7Ha 7jXMixOKh0Hz+AMC8eRRx3YDidNSr1Z48/0jevcjLaYBB2VAO55luvtqGckUkpPfXfab PD0w== 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=ufMtgntDUyzAaRFQ4SCuECFpBPIruLenzN+juQAD7ZY=; b=bMkt+7T9c8tChhkijFxRp1FbbgnASUG2MHFz4DP3OJa3eGv/agVje/DRGe9gcAMKGU RMcxyUnK8IA/jkdpFC/tSXnNpKcX15ATXgA4uSyZRNQSMD4wqfcpvrR/cpJHs5oWWer+ DBA6r1p5IpnO0gw/GcrP6cJM5Rs80oqtQO4O4InqbYrG2dHTk4b5AkVCTyMpSY4v3D12 3AvMVxc04XtG4CEIzQy6t99vdQ8hMKX9IJeyJ7ZcfzkmEQ3ZF/ZHAZ3lPJHCV7Yc7xFx Q9pC6pYSJ4i08ADZNkDeBZXxx7gclXZhuWItKm/yb5o+Fg0UScnyecxtQo98GGcCoe7w KNyQ== X-Gm-Message-State: APt69E2jXKts4hZSZhxuiUD+ctYTpFfT7DwPAEKTOJCpsxjvVqq3gXDz pOK2k1uxRk0ZCBXi5EZ5c5xhajdjUAGzCJQoTs4= X-Google-Smtp-Source: ADUXVKJiFGYz10ryjzU8wWXnVb3s8i3Vpefe6ZnLUeXysPLvSLakPYqJd3dvpVjHfUnf+6GFBnZd6Em1ze7gfpnALu4= X-Received: by 2002:a9d:26dc:: with SMTP id i28-v6mr1195264otd.27.1528271851429; Wed, 06 Jun 2018 00:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 00:57:10 -0700 (PDT) From: "Andrew G. Malis" Date: Wed, 6 Jun 2018 03:57:10 -0400 Message-ID: To: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000d32594056df48446" Archived-At: Subject: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 07:57:38 -0000 --000000000000d32594056df48446 Content-Type: text/plain; charset="UTF-8" I'm the author of some 40-odd RFCs (some of them very odd), some of them preceding the formation of the IETF, and over the years appearing in most of the available categories - historic, informational, proposed standard, draft standard, and full standard (I don't recall writing an experimental or BCP RFC, but the point is that I've had some amount of experience with RFCs). I've worked for organizations that are primarily generators of RFCs (the vendor community) and those that are primarily consumers of RFCs (the operator community). Of course, to some extent most organizations in our industry are both producers and consumers of RFCs, but again, you get the point. Over the years, including during my stint on the IAB, I've heard the various concerns about RFC confusion. However, I really haven't witnessed that confusion in practice. When I worked for an operator, and we needed to evaluate the various features implemented in vendor equipment, everyone I worked with understood the various categories of what was what, including the risks associated working with our vendors on features that were at that point in time only drafts in progress. During my stints at vendors, I've again found our customers in the operator community to be well informed regarding the status of ongoing and completed work in the IETF, what they would like to see implemented in the equipment they deploy, and why. They want to see the results of interoperability testing (and often run the tests themselves, or sponsor the work in test labs). They know how the protocols work, and why they would want to use them in their networks. In some cases, they're willing to deploy bleeding edge drafts, and understand the risks but have business reasons why it makes sense for them. In other cases, they take a more conservative approach to their networks. But in all cases, they're well informed regarding the status of the contents of any particular RFC or draft. I've not (to my memory) been contacted by anyone that had any misunderstanding that needed clearing up regarding the particular status of any of my RFCs. I realize that this is just one data point, and anecdotal in nature, but based on my experience, like Bob I'm skeptical of the changes being proposed. Cheers, Andy --000000000000d32594056df48446 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm the author of some 40-odd RFCs (some of them very = odd), some of them preceding the formation of the IETF, and over the years = appearing in most of the available categories - historic, informational, pr= oposed standard, draft standard, and full standard (I don't recall writ= ing an experimental or BCP RFC, but the point is that I've had some amo= unt of experience with RFCs).=C2=A0

I've worked for = organizations that are primarily generators of RFCs (the vendor community) = and those that are primarily consumers of RFCs (the operator community). Of= course, to some extent most organizations in our industry are both produce= rs and consumers of RFCs, but again, you get the point.

Over the years, including during my stint on the IAB, I've heard = the various concerns about RFC confusion. However, I really haven't wit= nessed that confusion in practice. When I worked for an operator, and we ne= eded to evaluate the various features implemented in vendor equipment, ever= yone I worked with understood the various categories of what was what, incl= uding the risks associated working with our vendors on features that were a= t that point in time only drafts in progress.

Duri= ng my stints at vendors, I've again found our customers in the operator= community to be well informed regarding the status of ongoing and complete= d work in the IETF, what they would like to see implemented in the equipmen= t they deploy, and why. They want to see the results of interoperability te= sting (and often run the tests themselves, or sponsor the work in test labs= ). They know how the protocols work, and why they would want to use them in= their networks. In some cases, they're willing to deploy bleeding edge= drafts, and understand the risks but have business reasons why it makes se= nse for them. In other cases, they take a more conservative approach to the= ir networks. But in all cases, they're well informed regarding the stat= us of the contents of any particular RFC or draft.

I've not (to my memory) been contacted by anyone that had any misunder= standing that needed clearing up regarding the particular status of any of = my RFCs.

I realize that this is just one data poin= t, and anecdotal in nature, but based on my experience, like Bob I'm sk= eptical of the changes being proposed.

Cheers,
Andy

--000000000000d32594056df48446-- From nobody Wed Jun 6 02:57:04 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05124130EE4 for ; Wed, 6 Jun 2018 02:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Dr-kcTgq_veM for ; Wed, 6 Jun 2018 02:57:00 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 1BBC4130ED0 for ; Wed, 6 Jun 2018 02:57:00 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id q13-v6so5683096qtp.4 for ; Wed, 06 Jun 2018 02:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=pjUiiBh099WO/t4qXaIYly5MSP5trxOVxzXvZP9C3G0=; b=LAqUTIL/lDcGLlRTqq+jvkd8b4c5KmSraJmd9fW23nWnrEgU6kbWl07Qf2T4YXslZv oVA0zRpZJZSdXiJscHZu33uvviXqFpjzTdUEKlEV4E6GA1NN/4N2cY3kIvAWr7uuxpor ve+/Dpj4TZbHCv0xUuzgDhmAz4ub10YrmlRnmXgxT5+akQrcNhoiUeiEGXKVXpVjVp61 7nC55DD/WhkiV/Ftw4bqAJPy+ToEKUsDUgusCWjl3qcTNZyBDGDli0svINjhtSOBP01q cqW562RRogrMThfBWHn2CczkbzAGnCqnXTNPAXtOwsrJLwNy25VNvHNxEAO2K84wiT+l D4tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=pjUiiBh099WO/t4qXaIYly5MSP5trxOVxzXvZP9C3G0=; b=FQMYe+jeCqAoYS0V2c3uxKvyuWfEAsg+a0Anv2tntq1GUqp/OI39lU/zDG4TZuhf6F XxnSguFBsufk1kflAkNkJBcEUdnMAT/yd/DClHdURwFRnSfk7v3DR+wLqwc58y8JcHw6 RmVmye1UbMSmSxaEiW2M0UTalQpDKem7ShmKr9PD/VFneWWB7decWgZiVdsN114d7X7k rZIZTPNXdEfZCYrLwTSzyPgUl2Ad0dJJ47E2NSIUjmHj3bTI3KAjLzZZi9FqI5og/2k+ BsoUgSR3BLYXLq94gkobqAhCOAua+jyurcdogLubBk7V42djS6eTmkHkTvDbFXFLB+K9 H+VA== X-Gm-Message-State: APt69E01UQY+olBXteXalIdRRBz9usWEASluwX3wjhaQ22j0/4k3oN4e 0J0Rk5KNFYHd5FjxzqsP5mWfV4TcxcsGHf+aSa8= X-Google-Smtp-Source: ADUXVKLKkVCRqbJK7pHAFdBSDiy4Cpu107HSLhOsETn5Mv9qYBzxCVmYzyUMZasqfwRwK6YyjjmheodPdcsF1nT1VFM= X-Received: by 2002:ac8:162e:: with SMTP id p43-v6mr2059770qtj.56.1528279019119; Wed, 06 Jun 2018 02:56:59 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 2002:ac8:36aa:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 02:56:58 -0700 (PDT) In-Reply-To: References: From: Barry Leiba Date: Wed, 6 Jun 2018 05:56:58 -0400 X-Google-Sender-Auth: 0xdhEPmpzy40CrrpOXuITBL3fP4 Message-ID: To: "Andrew G. Malis" Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:57:02 -0000 The problem is that it *is* broke(n). > Over the years, including during my stint on the IAB, I've heard the various > concerns about RFC confusion. However, I really haven't witnessed that > confusion in practice. I have. I have experience with (1) perceptions that Informational and Experimental IETF-stream RFCs are standards, along with demands that they be implemented, (2) perceptions that IAB-stream RFCs are BCPs that must be followed, and, probably worst, (3) perceptions that Independent-stream Informational documents that got little review and no consensus are standards, along with demands that they be implemented. Maybe the situation is worse at the app layer than at the routing layer, but it's been a clear problem at the app layer in my experience. (Now off to read Brian's draft...) Barry From nobody Wed Jun 6 03:24:21 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0184E130E5F for ; Wed, 6 Jun 2018 03:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 FQih1BPJHxfd for ; Wed, 6 Jun 2018 03:24:15 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 06E4D129C6B for ; Wed, 6 Jun 2018 03:24:15 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id d3-v6so5761632qto.1 for ; Wed, 06 Jun 2018 03:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uHL/LpSbhqj5f9SXQj5tYH/vexZcCaNTWBdAltzK5NI=; b=susOE7mZaHEyLaL3tbTEBHUnATYbY67z6X5PlEFYUZtIExHVkHVtBFWw9WCo3n6gAT j8aEEk8SCD8W4u8YwDx9mM+7OfWwwDjmI4omsy6A19fAv/cxif1jtjcC1TLD5uG5HMcN Ep9PbVqr3P9KHTKArzwfLEhLieeSg8Xkqumej7MsIxqtwcgG4ZT7bXCSbs55qxpWRiAz nv5tSfdeG3Jvv6gTzxIqqgd3+oVW+MvTnYZMaoon5hLBgiPn955c8JmMdcSgeZTo6q0B 3FVHra78KII1MgUXAtD6R5gnq7sb5ndRR3ELmRjTVM1HfSIhcQfKLR581SEOz/YpWLfz 8gwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uHL/LpSbhqj5f9SXQj5tYH/vexZcCaNTWBdAltzK5NI=; b=CDseNb//WQgU6fPZed3m0MV0+zWlNL+pHoCHIEUGoxhFJcwP5usPeLJ7RWsVK3iQIU 0VoSh2SVXrUuvchCD98UZnIqkCYgRBIpIcV+0zuxZYvSs/LfbnHKVyGVquearH7wIu8f OHBeyVhBczVk6u1W6y0NANgWc7Z396HzmPBCgZ8YP9a5pnYd8+KsRSVwhltpWoiuLzYe akvJegFDfF0qILzByH3b9QW//hSrWfUxXcu599l7z8R1Ka0WYkTYpfn1cR6ey7oQTbWE qxxf61apT2xc7OB4sK7/nbjtAHpOsjxN34/4ajOqjD+vachsoZEChWUEVXFSgjVV1s1h fExg== X-Gm-Message-State: APt69E3Sc+CS9i5/7bLHBD6lHKe4ffkkKStE7sB03tebVd8zroIKkyzr qzIWH2rerD/9gxhav1uWMwVJMJgKnLY/9zlNH+I= X-Google-Smtp-Source: ADUXVKJ6mkDol2DtbOlaPe4/3b73JVhwd6kj2s2YR+dWm92aD8iDJ+84+q2Hoz9Wici9tFDOUoij0piz/qgzKrW4F0E= X-Received: by 2002:ac8:162e:: with SMTP id p43-v6mr2136594qtj.56.1528280654105; Wed, 06 Jun 2018 03:24:14 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 2002:ac8:36aa:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 03:24:13 -0700 (PDT) In-Reply-To: <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> From: Barry Leiba Date: Wed, 6 Jun 2018 06:24:13 -0400 X-Google-Sender-Auth: _2FgMZMdU1YWXIk3MnXBONi37Ro Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 10:24:17 -0000 Brian, the draft appears to be saying, essentially, that we shouldn't make the sorts of changes to the RFC series that we've proposed to discuss here because the RFC series is an old and venerable thing and shouldn't be changed. I don't buy it. The primary thing I don't buy is that "RFC" still means "request for comments". At some level, sure, it does, because people can and will comment on RFCs, submit errata reports, and so on. But most of the world thinks of RFCs as IETF standards, with some subset understanding that the series also contains informational and experimental stuff. The comment period, really, is during the development of the Internet Drafts. One only needs to look at the strict scrutiny performed by the IESG to see that the bar for getting to RFC is well beyond that warranted for the publication of a request for comments. As to ownership, I agree that the series is owned by "the community", and it's exactly that community we're calling on for discussion of proposed changes. If we think that, for example, the IRTF is being short-changed here, we have only to publicize this discussion to the IRTF an ask them to come be part of it. The same goes for any other sub-community we think isn't adequately represented. Apart from that, I see little substance in the draft about your objection to considering the sort of change proposed here (apart from the "request for comments" part). Can you be clearer, not about the history of the RFC series, but about specifically why you think such a change would be bad? Barry On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter wrote: > -------- Forwarded Message -------- > Subject: I-D Action: draft-carpenter-request-for-comments-00.txt > Date: Tue, 05 Jun 2018 20:16:12 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Request for Comments > Author : Brian Carpenter > Filename : draft-carpenter-request-for-comments-00.txt > Pages : 7 > Date : 2018-06-05 > > Abstract: > This document discusses the Internet technical community's common > document series. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 > https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Wed Jun 6 06:45:21 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7829A130F1F for ; Wed, 6 Jun 2018 06:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 OM_h8XqszUss for ; Wed, 6 Jun 2018 06:45:09 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 F12F8130F1E for ; Wed, 6 Jun 2018 06:45:08 -0700 (PDT) Received: from [10.32.60.93] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w56Di6l6021607 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jun 2018 06:44:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.93] From: "Paul Hoffman" To: "Barry Leiba" Cc: rfcplusplus@ietf.org Date: Wed, 06 Jun 2018 06:45:04 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 13:45:17 -0000 On 6 Jun 2018, at 2:56, Barry Leiba wrote: > I have experience with (1) perceptions that Informational and > Experimental IETF-stream RFCs are standards, along with demands that > they be implemented, (2) perceptions that IAB-stream RFCs are BCPs > that must be followed, and, probably worst, (3) perceptions that > Independent-stream Informational documents that got little review and > no consensus are standards, along with demands that they be > implemented. What was the outcome of those misperceptions? How much different was it than if those people had correctly the perceived that the documents they were looking at were not standards? --Paul Hoffman From nobody Wed Jun 6 13:33:14 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F473130FD0 for ; Wed, 6 Jun 2018 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lKhRUihraO72 for ; Wed, 6 Jun 2018 13:33:08 -0700 (PDT) Received: from mail-pl0-x243.google.com (mail-pl0-x243.google.com [IPv6:2607:f8b0:400e:c01::243]) (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 CAB4E130F94 for ; Wed, 6 Jun 2018 13:33:08 -0700 (PDT) Received: by mail-pl0-x243.google.com with SMTP id z9-v6so4517491plk.11 for ; Wed, 06 Jun 2018 13:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7i0n8HgulaiM0LfeSXYFtxF9OkrX2uPCuiqYiFRuX8k=; b=qCj5shp6BcPAqrf7IfPtKV+kGTbwdErywmSqe17Si+c4Oegpeuw5xxv+HsDQuyr4Ls +iZUwgxycUGXohhjqLPAU/A6lF+bF7RS+xHFQpzV0bu6V35OhxiI0dDLwS7YZ7MJG7lq RBGHXM5pq3SyQP7M+iidyeEYJ7tzo3XCdDeGM6v8CWcWB8x8sm6yD3irhmEPJXzGrhKH UKo188iwlf5gOhFTmB9BF+PZwN5DG+TGHkoC726dBEnm7NzNYwCE5SCWty1VjLL7OIlk RhYI+2J20SW1Yu0+4AMtNYsm0aRLKZTmE2oTH9lgiPbhKJTerMuu8NPXswJcbwM3TORE rTmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7i0n8HgulaiM0LfeSXYFtxF9OkrX2uPCuiqYiFRuX8k=; b=lQRzcG0o5i0d+IsqZs/KL2ZfYdNGAmRn6EtCP4EgzoCSj48zYcAnLSu1jYJusvcuX/ +B0qhMBgxOsR1NMaZ2XDpLqCXa6TBck16gpEo+0oveiM5WwrFIY56vm7CXkD60NG+Olz ea7QGJUOejmn8ItyGQp7LgU8Q6Os7VUnF8FagbF+XT3Ql4Hr7/Wd5ap72Ay/DJieheCp yvQ2EMnKFVsp/govVZ7v9zpp4YGjOx63W+aXHj2MKZ108JLbs4K1te5fcRJvJzsrLV+k h+179CtBg9M0Ewp9rlfUxLHN5ysXDBv6FxeRY0nkWVT2X7fiY4rRa35ApquyeUwyx2vw Cllg== X-Gm-Message-State: APt69E2JDGAUDab2XTQT9B0neUVt17whPpZrY/lmayOq++YUCOx1a4YE LsAAwaJxuhaElI3qlnb46QaOvw== X-Google-Smtp-Source: ADUXVKKi5mbrZOISWZsQlsocaYfXQhDfgmg7KCW/yAQMmEau7KPk9ZquqTPx/WeqA91e+9BRVZqgLA== X-Received: by 2002:a17:902:6b04:: with SMTP id o4-v6mr4674746plk.101.1528317188145; Wed, 06 Jun 2018 13:33:08 -0700 (PDT) Received: from [10.2.0.117] ([131.203.242.18]) by smtp.gmail.com with ESMTPSA id a81-v6sm20313876pfl.167.2018.06.06.13.33.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 13:33:07 -0700 (PDT) To: Barry Leiba Cc: rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> From: Brian E Carpenter Message-ID: <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> Date: Thu, 7 Jun 2018 08:33:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 20:33:13 -0000 I'm out of time at this moment, but no, that isn't the argument. The argument is that having a single document series that is specifically named as not being dogma is the right thing to do. Better labels are a good idea, within that series, for sure. Regards Brian On 06/06/2018 22:24, Barry Leiba wrote: > Brian, the draft appears to be saying, essentially, that we shouldn't > make the sorts of changes to the RFC series that we've proposed to > discuss here because the RFC series is an old and venerable thing and > shouldn't be changed. I don't buy it. > > The primary thing I don't buy is that "RFC" still means "request for > comments". At some level, sure, it does, because people can and will > comment on RFCs, submit errata reports, and so on. But most of the > world thinks of RFCs as IETF standards, with some subset understanding > that the series also contains informational and experimental stuff. > The comment period, really, is during the development of the Internet > Drafts. One only needs to look at the strict scrutiny performed by > the IESG to see that the bar for getting to RFC is well beyond that > warranted for the publication of a request for comments. > > As to ownership, I agree that the series is owned by "the community", > and it's exactly that community we're calling on for discussion of > proposed changes. If we think that, for example, the IRTF is being > short-changed here, we have only to publicize this discussion to the > IRTF an ask them to come be part of it. The same goes for any other > sub-community we think isn't adequately represented. > > Apart from that, I see little substance in the draft about your > objection to considering the sort of change proposed here (apart from > the "request for comments" part). Can you be clearer, not about the > history of the RFC series, but about specifically why you think such a > change would be bad? > > Barry > > On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter > wrote: >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-carpenter-request-for-comments-00.txt >> Date: Tue, 05 Jun 2018 20:16:12 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Request for Comments >> Author : Brian Carpenter >> Filename : draft-carpenter-request-for-comments-00.txt >> Pages : 7 >> Date : 2018-06-05 >> >> Abstract: >> This document discusses the Internet technical community's common >> document series. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 >> https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Wed Jun 6 14:27:20 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC3A130DD8 for ; Wed, 6 Jun 2018 14:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 ryE3DTjxOCNu for ; Wed, 6 Jun 2018 14:27:12 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 02B4C130DD3 for ; Wed, 6 Jun 2018 14:27:12 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id c23-v6so5051744uan.3 for ; Wed, 06 Jun 2018 14:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iXB7Je1NctTbMY6iYsfh5ebU9RoAxIT69N7Vbz2Vh38=; b=Dzi1TDNIH3wh962hse0qi3LPmSR8P2r4CBPAwLvopq1UEAC2WoOPEwkc9e5JCbmRWu ewLa1vSSqf5sO1We9kk8EoDsTdlH420xkRNW0fAV1VninPvbEofKaULKhzvRqUI7jfmQ YgTT1brK5JPkBJyxuKSZwXFuSBlJms9RmxgRM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iXB7Je1NctTbMY6iYsfh5ebU9RoAxIT69N7Vbz2Vh38=; b=V6aC1op7heBGi3yCdG8NlSiuokb2JMXGewnYra4WWXiDXtVPcDXCRkknG3uxrPnF1B FbWukM3yWEE7+xsY/h1vs0Exh7Ppkh9AYblyKEePlsEm2k8ZG7l0rKtpCMEre1jlgl+O bOEEhWBn+NgjzF7IvaMQlFiLTTRdesd0Z7JfQlIVYYqlPyqEQwWoQM6xlEVOvGWZOLSw IbI+nu4G39H4Xg19GIvlygGJfrtnh+hUEpsp8xcJGYAuTzJUJp71DFphEaZZDduh6MV/ q+XxKvGb1pbPz/h3zJCXB6Ro+D026sC71K0NcLZba1OmwK/symFe8r3lBTnw5sKuGIjA Fzjg== X-Gm-Message-State: APt69E3uGOfu4qNo5Cxzh2yyCsXKsg3g8O7Z4YKB9Qj1nxSH2dh2kEZl DlT0TA4nCDWZySmPUvOlCYZRsD+vQEruTn+32KsQQA== X-Google-Smtp-Source: ADUXVKL1Lvlo8Qf3QPp80QZ3Qb3Woy8juXY58x3xnt68N+gqhtdcWKS48W2/goPTEmeION8fZullrOUR/14PYc+OH4M= X-Received: by 2002:a9f:2048:: with SMTP id 66-v6mr3053059uam.76.1528320430705; Wed, 06 Jun 2018 14:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:1981:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 14:26:50 -0700 (PDT) In-Reply-To: <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> From: Joseph Lorenzo Hall Date: Wed, 6 Jun 2018 17:26:50 -0400 Message-ID: To: Brian E Carpenter Cc: Barry Leiba , rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 21:27:18 -0000 I could also use some clarification, Brian. My take away from the draft was, "we have a bunch of ongoing experiments, it would not be wise to start another one until those have completed". What am I missing? On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter wrote: > I'm out of time at this moment, but no, that isn't the argument. > > The argument is that having a single document series that is specifically > named as not being dogma is the right thing to do. > > Better labels are a good idea, within that series, for sure. > > Regards > Brian > > On 06/06/2018 22:24, Barry Leiba wrote: >> Brian, the draft appears to be saying, essentially, that we shouldn't >> make the sorts of changes to the RFC series that we've proposed to >> discuss here because the RFC series is an old and venerable thing and >> shouldn't be changed. I don't buy it. >> >> The primary thing I don't buy is that "RFC" still means "request for >> comments". At some level, sure, it does, because people can and will >> comment on RFCs, submit errata reports, and so on. But most of the >> world thinks of RFCs as IETF standards, with some subset understanding >> that the series also contains informational and experimental stuff. >> The comment period, really, is during the development of the Internet >> Drafts. One only needs to look at the strict scrutiny performed by >> the IESG to see that the bar for getting to RFC is well beyond that >> warranted for the publication of a request for comments. >> >> As to ownership, I agree that the series is owned by "the community", >> and it's exactly that community we're calling on for discussion of >> proposed changes. If we think that, for example, the IRTF is being >> short-changed here, we have only to publicize this discussion to the >> IRTF an ask them to come be part of it. The same goes for any other >> sub-community we think isn't adequately represented. >> >> Apart from that, I see little substance in the draft about your >> objection to considering the sort of change proposed here (apart from >> the "request for comments" part). Can you be clearer, not about the >> history of the RFC series, but about specifically why you think such a >> change would be bad? >> >> Barry >> >> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter >> wrote: >>> -------- Forwarded Message -------- >>> Subject: I-D Action: draft-carpenter-request-for-comments-00.txt >>> Date: Tue, 05 Jun 2018 20:16:12 -0700 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Request for Comments >>> Author : Brian Carpenter >>> Filename : draft-carpenter-request-for-comments-00.txt >>> Pages : 7 >>> Date : 2018-06-05 >>> >>> Abstract: >>> This document discusses the Internet technical community's common >>> document series. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 >>> https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ >>> Rfcplusplus mailing list >>> Rfcplusplus@ietf.org >>> https://www.ietf.org/mailman/listinfo/rfcplusplus >> > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Wed Jun 6 16:21:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF3A130E09 for ; Wed, 6 Jun 2018 16:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, 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 d7f8gIDuu3Vu for ; Wed, 6 Jun 2018 16:20:52 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 1D3BD130DFC for ; Wed, 6 Jun 2018 16:20:52 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 76-v6so10448572itx.4 for ; Wed, 06 Jun 2018 16:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yXei6BHJAwVxPUaCKskgptCSGkypIy/i3GmRrrlBodk=; b=D57oSyUNBEcUm0+KftEfiGVMmOcXYy3jwdF9hVq6yvtQtttDqAyCGVhNtW9Gfgjkzu bK7vzXm+IogxPoITP9q46gXfZ27jFBH3pIdpB8K4FsuEodK4941EIytlgWOAMSLXydtI As7wSnwIscj1F4d8sPLWWnLwso1V2jGyeiNPKL7TQTkhPJmPTJxKfJ+IYK+Cbxt1f3U6 Vq7OHc/Bz2fTZCVHsGzACsumzElNXobRd9CcMLNlFEknpq3yriMYchCXmM0euFhfxWco HsnTMoHGo3p3VVpVRRHzRUAwL/bTcBUn/xXN7dcVlDF248KBf0+MR0/jhCenkvg8rJu8 NV2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yXei6BHJAwVxPUaCKskgptCSGkypIy/i3GmRrrlBodk=; b=eGWVpubCQCqNJE4IQk8emBakd94pUJT0K+BfSJBHAiVj5H0XVqvanKav1q2W+tSEJ/ 7XC1NdPDeNLaCACMJtg2Di72WiN/4W2MfiCISmAzCZbU6PF/EM3zkain115WtvH4MWiD m+NfYZEOhEl+7KaxW6N7QWCrcyTy04No0vVTRiXmHSgwZRdzIGUb3dlGjXoVluBdtRRy a+sy7Qd4WwE9j0bjc9phB32jJV+TTnSDRNKS3/6E9r1t1yiiExkkl3K9wpu8aPZLnp9l gIoCareSbtAAxjSGw/dcLAKS0rk3klkHrUrZnIrmQRGIcCMhVc5GHgVxgAVPLdZfoIRb ++Xg== X-Gm-Message-State: APt69E2zO9LqI1wFbxEPjXvZ+iYOMFKsxjWGvKXnQCVO+zmXYTVkTuin 6+Pn9MFvgkADDJurY5FvqQ2VdtcL3zXpAVVOShruLQ== X-Google-Smtp-Source: ADUXVKK/vPiGz1RbFp09AIUiQIXWHxtP0UrtjFBvqYvi1jvg4BzI5nHW4jISr36cEmm0aa2Trufx0mys/0FGLwHC3mw= X-Received: by 2002:a24:e10d:: with SMTP id n13-v6mr4597504ith.83.1528327251399; Wed, 06 Jun 2018 16:20:51 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8ea1:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 16:20:50 -0700 (PDT) In-Reply-To: <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> From: Barry Leiba Date: Wed, 6 Jun 2018 19:20:50 -0400 X-Google-Sender-Auth: CIp44mm1tlIGBtYZmdVnCueE2Oo Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 23:20:57 -0000 > The argument is that having a single document series that is specifically > named as not being dogma is the right thing to do. OK, I got that; thanks. Unfortunately, that's a matter of opinion that we differ on, and I think it's likely that neither of us is going to convince the other. Barry From nobody Wed Jun 6 16:34:16 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2152131011 for ; Wed, 6 Jun 2018 16:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, 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 xt-BqSs0MSDD for ; Wed, 6 Jun 2018 16:34:03 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 35931131026 for ; Wed, 6 Jun 2018 16:34:01 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id u4-v6so9686124iof.2 for ; Wed, 06 Jun 2018 16:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zlp+NL8eTIcpBb28BLjFQWwXwraOFiu5HbLBAEBbDvQ=; b=R7keuVbn12JPvLVX0vstRjXtdalluqp0XeJVs1siTqJaDNiLUbrdiUJlMJMWLt+it4 xOowIG59LTtErVnX8dXG6lh3YNthNyKjc7Lz1Yxf/eWfJZXA8dy3N+DmsI6H9LHLZyYN JeX+hEV0OSTYiwR2OISMajUi8Xhfc2WZSaMd8WYugzBkqKNW5m9HPCg7/DENbBcRpQVW i59DCXGeq4DBOmxPbSjhANOJGcKMZ6xLq0cgD4QewvZsRiAbMLXkuv8pmAKu4M2p201i rwyYKWdiAvYKkARQBm0Fo87anUfctATbxiVT5U/OkEH8WVPqjYSmapd1Cuh+VIpZAbvs gvgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zlp+NL8eTIcpBb28BLjFQWwXwraOFiu5HbLBAEBbDvQ=; b=Wh0TFeDdVRZ78wgP+C4/Y26qbfoM/0AIoVivOuqPvf6Mor62XH8YDSlXF05t+ov7qY eXQB4m2iZ46cqeyquVcsqOZVfRLCTz/8P2CrT964/4RbkSKCRz6WL4vjo984JiFMbe4r DwInxeo4mqkF0Z0fUdYdsrPQGU6kL5Ml9BwAgfpnOWztR1u6LuTLnJdoW41fMFGQ9OSB 5Gl0mr5o1QHoB6xDgINpWAHvklWWIksPRxedRwhJikMklqgoXsG4o6enYZaZaXsrSDCL sLtiZc3Q/R1oLCWT5wj6BbnqWlqVNeapImwxjlL9oycuy65CrGhuvQXPtS80irAT2JaV iyBw== X-Gm-Message-State: APt69E0rwjl8psn05TG4TSGwLQeUBjEmJzq0vSOYrM6tVAotaJS9lyPi omdK94Pe3flnXMVNRO0zcT4sBAGWW1dBSC2OqJvTiw== X-Google-Smtp-Source: ADUXVKLwWyCV6gW2YwvPym4lntKQIZ0Q3x7wl8Z+cwcU+NvYZyy02Ir86EqXqpdSZpbkljnjy0NbcRAUZJ1VfkqnEUs= X-Received: by 2002:a6b:bec3:: with SMTP id o186-v6mr5385435iof.147.1528328040420; Wed, 06 Jun 2018 16:34:00 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8ea1:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 16:33:59 -0700 (PDT) In-Reply-To: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> From: Barry Leiba Date: Wed, 6 Jun 2018 19:33:59 -0400 X-Google-Sender-Auth: CdM3hj99QGr-xotDrln_x3eQ03g Message-ID: To: Paul Hoffman Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 23:34:12 -0000 >> I have experience with (1) perceptions that Informational and >> Experimental IETF-stream RFCs are standards, along with demands that >> they be implemented, (2) perceptions that IAB-stream RFCs are BCPs >> that must be followed, and, probably worst, (3) perceptions that >> Independent-stream Informational documents that got little review and >> no consensus are standards, along with demands that they be >> implemented. > > What was the outcome of those misperceptions? How much different was it than > if those people had correctly the perceived that the documents they were > looking at were not standards? A fair pair of questions, with a common answer. One situation for the first -- one I was closely involved in and can remember the details of -- was that the customers said something to marketing sorts, who brought back to technical marketing support that "the customer wants to know why we don't have the LMNOP standard implemented." The tech support folks looked around and also didn't realize the problem and it bubbled its way around until it eventually got to the product management, who thought we'd missed something basic and took it to the developers. We finally explained to them that it was an experimental protocol, not a standard, and wasn't meant to be widely implemented in products... and why did the customer want it in the first place. No one seemed to know the answer to that last question, and it took us a while to get the mid-level managers to understand why we shouldn't put it into the product. It was similarly annoying to get the explanation to the marketing folks, and then eventually back to the customer reps, who told the customer. Apparently, someone on the customer side had read about LMNOP and saw that it was RFC 9876, and expected a company as savvy as IBM to have implemented this latest stuff, so a bit more hand-holding and re-explanation was needed before the flak stopped. In the end, it all worked out. But a good bit of time was wasted that would not have been wasted if the customer hadn't seen "RFC" and thought that it was an IETF standard. Just one case study. The other situations I remember were less of a big deal, but were generated from the same misunderstanding. Explanations were quicker and more brief, and responded to with, more or less, "Ah, OK." Barry From nobody Wed Jun 6 17:00:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C9D131028 for ; Wed, 6 Jun 2018 16:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 8hpvyUFtywfl for ; Wed, 6 Jun 2018 16:59:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 30D9F130E05 for ; Wed, 6 Jun 2018 16:59:54 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w56Nxnja062210 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Jun 2018 18:59:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Barry Leiba , Paul Hoffman Cc: rfcplusplus@ietf.org References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> From: Adam Roach Message-ID: <64facdf3-6c1d-366e-9490-911652a72e26@nostrum.com> Date: Wed, 6 Jun 2018 18:59:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 23:59:58 -0000 If we're collecting anecdotes, I want to point out that my experience lines up with Barry's. I've worked on multiple RFPs that included spreadsheets from the customer asking, line by line, for product compliance with long lists of RFCs. These lists included informational documents, IETF process documents, and experimental documents. Although I didn't run into quite the level of difficulty as the first situation Barry describes, I've had plenty of situations congruent with what he describes in his final paragraph. I also have a somewhat cloudy recollection of finding a mailing list thread involving an argument among Linux kernel developers regarding implementation of an experimental RFC that was not intended for widespread public use. One side argued that the kernel implementation was incomplete without it ("you're not RFC compliant") while the other tried to explain that you don't have to implement all RFCs to comply with a protocol, and that some are, in fact, potentially harmful to deploy widely. I wish I could recall the exact topic so as to find the thread again, but it's been a relatively long time since I came across this. /a On 6/6/18 6:33 PM, Barry Leiba wrote: >>> I have experience with (1) perceptions that Informational and >>> Experimental IETF-stream RFCs are standards, along with demands that >>> they be implemented, (2) perceptions that IAB-stream RFCs are BCPs >>> that must be followed, and, probably worst, (3) perceptions that >>> Independent-stream Informational documents that got little review and >>> no consensus are standards, along with demands that they be >>> implemented. >> What was the outcome of those misperceptions? How much different was it than >> if those people had correctly the perceived that the documents they were >> looking at were not standards? > A fair pair of questions, with a common answer. > > One situation for the first -- one I was closely involved in and can > remember the details of -- was that the customers said something to > marketing sorts, who brought back to technical marketing support that > "the customer wants to know why we don't have the LMNOP standard > implemented." The tech support folks looked around and also didn't > realize the problem and it bubbled its way around until it eventually > got to the product management, who thought we'd missed something basic > and took it to the developers. > > We finally explained to them that it was an experimental protocol, not > a standard, and wasn't meant to be widely implemented in products... > and why did the customer want it in the first place. No one seemed to > know the answer to that last question, and it took us a while to get > the mid-level managers to understand why we shouldn't put it into the > product. It was similarly annoying to get the explanation to the > marketing folks, and then eventually back to the customer reps, who > told the customer. > > Apparently, someone on the customer side had read about LMNOP and saw > that it was RFC 9876, and expected a company as savvy as IBM to have > implemented this latest stuff, so a bit more hand-holding and > re-explanation was needed before the flak stopped. > > In the end, it all worked out. But a good bit of time was wasted that > would not have been wasted if the customer hadn't seen "RFC" and > thought that it was an IETF standard. > > Just one case study. The other situations I remember were less of a > big deal, but were generated from the same misunderstanding. > Explanations were quicker and more brief, and responded to with, more > or less, "Ah, OK." > > Barry > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Wed Jun 6 17:09:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0764130E05 for ; Wed, 6 Jun 2018 17:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2TXM5gGm-S1a for ; Wed, 6 Jun 2018 17:09:38 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 1D4BB130E04 for ; Wed, 6 Jun 2018 17:09:38 -0700 (PDT) Received: from [10.32.60.93] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w5708Ya8015686 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jun 2018 17:08:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.93] From: "Paul Hoffman" To: "Adam Roach" Cc: "Barry Leiba" , rfcplusplus@ietf.org Date: Wed, 06 Jun 2018 17:09:32 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: <64facdf3-6c1d-366e-9490-911652a72e26@nostrum.com> References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> <64facdf3-6c1d-366e-9490-911652a72e26@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 00:09:41 -0000 >> What was the outcome of those misperceptions? How much different was >> it than >> if those people had correctly the perceived that the documents they >> were >> looking at were not standards? On 6 Jun 2018, at 16:59, Adam Roach wrote: > If we're collecting anecdotes, I want to point out that my experience > lines up with Barry's. I've worked on multiple RFPs that included > spreadsheets from the customer asking, line by line, for product > compliance with long lists of RFCs. These lists included informational > documents, IETF process documents, and experimental documents. > Although I didn't run into quite the level of difficulty as the first > situation Barry describes, I've had plenty of situations congruent > with what he describes in his final paragraph. > > I also have a somewhat cloudy recollection of finding a mailing list > thread involving an argument among Linux kernel developers regarding > implementation of an experimental RFC that was not intended for > widespread public use. One side argued that the kernel implementation > was incomplete without it ("you're not RFC compliant") while the other > tried to explain that you don't have to implement all RFCs to comply > with a protocol, and that some are, in fact, potentially harmful to > deploy widely. I wish I could recall the exact topic so as to find the > thread again, but it's been a relatively long time since I came across > this. So, for the first question, the outcome in these cases was "we had to explain the situation to the customers and they eventually (and possibly grumpily) understood". I am not sure what the answer to the second question would be, particularly for that first story. They were obviously pulling at "IETF documents", not standards, so if they existed in different series, it sounds like the result might have been the same. --Paul Hoffman From nobody Wed Jun 6 17:22:57 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8D8131030 for ; Wed, 6 Jun 2018 17:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 ClIuKi9fTXTk for ; Wed, 6 Jun 2018 17:22:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9B1A413102D for ; Wed, 6 Jun 2018 17:22:46 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w570MiKV065978 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Jun 2018 19:22:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Paul Hoffman Cc: Barry Leiba , rfcplusplus@ietf.org References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> <64facdf3-6c1d-366e-9490-911652a72e26@nostrum.com> From: Adam Roach Message-ID: <02606336-e510-d53f-ad2f-ed35d3b2bd76@nostrum.com> Date: Wed, 6 Jun 2018 19:22:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 00:22:55 -0000 On 6/6/18 7:09 PM, Paul Hoffman wrote: > ...it sounds like the result might have been the same. One runs experiments to test hypotheses. Your gut-feel "might" is only very vaguely aligned with my gut feel "probably would not" on this point, in that they both leave room for the other possibility to be true. /a From nobody Wed Jun 6 17:51:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD3C130E0E for ; Wed, 6 Jun 2018 17:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pKu9_JhuqtGH for ; Wed, 6 Jun 2018 17:51:34 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 525A6130E02 for ; Wed, 6 Jun 2018 17:51:34 -0700 (PDT) Received: from [10.32.60.93] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w570oVVI017295 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jun 2018 17:50:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.93] From: "Paul Hoffman" To: "Adam Roach" Cc: "Barry Leiba" , rfcplusplus@ietf.org Date: Wed, 06 Jun 2018 17:51:30 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: <601FD4A2-1F2E-44AD-870E-8A1A8F998495@vpnc.org> In-Reply-To: <02606336-e510-d53f-ad2f-ed35d3b2bd76@nostrum.com> References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> <64facdf3-6c1d-366e-9490-911652a72e26@nostrum.com> <02606336-e510-d53f-ad2f-ed35d3b2bd76@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 00:51:38 -0000 On 6 Jun 2018, at 17:22, Adam Roach wrote: > On 6/6/18 7:09 PM, Paul Hoffman wrote: >> ...it sounds like the result might have been the same. > > > One runs experiments to test hypotheses. Your gut-feel "might" is only > very vaguely aligned with my gut feel "probably would not" on this > point, in that they both leave room for the other possibility to be > true. It seems unlikely that we can run experiments on this. Given that, we should look at the data that we find by looking around in the environment. As pattern-seeking humans, we'll try to fit that data into useful conclusions; we'll also probably sit in the same room as others who come to different conclusions for the same data. --Paul Hoffman From nobody Wed Jun 6 19:19:07 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D4130E03 for ; Wed, 6 Jun 2018 19:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 YKvmv7BY15Y0 for ; Wed, 6 Jun 2018 19:18:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 36B7B130E14 for ; Wed, 6 Jun 2018 19:18:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D08DFCA6C24; Wed, 6 Jun 2018 19:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1528337937; bh=MAsObYBL227rffUI4ciueGmw3qy1dkqZD04FUXqxgiw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=oSEuO1H3ScPaZm1eOmYAXrv+iURGb8gtBaCP7jbVmf3JuLhmDSYv0o5/DP25NQzSK GDEkaGhJCRSZUI3W2GkTMPQp5CSBVH0Fec1UHmYoHYa0/nczKi0TgoN0w6p2diLsoQ moAYw2ZU38BKiK46NjIGd+6LhuoFzQEaJYBe0bN8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DB459CA6C15; Wed, 6 Jun 2018 19:18:56 -0700 (PDT) To: Barry Leiba , Paul Hoffman Cc: rfcplusplus@ietf.org References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> From: "Joel M. Halpern" Message-ID: Date: Wed, 6 Jun 2018 22:18:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 02:19:04 -0000 I have seen the exact sequence you describe (and worse) where the document in quesiton was an Internet Draft. I have seen this more than once. Thus, based on the evidence I have seen, changing names is unlikely to help. Yours, Joel PS: And changing names as an experiment is a recipe for more serious problems. On 6/6/18 7:33 PM, Barry Leiba wrote: >>> I have experience with (1) perceptions that Informational and >>> Experimental IETF-stream RFCs are standards, along with demands that >>> they be implemented, (2) perceptions that IAB-stream RFCs are BCPs >>> that must be followed, and, probably worst, (3) perceptions that >>> Independent-stream Informational documents that got little review and >>> no consensus are standards, along with demands that they be >>> implemented. >> >> What was the outcome of those misperceptions? How much different was it than >> if those people had correctly the perceived that the documents they were >> looking at were not standards? > > A fair pair of questions, with a common answer. > > One situation for the first -- one I was closely involved in and can > remember the details of -- was that the customers said something to > marketing sorts, who brought back to technical marketing support that > "the customer wants to know why we don't have the LMNOP standard > implemented." The tech support folks looked around and also didn't > realize the problem and it bubbled its way around until it eventually > got to the product management, who thought we'd missed something basic > and took it to the developers. > > We finally explained to them that it was an experimental protocol, not > a standard, and wasn't meant to be widely implemented in products... > and why did the customer want it in the first place. No one seemed to > know the answer to that last question, and it took us a while to get > the mid-level managers to understand why we shouldn't put it into the > product. It was similarly annoying to get the explanation to the > marketing folks, and then eventually back to the customer reps, who > told the customer. > > Apparently, someone on the customer side had read about LMNOP and saw > that it was RFC 9876, and expected a company as savvy as IBM to have > implemented this latest stuff, so a bit more hand-holding and > re-explanation was needed before the flak stopped. > > In the end, it all worked out. But a good bit of time was wasted that > would not have been wasted if the customer hadn't seen "RFC" and > thought that it was an IETF standard. > > Just one case study. The other situations I remember were less of a > big deal, but were generated from the same misunderstanding. > Explanations were quicker and more brief, and responded to with, more > or less, "Ah, OK." > > Barry > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Wed Jun 6 22:13:28 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3015130E64 for ; Wed, 6 Jun 2018 22:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yDAy2zvpgQ_P for ; Wed, 6 Jun 2018 22:13:22 -0700 (PDT) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 240F912777C for ; Wed, 6 Jun 2018 22:13:22 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id c41-v6so5287345plj.10 for ; Wed, 06 Jun 2018 22:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=X6nc40jy93kDd7IrVk7A09sSxyqcz9p+UoFLmJjo2Yk=; b=Gj5BRD0VWslH6sitV6qP/f64ILxehdtxcMzGnbgZtzl+O+hmnCSkxqL4yCvrKV7eB7 55x4j1rH1SG7kFDkSzaNnJ3Q/xV+ibCUnQEh4fzlK/LV/ceq2m7BJd0fzcCekf8ff/bd 288i/Vu93sOYwdvhwXhfxiuepTKgFzkksdDGcxl9enGmQRreuRx5wq2ft11v7UoR+9Zy grLgx7IT6MbOUuXg0YuCQ9rIcGkPnNB7YQCz+/IfT8Aee5cotwXie810nID0gKBbKf/v u98b+CryCKLpF0wLO5KxjrpxiYkt9/ebHoa9pSqgb8wvfex6htd/1Tg2rSZe+qkAfrqd r9XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=X6nc40jy93kDd7IrVk7A09sSxyqcz9p+UoFLmJjo2Yk=; b=d0ThmdgyLWYeopM18YzQAXnDsVmbLt+BWxLCFcPDsKlTjJNjUekvr2u5YH+TLOVa1y 2lTWk1Cb5wWHAn9r+0oM3xYau9bcMFSSOhiHTEebTN5BHDcoyRSB32Go9ft7AzpFXPR+ PWZgqeJd4rc66AgONouYIaZn8yscqAnxk+CT6qG31FgHJmS1erNocfcHAa7sxStb/d0I Dc5NRtuO+IDWOm/BIXsWmr+fBY+tb6Qbt1LOBzxp5VBTxS39civfKMyY1Ft+xrtIBhlc QSy2TcLCGUTIaPEfoFqrwN127zAS610TqW078BKac1t9alAikgt25Sfj9lLQdBlueVKv Ju3A== X-Gm-Message-State: APt69E0i3bR52ndtClERpoavn3+CaQLFplE0RqI8VPGGntSMIxvhwkXA oWYV+q4iFLK9s64QJIcYWnfCCw== X-Google-Smtp-Source: ADUXVKJNqXTWF9+u2XYooxoii5070V2AqSNB3p63hEGDa1g4WjmgWk5l5Gg3AHEafSw3M0yjZrmi8w== X-Received: by 2002:a17:902:8d85:: with SMTP id v5-v6mr458897plo.93.1528348401304; Wed, 06 Jun 2018 22:13:21 -0700 (PDT) Received: from [10.2.0.117] ([131.203.242.18]) by smtp.gmail.com with ESMTPSA id l14-v6sm18391563pfi.6.2018.06.06.22.13.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 22:13:20 -0700 (PDT) To: Joseph Lorenzo Hall Cc: Barry Leiba , rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 7 Jun 2018 17:13:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 05:13:26 -0000 On 07/06/2018 09:26, Joseph Lorenzo Hall wrote: > I could also use some clarification, Brian. My take away from the > draft was, "we have a bunch of ongoing experiments, it would not be > wise to start another one until those have completed". What am I > missing? That is one of the takeaways. Let's figure out why past attempts, especially the STD designation, haven't fixed a problem that was first documented in 1994. Probably the problem is deeper than just document labels, so let's figure out the problem too. This can't be very urgent, because we've managed for the last 24 years. There are at least two other points too: 1. The RFC series belongs to everybody, not just to the IETF. So we can't unilaterally decide for everbody. 2. It is good for the IETF to be fundamentally modest and open to feedback about its work. Calling all our documents "request for comments" is therefore highly appropriate. Regards Brian > > On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter > wrote: >> I'm out of time at this moment, but no, that isn't the argument. >> >> The argument is that having a single document series that is specifically >> named as not being dogma is the right thing to do. >> >> Better labels are a good idea, within that series, for sure. >> >> Regards >> Brian >> >> On 06/06/2018 22:24, Barry Leiba wrote: >>> Brian, the draft appears to be saying, essentially, that we shouldn't >>> make the sorts of changes to the RFC series that we've proposed to >>> discuss here because the RFC series is an old and venerable thing and >>> shouldn't be changed. I don't buy it. >>> >>> The primary thing I don't buy is that "RFC" still means "request for >>> comments". At some level, sure, it does, because people can and will >>> comment on RFCs, submit errata reports, and so on. But most of the >>> world thinks of RFCs as IETF standards, with some subset understanding >>> that the series also contains informational and experimental stuff. >>> The comment period, really, is during the development of the Internet >>> Drafts. One only needs to look at the strict scrutiny performed by >>> the IESG to see that the bar for getting to RFC is well beyond that >>> warranted for the publication of a request for comments. >>> >>> As to ownership, I agree that the series is owned by "the community", >>> and it's exactly that community we're calling on for discussion of >>> proposed changes. If we think that, for example, the IRTF is being >>> short-changed here, we have only to publicize this discussion to the >>> IRTF an ask them to come be part of it. The same goes for any other >>> sub-community we think isn't adequately represented. >>> >>> Apart from that, I see little substance in the draft about your >>> objection to considering the sort of change proposed here (apart from >>> the "request for comments" part). Can you be clearer, not about the >>> history of the RFC series, but about specifically why you think such a >>> change would be bad? >>> >>> Barry >>> >>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter >>> wrote: >>>> -------- Forwarded Message -------- >>>> Subject: I-D Action: draft-carpenter-request-for-comments-00.txt >>>> Date: Tue, 05 Jun 2018 20:16:12 -0700 >>>> From: internet-drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> >>>> Title : Request for Comments >>>> Author : Brian Carpenter >>>> Filename : draft-carpenter-request-for-comments-00.txt >>>> Pages : 7 >>>> Date : 2018-06-05 >>>> >>>> Abstract: >>>> This document discusses the Internet technical community's common >>>> document series. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 >>>> https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> _______________________________________________ >>>> Rfcplusplus mailing list >>>> Rfcplusplus@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rfcplusplus >>> >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus > > > From nobody Wed Jun 6 22:23:08 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336ED12F18C for ; Wed, 6 Jun 2018 22:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 6e6V5SxAesn9 for ; Wed, 6 Jun 2018 22:23:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 875B5130E37 for ; Wed, 6 Jun 2018 22:23:02 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w575MxpS013834 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Jun 2018 00:23:00 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Barry Leiba Cc: rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> From: Adam Roach Message-ID: <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> Date: Thu, 7 Jun 2018 00:22:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 05:23:06 -0000 On 6/6/18 3:33 PM, Brian E Carpenter wrote: > Better labels are a good idea, within that series, for sure. As a thought experiment (and taking care to note that I am not proposing this, merely laying it out as a hypothetical): Would you be opposed to the prospect of issuing no further documents with designations of RFCXXXX, and instead starting the numbering over with, say, RFC-S0001, RFC-B0001, RFC-N0001, RFC-I0001, RFC-E0001, RFC-R0001, and RFC-A0001 for "standard", "BCP", "informational", "ISE", "experimental", "IRTF", and "IAB", respectively? /a From nobody Wed Jun 6 22:44:27 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFCB130E1C for ; Wed, 6 Jun 2018 22:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JG2k8-uG2ClM for ; Wed, 6 Jun 2018 22:44:22 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 0164B12F18C for ; Wed, 6 Jun 2018 22:44:21 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id r11-v6so4320455pfl.6 for ; Wed, 06 Jun 2018 22:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zw1obkf/tB7zWqR7IikJ8mu9WNGdVtpXhaMXfRdN60A=; b=lhhVwrufpQtILWLxSPCkOzTgFhr2SdsoN950GrOJG3XtV4knYVAHk5NOyZoLwc8PaY Yzces8vPV13XYZ4ViRFKlteJRB8Hy0GM/YR5t0Dp+30m0kDDK6WzcesDVuON+4/YtkhT VA2lJ0MMtoGQgclrcfWK/o3/BiAdIhv2GlBpoXdeSgkaXFem+bMM9RvJyeYh+K1lnP+u EFNOOsM3hCYSvFFqUeVGMFoms/eBopGGd0/gQJj8ok865PYKYmvs2/SU3fGRuIKaioEP 4g2BpKNcs9zxkkUpM3sWx02RaiQJ35UXqGhs67WTaty4cYc6lSsucL7Mr26l9BMbNtTQ +Y9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zw1obkf/tB7zWqR7IikJ8mu9WNGdVtpXhaMXfRdN60A=; b=bpCFOTS2HnltceDx4HKvC0HnzSFWnt0/L5USB1peeJwpGlUHo4W+fdxjn8JuDFC9cl uLvGqoZgZeljSl2Ex0lYqsnrXsxpZ0CKpfFcp443LIVto+CBQuGzcZOwxNs5Wlh3nV/Q MFAGFOMsXc6kKT5vgf3wTYwROCLnyUR94ZVhxdl6bS9BMQiZF+COTJgJB/+GR62pFdDK 4Jnz8YijMr7PsTSVTbgfHYfjbkAHIkfynf2DREAvva8dDEtDcTDI3XVDZFf0Prce7Jo8 SWghIXqHFfcFKWeOvJILWlguY9lV4B84VlxYpbJmevqYSJxrJzY7KY7SaBxujf+qAQR+ v3qQ== X-Gm-Message-State: APt69E223+1w5LmZXopYm1m9Z1I6ZqClMhAjHfQCbqJmMMc40y6Xl0dk 0qdF1HJNpXvcU9CcvrIGn0LvXQ== X-Google-Smtp-Source: ADUXVKItgtlItH+ktTx8fl7yprYCi0BdShNMz5d8DT5YySygn/u/hD7DEBAPCxR59CmoIJz+TYlYLA== X-Received: by 2002:a63:a44a:: with SMTP id c10-v6mr421696pgp.198.1528350261096; Wed, 06 Jun 2018 22:44:21 -0700 (PDT) Received: from [10.2.0.117] ([131.203.242.18]) by smtp.gmail.com with ESMTPSA id z25-v6sm103605698pfi.171.2018.06.06.22.44.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 22:44:20 -0700 (PDT) To: Adam Roach , Barry Leiba Cc: rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> From: Brian E Carpenter Message-ID: <375bf4a5-8122-3f9c-89f5-50d7b9da2a3c@gmail.com> Date: Thu, 7 Jun 2018 17:44:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 05:44:26 -0000 On 07/06/2018 17:22, Adam Roach wrote: > On 6/6/18 3:33 PM, Brian E Carpenter wrote: >> Better labels are a good idea, within that series, for sure. > > > As a thought experiment (and taking care to note that I am not proposing > this, merely laying it out as a hypothetical): Would you be opposed to > the prospect of issuing no further documents with designations of > RFCXXXX, and instead starting the numbering over with, say, RFC-S0001, > RFC-B0001, RFC-N0001, RFC-I0001, RFC-E0001, RFC-R0001, and RFC-A0001 for > "standard", "BCP", "informational", "ISE", "experimental", "IRTF", and > "IAB", respectively? a) I'm sure the details of that could stand a great deal of bike-shedding, but let's ignore that for now. b) I don't want to form a firm opinion instantly, but I think this is the sort of re-labelling exercise that might bridge the gap. Certainly it's worth discussion (but I stick to the idea that we need to be clear about the problems we're trying to solve). Brian From nobody Wed Jun 6 22:52:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5266C130E27 for ; Wed, 6 Jun 2018 22:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 b3vQm6vub-8j for ; Wed, 6 Jun 2018 22:51:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4569A12F18C for ; Wed, 6 Jun 2018 22:51:52 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w575pmfG018431 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Jun 2018 00:51:50 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Barry Leiba Cc: rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> <375bf4a5-8122-3f9c-89f5-50d7b9da2a3c@gmail.com> From: Adam Roach Message-ID: Date: Thu, 7 Jun 2018 00:51:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <375bf4a5-8122-3f9c-89f5-50d7b9da2a3c@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 05:51:57 -0000 On 6/7/18 12:44 AM, Brian E Carpenter wrote: > On 07/06/2018 17:22, Adam Roach wrote: >> On 6/6/18 3:33 PM, Brian E Carpenter wrote: >>> Better labels are a good idea, within that series, for sure. >> >> As a thought experiment (and taking care to note that I am not proposing >> this, merely laying it out as a hypothetical): Would you be opposed to >> the prospect of issuing no further documents with designations of >> RFCXXXX, and instead starting the numbering over with, say, RFC-S0001, >> RFC-B0001, RFC-N0001, RFC-I0001, RFC-E0001, RFC-R0001, and RFC-A0001 for >> "standard", "BCP", "informational", "ISE", "experimental", "IRTF", and >> "IAB", respectively? > a) I'm sure the details of that could stand a great deal of bike-shedding, > but let's ignore that for now. > > b) I don't want to form a firm opinion instantly, but I think this > is the sort of re-labelling exercise that might bridge the gap. > Certainly it's worth discussion (but I stick to the idea that we > need to be clear about the problems we're trying to solve). Thanks. I was hoping to see if I could tease some of your concerns apart, and I think your reaction -- that is, the fact that you didn't reply with "that has largely the same problems as the existing proposal" -- is very helpful in understanding your primary objections. /a From nobody Wed Jun 6 23:21:33 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCDA12777C for ; Wed, 6 Jun 2018 23:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5F2M8C-bmEt9 for ; Wed, 6 Jun 2018 23:21:27 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 CA5CA126DBF for ; Wed, 6 Jun 2018 23:21:26 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id t22-v6so7564557oih.6 for ; Wed, 06 Jun 2018 23:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1fNGua15E27e4AFo1MBrIVu+8wcdLQJeKxK0UUpA1us=; b=D5KmlV1Bb7qaJcwpOkeoHVOGkpbwJiz6uzjY0B2ozKRtdOZT9lsnTi+Od9a6REDEVb PRalTpXWovKZe2rT7UTopFYKJ+UxkLD3ApG9qSTQamPnI1lpRCCjtIG0m/1KXXFmOhIU K8SskcwuWQxFr45O04fgxMMQ1ZjPVHpoV+czmk3rVlLFQ3NR9wRtT4bXHkQ7lyGR3I47 bWZGrPmoWJoizpvh8KnOMPl22v9clkx8eS3AvMVpxpLIsALA4DYXMOCU5+/EPxDljC1s nGI0qyVFgxU/kpniAYFxlKSzUgFca4+Q8RmGzsSD/Q8nT8+pEgsXj4myLd6gXaFrZvNx wuCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1fNGua15E27e4AFo1MBrIVu+8wcdLQJeKxK0UUpA1us=; b=SwXW5cpoC9RmSMw0xYOdyQDiywMipXGEiKRss/EE/QdOvsdzH6lTIh9t2S3/ECYELb T7/Upi2wD2rpJVHeTaKUm6EHTyII4M5V1dPFdyNWD6ExOtV2XTvIo9dLGWUenm4xKNW5 SvZ8hqeY2cC/1OEdPPGLzBmO6ihWgyOKcXC4oHS9nq715dnl5cVKLLj/gqQ0xriJh16L VX4f4BmJjayTealGk32c6SHdK0NBp8FGSm0V4lQq9u9vGizoPGKlFnH6qvyZG53wuOr0 DHqHLM8N4Gw2FEFp8Nx4hO4f6RSvFu8ZaRmYPPKydDSyhk5QSCIjthjKGxRhuyFmorAU OSKw== X-Gm-Message-State: APt69E3QaBOH/QidkrFRJlJZs6wRURk8+2bS2oKiVGlgajyDgUMn1lJu L/u6HRvDRJleO13LrYotJ1LMo8IRsUcBA+kdNlo= X-Google-Smtp-Source: ADUXVKLO+me9t18JE7ulP5SefJpLalqmRBIPAclxWzbTZdjo7WYv6egxtUozrr+/++7BqP+IpvZiQBnpHNbwoFvPwTU= X-Received: by 2002:aca:5c89:: with SMTP id q131-v6mr222476oib.154.1528352486091; Wed, 06 Jun 2018 23:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 23:21:05 -0700 (PDT) In-Reply-To: References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> From: "Andrew G. Malis" Date: Thu, 7 Jun 2018 02:21:05 -0400 Message-ID: To: "Joel M. Halpern" Cc: Barry Leiba , Paul Hoffman , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000067047056e074be0" Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 06:21:32 -0000 --000000000000067047056e074be0 Content-Type: text/plain; charset="UTF-8" I was just about to make Joel's last point in response to an earlier email. If we deem the "experiment" a failure, how do we go back? Do we reissue all of the non-RFCs as RFCs? I would be much happier with us working on a very clear set of text to put into the first page of each RFC, so that if anyone were to take the trouble to read it, they would see a statement like: THIS DOCUMENT DEFINES AN EXPERIMENT THAT IS NOT INTENDED FOR WIDESPREAD USE IN OPERATIONAL NETWORKS. or THIS DOCUMENT IS FOR INFORMATION ONLY, AND DOES NOT SPECIFY AN IETF-APPROVED PROTOCOL. or THIS DOCUMENT REPRESENTS THE CONSENSUS OF THE IETF AND HAS BEEN PROPOSED TO BECOME AN IETF STANDARD. or THIS DOCUMENT IS AN IETF STANDARD. Whatever we agree on for the wording, it should be shouted at the reader in all caps, and in bold as well once we support styled text, with a box around it ... whatever we need to ensure that you can't miss it. Cheers, Andy On Wed, Jun 6, 2018 at 10:18 PM, Joel M. Halpern wrote: > I have seen the exact sequence you describe (and worse) where the document > in quesiton was an Internet Draft. I have seen this more than once. > > Thus, based on the evidence I have seen, changing names is unlikely to > help. > > Yours, > Joel > > PS: And changing names as an experiment is a recipe for more serious > problems. > > > On 6/6/18 7:33 PM, Barry Leiba wrote: > >> I have experience with (1) perceptions that Informational and >>>> Experimental IETF-stream RFCs are standards, along with demands that >>>> they be implemented, (2) perceptions that IAB-stream RFCs are BCPs >>>> that must be followed, and, probably worst, (3) perceptions that >>>> Independent-stream Informational documents that got little review and >>>> no consensus are standards, along with demands that they be >>>> implemented. >>>> >>> >>> What was the outcome of those misperceptions? How much different was it >>> than >>> if those people had correctly the perceived that the documents they were >>> looking at were not standards? >>> >> >> A fair pair of questions, with a common answer. >> >> One situation for the first -- one I was closely involved in and can >> remember the details of -- was that the customers said something to >> marketing sorts, who brought back to technical marketing support that >> "the customer wants to know why we don't have the LMNOP standard >> implemented." The tech support folks looked around and also didn't >> realize the problem and it bubbled its way around until it eventually >> got to the product management, who thought we'd missed something basic >> and took it to the developers. >> >> We finally explained to them that it was an experimental protocol, not >> a standard, and wasn't meant to be widely implemented in products... >> and why did the customer want it in the first place. No one seemed to >> know the answer to that last question, and it took us a while to get >> the mid-level managers to understand why we shouldn't put it into the >> product. It was similarly annoying to get the explanation to the >> marketing folks, and then eventually back to the customer reps, who >> told the customer. >> >> Apparently, someone on the customer side had read about LMNOP and saw >> that it was RFC 9876, and expected a company as savvy as IBM to have >> implemented this latest stuff, so a bit more hand-holding and >> re-explanation was needed before the flak stopped. >> >> In the end, it all worked out. But a good bit of time was wasted that >> would not have been wasted if the customer hadn't seen "RFC" and >> thought that it was an IETF standard. >> >> Just one case study. The other situations I remember were less of a >> big deal, but were generated from the same misunderstanding. >> Explanations were quicker and more brief, and responded to with, more >> or less, "Ah, OK." >> >> Barry >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> >> > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000067047056e074be0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was just about to make Joel's last point in response= to an earlier email. If we deem the "experiment" a failure, how = do we go back? Do we reissue all of the non-RFCs as RFCs?

I would be much happier with us working on a very clear set of text to pu= t into the first page of each RFC, so that if anyone were to take the troub= le to read it, they would see a statement like:

TH= IS DOCUMENT DEFINES AN EXPERIMENT THAT IS NOT INTENDED FOR WIDESPREAD USE I= N OPERATIONAL NETWORKS.

or

THIS DOCUMENT IS FOR INFORMATION ONLY, AND DOES NOT SPECIFY AN IETF-APPRO= VED PROTOCOL.

or

THIS DOC= UMENT REPRESENTS THE CONSENSUS OF THE IETF AND HAS BEEN PROPOSED TO BECOME = AN IETF STANDARD.

or

THIS= DOCUMENT IS AN IETF STANDARD.

Whatever we agree o= n for the wording, it should be shouted at the reader in all caps, and in b= old as well once we support styled text, with a box around it ... whatever = we need to ensure that you can't miss it.

Chee= rs,
Andy

On Wed, Jun 6, 2018 at 10:18 PM, Joel M. Halper= n <jmh@joelhalpern.com> wrote:
I have seen the exact sequence you describe (and worse) where the do= cument in quesiton was an Internet Draft.=C2=A0 =C2=A0I have seen this more= than once.

Thus, based on the evidence I have seen, changing names is unlikely to help= .

Yours,
Joel

PS: And changing names as an experiment is a recipe for more serious proble= ms.


On 6/6/18 7:33 PM, Barry Leiba wrote:
I have experience with (1) perceptions that Informational and
Experimental IETF-stream RFCs are standards, along with demands that
they be implemented, (2) perceptions that IAB-stream RFCs are BCPs
that must be followed, and, probably worst, (3) perceptions that
Independent-stream Informational documents that got little review and
no consensus are standards, along with demands that they be
implemented.

What was the outcome of those misperceptions? How much different was it tha= n
if those people had correctly the perceived that the documents they were looking at were not standards?

A fair pair of questions, with a common answer.

One situation for the first -- one I was closely involved in and can
remember the details of -- was that the customers said something to
marketing sorts, who brought back to technical marketing support that
"the customer wants to know why we don't have the LMNOP standard implemented."=C2=A0 The tech support folks looked around and also didn= 't
realize the problem and it bubbled its way around until it eventually
got to the product management, who thought we'd missed something basic<= br> and took it to the developers.

We finally explained to them that it was an experimental protocol, not
a standard, and wasn't meant to be widely implemented in products... and why did the customer want it in the first place.=C2=A0 No one seemed to=
know the answer to that last question, and it took us a while to get
the mid-level managers to understand why we shouldn't put it into the product.=C2=A0 It was similarly annoying to get the explanation to the
marketing folks, and then eventually back to the customer reps, who
told the customer.

Apparently, someone on the customer side had read about LMNOP and saw
that it was RFC 9876, and expected a company as savvy as IBM to have
implemented this latest stuff, so a bit more hand-holding and
re-explanation was needed before the flak stopped.

In the end, it all worked out.=C2=A0 But a good bit of time was wasted that=
would not have been wasted if the customer hadn't seen "RFC" = and
thought that it was an IETF standard.

Just one case study.=C2=A0 The other situations I remember were less of a big deal, but were generated from the same misunderstanding.
Explanations were quicker and more brief, and responded to with, more
or less, "Ah, OK."

Barry

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus


_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--000000000000067047056e074be0-- From nobody Wed Jun 6 23:28:59 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C5D12777C for ; Wed, 6 Jun 2018 23:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 SbFTLd82No0c for ; Wed, 6 Jun 2018 23:28:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6FD4B130E7B for ; Wed, 6 Jun 2018 23:28:52 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w576Slwl024201 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Jun 2018 01:28:48 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: "Andrew G. Malis" , "Joel M. Halpern" Cc: Barry Leiba , Paul Hoffman , rfcplusplus@ietf.org References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> From: Adam Roach Message-ID: <679126cc-e72b-aace-3374-4d5c95688b23@nostrum.com> Date: Thu, 7 Jun 2018 01:28:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 06:28:57 -0000 On 6/7/18 1:21 AM, Andrew G. Malis wrote: > I was just about to make Joel's last point in response to an earlier > email. If we deem the "experiment" a failure, how do we go back? Do we > reissue all of the non-RFCs as RFCs? The BOF description currently says: "At the end of the experiment, the community would discuss whether these stream identifiers were sufficiently useful in technical references and discussions to maintain the technical dialog among the relevant technical communities. If they are not, RFC numbers would be allocated for each document published under the experiment..." /a From nobody Wed Jun 6 23:38:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197E7130FBB for ; Wed, 6 Jun 2018 23:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kUmWGuCVzIcS for ; Wed, 6 Jun 2018 23:38:44 -0700 (PDT) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (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 2607D130E9A for ; Wed, 6 Jun 2018 23:38:44 -0700 (PDT) Received: by mail-pl0-x233.google.com with SMTP id 30-v6so5440731pld.13 for ; Wed, 06 Jun 2018 23:38:44 -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=LjCESp1PEHmLMi0TRzcC9Mi0T82EYHuOQSLYPOzYpoY=; b=CTuuFKRKcbcnasUvYKJ86sU6pmWZ4BnqDovbwJzwR758NARUo5iez+gMCn/AbO5UmB sPxD1a99tUYaA4HHXLSH3L2lbsTKYwtbeTAGmjIsXmNUvqK9BtS6w/+/PhK6rVuDymG2 RWWk9z2xTkfq3TqtESjXaxriy7A6UUM38wC4kngmBGVfbvqD/IO7T8y/kehgREq7F53m 7ZJNVHmGVmJbASKl5Dr90A4C1P3fNBnFXStkmOQc4yE0OQUQiIe7JC0JG6cICV4DvPpG y3OQ7WHjPy1MU1wHhz3OK7aAHGNEO7YBNUUAOvTneMCfm3SJOW5gxkQEK4JpKu946Fja 8krg== 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=LjCESp1PEHmLMi0TRzcC9Mi0T82EYHuOQSLYPOzYpoY=; b=sek2n8nQTne94tIz28X4fJJKAhDbslB2IIRyks3Njmvw7NKYPLVBiumLuiYln0zvWi BTLZnyKn6kXGAZvZrD3sqz2MFUXTWPQtpPWOBGSO17dUdZ0t1SsNycs6TQyCD1a0aJt4 A8F90emftkdUgQZwcvlvAWbYXxWpGLlxrwYGbk15l3VEBiu3YR22nkpXdP+NZ1KNtDmJ Xh3ioFqADDYSi1HMBrCnfg+2PxKQWfzMINcfy8mhkUG34gFdejBx6VhFZ6bAaKEDGv2P QmFV0JjZHiNXipWCH+KycRWvMbV7xFAHJWiJ1AL5VC5xx0U5u/mraLzUG8tryX8IlwCI +IdA== X-Gm-Message-State: APt69E0QUByOtiNtkuQmWOkRZ0CRBbxFldBS2Whty49BI5VQT4Jut6pv 0EHhp/bMQL7CGqRMyLhaunumcwAJ X-Google-Smtp-Source: ADUXVKLSvdwBOtjCF7exizbOZ3qdnDQ+7w4wtb1w8yyJGxLZTg/2ZrO9NnosOtKJhOAQwfvb0FMGag== X-Received: by 2002:a17:902:3081:: with SMTP id v1-v6mr719760plb.266.1528353523465; Wed, 06 Jun 2018 23:38:43 -0700 (PDT) Received: from aspen.local (63-140-99-174-radius.dynamic.acsalaska.net. [63.140.99.174]) by smtp.gmail.com with ESMTPSA id p12-v6sm5226352pfi.175.2018.06.06.23.38.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 23:38:42 -0700 (PDT) To: rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> <375bf4a5-8122-3f9c-89f5-50d7b9da2a3c@gmail.com> From: Melinda Shore Message-ID: <36d76549-da5c-c88f-f876-cd6fa61f8c63@gmail.com> Date: Wed, 6 Jun 2018 22:38:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 06:38:52 -0000 I think there's this fundamental question that perhaps drove the initial discussion leading to the BOF proposal, which is whether or not there are distinctions between categories of RFCs that matter. One that does seem consequential, for example, is the difference between documents that reflect IETF consensus and documents that do not reflect IETF consensus. If these are distinctions we care about, should that be reflected in how they're published? I'm not really in love with the proposed experiment but I do think that we're at a point in the maturity process of both the IETF and the internet more broadly that it's a discussion worth having. (I'm a little concerned that we'll end up rat-holing on the proposal, but I'm also hopeful about a well-managed discussion). Melinda From nobody Wed Jun 6 23:57:51 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5B9130E80 for ; Wed, 6 Jun 2018 23:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, 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 pvaMvrEVrVXv for ; Wed, 6 Jun 2018 23:57:46 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 6BE75130E7E for ; Wed, 6 Jun 2018 23:57:46 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id a3-v6so11358596itd.0 for ; Wed, 06 Jun 2018 23:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vVhOwGT4VuwMTi1+kUfBD0mqrtXcDcbYML+UaXtVtD8=; b=Hx83bUA7gVZ9TZM7egjxpav/lmmXt2Edr6K7xrRr5dkJlzNaQZ1qDSxN/ysJdu/NFZ 1BDg492W3e0I/rjBMLVp5tqrW+L+RsvAJ1B/MV0swD3ql2VMZhM60cpvM/zxWFDNQyE3 PGVHSeJeSlDI3rKRiCmHyV22b2MtoCRwBu1RNRYpM+mrhBRUIcb+nXGzNbxUI6wRMnlk N1LGGMFH+U82WFdhCvkoDBMjPt2Z3iIpsHSBRpEin+UfZj9MNazUIZQVl713pws0wTZg H9yfLMXxpyI/K7dFdSy1cozAvEY6JimxYyYeCFQWPOXg7pG4AZ/NQnseya4iqDkzrBM4 1HBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vVhOwGT4VuwMTi1+kUfBD0mqrtXcDcbYML+UaXtVtD8=; b=iGwAVAIrYl7XS7BJ5P3j/VScIb0gWo52BNR08P7jfSQDaxmYm3R2E4QLtlP8i+89BU qYEou8Oz+bRGmhPf9GZpdvldo8EdRWzUQgA7AMrLfSB7V/IIHJMCwyFioaEK1L/irYvs JjAYVYVx5nVs/VCFMJGH4WjnvVUcrVCYUoIeG4CjC99JbQq2DeS42ga8xqgHT6MgffMV UKzETjiHIdMDa1GSM1y77mCg9HwyGi18uw8E4sLfaMoVFCBphuHoQxqDabGdybLGdW5G mQmRDBgbxT2HWiLY16cgrA5lbeqT5DXUSqbTt7ye2TeWiuip2jpncQ1H24fJfcRjsAD6 HTtw== X-Gm-Message-State: APt69E3JBcAdS2/xA8fH4t+8bxndMHaKxuImIiNMrVP5r0TOI+u8bDV7 psCX2dh8gFBhQR9f8dGVxQO5TP9RHCLX8635PhM= X-Google-Smtp-Source: ADUXVKKBVFYZ73pMclOBeajGcxr2T5W3Q6WBHED2CHXmchgnVt/gmreMsKfsT6dbYE3lgvZzrLV4v3mH9c8CTdF/55Q= X-Received: by 2002:a24:f007:: with SMTP id s7-v6mr881264ith.15.1528354665710; Wed, 06 Jun 2018 23:57:45 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 2002:ac0:8ea1:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 23:57:44 -0700 (PDT) In-Reply-To: <679126cc-e72b-aace-3374-4d5c95688b23@nostrum.com> References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> <679126cc-e72b-aace-3374-4d5c95688b23@nostrum.com> From: Barry Leiba Date: Thu, 7 Jun 2018 02:57:44 -0400 X-Google-Sender-Auth: m4Ru3ukrXXjSO2X_PU5omBrcBew Message-ID: To: Adam Roach Cc: "Andrew G. Malis" , "Joel M. Halpern" , Paul Hoffman , rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 06:57:50 -0000 >> I was just about to make Joel's last point in response to an earlier >> email. If we deem the "experiment" a failure, how do we go back? Do we >> reissue all of the non-RFCs as RFCs? > > The BOF description currently says: "At the end of the experiment, the > community would discuss whether these stream identifiers were sufficiently > useful in technical references and discussions to maintain the technical > dialog among the relevant technical communities. If they are not, RFC > numbers would be allocated for each document published under the > experiment..." Apart from that, I would suggest that we continue the consecutive numbering as though we were issuing RFCs, and then change the prefix. So, RFC9112, IAB9113, BCP9114, RFC9115, EXP9116, etc. That will make it trivial to switch them all back to "RFC" if we decide to. Barry From nobody Thu Jun 7 01:32:38 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C7912F18C for ; Thu, 7 Jun 2018 01:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 twUEzryDIp_q for ; Thu, 7 Jun 2018 01:32:33 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF2E130E97 for ; Thu, 7 Jun 2018 01:32:33 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 99DF360AE3; Thu, 7 Jun 2018 10:32:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 7021780089; Thu, 7 Jun 2018 10:32:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0389.001; Thu, 7 Jun 2018 10:32:30 +0200 From: To: Adam Roach , Barry Leiba , "Paul Hoffman" CC: "rfcplusplus@ietf.org" Thread-Topic: [Rfcplusplus] If it ain't broke ... Thread-Index: AQHT/Xy7uo+2GmTDE0Oh0YYEX49f16RTHKQAgACki4CAAAcyAIAArivQ Date: Thu, 7 Jun 2018 08:32:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF3066D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> <64facdf3-6c1d-366e-9490-911652a72e26@nostrum.com> In-Reply-To: <64facdf3-6c1d-366e-9490-911652a72e26@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 08:32:36 -0000 Hi Adam, all,=20 It is completely fine to have informational or experimental RFCs be listed = in RFPs. This can be on purpose by the RFP issuers. For example, RFPs can include RFC 6830 (experimental), RFC 6824 (experiment= al), RFC 6877 (info), RFC 6234 (info),... IMHO, introducing a new serie does not prevent that informational or experi= mental specs to be included in RFPs.=20 Cheers, Med > -----Message d'origine----- > De=A0: Rfcplusplus [mailto:rfcplusplus-bounces@ietf.org] De la part de Ad= am > Roach > Envoy=E9=A0: jeudi 7 juin 2018 02:00 > =C0=A0: Barry Leiba; Paul Hoffman > Cc=A0: rfcplusplus@ietf.org > Objet=A0: Re: [Rfcplusplus] If it ain't broke ... >=20 > If we're collecting anecdotes, I want to point out that my experience > lines up with Barry's. I've worked on multiple RFPs that included > spreadsheets from the customer asking, line by line, for product > compliance with long lists of RFCs. These lists included informational > documents, IETF process documents, and experimental documents. Although > I didn't run into quite the level of difficulty as the first situation > Barry describes, I've had plenty of situations congruent with what he > describes in his final paragraph. >=20 > I also have a somewhat cloudy recollection of finding a mailing list > thread involving an argument among Linux kernel developers regarding > implementation of an experimental RFC that was not intended for > widespread public use. One side argued that the kernel implementation > was incomplete without it ("you're not RFC compliant") while the other > tried to explain that you don't have to implement all RFCs to comply > with a protocol, and that some are, in fact, potentially harmful to > deploy widely. I wish I could recall the exact topic so as to find the > thread again, but it's been a relatively long time since I came across th= is. >=20 > /a >=20 >=20 > On 6/6/18 6:33 PM, Barry Leiba wrote: > >>> I have experience with (1) perceptions that Informational and > >>> Experimental IETF-stream RFCs are standards, along with demands that > >>> they be implemented, (2) perceptions that IAB-stream RFCs are BCPs > >>> that must be followed, and, probably worst, (3) perceptions that > >>> Independent-stream Informational documents that got little review and > >>> no consensus are standards, along with demands that they be > >>> implemented. > >> What was the outcome of those misperceptions? How much different was i= t > than > >> if those people had correctly the perceived that the documents they we= re > >> looking at were not standards? > > A fair pair of questions, with a common answer. > > > > One situation for the first -- one I was closely involved in and can > > remember the details of -- was that the customers said something to > > marketing sorts, who brought back to technical marketing support that > > "the customer wants to know why we don't have the LMNOP standard > > implemented." The tech support folks looked around and also didn't > > realize the problem and it bubbled its way around until it eventually > > got to the product management, who thought we'd missed something basic > > and took it to the developers. > > > > We finally explained to them that it was an experimental protocol, not > > a standard, and wasn't meant to be widely implemented in products... > > and why did the customer want it in the first place. No one seemed to > > know the answer to that last question, and it took us a while to get > > the mid-level managers to understand why we shouldn't put it into the > > product. It was similarly annoying to get the explanation to the > > marketing folks, and then eventually back to the customer reps, who > > told the customer. > > > > Apparently, someone on the customer side had read about LMNOP and saw > > that it was RFC 9876, and expected a company as savvy as IBM to have > > implemented this latest stuff, so a bit more hand-holding and > > re-explanation was needed before the flak stopped. > > > > In the end, it all worked out. But a good bit of time was wasted that > > would not have been wasted if the customer hadn't seen "RFC" and > > thought that it was an IETF standard. > > > > Just one case study. The other situations I remember were less of a > > big deal, but were generated from the same misunderstanding. > > Explanations were quicker and more brief, and responded to with, more > > or less, "Ah, OK." > > > > Barry > > > > _______________________________________________ > > Rfcplusplus mailing list > > Rfcplusplus@ietf.org > > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Thu Jun 7 01:49:34 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4E7130EA8 for ; Thu, 7 Jun 2018 01:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Yvgxh6FfFlHd for ; Thu, 7 Jun 2018 01:49:28 -0700 (PDT) Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) (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 447EB130E01 for ; Thu, 7 Jun 2018 01:49:28 -0700 (PDT) Received: by mail-qt0-f172.google.com with SMTP id d3-v6so9358294qto.1 for ; Thu, 07 Jun 2018 01:49:28 -0700 (PDT) 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=oNi8755kYMvfu0/8S8EqJ72zIbF4zjtx848wSKOgjbs=; b=ZL5YDpLLmDen4k8FDLCeRjiK9V2kqiyDSA1+I6D8vCAeTqBfrk5KJtL9RljN5bbLml ov8QuSS83bJqxvEhDjehFIrjoK4YvA7iCxfZTTrN++xKMIAlMgb6tR17lqRkkccSlipp lkdKP9T7T9XbuN1jWL4l8JddjdqmSW9Db/L75hg4WQUsYb5nIbcVPqIDG5r37Ix8taRD MQ24Sf5HDUJlNZn61DVqw7Q/m4K8uVeAT0RQlxyynBMxKXpCeGWgUKt58GWt3VKoAo4Q pM525m4e0ZJJguxFd8Gq3JaHTJguA9jEEma8AqF+dqPP6afcpTV+8Ec7sj+0RLaKAV+t vXNg== X-Gm-Message-State: APt69E1phspPWTCfQ8OH5bUDVaDAoRRdXjygfUTNfTeUXs7iQknK+A41 ShzFixRJM59T6fqy6gbKlZM9c448tqfyostRrm4= X-Google-Smtp-Source: ADUXVKJZluyBLamUzp4ButWBjhxxOqPhM5LN0g/I9O7CAnVZwDd1EG+LSOh8JuXmqJ7R2bTB0dPAFGfzJDvoGX3K4fs= X-Received: by 2002:a0c:b892:: with SMTP id y18-v6mr773343qvf.188.1528361367196; Thu, 07 Jun 2018 01:49:27 -0700 (PDT) MIME-Version: 1.0 References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> <375bf4a5-8122-3f9c-89f5-50d7b9da2a3c@gmail.com> <36d76549-da5c-c88f-f876-cd6fa61f8c63@gmail.com> In-Reply-To: <36d76549-da5c-c88f-f876-cd6fa61f8c63@gmail.com> From: Barry Leiba Date: Thu, 7 Jun 2018 10:49:15 +0200 Message-ID: To: Melinda Shore Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000615888056e095c07" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 08:49:31 -0000 --000000000000615888056e095c07 Content-Type: text/plain; charset="UTF-8" > One that does seem > consequential, for example, is the difference between > documents that reflect IETF consensus and documents that do > not reflect IETF consensus. Necessary, but not sufficient. In current usage, all IETF stream documents get IETF consensus (they all go through last call), but we do need to distinguish standards track from experimental, and both of those from informational. Barry On Thu, Jun 7, 2018 at 8:38 AM Melinda Shore wrote: > I think there's this fundamental question that perhaps > drove the initial discussion leading to the BOF proposal, > which is whether or not there are distinctions between > categories of RFCs that matter. One that does seem > consequential, for example, is the difference between > documents that reflect IETF consensus and documents that do > not reflect IETF consensus. If these are distinctions we > care about, should that be reflected in how they're published? > > I'm not really in love with the proposed experiment but I > do think that we're at a point in the maturity process of > both the IETF and the internet more broadly that it's a > discussion worth having. (I'm a little concerned that > we'll end up rat-holing on the proposal, but I'm also hopeful > about a well-managed discussion). > > Melinda > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000615888056e095c07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> One that = does seem

> consequential,= for example, is the difference between

> documents that= reflect IETF consensus and documents that do

> not reflect IE= TF consensus.


Necessary, but not sufficient.=C2=A0 In current usage, all IETF stream doc= uments get IETF consensus (they all go through last call), but we do need t= o distinguish standards track from experimental, and both of those from inf= ormational.

Barry
<= div>
On Thu, Jun 7, 2018 at 8:38 AM Meli= nda Shore <melinda.shore@gmai= l.com> wrote:
I think there&= #39;s this fundamental question that perhaps
drove the initial discussion leading to the BOF proposal,
which is whether or not there are distinctions between
categories of RFCs that matter.=C2=A0 One that does seem
consequential, for example, is the difference between
documents that reflect IETF consensus and documents that do
not reflect IETF consensus.=C2=A0 If these are distinctions we
care about, should that be reflected in how they're published?

I'm not really in love with the proposed experiment but I
do think that we're at a point in the maturity process of
both the IETF and the internet more broadly that it's a
discussion worth having.=C2=A0 (I'm a little concerned that
we'll end up rat-holing on the proposal, but I'm also hopeful
about a well-managed discussion).

Melinda

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusplus
--000000000000615888056e095c07-- From nobody Thu Jun 7 01:55:28 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E987130EA8 for ; Thu, 7 Jun 2018 01:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 GRmyq6k1Dahq for ; Thu, 7 Jun 2018 01:55:14 -0700 (PDT) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (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 0E3E6130E01 for ; Thu, 7 Jun 2018 01:55:14 -0700 (PDT) Received: by mail-qk0-f171.google.com with SMTP id q70-v6so5811363qke.1 for ; Thu, 07 Jun 2018 01:55:14 -0700 (PDT) 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=hJej+R5p/Mf/Xcl782OIk4j5t09snPB9Fx5y7ZXI2ZQ=; b=Rc+p8YK/kVZ7JUFA/YJDNfGU2nnLzZE7KGon312ERYlqElB4UeMHCh0aK6IOVAV/Rv vI7UzoJxVFPCTxa6mbIFr+ZN30j8QEOKNdjAlEdZ4tAxCOlgUMyJvcxAJif5zL4dI1je VR8Eyxo6CrMESybCECNLdHjZc2Jtxpj+FLsfQ+z6QiaUFBksEv+NjVrlogO3CZy59zNB SdqHo0tOSJA65g8WVO8r9H4loDVPlqaw/PGPUaseXJ6w4qZYLT3iDZq2iL2hxrrEtC+C y0ZDy0H7XufCbIuh1gooltlhpap1o5Ew9y3jVRr/U8pwMFLATLRl1fd4AoSHJrlpgJxv bVBA== X-Gm-Message-State: APt69E0NUIq5O7sBiIIDpdEAQyaIlEcBzznon7uWpZSkb3GoDq7bZLz4 0IlAohcsW2Sdp1jevk3BuAmXxFrVo5bFXDNJM5E= X-Google-Smtp-Source: ADUXVKK0IIrYWxxb4TIXHsQVVmqLIWd2BMMQVlytqkbEMPm0FEcXMDjqksT+uJsoimzRdIQ3BC+nG7i999otzg0jDcs= X-Received: by 2002:a37:a38c:: with SMTP id m134-v6mr730736qke.57.1528361713059; Thu, 07 Jun 2018 01:55:13 -0700 (PDT) MIME-Version: 1.0 References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> In-Reply-To: From: Barry Leiba Date: Thu, 7 Jun 2018 10:55:01 +0200 Message-ID: To: "Joel M. Halpern" Cc: Paul Hoffman , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000fec9f9056e0970c4" Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 08:55:16 -0000 --000000000000fec9f9056e0970c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I have seen the exact sequence you describe (and worse) where the > document in quesiton was an Internet Draft. I have seen this more than > once. Indeed, you=E2=80=99re right. It=E2=80=99s clear that =E2=80=9CRFC=E2=80= =9D is not the only thing that confuses people, and there=E2=80=99s certainly evidence that some consider = anything posted to the IETF to be a standard. At best, what some of us are proposing will only solve part of the problem. > Thus, based on the evidence I have seen, changing names is unlikely to help. And you might well be right about that too. My sense is that it will help, but not fix everything. I certainly could be wrong about that. Barry --000000000000fec9f9056e0970c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

&= gt; I have seen the exact sequence you describe (and worse) where the=C2=A0=

> document in qu= esiton was an Internet Draft. =C2=A0 I have seen this more than=C2=A0

> once.


Indeed, you=E2=80=99re right.=C2=A0 I= t=E2=80=99s clear that =E2=80=9CRFC=E2=80=9D is not the only thing that con= fuses people, and there=E2=80=99s certainly evidence that some consider any= thing posted to the IETF to be a standard.=C2=A0 At best, what some of us a= re proposing will only solve part of the problem.

> Thus, based on the evidence I have seen, chan= ging names is unlikely to help.

And you might well be right about that too.=C2=A0 = My sense is that it will help, but not fix everything.=C2=A0 I certainly co= uld be wrong about that.

Barry



--000000000000fec9f9056e0970c4-- From nobody Thu Jun 7 02:32:09 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D630130E86 for ; Thu, 7 Jun 2018 02:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 l6QD0PVbkBpM for ; Thu, 7 Jun 2018 02:31:59 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 76CEC130FF0 for ; Thu, 7 Jun 2018 02:31:59 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id v17-v6so2993415ybe.7 for ; Thu, 07 Jun 2018 02:31:59 -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=YAvTZWQOu1uzdM2mPspObp9OmrPoGrsmdyw9+du5zQs=; b=hwECVBi8UE2AOv20Yc/QuELEDvX5C6R2B0TTcnJZM1KF7tGpHlMN3Sx4gcMqCWz2vN imIpS5FLW6JJCjsLKwDoPqL4ijKFVQraB192cBuCM56ti7cLZJgmUNllKZQw7ceT3keP z6qzFbUna85eN6M9YHlW5S8m+7M7jqZA/pG515g0rj/Bcpcy8ab4bJnR5N24yEa+Y4r/ 6Phkgp6ITEcw83ayzExndHMSPjtw84KE9S0p4LtVXXPUOTOuLAnTGpST2AEiHmAnNwEU GPjxrUfyUymSf21RQGFB0xYPKEKOAaoKB1jBM6tw9TZxFdDWdY0PfVNxcz9QskzZnH2y WKYw== 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=YAvTZWQOu1uzdM2mPspObp9OmrPoGrsmdyw9+du5zQs=; b=YPjoogo2qxFHmVgbATzgaxX4/kXb+DhOPy+hpUB8QmPU4Z3E9NQuwh01nVvmufT56b JlCFBLv84dDdqF1c9WljiCitiMDOJqiJk3GVx+Y5JNj0d/Bta77DfOHfnoXnOfzcI4Uf cDKvMC2qrK7F0DrqVFR8WATY0CCtCLniJt62V2rOZ5niWIu4wQMxPu0hn1NM0eugO7HX 9w5pfTXPMD2pCByx0XiI/a0A1pqMAC8maMwZvFUXEF5QS7Ies3i1c/a4Nl+Bhm/3a7yN mwart4mscPn1EGa4pOIkw08nOojw9m54ADOLjUHMBy+ul+4TB3vQwWMReXt3rrpc/r9G SJmA== X-Gm-Message-State: APt69E2Em3nNroZJle1sxJYCVrfZ+Wti3/kYCkqVGtCtU2MGQ4FaP33+ nNZnUbp6K67ogzEH89W3ufsbQqK+J+CrtjmLQKEcXw== X-Google-Smtp-Source: ADUXVKIfG7Q95hI7lWxx7NlaXx3NypQfoWC22kSKTLOdJExpdbQ7P+qZzml3v8LlQGKmC3NnYsvwhynMmWPfxNGftIw= X-Received: by 2002:a25:778e:: with SMTP id s136-v6mr552216ybc.235.1528363918267; Thu, 07 Jun 2018 02:31:58 -0700 (PDT) MIME-Version: 1.0 References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 7 Jun 2018 04:31:46 -0500 Message-ID: To: Brian E Carpenter Cc: Joe Hall , Barry Leiba , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000006f9b22056e09f48b" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 09:32:05 -0000 --0000000000006f9b22056e09f48b Content-Type: text/plain; charset="UTF-8" I'm doing my best to listen before speaking ... On Thu, Jun 7, 2018 at 12:13 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 07/06/2018 09:26, Joseph Lorenzo Hall wrote: > > I could also use some clarification, Brian. My take away from the > > draft was, "we have a bunch of ongoing experiments, it would not be > > wise to start another one until those have completed". What am I > > missing? > > That is one of the takeaways. Let's figure out why past attempts, > especially the STD designation, haven't fixed a problem that was > first documented in 1994. The IETF Problem Statement RFC from 2004 talks about this in https://tools.ietf.org/html/rfc3774#section-2.4, but the high-order bit was that STDs only help specifications at the penultimate level of the hierarchy ("Internet Standard"). So this is way less mysterious than some other issues under discussion. Fixing the STD designation might, or might not, be orthogonal to the experiment being proposed here. Spencer > Probably the problem is deeper than > just document labels, so let's figure out the problem too. > > This can't be very urgent, because we've managed for the last 24 years. > > There are at least two other points too: > > 1. The RFC series belongs to everybody, not just to the IETF. > So we can't unilaterally decide for everbody. > > 2. It is good for the IETF to be fundamentally modest and open > to feedback about its work. Calling all our documents "request for > comments" is therefore highly appropriate. > > Regards > Brian > > > > > On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter > > wrote: > >> I'm out of time at this moment, but no, that isn't the argument. > >> > >> The argument is that having a single document series that is > specifically > >> named as not being dogma is the right thing to do. > >> > >> Better labels are a good idea, within that series, for sure. > >> > >> Regards > >> Brian > >> > >> On 06/06/2018 22:24, Barry Leiba wrote: > >>> Brian, the draft appears to be saying, essentially, that we shouldn't > >>> make the sorts of changes to the RFC series that we've proposed to > >>> discuss here because the RFC series is an old and venerable thing and > >>> shouldn't be changed. I don't buy it. > >>> > >>> The primary thing I don't buy is that "RFC" still means "request for > >>> comments". At some level, sure, it does, because people can and will > >>> comment on RFCs, submit errata reports, and so on. But most of the > >>> world thinks of RFCs as IETF standards, with some subset understanding > >>> that the series also contains informational and experimental stuff. > >>> The comment period, really, is during the development of the Internet > >>> Drafts. One only needs to look at the strict scrutiny performed by > >>> the IESG to see that the bar for getting to RFC is well beyond that > >>> warranted for the publication of a request for comments. > >>> > >>> As to ownership, I agree that the series is owned by "the community", > >>> and it's exactly that community we're calling on for discussion of > >>> proposed changes. If we think that, for example, the IRTF is being > >>> short-changed here, we have only to publicize this discussion to the > >>> IRTF an ask them to come be part of it. The same goes for any other > >>> sub-community we think isn't adequately represented. > >>> > >>> Apart from that, I see little substance in the draft about your > >>> objection to considering the sort of change proposed here (apart from > >>> the "request for comments" part). Can you be clearer, not about the > >>> history of the RFC series, but about specifically why you think such a > >>> change would be bad? > >>> > >>> Barry > >>> > >>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter > >>> wrote: > >>>> -------- Forwarded Message -------- > >>>> Subject: I-D Action: draft-carpenter-request-for-comments-00.txt > >>>> Date: Tue, 05 Jun 2018 20:16:12 -0700 > >>>> From: internet-drafts@ietf.org > >>>> Reply-To: internet-drafts@ietf.org > >>>> To: i-d-announce@ietf.org > >>>> > >>>> > >>>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>>> > >>>> > >>>> Title : Request for Comments > >>>> Author : Brian Carpenter > >>>> Filename : draft-carpenter-request-for-comments-00.txt > >>>> Pages : 7 > >>>> Date : 2018-06-05 > >>>> > >>>> Abstract: > >>>> This document discusses the Internet technical community's common > >>>> document series. > >>>> > >>>> > >>>> The IETF datatracker status page for this draft is: > >>>> > https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ > >>>> > >>>> There are also htmlized versions available at: > >>>> https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 > >>>> > https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 > >>>> > >>>> > >>>> Please note that it may take a couple of minutes from the time of > submission > >>>> until the htmlized version and diff are available at tools.ietf.org. > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> _______________________________________________ > >>>> I-D-Announce mailing list > >>>> I-D-Announce@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>> > >>>> _______________________________________________ > >>>> Rfcplusplus mailing list > >>>> Rfcplusplus@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rfcplusplus > >>> > >> > >> _______________________________________________ > >> Rfcplusplus mailing list > >> Rfcplusplus@ietf.org > >> https://www.ietf.org/mailman/listinfo/rfcplusplus > > > > > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --0000000000006f9b22056e09f48b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm doing my best to listen before speaking ...=C2=A0<= div>
On 07/06/2018 09:26, Joseph Lorenzo Hall wrot= e:
> I could also use some clarification, Brian. My take away from the
> draft was, "we have a bunch of ongoing experiments, it would not = be
> wise to start another one until those have completed". What am I<= br> > missing?

That is one of the takeaways. Let's figure out why past attempts,
especially the STD designation, haven't fixed a problem that was
first documented in 1994.

The IETF Problem= Statement RFC from 2004 talks about this in=C2=A0https://tools.ietf.org/html/rfc3774#sect= ion-2.4, but the high-order bit was that STDs only help specifications = at the penultimate level of the hierarchy ("Internet Standard"). = So this is way less mysterious than some other issues under discussion.

Fixing the STD designation might, or might not, be or= thogonal to the experiment being proposed here.

Sp= encer
=C2=A0
Probably the problem is deeper than
just document labels, so let's figure out the problem too.

This can't be very urgent, because we've managed for the last 24 ye= ars.

There are at least two other points too:

1. The RFC series belongs to everybody, not just to the IETF.
So we can't unilaterally decide for everbody.

2. It is good for the IETF to be fundamentally modest and open
to feedback about its work. Calling all our documents "request for
comments" is therefore highly appropriate.

Regards
=C2=A0 =C2=A0Brian

>
> On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter
> <b= rian.e.carpenter@gmail.com> wrote:
>> I'm out of time at this moment, but no, that isn't the arg= ument.
>>
>> The argument is that having a single document series that is speci= fically
>> named as not being dogma is the right thing to do.
>>
>> Better labels are a good idea, within that series, for sure.
>>
>> Regards
>>=C2=A0 =C2=A0 Brian
>>
>> On 06/06/2018 22:24, Barry Leiba wrote:
>>> Brian, the draft appears to be saying, essentially, that we sh= ouldn't
>>> make the sorts of changes to the RFC series that we've pro= posed to
>>> discuss here because the RFC series is an old and venerable th= ing and
>>> shouldn't be changed.=C2=A0 I don't buy it.
>>>
>>> The primary thing I don't buy is that "RFC" stil= l means "request for
>>> comments".=C2=A0 At some level, sure, it does, because pe= ople can and will
>>> comment on RFCs, submit errata reports, and so on.=C2=A0 But m= ost of the
>>> world thinks of RFCs as IETF standards, with some subset under= standing
>>> that the series also contains informational and experimental s= tuff.
>>> The comment period, really, is during the development of the I= nternet
>>> Drafts.=C2=A0 One only needs to look at the strict scrutiny pe= rformed by
>>> the IESG to see that the bar for getting to RFC is well beyond= that
>>> warranted for the publication of a request for comments.
>>>
>>> As to ownership, I agree that the series is owned by "the= community",
>>> and it's exactly that community we're calling on for d= iscussion of
>>> proposed changes.=C2=A0 If we think that, for example, the IRT= F is being
>>> short-changed here, we have only to publicize this discussion = to the
>>> IRTF an ask them to come be part of it.=C2=A0 The same goes fo= r any other
>>> sub-community we think isn't adequately represented.
>>>
>>> Apart from that, I see little substance in the draft about you= r
>>> objection to considering the sort of change proposed here (apa= rt from
>>> the "request for comments" part).=C2=A0 Can you be c= learer, not about the
>>> history of the RFC series, but about specifically why you thin= k such a
>>> change would be bad?
>>>
>>> Barry
>>>
>>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter
>>> <brian.e.carpenter@gmail.com> wrote:
>>>> -------- Forwarded Message --------
>>>> Subject: I-D Action: draft-carpenter-request-for-comments-= 00.txt
>>>> Date: Tue, 05 Jun 2018 20:16:12 -0700
>>>> From: internet-drafts@ietf.org
>>>> Reply-To: internet-drafts@ietf.org
>>>> To: i-d-announce@ietf.org
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Interne= t-Drafts directories.
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: Request for Comments
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : Brian Carpenter
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2= =A0 =C2=A0 : draft-carpenter-request-for-comments-00.txt
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: 7
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : 2018-06-05
>>>>
>>>> Abstract:
>>>>=C2=A0 =C2=A0 This document discusses the Internet technica= l community's common
>>>>=C2=A0 =C2=A0 document series.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datat= racker.ietf.org/doc/draft-carpenter-request-for-comments/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ie= tf.org/html/draft-carpenter-request-for-comments-00
>>>> https:= //datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00=
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the = time of submission
>>>> until the htmlized version and diff are available at tools.iet= f.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/list= info/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shad= ow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.t= xt
>>>>
>>>> _______________________________________________
>>>> Rfcplusplus mailing list
>>>> = Rfcplusplus@ietf.org
>>>> https://www.ietf.org/mailman/listi= nfo/rfcplusplus
>>>
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> Rfcplusp= lus@ietf.org
>> https://www.ietf.org/mailman/listinfo/rfc= plusplus
>
>
>

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusplus
--0000000000006f9b22056e09f48b-- From nobody Thu Jun 7 02:42:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FC5130FE9 for ; Thu, 7 Jun 2018 02:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NCb1KELJpWRQ for ; Thu, 7 Jun 2018 02:42:31 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 343BC130E86 for ; Thu, 7 Jun 2018 02:42:31 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w13-v6so2794169ywa.5 for ; Thu, 07 Jun 2018 02:42:31 -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=O8E+NMHLGyYCryJtlIB8GM2K69zSd85dAkzgcme8ntc=; b=OWwY0fNIfMdsvu4qTmVU6sJPW/f5Lm5TkSIw6eFhEBn4Yv0saCvMpakuE5ZOAltnLr /i/6upjv8T7xvXAPDGkeFi4YNhqzHiwKbzUXnA5lO1lHzabiimw/vEnDkkJN+PvaqciJ f2vlYspttGjqsSt0jYYaZ/wP+LlZSpsPSQR2XWvHznT6eijc0+TRiTwTbVmWw/c+uB5z rPJUP80My81LWEkSkuz0FGz8aosKIhjgRf4hcMZB29kr2aWHrMjiYcwB9ganUJ32KnUR uvNqGv+/DCjMhbWm7ZdEstswpSQOq1kwYjhEX11dDVTExH8mb2VVwOPBYDb21PC4Evre ykyQ== 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=O8E+NMHLGyYCryJtlIB8GM2K69zSd85dAkzgcme8ntc=; b=lgL5mF7ZBIHW8SMNox8PqpKYlabaQKNbSXoScbMn3POZHMPqzJpVDPoMSbUsfocQCs dXdqYhDRO6k8G93/xfrPz3ocKX7a8cxtSdX9AvMVfvdg2cQg7qy36ev4dRNyaiWjERmR X0SuJEPHGR0iRoRMYgZOVegmUXBDXpbw5VnFJ/TyMLXKa3mxNOT1WAt3WYCcB6u91Fd8 GGPeBKg4bIme9uoezFvz3zPiTrCgrkLzzo5R08VwDebXRzxzTp44AzpB6WVeMFQplCqI PDGLcA4NdOglfX6HOVtuX3FqaI/oS1eNzHL+pa6+Y5wKxeMELMxbrp8gHKyzEXhPGsUb QRPg== X-Gm-Message-State: APt69E2o6XRbpWSt4IWFRhn7JeU6OFNGi/CgdW8CyHsRLHXwp/8OQpbz gy1SIon5poJTsrvrwszei7I4at4NVqA8h331Cp0= X-Google-Smtp-Source: ADUXVKK8bW10XMl4P5jA6axvsMnid1ya/d51+Mv02OhNa0jwR6UJ7eo91E2xPfP7Dhybx2HzRF58beE2azUsfYaqOxo= X-Received: by 2002:a0d:e812:: with SMTP id r18-v6mr573059ywe.19.1528364550253; Thu, 07 Jun 2018 02:42:30 -0700 (PDT) MIME-Version: 1.0 References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 7 Jun 2018 04:42:18 -0500 Message-ID: To: Brian E Carpenter Cc: Joe Hall , Barry Leiba , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000001af27e056e0a1a4b" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 09:42:39 -0000 --0000000000001af27e056e0a1a4b Content-Type: text/plain; charset="UTF-8" And, just to avoid confusing more people than I've already confused ... On Thu, Jun 7, 2018 at 4:31 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > I'm doing my best to listen before speaking ... > > On Thu, Jun 7, 2018 at 12:13 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 07/06/2018 09:26, Joseph Lorenzo Hall wrote: >> > I could also use some clarification, Brian. My take away from the >> > draft was, "we have a bunch of ongoing experiments, it would not be >> > wise to start another one until those have completed". What am I >> > missing? >> >> That is one of the takeaways. Let's figure out why past attempts, >> especially the STD designation, haven't fixed a problem that was >> first documented in 1994. > > > The IETF Problem Statement RFC from 2004 talks about this in > https://tools.ietf.org/html/rfc3774#section-2.4, but the high-order bit > was that STDs only help specifications at the penultimate level of the > hierarchy ("Internet Standard"). So this is way less mysterious than some > other issues under discussion. > "... the ultimate level of the hierarchy". ("Must not send e-mail about process BOFs while watching the QUIC interim meeting. Must not send e-mail about process BOFs while watching the QUIC interim meeting ...") Thanks, Barry, for poking me about this. Spencer > > Fixing the STD designation might, or might not, be orthogonal to the > experiment being proposed here. > > Spencer > > >> Probably the problem is deeper than >> just document labels, so let's figure out the problem too. >> >> This can't be very urgent, because we've managed for the last 24 years. >> >> There are at least two other points too: >> >> 1. The RFC series belongs to everybody, not just to the IETF. >> So we can't unilaterally decide for everbody. >> >> 2. It is good for the IETF to be fundamentally modest and open >> to feedback about its work. Calling all our documents "request for >> comments" is therefore highly appropriate. >> >> Regards >> Brian >> >> > >> > On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter >> > wrote: >> >> I'm out of time at this moment, but no, that isn't the argument. >> >> >> >> The argument is that having a single document series that is >> specifically >> >> named as not being dogma is the right thing to do. >> >> >> >> Better labels are a good idea, within that series, for sure. >> >> >> >> Regards >> >> Brian >> >> >> >> On 06/06/2018 22:24, Barry Leiba wrote: >> >>> Brian, the draft appears to be saying, essentially, that we shouldn't >> >>> make the sorts of changes to the RFC series that we've proposed to >> >>> discuss here because the RFC series is an old and venerable thing and >> >>> shouldn't be changed. I don't buy it. >> >>> >> >>> The primary thing I don't buy is that "RFC" still means "request for >> >>> comments". At some level, sure, it does, because people can and will >> >>> comment on RFCs, submit errata reports, and so on. But most of the >> >>> world thinks of RFCs as IETF standards, with some subset understanding >> >>> that the series also contains informational and experimental stuff. >> >>> The comment period, really, is during the development of the Internet >> >>> Drafts. One only needs to look at the strict scrutiny performed by >> >>> the IESG to see that the bar for getting to RFC is well beyond that >> >>> warranted for the publication of a request for comments. >> >>> >> >>> As to ownership, I agree that the series is owned by "the community", >> >>> and it's exactly that community we're calling on for discussion of >> >>> proposed changes. If we think that, for example, the IRTF is being >> >>> short-changed here, we have only to publicize this discussion to the >> >>> IRTF an ask them to come be part of it. The same goes for any other >> >>> sub-community we think isn't adequately represented. >> >>> >> >>> Apart from that, I see little substance in the draft about your >> >>> objection to considering the sort of change proposed here (apart from >> >>> the "request for comments" part). Can you be clearer, not about the >> >>> history of the RFC series, but about specifically why you think such a >> >>> change would be bad? >> >>> >> >>> Barry >> >>> >> >>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter >> >>> wrote: >> >>>> -------- Forwarded Message -------- >> >>>> Subject: I-D Action: draft-carpenter-request-for-comments-00.txt >> >>>> Date: Tue, 05 Jun 2018 20:16:12 -0700 >> >>>> From: internet-drafts@ietf.org >> >>>> Reply-To: internet-drafts@ietf.org >> >>>> To: i-d-announce@ietf.org >> >>>> >> >>>> >> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >>>> >> >>>> >> >>>> Title : Request for Comments >> >>>> Author : Brian Carpenter >> >>>> Filename : draft-carpenter-request-for-comments-00.txt >> >>>> Pages : 7 >> >>>> Date : 2018-06-05 >> >>>> >> >>>> Abstract: >> >>>> This document discusses the Internet technical community's common >> >>>> document series. >> >>>> >> >>>> >> >>>> The IETF datatracker status page for this draft is: >> >>>> >> https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ >> >>>> >> >>>> There are also htmlized versions available at: >> >>>> https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 >> >>>> >> https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 >> >>>> >> >>>> >> >>>> Please note that it may take a couple of minutes from the time of >> submission >> >>>> until the htmlized version and diff are available at tools.ietf.org. >> >>>> >> >>>> Internet-Drafts are also available by anonymous FTP at: >> >>>> ftp://ftp.ietf.org/internet-drafts/ >> >>>> >> >>>> _______________________________________________ >> >>>> I-D-Announce mailing list >> >>>> I-D-Announce@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>>> >> >>>> _______________________________________________ >> >>>> Rfcplusplus mailing list >> >>>> Rfcplusplus@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/rfcplusplus >> >>> >> >> >> >> _______________________________________________ >> >> Rfcplusplus mailing list >> >> Rfcplusplus@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> > >> > >> > >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> > --0000000000001af27e056e0a1a4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, just to avoid confusing more people than I've alr= eady confused ...=C2=A0

I'm doing = my best to listen before speaking ...=C2=A0

On Thu, Jun 7, 2018 at 12:13 AM Brian E Carpenter <= brian.e.ca= rpenter@gmail.com> wrote:
On 07/06/2018 09:26, Joseph Lorenzo Hall wrote:
> I could also use some clarification, Brian. My take away from the
> draft was, "we have a bunch of ongoing experiments, it would not = be
> wise to start another one until those have completed". What am I<= br> > missing?

That is one of the takeaways. Let's figure out why past attempts,
especially the STD designation, haven't fixed a problem that was
first documented in 1994.

The IETF Problem= Statement RFC from 2004 talks about this in=C2=A0https://tools.ietf.org= /html/rfc3774#section-2.4, but the high-order bit was that STDs only he= lp specifications at the penultimate level of the hierarchy ("Internet= Standard"). So this is way less mysterious than some other issues und= er discussion.

&quo= t;... the ultimate level of the hierarchy".=C2=A0

=
("Must not send e-mail about process BOFs while watching the QUIC= interim meeting. Must not send e-mail about process BOFs while watching th= e QUIC interim meeting ...")

Thanks, Barry, f= or poking me about this.

Spencer
=C2=A0<= /div>

Fixing the STD designation might, or might no= t, be orthogonal to the experiment being proposed here.

Spencer
=C2=A0
Probably the problem is deeper than
just document labels, so let's figure out the problem too.

This can't be very urgent, because we've managed for the last 24 ye= ars.

There are at least two other points too:

1. The RFC series belongs to everybody, not just to the IETF.
So we can't unilaterally decide for everbody.

2. It is good for the IETF to be fundamentally modest and open
to feedback about its work. Calling all our documents "request for
comments" is therefore highly appropriate.

Regards
=C2=A0 =C2=A0Brian

>
> On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter
> <b= rian.e.carpenter@gmail.com> wrote:
>> I'm out of time at this moment, but no, that isn't the arg= ument.
>>
>> The argument is that having a single document series that is speci= fically
>> named as not being dogma is the right thing to do.
>>
>> Better labels are a good idea, within that series, for sure.
>>
>> Regards
>>=C2=A0 =C2=A0 Brian
>>
>> On 06/06/2018 22:24, Barry Leiba wrote:
>>> Brian, the draft appears to be saying, essentially, that we sh= ouldn't
>>> make the sorts of changes to the RFC series that we've pro= posed to
>>> discuss here because the RFC series is an old and venerable th= ing and
>>> shouldn't be changed.=C2=A0 I don't buy it.
>>>
>>> The primary thing I don't buy is that "RFC" stil= l means "request for
>>> comments".=C2=A0 At some level, sure, it does, because pe= ople can and will
>>> comment on RFCs, submit errata reports, and so on.=C2=A0 But m= ost of the
>>> world thinks of RFCs as IETF standards, with some subset under= standing
>>> that the series also contains informational and experimental s= tuff.
>>> The comment period, really, is during the development of the I= nternet
>>> Drafts.=C2=A0 One only needs to look at the strict scrutiny pe= rformed by
>>> the IESG to see that the bar for getting to RFC is well beyond= that
>>> warranted for the publication of a request for comments.
>>>
>>> As to ownership, I agree that the series is owned by "the= community",
>>> and it's exactly that community we're calling on for d= iscussion of
>>> proposed changes.=C2=A0 If we think that, for example, the IRT= F is being
>>> short-changed here, we have only to publicize this discussion = to the
>>> IRTF an ask them to come be part of it.=C2=A0 The same goes fo= r any other
>>> sub-community we think isn't adequately represented.
>>>
>>> Apart from that, I see little substance in the draft about you= r
>>> objection to considering the sort of change proposed here (apa= rt from
>>> the "request for comments" part).=C2=A0 Can you be c= learer, not about the
>>> history of the RFC series, but about specifically why you thin= k such a
>>> change would be bad?
>>>
>>> Barry
>>>
>>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter
>>> <brian.e.carpenter@gmail.com> wrote:
>>>> -------- Forwarded Message --------
>>>> Subject: I-D Action: draft-carpenter-request-for-comments-= 00.txt
>>>> Date: Tue, 05 Jun 2018 20:16:12 -0700
>>>> From: internet-drafts@ietf.org
>>>> Reply-To: internet-drafts@ietf.org
>>>> To: i-d-announce@ietf.org
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Interne= t-Drafts directories.
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: Request for Comments
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : Brian Carpenter
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2= =A0 =C2=A0 : draft-carpenter-request-for-comments-00.txt
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: 7
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : 2018-06-05
>>>>
>>>> Abstract:
>>>>=C2=A0 =C2=A0 This document discusses the Internet technica= l community's common
>>>>=C2=A0 =C2=A0 document series.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datat= racker.ietf.org/doc/draft-carpenter-request-for-comments/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ie= tf.org/html/draft-carpenter-request-for-comments-00
>>>> https:= //datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00=
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the = time of submission
>>>> until the htmlized version and diff are available at tools.iet= f.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/list= info/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shad= ow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.t= xt
>>>>
>>>> _______________________________________________
>>>> Rfcplusplus mailing list
>>>> = Rfcplusplus@ietf.org
>>>> https://www.ietf.org/mailman/listi= nfo/rfcplusplus
>>>
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> Rfcplusp= lus@ietf.org
>> https://www.ietf.org/mailman/listinfo/rfc= plusplus
>
>
>

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusplus
--0000000000001af27e056e0a1a4b-- From nobody Thu Jun 7 02:44:08 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4988F130FE9 for ; Thu, 7 Jun 2018 02:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 RwWR5X0JrtQ7 for ; Thu, 7 Jun 2018 02:44:01 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364D1130E86 for ; Thu, 7 Jun 2018 02:44:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 662761CADDE for ; Thu, 7 Jun 2018 02:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BqndTNK_9p4 for ; Thu, 7 Jun 2018 02:43:58 -0700 (PDT) Received: from [100.103.122.124] (50.sub-174-206-3.myvzw.com [174.206.3.50]) by c8a.amsl.com (Postfix) with ESMTPSA id A13E01CADDD for ; Thu, 7 Jun 2018 02:43:57 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3B169AB0-A9B8-43D0-A1F5-00E8B43D3571 Mime-Version: 1.0 Content-Language: en-US From: "Heather Flanagan (RFC Series Editor)" X-Mailer: iPhone Mail (15F79) Fcc: imap://rfcprse@pop.amsl.com/INBOX/Sent In-Reply-To: X-Identity-Key: id4 Date: Thu, 7 Jun 2018 10:43:56 +0100 X-Account-Key: account5 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0; deliveryformat=4 Message-Id: Content-Transfer-Encoding: 7bit References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> To: rfcplusplus@ietf.org Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 09:44:05 -0000 --Apple-Mail-3B169AB0-A9B8-43D0-A1F5-00E8B43D3571 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 6/7/18 9:55 AM, Barry Leiba wrote: > > I have seen the exact sequence you describe (and worse) where the=20 > > document in quesiton was an Internet Draft. I have seen this more than= =20 > > once. >=20 > Indeed, you=E2=80=99re right. It=E2=80=99s clear that =E2=80=9CRFC=E2=80=9D= is not the only thing that confuses people, and there=E2=80=99s certainly e= vidence that some consider anything posted to the IETF to be a standard. At= best, what some of us are proposing will only solve part of the problem. >=20 > > Thus, based on the evidence I have seen, changing names is unlikely to h= elp. >=20 > And you might well be right about that too. My sense is that it will help= , but not fix everything. I certainly could be wrong about that. And this is probably the heart of my concerns with the experiment as propose= d. I think we have quite a bit of anecdotal information about the problem (o= r set of problems), but we have no measurements to baseline and prove th= e existence of those problems. We also have a number of ideas on how to fix w= hatever we're defining the problem to be today, but no way to measure whethe= r the fix worked (in part because we have insufficient data regarding the sc= ope of the problem(s) today).=20 I'm not opposed to making changes, but I want to start from a proper evaluat= ion and a review of options (similar to what I did in RFC 6949 for the forma= t work) before we jump in with change for change's sake. -Heather --Apple-Mail-3B169AB0-A9B8-43D0-A1F5-00E8B43D3571 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=20 =20 =20
On 6/7/18 9:55 AM, Barry Leiba wrote:
=

> I have s= een the exact sequence you describe (and worse) where the 

> document= in quesiton was an Internet Draft.   I have seen this more than 

> once.


Indeed, you=E2=80=99re right.  It=E2=80=99s cle= ar that =E2=80=9CRFC=E2=80=9D is not the only thing that confuses people, and there=E2=80=99s certain= ly evidence that some consider anything posted to the IETF to be a standard.  At best, what some of us are proposing will only solve part of the problem.

> Thus, b= ased on the evidence I have seen, changing names is unlikely to help.


And you might well be right about that too.  My= sense is that it will help, but not fix everything.  I certainl= y could be wrong about that.


And this is probably the heart of my concerns with the experiment as proposed. I think we have quite a bit of anecdotal information about the problem (or set of problems), but we have no measurements to baseline and prove the existence of those problems. We also have a number of ideas on how to fix whatever we're defining the problem to be today, but no way to measure whether the fix worked (in part because we have insufficient data regarding the scope of the problem(s) today).

I'm not opposed to making changes, but I want to start from a proper evaluation and a review of options (similar to what I did in RFC 6949 for the format work) before we jump in with change for change's sake.

-Heather
=20
= --Apple-Mail-3B169AB0-A9B8-43D0-A1F5-00E8B43D3571-- From nobody Thu Jun 7 05:37:04 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81923131117 for ; Thu, 7 Jun 2018 05:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 rJoFcWKQVmy0 for ; Thu, 7 Jun 2018 05:36:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 BC2EC1310EE for ; Thu, 7 Jun 2018 05:36:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9DC4E240D83; Thu, 7 Jun 2018 05:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1528375019; bh=yYNtN02gIVYG62Wm9hpAQZIutvhPvLoWkr2vsA4eM90=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mLkyDRDVvmPiXcH39DMZAvWBB5WMjrLWO7SngFU56gU8vtfHCcPXs0oV6LwL8jfNY e6GNr5KWELuD3Au9jxVtLvdVqftaEzHxL6CAhIwYwoNSzj1KAJZ/BnxS/V3JV/3C+B aYWE51H62Gu7Cg5673NbjusjYFp88VkkHehNOlqg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A2FA42402CE; Thu, 7 Jun 2018 05:36:58 -0700 (PDT) To: Adam Roach Cc: Barry Leiba , Paul Hoffman , rfcplusplus@ietf.org References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> <679126cc-e72b-aace-3374-4d5c95688b23@nostrum.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 7 Jun 2018 08:36:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <679126cc-e72b-aace-3374-4d5c95688b23@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] IEperimenting with RFCs X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 12:37:02 -0000 There are several problems with the notion of experiment. The first is that I can not understand how we would judge the success or failure of the experiment after three years. The stated goal is to reduce confusion. Since such confusion is extremely hard to measure, I wonder how we will know whether and how much reduction we would achieve. (IN most other experiment proposals the IESG has asserted, for good reason, that this is an important property of the experiment.) The second problem is the drawbacks of declaring failure of the experiment. It is not just that we need RFC numbers for all the documents. (Yes, I saw that in the proposal.) It is that we will still have a commitment to maintain the immutable documents of whatever name we have produced. Principally because we will hav eno way of knowing who is making use of those names in discussions or citations. Yours, Joel On 6/7/18 2:28 AM, Adam Roach wrote: > On 6/7/18 1:21 AM, Andrew G. Malis wrote: >> I was just about to make Joel's last point in response to an earlier >> email. If we deem the "experiment" a failure, how do we go back? Do we >> reissue all of the non-RFCs as RFCs? > > > The BOF description currently says: "At the end of the experiment, the > community would discuss whether these stream identifiers were > sufficiently useful in technical references and discussions to maintain > the technical dialog among the relevant technical communities. If they > are not, RFC numbers would be allocated for each document published > under the experiment..." > > /a > From nobody Thu Jun 7 08:02:43 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7CB130F2B for ; Thu, 7 Jun 2018 08:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Vn1PrHTr1z0q for ; Thu, 7 Jun 2018 08:02:25 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 633E7130F27 for ; Thu, 7 Jun 2018 08:02:25 -0700 (PDT) X-AuditID: 12074422-36fff70000001f22-55-5b1949002bce Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B0.C5.07970.009491B5; Thu, 7 Jun 2018 11:02:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w57F2Nkf004410; Thu, 7 Jun 2018 11:02:24 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w57F2JFf010881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jun 2018 11:02:22 -0400 Date: Thu, 7 Jun 2018 10:02:19 -0500 From: Benjamin Kaduk To: Barry Leiba Cc: rfcplusplus@ietf.org Message-ID: <20180607150219.GN72167@kduck.kaduk.org> References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> <375bf4a5-8122-3f9c-89f5-50d7b9da2a3c@gmail.com> <36d76549-da5c-c88f-f876-cd6fa61f8c63@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixG6nrsvgKRlt8OStgsWhxZdYLV5ur3Ng 8mhZ1cvssWTJT6YApigum5TUnMyy1CJ9uwSujLltqgXbWSp65v5mbmA8wNzFyMEhIWAicft8 XBcjF4eQwGImiaPtT9khnA2MEkdOrGOEcK4wSaye+4Wpi5GTg0VARWLLmq2MIDYbkN3QfZkZ xBYR0JR4/nkKWA2zgITE0q3fWEBsYYFIidsLvoHFeYG2/Tz8gx3EFhJoZ5FY1aMMEReUODnz CQtEr5bEjX8vmUCuYxaQllj+jwMkzCkQKPFk/hNWEFtUQFlib98h9gmMArOQdM9C0j0LoXsB I/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2M4AB1UdrBOPGf1yFGAQ5GJR7e BCvJaCHWxLLiytxDjJIcTEqivIuUJaKF+JLyUyozEosz4otKc1KLDzFKcDArifAmXhKLFuJN SaysSi3Kh0lJc7AoifPmLmKMFhJITyxJzU5NLUgtgsnKcHAoSfA6egDtESxKTU+tSMvMKUFI M3FwggznARouBFLDW1yQmFucmQ6RP8WoKCXOm+MOlBAASWSU5sH1ghKIRPb+mleM4kCvCPOy grTzAJMPXPcroMFMQIM9mMEGlyQipKQaGFfdcvnjulPx1CPWKwE311TkRvb7RB5ZfCHbxi3I gCtHyjyt/smkPUIPUq5XMh997rju5XebfcFWP9RWMcrbv1nQZVW6gCH1R1nps+Y7WcVdm52y rORP7P904mr3wW36Kn9XHL9h3Gf2QnNbrqlOptbVK15bJfodOGXyFIWft5nvdIlp0bObrsRS nJFoqMVcVJwIAJ2HikP7AgAA Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 15:02:34 -0000 On Thu, Jun 07, 2018 at 10:49:15AM +0200, Barry Leiba wrote: > > One that does seem > > > consequential, for example, is the difference between > > > documents that reflect IETF consensus and documents that do > > > not reflect IETF consensus. > > Necessary, but not sufficient. In current usage, all IETF stream documents > get IETF consensus (they all go through last call), but we do need to At risk of picking nits (and inflaming old arguments), we did approve draft-mm-wg-effect-encrypt in the IETF stream with 'consensus: no". -Benjamin From nobody Thu Jun 7 15:51:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2E4130DE0 for ; Thu, 7 Jun 2018 15:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ESwTYD4EFFsv for ; Thu, 7 Jun 2018 15:51:52 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 E336C130DD3 for ; Thu, 7 Jun 2018 15:51:51 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id f79-v6so10152906oib.7 for ; Thu, 07 Jun 2018 15:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=03SIgHFcvNKDCw0s3NnXc4nIXeKrz6oLUrMxO37UTzc=; b=bJGuN693eYWwwb1AYy7yExRpBz4hoKzijwd98QdEs609sxNLZJe3ca8oLQBeETLvTu QoYClQGTM7W39TJ+ph09A0A3tp/1fSp0AuKQOerF4yQtELVnEjWjHNdTy1bIQ0yiRIyl JX4QyfsUr90DaQxAob0w0QZ2PmUrVupwtCEw1Z/9+XqH+eUn2bP923WItSp0qDNM45r7 rBluxJgdGCEGur/KrDz82XAUfunVPBIWjQkf7C+4NsIvHAPpmmRejyUyeuoqcumSnUJ/ 72jH2bTTTcUZytbuf/rPHmW2HWG8StphCZep17CtfUZl/gW7fFYLfF2yRROrpgRvMlAy trPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=03SIgHFcvNKDCw0s3NnXc4nIXeKrz6oLUrMxO37UTzc=; b=F4Uenhkqh3Ls5M82/DSKgW9iGlS/x8OiXF5qujgxHKNBFMFHIKJxdP2VvtgZtnWrxO RKt08IAOJb+cZftshem//enS2iymBEyuD+9R81PwCBD/tX3/k8BYNx75TDS7W9BVA2Dw N8/eZaukI/BxRJUE5Pe4QZ4Uipm8EuMEXLiSAHrveA+7gtaAvq2/Ark2qQLhxg2I/Dw+ QIsVvFIRdmLf/nY5/aYJsx+OmTwmAHAr3KkJAqIBMltebMj48yaC6HE3r5iDo6BxCUOj xQXz24LTbWZR0f+KoXKNoo0miv4D6EVJwnv4hk3v+WTKfk+8KNRT86fe87EgKrI3X2pF aJrQ== X-Gm-Message-State: APt69E0En/6hybBy3PaSebb1zQoMro+fh1qBDDkqZJW+Jm+WLXuq63po 8aUNLy0vJDUjvDW9HWDGEmR2ZdjIvCPML2SM7kM= X-Google-Smtp-Source: ADUXVKISXRZp9tIIpO+PFU6VNqVhvfJAGjEI4lyQtnjx3IdZHQa5yCfGdTv4gsfTmtZVrTeK+mWz95KJTSxAIThRe8M= X-Received: by 2002:aca:c38f:: with SMTP id t137-v6mr1887216oif.284.1528411910906; Thu, 07 Jun 2018 15:51:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 15:51:20 -0700 (PDT) In-Reply-To: References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> From: Ted Hardie Date: Thu, 7 Jun 2018 15:51:20 -0700 Message-ID: To: Brian E Carpenter Cc: Joseph Lorenzo Hall , Barry Leiba , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000005274a056e1521f7" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 22:51:55 -0000 --00000000000005274a056e1521f7 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 6, 2018 at 10:13 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > 1. The RFC series belongs to everybody, not just to the IETF. > So we can't unilaterally decide for everbody. > > Since RFC 4844, the RFC series has had a pretty clear concept of "streams" and "stream managers". So I don't think we actually need to poll "everybody" to work out whether something is acceptable--we already have designated managers, each of which has a pretty strong sense of accountability to both the broader technical community and the health of the Internet. While this BoF lays out the question in terms of RFC 1796, a different way of asking this question would be: "We've had streams with different managers and characteristics since RFC 4844, but that doesn't seem to translate into public understanding of their differences despite the internal markings. Should we try an experiment that adjusts the external labels as a new step in making the streams identifiable?" regards, Ted --00000000000005274a056e1521f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 6, 2018 at 10:13 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:


1. The RFC series belongs to everybody, not just to the IETF.
So we can't unilaterally decide for everbody.


Since RFC 4844, the RFC series has had= a pretty clear concept of "streams" and "stream managers&qu= ot;.=C2=A0 So I don't think we actually need to poll "everybody&qu= ot; to work out whether something is acceptable--we already have designated= managers, each of which has a pretty strong sense of accountability to bot= h the broader technical community and the health of the Internet.

While this BoF lays out the question in terms of RFC 1796, = a different way of asking this question would be:

=
"We've had streams with different managers and characteristic= s since RFC 4844, but that doesn't seem to translate into public unders= tanding of their differences despite the internal markings.=C2=A0 Should we= try an experiment that adjusts the external labels as a new step in making= the streams identifiable?"

regards,

Ted
--00000000000005274a056e1521f7-- From nobody Thu Jun 7 20:07:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DBD130E14 for ; Thu, 7 Jun 2018 20:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HW8KbfxZLMsh for ; Thu, 7 Jun 2018 20:07:37 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 D83F2130E13 for ; Thu, 7 Jun 2018 20:07:37 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id z1-v6so5683071pgv.12 for ; Thu, 07 Jun 2018 20:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zqunsp7+oLOFFmMzedbgmuJlYsYDFHhJIYcE7p6R920=; b=G6oAWM4dORUzhy9tCGDLDvbcWCbjq3QzW+wcSEOxRo38G2WL6Z9qn7pjDX3wwpJ3Qd WUw3S2Q3xSVUjUQK2t0p8GiDVzDjIqvSBQGYTbz7ca3XDp0RmyR71w9w367MteyITZYv QrAWjuV0U1XdkKXzSsfotaVJLLUrPpo+S/tCG2JQQx29aDw3NFmmM/hmaEmCTr0vebL/ 1+8rf9x/1Jhptoqq+kqnZhAOD5Ms/TBm680E+ohVuSaKElqPmnjAhaxBGrXPaWDHHcI8 uZx4XMog0XSsn6Hi4TkXOGe7Y6D695OYL/DefyLzD0No6874+XZ+QAEagj1gd4NWSug3 X3dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zqunsp7+oLOFFmMzedbgmuJlYsYDFHhJIYcE7p6R920=; b=BwLFAE5xkvvsy13tuaQtYvfNNpewkuwCFoB8ZHlFHbDiGfUyCFiaVr3u+EwCdYNWYH 9EMmHy9X0DtkUNXRLNQZ8kOaQ92dl5lAhue9JdW3WDrdO3pgLv1Ap5Mhd/IIJlYhug6/ H8oqj9DeQqQozmoNG+zxrSPWCM6XMs+aL/eBH4IYn0GXGUMtk04e8+Q7kdswsYkrSu24 FBF1oe8CIYawkBl+tL30b1znoVf2qcK0pI1aJfWgujKLO9weglZpF7BgYpYqcfytvPYv kSMANPU9a03D3ZvjM7nmg6mEiFfuZ23IU6U/LknIFeSMygbupgTjlu5SpbI5GaCkoC3i fOUg== X-Gm-Message-State: APt69E0x6BdK5ftXzGFqSE5MZoP+qz0ZZcU2MiEpDDiDK2D16yrfHvt4 nf1XZdhuDp+2hR85MH9hMoOV5Q== X-Google-Smtp-Source: ADUXVKLY7djjlXWw3OJgoTI7Ofj42IMntsJn1Ddk4t80ELHdnf1MqZMIGH1n5HU54sEeSe7sxxPPbw== X-Received: by 2002:a62:d117:: with SMTP id z23-v6mr4090576pfg.99.1528427257080; Thu, 07 Jun 2018 20:07:37 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id j15-v6sm24338914pfk.40.2018.06.07.20.07.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 20:07:36 -0700 (PDT) To: Ted Hardie Cc: Joseph Lorenzo Hall , Barry Leiba , rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> From: Brian E Carpenter Message-ID: <9653b352-7c18-fce9-a419-06b74f94f4a1@gmail.com> Date: Fri, 8 Jun 2018 15:07:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 03:07:41 -0000 On 08/06/2018 10:51, Ted Hardie wrote: > On Wed, Jun 6, 2018 at 10:13 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> >> >> 1. The RFC series belongs to everybody, not just to the IETF. >> So we can't unilaterally decide for everbody. >> >> > Since RFC 4844, the RFC series has had a pretty clear concept of "streams" > and "stream managers". So I don't think we actually need to poll > "everybody" to work out whether something is acceptable--we already have > designated managers, each of which has a pretty strong sense of > accountability to both the broader technical community and the health of > the Internet. > > While this BoF lays out the question in terms of RFC 1796, a different way > of asking this question would be: > > "We've had streams with different managers and characteristics since RFC > 4844, but that doesn't seem to translate into public understanding of their > differences despite the internal markings. Should we try an experiment > that adjusts the external labels as a new step in making the streams > identifiable?" It's worth a discussion. But I think there are two problems closely linked to that one, which are actually more important: 1. That people, with the best will in the world, cannot reliably find the *latest* version of a standard, which I'm sure most of them expect STDnnnn to lead them to, if they know at all that STD numbers exist. 2. That people cannot find a reliable guide to all the documents of all categories that cover a given topic. Proposals for solving these problems have been made in the past, but our users (readers of RFCs) still have them. Brian From nobody Thu Jun 7 20:57:04 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB9D130E18 for ; Thu, 7 Jun 2018 20:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 m6uYPI8zew-x for ; Thu, 7 Jun 2018 20:57:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B6C5C130E14 for ; Thu, 7 Jun 2018 20:57:00 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w583uqBS039562 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Jun 2018 22:56:53 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian E Carpenter , Ted Hardie Cc: Barry Leiba , rfcplusplus@ietf.org, Joseph Lorenzo Hall References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <9653b352-7c18-fce9-a419-06b74f94f4a1@gmail.com> From: Adam Roach Message-ID: <464ac12b-832e-2bbd-b98c-baff3b137497@nostrum.com> Date: Thu, 7 Jun 2018 22:56:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9653b352-7c18-fce9-a419-06b74f94f4a1@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 03:57:03 -0000 On 6/7/18 10:07 PM, Brian E Carpenter wrote: > It's worth a discussion. But I think there are two problems closely > linked to that one, which are actually more important... Relative importance is somewhat subjective. I have seen very little pain from the first one you describe, mostly due to the ready availability of "obsoleted" information in both the datatracker and on tools.ietf.org. The second is definitely an issue, but it seems rather unrelated to the problem this BOF claims to address. Perhaps a separate effort with its own proponents and proposals would be in order for it. In any case, the proposed experiment certainly leaves a number of problems unsolved, and I suspect that's by design. I don't believe a grand unified theory of how to fix everything about the IETF's documents would be manageable. /a From nobody Thu Jun 7 21:33:20 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A45130E14 for ; Thu, 7 Jun 2018 21:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0K4fogr3RnUL for ; Thu, 7 Jun 2018 21:33:16 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (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 13630130DEF for ; Thu, 7 Jun 2018 21:33:16 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id w17-v6so7494244pll.9 for ; Thu, 07 Jun 2018 21:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Bv7sBKhDcandJ/2UUqySafU9x1WRJe0vzadexoIjVL8=; b=BW7uERBxa57dV5ch/j0iiRf50it4SiAdYIQiK3wj4j5ITkjg7CmTFWTPfylFTgrCeK A5GmE4DTos/REbvDxtQ3PPX1HN5f/0oK7LgRvo4dGdKvwHXQIJxGH3dOtBCugk12R1Me YwJCPl+2gjHhpy3rAB4wWGhshCTijgVs4zLhCbR268M9y4htYYYw16EYcQMOI8AIzEag poh6e14kaGAyXPi4JCnJxl4MNuMwVc5GhqWg51CVxXzkSYGRwBm8IwT6UyvXhGv6KPLo LoIDCBjnsO6XDwCP6OQBKAm/5FjUv/oCfHbtoEo63wh+7tkdRK23qHTykk/Vrg8BkXPm Xxsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Bv7sBKhDcandJ/2UUqySafU9x1WRJe0vzadexoIjVL8=; b=SSRt/L1mRG3YMiL3SjUUH+gPmewINrcxjGxuJenn1jK+UpBiCs+4jFZ2x0bFU9bO/8 w1+xc0+IusjlB0e39kglThWHkz1QvyGB6teRGwaH0KUQyvlJMAIf0CqkYkwtfIWiuoBJ bCGWSGuva0LSMWobdMLTcFRepJoC3da+DGSjE26Qbyeu4huUryqXUuvyrYnsciTMnzib 3t14lHO+0sy+b7teXpTHlx2lfBdnvN1o0kSNAoqf97cbe2/ingtA+qwT4hBjezHxXp6o E3F6GiyFliDfHRxaCM4OOvmQT+fFxN0v9G0A6aK6ug9GFrwLdJafBINK3KIkN5QjPn4x CuAA== X-Gm-Message-State: APt69E0kvjiHoxKo/ltf5I3T6u2H4BsdXzPVZI8W18btdJfuFW6hn/4B vQfzJ7GUMQOMqBXttNmjl0M= X-Google-Smtp-Source: ADUXVKJ1Ti31Dn1epFxAKPQmwXbI7v+R7Buuwo9uAU3HOt6zX/t5BgB32QpSOl2zui3J+jGu9ULsgA== X-Received: by 2002:a17:902:9309:: with SMTP id bc9-v6mr4873042plb.189.1528432395535; Thu, 07 Jun 2018 21:33:15 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id x124-v6sm24080338pgb.53.2018.06.07.21.33.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 21:33:14 -0700 (PDT) To: Adam Roach , Ted Hardie Cc: Barry Leiba , rfcplusplus@ietf.org, Joseph Lorenzo Hall References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <9653b352-7c18-fce9-a419-06b74f94f4a1@gmail.com> <464ac12b-832e-2bbd-b98c-baff3b137497@nostrum.com> From: Brian E Carpenter Message-ID: <41d0dc8f-6b21-e796-5ae5-7ba38825c10d@gmail.com> Date: Fri, 8 Jun 2018 16:33:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <464ac12b-832e-2bbd-b98c-baff3b137497@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 04:33:18 -0000 On 08/06/2018 15:56, Adam Roach wrote: > On 6/7/18 10:07 PM, Brian E Carpenter wrote: >> It's worth a discussion. But I think there are two problems closely >> linked to that one, which are actually more important... > > Relative importance is somewhat subjective. I have seen very little pain > from the first one you describe, mostly due to the ready availability of > "obsoleted" information in both the datatracker and on tools.ietf.org. And on the RFC Editor site. But not, unfortunately when you use an arbitrary search tool. That's probably an issue we can't solve anyway, but it seems to me I see it at least as often as experimental RFCs being mistaken for standards. > The second is definitely an issue, but it seems rather unrelated to the > problem this BOF claims to address. Perhaps a separate effort with its > own proponents and proposals would be in order for it. That's been tried before, and the proposal did include a new document series. Consensus did not occur in the IESG, for which I share the blame. > In any case, the proposed experiment certainly leaves a number of > problems unsolved, and I suspect that's by design. I don't believe a > grand unified theory of how to fix everything about the IETF's documents > would be manageable. Agreed. But selecting one problem whose importance is contested seems a bit arbitrary. Brian From nobody Thu Jun 7 22:13:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0137130E1F for ; Thu, 7 Jun 2018 22:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kwZhaEy_BdUH for ; Thu, 7 Jun 2018 22:13:44 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 DBEF1130E14 for ; Thu, 7 Jun 2018 22:13:43 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id 81-v6so3760440ywb.6 for ; Thu, 07 Jun 2018 22:13:43 -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=5rd/WrqdNflEVSHFWaB/D+Jr8hf28/J+sCrizXrNZYY=; b=EBQomTcm+uKUtZCG1Vhxyx4cP6TP1Hs+z6zyMb0UY2TXDav//oou49s5RhzQ0gRA9C e4Zq7O1YvJKSvvFUA69wGZoOdcfZLYFOxAYVjLYcYgVKQsUEwlpd1kd12JDnHjoWdpgQ s1ORYpabBmQNs3iHTNFHH6OUfKPAd+VmDn+493fo56ftHr6ikO+kF7P26t0ythP1ZiQ4 Cz/5VWHIsSE7qgbODRofial9F1EHltXfmPhYsbek4D9IfYwfvyr9LIHtGZPPqf/2f7Ra v7Lel0W4BrZqvTytIZmUbN45PZECPforrE75wrRFxP2HHRgE37f/kOTW1oFjmj9Eu6dZ TmHQ== 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=5rd/WrqdNflEVSHFWaB/D+Jr8hf28/J+sCrizXrNZYY=; b=nzBADpxGxh/BL2r9nYLEybW0dnbILMSNDd4iSkniIBwnO1weRuLPzxyrcBD5ROeiiD 7auHs1+6RWDz2b9Y8ZmU/LTjMFqsI8QA1634JqoThWzVsZLp5dfp8RbQ7oTCEtcTmpp7 j1rHTr/cFebff2C9vNi4IE8QkCpyKflraXutOvdtB6v4+ZE3BhTyGkJKUkdAbJY/Idzq FwLIsmoREi/ZRzJKezmJE1GA8lJAhL//Tp01tLVAdHW/U6mF6i6X3OZfLhipyRmhjIhG XaQew/x8n/OKBb+x+LvQeMWllJSHq68MpDmafkzQCMf2lehC2oDMdVOymyqk9Tip/LYl YakA== X-Gm-Message-State: APt69E0qAp08DkY3ok88aIl3NNvQf4d4fJn2akokIKQDoZmbrNtRPBf3 WQzp+6sv0/qfHlHNalNIlgcyU+5Y/rL4CpSx6fg= X-Google-Smtp-Source: ADUXVKJTQGAVOxZ/HeKSAvPwCDPDqQwLML+HiOSfh9oHqW6eNdoks++Dqo0i8jBp/EDxKe6o+wWn6rwi1ewfUm9Sl38= X-Received: by 2002:a0d:e812:: with SMTP id r18-v6mr2791121ywe.19.1528434822917; Thu, 07 Jun 2018 22:13:42 -0700 (PDT) MIME-Version: 1.0 References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <9653b352-7c18-fce9-a419-06b74f94f4a1@gmail.com> <464ac12b-832e-2bbd-b98c-baff3b137497@nostrum.com> In-Reply-To: <464ac12b-832e-2bbd-b98c-baff3b137497@nostrum.com> From: Spencer Dawkins at IETF Date: Fri, 8 Jun 2018 00:13:30 -0500 Message-ID: To: Adam Roach Cc: Brian E Carpenter , Ted Hardie , Barry Leiba , rfcplusplus@ietf.org, Joe Hall Content-Type: multipart/alternative; boundary="000000000000aeb0f0056e1a7650" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 05:13:47 -0000 --000000000000aeb0f0056e1a7650 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 7, 2018 at 10:57 PM Adam Roach wrote: > On 6/7/18 10:07 PM, Brian E Carpenter wrote: > > It's worth a discussion. But I think there are two problems closely > > linked to that one, which are actually more important... > > Relative importance is somewhat subjective. I have seen very little pain > from the first one you describe, mostly due to the ready availability of > "obsoleted" information in both the datatracker and on tools.ietf.org. > What follows may be the only relevant experience I have with this, but it was both hilarious and terrifying. In the early 2000s, I worked for "a large-scale network monitoring vendor" who had been very successful in noticing and alarming for network performance problems in SS7 networks, GSM networks (which had a lot of overlap), GPRS networks, and UMTS networks, and was adding performance analysis for TCP (not for applications, I was already talking to them about not being able to do that reliably, and HTTPS was already a thing). They cracked open the TCP standard, which is STD 7, and implemented Standard TCP. So, basically, RFC 793 (not even the new material in RFC 1122, because they didn't find that, it's part of a different STD, STD 3, and this was all before Updates in headers - you can find that STD 3 updates STD 7 in the datatracker now, but stay with me here, because it wouldn't have mattered if they'd done STD 3 as well). They came to me with traces of what they were actually seeing on live traffic, and it was LOADS of TCP mechanisms that aren't in RFC 793, and weren't in RFC 1122, because, heck, yes, people deployed Proposed Standards. I explained what they were looking at, told them that STDs didn't mean what one might think, and we all had a good laugh, because it was harmless fun - at least at the time, passive network monitors on optical networks didn't have transmit leads, so you couldn't really shoot anything except your own foot. I was talking about this at the next IETF meeting (probably at Newtrk, because that was still going on), and someone from "one of the largest cell phone manufacturers in the world" told me his company had done the same thing, except on cell phones that DID transmit packets, and would have been using the finest congestion control available in RFC 793, which predated Slow Start ... and he wasn't laughing. That's my story. Mileage may vary for other people. I have no idea how unique it was, or whether anything like that will ever happen again. But sometimes it stinks that nobody except maybe us knows what standards actually are ... I'm back to lurking. Enjoy your Fridays, all. Spencer > The second is definitely an issue, but it seems rather unrelated to the > problem this BOF claims to address. Perhaps a separate effort with its > own proponents and proposals would be in order for it. > > In any case, the proposed experiment certainly leaves a number of > problems unsolved, and I suspect that's by design. I don't believe a > grand unified theory of how to fix everything about the IETF's documents > would be manageable. > > /a > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000aeb0f0056e1a7650 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 7,= 2018 at 10:57 PM Adam Roach <adam@n= ostrum.com> wrote:
On 6/7/1= 8 10:07 PM, Brian E Carpenter wrote:
> It's worth a discussion. But I think there are two problems closel= y
> linked to that one, which are actually more important...

Relative importance is somewhat subjective. I have seen very little pain from the first one you describe, mostly due to the ready availability of "obsoleted" information in both the datatracker and on tools.ietf.org= .

What follows m= ay be the only relevant experience I have with this, but it was both hilari= ous and terrifying.

In the early 2000s, I worked for "a larg= e-scale network monitoring vendor" who had been very successful in not= icing and alarming for network performance problems in SS7 networks, GSM ne= tworks (which had a lot of overlap), GPRS networks, and UMTS networks, and = was adding performance analysis for TCP (not for applications, I was alread= y talking to them about not being able to do that reliably, and HTTPS was a= lready a thing).

They cracked open the TCP standar= d, which is STD 7, and implemented Standard TCP. So, basically, RFC 793 (no= t even the new material in RFC 1122, because they didn't find that, it&= #39;s part of a different STD, STD 3, and this was all before Updates in he= aders - you can find that STD 3 updates STD 7 in the datatracker now, but s= tay with me here, because it wouldn't have mattered if they'd done = STD 3 as well).

They came to me with traces of wha= t they were actually seeing on live traffic, and it was LOADS of TCP mechan= isms that aren't in RFC 793, and weren't in RFC 1122, because, heck= , yes, people deployed Proposed Standards.

I expla= ined what they were looking at, told them that STDs didn't mean what on= e might think, and we all had a good laugh, because it was harmless fun - a= t least at the time, passive network monitors on optical networks didn'= t have transmit leads, so you couldn't really shoot anything except you= r own foot.

I was talking about this at the next I= ETF meeting (probably at Newtrk, because that was still going on), and some= one from "one of the largest cell phone manufacturers in the world&quo= t; told me his company had done the same thing, except on cell phones that = DID transmit packets, and would have been using the finest congestion contr= ol available in RFC 793, which predated Slow Start ... and he wasn't la= ughing.

That's my story. Mileage may vary for = other people. I have no idea how unique it was, or whether anything like th= at will ever happen again.

But sometimes it stinks= that nobody except maybe us knows what standards actually are ...

I'm back to lurking. Enjoy your Fridays, all.

Spencer
=C2=A0
The second is definitely an issue, but it seems rather unrelated to the problem this BOF claims to address. Perhaps a separate effort with its
own proponents and proposals would be in order for it.

In any case, the proposed experiment certainly leaves a number of
problems unsolved, and I suspect that's by design. I don't believe = a
grand unified theory of how to fix everything about the IETF's document= s
would be manageable.

/a

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.= org
https://www.ietf.org/mailman/listinfo/rfcplusplus
--000000000000aeb0f0056e1a7650-- From nobody Fri Jun 8 15:22:08 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516ED130F49 for ; Fri, 8 Jun 2018 15:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KEM8jUWydbOL for ; Fri, 8 Jun 2018 15:22:04 -0700 (PDT) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (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 80AEC130DC2 for ; Fri, 8 Jun 2018 15:22:04 -0700 (PDT) Received: by mail-pl0-x234.google.com with SMTP id w17-v6so9034522pll.9 for ; Fri, 08 Jun 2018 15:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3L6lp+UADUWH/vOYCRUiuzGeI6QdV9n4/2zQGKKqQAw=; b=YTERExiRAgsb8QvFUTVLXFyV6l5Zy5XnClWU56e76My+wf0sIn244sxE6+JAromXd6 DBGsCyIFa+ihHZan4adEc5YcBhUAm7Eq1Io0LBPy9185Ym1Kid0ehPVmROu3C4W5V9VZ tsUrzaRj37wyDjrIC1OYE0RGL8eT4zKuYevPlryMZfeT+U2XS6p1o6CMVtu1qfOAxoUe 2UwJFQhbt+KI9yuQ3n7Y8WDv21XegL+jONHBpkyGjX/S/XyQBmghz+mfGt5w94TZVShk /gX8L0YU11vvlUWiYPzwRw/ZMCmCE/IftPcFkVA789qlgIW+TrVBZ1GugiwFo7cbPCmo EaeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3L6lp+UADUWH/vOYCRUiuzGeI6QdV9n4/2zQGKKqQAw=; b=Q5kXcTBBhlsLslVax+kO3xkJ5j9tVMxlLs8cxEUs9rf9CDQkE+rSW1VlG8G5X37a08 Qo8SgKOeKP79JuTzgHfKK1+BYB3Mgv+iHqOg2X33wNVkYRgKWm5eL0ROK8C3GkKnrKRD Ih7jTWXqFrgqn68O8qgOGsn4Vgredx1injhElAhX/eCyFSYCYvnvqaZeJwPBqwtzFYGI QWX8O3VXq8yp41k+/Z2b2k0pGqn+DQ82Kr2lGPeoIFnA27hmAABE2NlB1Swc0ki9pNB4 PkyJB8y7nJIu3waYFvDO7p2r9sT65gBns2bTJAjtQuvuLzc8jTHPERkVfvfdpZAkPrje aqkQ== X-Gm-Message-State: APt69E0j9RCsGB0kwxO4tiF2Zygpqs1T012O91GQfN6dfZFdNjfZdURv NW9jW40J7xoYt7uOctYwzHU4zA== X-Google-Smtp-Source: ADUXVKI7r97woTa+NtdmebYWX7X9oo+vm51ltj6C7WJb5Tagxx8OEBfJ377Yj1RkpITevQMS+kvItQ== X-Received: by 2002:a17:902:740a:: with SMTP id g10-v6mr8484021pll.246.1528496523822; Fri, 08 Jun 2018 15:22:03 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z3-v6sm9145711pfn.36.2018.06.08.15.22.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 15:22:02 -0700 (PDT) To: Barry Leiba , Adam Roach Cc: "Joel M. Halpern" , "Andrew G. Malis" , Paul Hoffman , rfcplusplus@ietf.org References: <1C91022B-8CE7-4842-B064-C21322C3F6F3@vpnc.org> <679126cc-e72b-aace-3374-4d5c95688b23@nostrum.com> From: Brian E Carpenter Message-ID: Date: Sat, 9 Jun 2018 10:22:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] If it ain't broke ... X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 22:22:07 -0000 On 07/06/2018 18:57, Barry Leiba wrote: >>> I was just about to make Joel's last point in response to an earlier >>> email. If we deem the "experiment" a failure, how do we go back? Do we >>> reissue all of the non-RFCs as RFCs? >> >> The BOF description currently says: "At the end of the experiment, the >> community would discuss whether these stream identifiers were sufficiently >> useful in technical references and discussions to maintain the technical >> dialog among the relevant technical communities. If they are not, RFC >> numbers would be allocated for each document published under the >> experiment..." > > Apart from that, I would suggest that we continue the consecutive > numbering as though we were issuing RFCs, and then change the prefix. > So, RFC9112, IAB9113, BCP9114, RFC9115, EXP9116, etc. That will make > it trivial to switch them all back to "RFC" if we decide to. There's a gotcha there, which is that flipping labels in the metadata of a document is easy, but flipping them in the archival text isn't just difficult, it's always been forbidden in the RFC series. The only obvious implementation technique is that if we experimentally issue a document as, say, RFC-BCP9114 (to use that format as an example), and later decided the experiment had failed, would be then to retroactively issue the text as RFC9114 and insert it in the archive. Copies of RFC-BCP9114 would then float around for ever, as IENs do today. Also, this doesn't do what BCP and STD numbers do, which is bind together the various RFCs that constitute a single BCP or STD. And it certainly doesn't do what ISDs were proposed for, which is to bind together all the documents of any status that are relevant to a single purpose. I'm still not sure that the cure is better than the alleged disease. And I think that ISDs would cure the alleged disease and two others at the same time. They involve real work, however,not just labels. The base reference for ISDs: https://tools.ietf.org/html/draft-klensin-isdbis-00 Brian From nobody Fri Jun 8 20:12:47 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6138130E0C for ; Fri, 8 Jun 2018 20:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WcdTEaEkDPTU for ; Fri, 8 Jun 2018 20:12:43 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 E7F14130E0E for ; Fri, 8 Jun 2018 20:12:42 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id l2-v6so7203724pgc.7 for ; Fri, 08 Jun 2018 20:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SnqF7AnF+4Z58PUtIXtL222qQrKiN0UbpEu8Tx6e8Hw=; b=hWjEo7rVUMHQtaDVfVwMK1g2o0nWjwdZYLtWmMvnmDlrJ8ZsL0GP16K1/LIeSlvBWF 3KaD/RJr/GHavRlFky4NjMVnn0JS51lE4wlbI6VwYszjw6YrqB5TtDv9d2iSj6mrAHyk ww9/kWdMN5+9jsqf4fC9cKk4Sz0uZc7mHH6GQjGRCY4Ng+VO2gA/Zfc8IaAU6raatwh5 8xGqEpMh6ML4y4k1ZGkmbc95R+9S5HoHZXODhKBhI+eHwALenIB5QqVe822CInZ158No PgfCCyNV3A/ytnxrt0kPhekjUtp/daQVEqgINClUFEDWd53s0C+CJcW6qyJe1GVzvfV0 /Oyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SnqF7AnF+4Z58PUtIXtL222qQrKiN0UbpEu8Tx6e8Hw=; b=Y4Sam3e1TJfMQLsikWpLSyrdjs48GDNtR+MhaUYerlOF4mugjGTI2jsHdIpDqb3jZ3 ex65NhaNF6YAOXffpqmBbimki2a3onpeIibgQ0T1fSbMYXA37NxZlBKxxLNO1tdhNq/z YbN/Zh46sDqEYXPSKw1+pkxEZtrhQDmfdWPIyRTB6qW/g0DTfiUcIJuwTUyQGy0dF9io ZCvygPX6ddtoMBuEfYyK8i/eAHfxab5Z15tXsQn37EoH60wWDLkHyPE9roNOKpIzj+x9 7WJzgaqoddgQeoI1h2LS7thJ/MB4qLSisE4tCxhX8DpO9dSxEmmWHBnxyBjujO3ACDnK RFJA== X-Gm-Message-State: APt69E3Bcc+YhY6OIvhCg4qUwwqcBPnAdMus+I5+k4SRn/q3cKjc7g6t WqEibiijck8vi7f/Gouoh4uBBQ== X-Google-Smtp-Source: ADUXVKIcXc30UkQT+nbQpn1+koZh7YZDoeVhB+OS9DZ2YmbUQ2530CqfXnN6TdFPIZ5cRw08dPraXw== X-Received: by 2002:a63:648:: with SMTP id 69-v6mr7384259pgg.205.1528513962114; Fri, 08 Jun 2018 20:12:42 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id r2-v6sm4205730pfa.49.2018.06.08.20.12.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 20:12:40 -0700 (PDT) To: Spencer Dawkins at IETF Cc: Joe Hall , Barry Leiba , rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> From: Brian E Carpenter Message-ID: <4a9acd7f-9889-af04-29d3-284d54e79361@gmail.com> Date: Sat, 9 Jun 2018 15:12:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 03:12:45 -0000 On 07/06/2018 21:31, Spencer Dawkins at IETF wrote: > I'm doing my best to listen before speaking ... > > On Thu, Jun 7, 2018 at 12:13 AM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 07/06/2018 09:26, Joseph Lorenzo Hall wrote: >>> I could also use some clarification, Brian. My take away from the >>> draft was, "we have a bunch of ongoing experiments, it would not be >>> wise to start another one until those have completed". What am I >>> missing? >> >> That is one of the takeaways. Let's figure out why past attempts, >> especially the STD designation, haven't fixed a problem that was >> first documented in 1994. > > > The IETF Problem Statement RFC from 2004 talks about this in > https://tools.ietf.org/html/rfc3774#section-2.4, but the high-order bit was > that STDs only help specifications at the penultimate level of the > hierarchy ("Internet Standard"). So this is way less mysterious than some > other issues under discussion. > > Fixing the STD designation might, or might not, be orthogonal to the > experiment being proposed here. I don't think it's orthogonal. I think this is part of the confusion in the "market", exemplified by the ancient comment that "The Internet runs on Proposed Standards." [Fred Baker, I think, said that first.] If you aren't doing the right thing by implemementing an "STD", because it's been superseded by a mere RFC, why are you going to believe that the label matters at all? If RFC-PS9876 supersedes RFC-STD8200, how is a reader of 8200 supposed to know that? The label doesn't help in the least; rather the opposite, since STD is clearly superior to PS. And how is the implementer supposed to know that the real list of IPv6 "conformance" requirements is to be found in draft-ietf-6man-rfc6434-bis-23 ? There are, IMHO, simply no easy and cheap solutions here. Solving a small corner of a complex problem seems like a distraction to me. Brian > > Spencer > > >> Probably the problem is deeper than >> just document labels, so let's figure out the problem too. >> >> This can't be very urgent, because we've managed for the last 24 years. >> >> There are at least two other points too: >> >> 1. The RFC series belongs to everybody, not just to the IETF. >> So we can't unilaterally decide for everbody. >> >> 2. It is good for the IETF to be fundamentally modest and open >> to feedback about its work. Calling all our documents "request for >> comments" is therefore highly appropriate. >> >> Regards >> Brian >> >>> >>> On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter >>> wrote: >>>> I'm out of time at this moment, but no, that isn't the argument. >>>> >>>> The argument is that having a single document series that is >> specifically >>>> named as not being dogma is the right thing to do. >>>> >>>> Better labels are a good idea, within that series, for sure. >>>> >>>> Regards >>>> Brian >>>> >>>> On 06/06/2018 22:24, Barry Leiba wrote: >>>>> Brian, the draft appears to be saying, essentially, that we shouldn't >>>>> make the sorts of changes to the RFC series that we've proposed to >>>>> discuss here because the RFC series is an old and venerable thing and >>>>> shouldn't be changed. I don't buy it. >>>>> >>>>> The primary thing I don't buy is that "RFC" still means "request for >>>>> comments". At some level, sure, it does, because people can and will >>>>> comment on RFCs, submit errata reports, and so on. But most of the >>>>> world thinks of RFCs as IETF standards, with some subset understanding >>>>> that the series also contains informational and experimental stuff. >>>>> The comment period, really, is during the development of the Internet >>>>> Drafts. One only needs to look at the strict scrutiny performed by >>>>> the IESG to see that the bar for getting to RFC is well beyond that >>>>> warranted for the publication of a request for comments. >>>>> >>>>> As to ownership, I agree that the series is owned by "the community", >>>>> and it's exactly that community we're calling on for discussion of >>>>> proposed changes. If we think that, for example, the IRTF is being >>>>> short-changed here, we have only to publicize this discussion to the >>>>> IRTF an ask them to come be part of it. The same goes for any other >>>>> sub-community we think isn't adequately represented. >>>>> >>>>> Apart from that, I see little substance in the draft about your >>>>> objection to considering the sort of change proposed here (apart from >>>>> the "request for comments" part). Can you be clearer, not about the >>>>> history of the RFC series, but about specifically why you think such a >>>>> change would be bad? >>>>> >>>>> Barry >>>>> >>>>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter >>>>> wrote: >>>>>> -------- Forwarded Message -------- >>>>>> Subject: I-D Action: draft-carpenter-request-for-comments-00.txt >>>>>> Date: Tue, 05 Jun 2018 20:16:12 -0700 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>>>>> >>>>>> >>>>>> Title : Request for Comments >>>>>> Author : Brian Carpenter >>>>>> Filename : draft-carpenter-request-for-comments-00.txt >>>>>> Pages : 7 >>>>>> Date : 2018-06-05 >>>>>> >>>>>> Abstract: >>>>>> This document discusses the Internet technical community's common >>>>>> document series. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> >> https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ >>>>>> >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 >>>>>> >> https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> _______________________________________________ >>>>>> Rfcplusplus mailing list >>>>>> Rfcplusplus@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rfcplusplus >>>>> >>>> >>>> _______________________________________________ >>>> Rfcplusplus mailing list >>>> Rfcplusplus@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rfcplusplus >>> >>> >>> >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> > From nobody Mon Jun 11 07:43:03 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6608130FDC for ; Mon, 11 Jun 2018 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 tjnXf_OPqzWz for ; Mon, 11 Jun 2018 07:42:59 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 2712C124D68 for ; Mon, 11 Jun 2018 07:42:59 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id x36-v6so6777308ybi.0 for ; Mon, 11 Jun 2018 07:42:59 -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=U+jDP46jzzOSLS2tBJtQ7s137Rom6W3hRjZZ8m3bmk4=; b=kNxnPEj6tXN1R9OCy7KwhMe8XH3SwIAkNh0hJC+lOhvL0tmXtpRZTkAjnhENiajYPO 2OS2TRQdSTu6rcPMRM3+oQyORlk2xUxnE9juew0yBN5i+GC++jBnxio47qHkIq78f01H 2d+suQGymP9yXUcHqtw2jf3PYtPlXgKx2EYVLAm58s+2FcUYykbs63FRH0ZOb7SZ2Hvt 1dJSm9bnmp0vzazc8tGt5XCZrtem+URE/YM/xRZdRywzO7DCSJlxlW0Lpc8beCYxhnvO Rc223i2MBXhrd7syV3Uo7o5sBPXsZTvF0dCbYsdtixa2S8s76HYuavsboLB8nwcV98hZ aYJQ== 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=U+jDP46jzzOSLS2tBJtQ7s137Rom6W3hRjZZ8m3bmk4=; b=NkTFbBj1yVi/tFBNfJqhy6opHpXu5DCiTMwJmDCGwnZoc35kL4Iwkb7UtMYQgrxej2 Htqcp/8Q16amkP5pcahmYHn29l8MMnGa1HNEx8uyS0lxdrPK4jWQ9AK4sTmkjIjfpXvD V35Yx8WmHs7yMsdgql8oPFJ7V0kLyFVOoRUD/AI7iR4vlUAIku433D+BFZY0YBMv4biu ecrYUhjZ4DJeLSn1CLFAn/OUdZgnVCBEvQGTHhNraX9HB6Mv6t8PV3J53i//chzJ7gGj MiiWmbjUujdde7vuDbXmxDf7gdS/rWhnKdtLtYrPHrLE1UBa3QJVdTMQi5WSlFSc6lhT 2jOw== X-Gm-Message-State: APt69E1r9WwaCFvwFviPGruULUpEbhV2KcR0sr8BXU87RzpLIZrrE6jG hWOkv7a/Jcyt4y1tNn0t7SUykBBvfUBe1/GIqGM= X-Google-Smtp-Source: ADUXVKLZNjeYQFsZ78QYd3uLpep6LxChQ+8dlfNBSd54nzRnb+B0U43EthLmDWl8Gk1Oedo7m+3eIzEDi+JCsYaSSR8= X-Received: by 2002:a25:ac9c:: with SMTP id x28-v6mr10413118ybi.44.1528728178225; Mon, 11 Jun 2018 07:42:58 -0700 (PDT) MIME-Version: 1.0 References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <4a9acd7f-9889-af04-29d3-284d54e79361@gmail.com> In-Reply-To: <4a9acd7f-9889-af04-29d3-284d54e79361@gmail.com> From: Spencer Dawkins at IETF Date: Mon, 11 Jun 2018 09:42:45 -0500 Message-ID: To: Brian E Carpenter Cc: Joe Hall , Barry Leiba , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000057831056e5ec453" Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 14:43:02 -0000 --000000000000057831056e5ec453 Content-Type: text/plain; charset="UTF-8" I feel bad for pointing this out, but ... On Fri, Jun 8, 2018 at 10:12 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 07/06/2018 21:31, Spencer Dawkins at IETF wrote: > > I'm doing my best to listen before speaking ... > > > > On Thu, Jun 7, 2018 at 12:13 AM Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 07/06/2018 09:26, Joseph Lorenzo Hall wrote: > >>> I could also use some clarification, Brian. My take away from the > >>> draft was, "we have a bunch of ongoing experiments, it would not be > >>> wise to start another one until those have completed". What am I > >>> missing? > >> > >> That is one of the takeaways. Let's figure out why past attempts, > >> especially the STD designation, haven't fixed a problem that was > >> first documented in 1994. > > > > > > The IETF Problem Statement RFC from 2004 talks about this in > > https://tools.ietf.org/html/rfc3774#section-2.4, but the high-order bit > was > > that STDs only help specifications at the penultimate level of the > > hierarchy ("Internet Standard"). So this is way less mysterious than some > > other issues under discussion. > > > > Fixing the STD designation might, or might not, be orthogonal to the > > experiment being proposed here. > > I don't think it's orthogonal. I think this is part of the confusion in > the "market", exemplified by the ancient comment that "The Internet runs > on Proposed Standards." [Fred Baker, I think, said that first.] If you > aren't doing the right thing by implemementing an "STD", because it's > been superseded by a mere RFC, why are you going to believe that the > label matters at all? > > If RFC-PS9876 supersedes RFC-STD8200, how is a reader of 8200 supposed > to know that? The label doesn't help in the least; rather the opposite, > since STD is clearly superior to PS. > Yeah, based on my experience and John Loughney's experience, we proposed https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01. I think there's a variation of Godwin's Law that applies, when that draft is mentioned during an e-mail discussion ... Spencer > And how is the implementer supposed to know that the real list of IPv6 > "conformance" requirements is to be found in > draft-ietf-6man-rfc6434-bis-23 ? > > There are, IMHO, simply no easy and cheap solutions here. Solving > a small corner of a complex problem seems like a distraction to me. > > Brian > > > > > > Spencer > > > > > >> Probably the problem is deeper than > >> just document labels, so let's figure out the problem too. > >> > >> This can't be very urgent, because we've managed for the last 24 years. > >> > >> There are at least two other points too: > >> > >> 1. The RFC series belongs to everybody, not just to the IETF. > >> So we can't unilaterally decide for everbody. > >> > >> 2. It is good for the IETF to be fundamentally modest and open > >> to feedback about its work. Calling all our documents "request for > >> comments" is therefore highly appropriate. > >> > >> Regards > >> Brian > >> > >>> > >>> On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter > >>> wrote: > >>>> I'm out of time at this moment, but no, that isn't the argument. > >>>> > >>>> The argument is that having a single document series that is > >> specifically > >>>> named as not being dogma is the right thing to do. > >>>> > >>>> Better labels are a good idea, within that series, for sure. > >>>> > >>>> Regards > >>>> Brian > >>>> > >>>> On 06/06/2018 22:24, Barry Leiba wrote: > >>>>> Brian, the draft appears to be saying, essentially, that we shouldn't > >>>>> make the sorts of changes to the RFC series that we've proposed to > >>>>> discuss here because the RFC series is an old and venerable thing and > >>>>> shouldn't be changed. I don't buy it. > >>>>> > >>>>> The primary thing I don't buy is that "RFC" still means "request for > >>>>> comments". At some level, sure, it does, because people can and will > >>>>> comment on RFCs, submit errata reports, and so on. But most of the > >>>>> world thinks of RFCs as IETF standards, with some subset > understanding > >>>>> that the series also contains informational and experimental stuff. > >>>>> The comment period, really, is during the development of the Internet > >>>>> Drafts. One only needs to look at the strict scrutiny performed by > >>>>> the IESG to see that the bar for getting to RFC is well beyond that > >>>>> warranted for the publication of a request for comments. > >>>>> > >>>>> As to ownership, I agree that the series is owned by "the community", > >>>>> and it's exactly that community we're calling on for discussion of > >>>>> proposed changes. If we think that, for example, the IRTF is being > >>>>> short-changed here, we have only to publicize this discussion to the > >>>>> IRTF an ask them to come be part of it. The same goes for any other > >>>>> sub-community we think isn't adequately represented. > >>>>> > >>>>> Apart from that, I see little substance in the draft about your > >>>>> objection to considering the sort of change proposed here (apart from > >>>>> the "request for comments" part). Can you be clearer, not about the > >>>>> history of the RFC series, but about specifically why you think such > a > >>>>> change would be bad? > >>>>> > >>>>> Barry > >>>>> > >>>>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter > >>>>> wrote: > >>>>>> -------- Forwarded Message -------- > >>>>>> Subject: I-D Action: draft-carpenter-request-for-comments-00.txt > >>>>>> Date: Tue, 05 Jun 2018 20:16:12 -0700 > >>>>>> From: internet-drafts@ietf.org > >>>>>> Reply-To: internet-drafts@ietf.org > >>>>>> To: i-d-announce@ietf.org > >>>>>> > >>>>>> > >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>>>>> > >>>>>> > >>>>>> Title : Request for Comments > >>>>>> Author : Brian Carpenter > >>>>>> Filename : > draft-carpenter-request-for-comments-00.txt > >>>>>> Pages : 7 > >>>>>> Date : 2018-06-05 > >>>>>> > >>>>>> Abstract: > >>>>>> This document discusses the Internet technical community's common > >>>>>> document series. > >>>>>> > >>>>>> > >>>>>> The IETF datatracker status page for this draft is: > >>>>>> > >> https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/ > >>>>>> > >>>>>> There are also htmlized versions available at: > >>>>>> https://tools.ietf.org/html/draft-carpenter-request-for-comments-00 > >>>>>> > >> > https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00 > >>>>>> > >>>>>> > >>>>>> Please note that it may take a couple of minutes from the time of > >> submission > >>>>>> until the htmlized version and diff are available at tools.ietf.org > . > >>>>>> > >>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>> > >>>>>> _______________________________________________ > >>>>>> I-D-Announce mailing list > >>>>>> I-D-Announce@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Rfcplusplus mailing list > >>>>>> Rfcplusplus@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/rfcplusplus > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Rfcplusplus mailing list > >>>> Rfcplusplus@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rfcplusplus > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Rfcplusplus mailing list > >> Rfcplusplus@ietf.org > >> https://www.ietf.org/mailman/listinfo/rfcplusplus > >> > > > --000000000000057831056e5ec453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I feel bad for pointing this out, but ...

On 07/06/2018 21:31, Spencer Dawkins at IETF wrote:
> I'm doing my best to listen before speaking ...
>
> On Thu, Jun 7, 2018 at 12:13 AM Brian E Carpenter <
> brian= .e.carpenter@gmail.com> wrote:
>
>> On 07/06/2018 09:26, Joseph Lorenzo Hall wrote:
>>> I could also use some clarification, Brian. My take away from = the
>>> draft was, "we have a bunch of ongoing experiments, it wo= uld not be
>>> wise to start another one until those have completed". Wh= at am I
>>> missing?
>>
>> That is one of the takeaways. Let's figure out why past attemp= ts,
>> especially the STD designation, haven't fixed a problem that w= as
>> first documented in 1994.
>
>
> The IETF Problem Statement RFC from 2004 talks about this in
> https://tools.ietf.org/html/rfc3774#section-2.4<= /a>, but the high-order bit was
> that STDs only help specifications at the penultimate level of the
> hierarchy ("Internet Standard"). So this is way less mysteri= ous than some
> other issues under discussion.
>
> Fixing the STD designation might, or might not, be orthogonal to the > experiment being proposed here.

I don't think it's orthogonal. I think this is part of the confusio= n in
the "market", exemplified by the ancient comment that "The I= nternet runs
on Proposed Standards." [Fred Baker, I think, said that first.] If you=
aren't doing the right thing by implemementing an "STD", beca= use it's
been superseded by a mere RFC, why are you going to believe that the
label matters at all?

If RFC-PS9876 supersedes RFC-STD8200, how is a reader of 8200 supposed
to know that? The label doesn't help in the least; rather the opposite,=
since STD is clearly superior to PS.


I think there's a variati= on of Godwin's Law that applies, when that draft is mentioned during an= e-mail discussion ...

Spencer
=C2=A0
And how is the impleme= nter supposed to know that the real list of IPv6
"conformance" requirements is to be found in draft-ietf-6man-rfc6= 434-bis-23 ?

There are, IMHO, simply no easy and cheap solutions here. Solving
a small corner of a complex problem seems like a distraction to me.

=C2=A0 =C2=A0Brian


>
> Spencer
>
>
>> Probably the problem is deeper than
>> just document labels, so let's figure out the problem too.
>>
>> This can't be very urgent, because we've managed for the l= ast 24 years.
>>
>> There are at least two other points too:
>>
>> 1. The RFC series belongs to everybody, not just to the IETF.
>> So we can't unilaterally decide for everbody.
>>
>> 2. It is good for the IETF to be fundamentally modest and open
>> to feedback about its work. Calling all our documents "reques= t for
>> comments" is therefore highly appropriate.
>>
>> Regards
>>=C2=A0 =C2=A0 Brian
>>
>>>
>>> On Wed, Jun 6, 2018 at 4:33 PM, Brian E Carpenter
>>> <brian.e.carpenter@gmail.com> wrote:
>>>> I'm out of time at this moment, but no, that isn't= the argument.
>>>>
>>>> The argument is that having a single document series that = is
>> specifically
>>>> named as not being dogma is the right thing to do.
>>>>
>>>> Better labels are a good idea, within that series, for sur= e.
>>>>
>>>> Regards
>>>>=C2=A0 =C2=A0 Brian
>>>>
>>>> On 06/06/2018 22:24, Barry Leiba wrote:
>>>>> Brian, the draft appears to be saying, essentially, th= at we shouldn't
>>>>> make the sorts of changes to the RFC series that we= 9;ve proposed to
>>>>> discuss here because the RFC series is an old and vene= rable thing and
>>>>> shouldn't be changed.=C2=A0 I don't buy it. >>>>>
>>>>> The primary thing I don't buy is that "RFC&qu= ot; still means "request for
>>>>> comments".=C2=A0 At some level, sure, it does, be= cause people can and will
>>>>> comment on RFCs, submit errata reports, and so on.=C2= =A0 But most of the
>>>>> world thinks of RFCs as IETF standards, with some subs= et understanding
>>>>> that the series also contains informational and experi= mental stuff.
>>>>> The comment period, really, is during the development = of the Internet
>>>>> Drafts.=C2=A0 One only needs to look at the strict scr= utiny performed by
>>>>> the IESG to see that the bar for getting to RFC is wel= l beyond that
>>>>> warranted for the publication of a request for comment= s.
>>>>>
>>>>> As to ownership, I agree that the series is owned by &= quot;the community",
>>>>> and it's exactly that community we're calling = on for discussion of
>>>>> proposed changes.=C2=A0 If we think that, for example,= the IRTF is being
>>>>> short-changed here, we have only to publicize this dis= cussion to the
>>>>> IRTF an ask them to come be part of it.=C2=A0 The same= goes for any other
>>>>> sub-community we think isn't adequately represente= d.
>>>>>
>>>>> Apart from that, I see little substance in the draft a= bout your
>>>>> objection to considering the sort of change proposed h= ere (apart from
>>>>> the "request for comments" part).=C2=A0 Can = you be clearer, not about the
>>>>> history of the RFC series, but about specifically why = you think such a
>>>>> change would be bad?
>>>>>
>>>>> Barry
>>>>>
>>>>> On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter
>>>>> <brian.e.carpenter@gmail.com> wrote:
>>>>>> -------- Forwarded Message --------
>>>>>> Subject: I-D Action: draft-carpenter-request-for-c= omments-00.txt
>>>>>> Date: Tue, 05 Jun 2018 20:16:12 -0700
>>>>>> From: internet-drafts@ietf.org
>>>>>> Reply-To: internet-drafts@ietf.org
>>>>>> To: i-d-announce@ietf.org
>>>>>>
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line= Internet-Drafts
>> directories.
>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Request for Comments
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : Brian Carpenter
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 = =C2=A0 =C2=A0 =C2=A0 : draft-carpenter-request-for-comments-00.txt
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 7
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2018-06-05
>>>>>>
>>>>>> Abstract:
>>>>>>=C2=A0 =C2=A0 This document discusses the Internet = technical community's common
>>>>>>=C2=A0 =C2=A0 document series.
>>>>>>
>>>>>>
>>>>>> The IETF datatracker status page for this draft is= :
>>>>>>
>> https://datatracker.i= etf.org/doc/draft-carpenter-request-for-comments/
>>>>>>
>>>>>> There are also htmlized versions available at:
>>>>>> https://= tools.ietf.org/html/draft-carpenter-request-for-comments-00
>>>>>>
>> https://datatr= acker.ietf.org/doc/html/draft-carpenter-request-for-comments-00
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes f= rom the time of
>> submission
>>>>>> until the htmlized version and diff are available = at t= ools.ietf.org.
>>>>>>
>>>>>> Internet-Drafts are also available by anonymous FT= P at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/<= br> >>>>>>
>>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list
>>>>>> I-D-Announce@ietf.org
>>>>>> https://www.ietf.org/mail= man/listinfo/i-d-announce
>>>>>> Internet-Draft directories: http://www.ietf.= org/shadow.html
>>>>>> or ftp://ftp.ietf.org/ietf/1shadow= -sites.txt
>>>>>>
>>>>>> _______________________________________________ >>>>>> Rfcplusplus mailing list
>>>>>> Rfcplusplus@ietf.org
>>>>>> https://www.ietf.org/mailm= an/listinfo/rfcplusplus
>>>>>
>>>>
>>>> _______________________________________________
>>>> Rfcplusplus mailing list
>>>> = Rfcplusplus@ietf.org
>>>> https://www.ietf.org/mailman/listi= nfo/rfcplusplus
>>>
>>>
>>>
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> Rfcplusp= lus@ietf.org
>> https://www.ietf.org/mailman/listinfo/rfc= plusplus
>>
>
--000000000000057831056e5ec453-- From nobody Mon Jun 11 08:55:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DC8130F58 for ; Mon, 11 Jun 2018 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 iuKBX2nl7gfu for ; Mon, 11 Jun 2018 08:55:49 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 ABAF8130E5F for ; Mon, 11 Jun 2018 08:55:49 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id c128-v6so18315882oig.11 for ; Mon, 11 Jun 2018 08:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=39sbc9MZlwXcffGZEHmiRGuqxXcki7IXBspaNf5GU2c=; b=MkGmwRqsQGesrmM8dMMa4YQrhIkQtd0CjVrYz0G4WWV0fA835TXVzaKJqtDCzHKelW EDot1i3Y0sb23EpX1rPVDEAzT271AEZ+w4MGIapGhm/x/nZMwOQvxDRJPF6hA5Vg4S9b oAT151xWOIEJsXvGP0orJc+dZGcEDcB5Y83SRAezxygGP+O3GsoDkAVOFUOByNHa6J7S hCnicZ4dR2y0cZRpPRuZ8q+DQBgMPpwKlWkp5emFs8f/ZV/AipZhdzlHwcN0/TWRWXF/ 4FvV9rhqpoQ9ijUI9JTYzH9PM5zQI+RyB48sX6XaWMOLGQwcCK8sEMufpJTJy/E2WxYq +H1w== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=39sbc9MZlwXcffGZEHmiRGuqxXcki7IXBspaNf5GU2c=; b=UDDSm/BudxT0gBAxaLoG9YqimPfdS2nQElJOfSPDJyMN2GBje/qaaOWsRmgO4Eueys KkLtr83WLPsljENgaTYBWjD9qOr3330xKorYigBKl0AecC6mI/yuoqp31i2km2tat1lc gGhZjCUxaNYdbNhgpZmxJEIzqh+LTi1qz7wI/TIYvQ9GoFmXJNzwdxWNQ+11rVYEL6T6 QLSIZL0vpJcLO+CpLzOvWzanEDupVHB87zlh5a8PE8NqeiHvBvD/1fwXscpImffnUAh6 gHMbBb6MkqO18BMdYfvV5eYqi8zCBnvh8L/dxwPAoE3LG/fFcWQ2NKSfxiNiWrgr7Yez KZCQ== X-Gm-Message-State: APt69E1Gi0FBQOPADqO+QZJy2oKlAc9HjwHPdbGNVowVjRAw5RmEJA3n mYQVC1km02l7/rvxvKFRbV6DlhfBF7r9 X-Google-Smtp-Source: ADUXVKJzf40EuO64xhhY4b8V5pNx84vN0+Wa/cShbHpnGZAki/0Vg7w4KVEoO3KlXfsEva7BG/Wtkw== X-Received: by 2002:aca:e34a:: with SMTP id a71-v6mr8257972oih.283.1528732548761; Mon, 11 Jun 2018 08:55:48 -0700 (PDT) Received: from [192.168.1.7] ([65.129.137.157]) by smtp.googlemail.com with ESMTPSA id l80-v6sm12629020oih.9.2018.06.11.08.55.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 08:55:48 -0700 (PDT) To: rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <9653b352-7c18-fce9-a419-06b74f94f4a1@gmail.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: Date: Mon, 11 Jun 2018 09:55:45 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <9653b352-7c18-fce9-a419-06b74f94f4a1@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:55:52 -0000 On 06/07/2018 09:07 PM, Brian E Carpenter wrote: >... > > It's worth a discussion. But I think there are two problems closely linked > to that one, which are actually more important: > > 1. That people, with the best will in the world, cannot reliably find > the *latest* version of a standard, which I'm sure most of them expect > STDnnnn to lead them to, if they know at all that STD numbers exist. > > 2. That people cannot find a reliable guide to all the documents > of all categories that cover a given topic. > > Proposals for solving these problems have been made in the past, > but our users (readers of RFCs) still have them. And I would add a much more difficult "it would be nice" item of: 3. What are people really using, or getting ready to implement? A nice web page listing: protocol, latest standard, proposed standards, hopeful document(s), and with a big bold "X" indicating that someone implemented this, and maybe a little 'x' if they are planning to in the near future. Because I really don't like evaluating a document, digging in deep, only to find that no one cares to use the latest neat idea. -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135 From nobody Mon Jun 11 13:29:46 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE81C130E7E for ; Mon, 11 Jun 2018 13:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xx0e0xoGQklD for ; Mon, 11 Jun 2018 13:29:42 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 5444B130DDE for ; Mon, 11 Jun 2018 13:29:42 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id y5-v6so9929425pfn.4 for ; Mon, 11 Jun 2018 13:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7HOfjY0L26eK44LD6tGV6//dMuk5neSdvIXqfYdU4sk=; b=VwKdReOpyMeu4bZtbRzvrGM0R5UfLzttV5nR15Mc6BIfYbeS/zL0s7hKhjvD8q40kr f8Ob0e37JdYDaEheS4f4mXwpfOig/gDsub5AR4I3fiogUQdDPT6tOhpUw9uNb8+v65M5 deDBMj6aJzLNonR8Zo6C2Li7cJ3M6FbyG0ZrdsDQzYWabmt7QAl/AvQMSAbzkeJEsx6W NvSnGXipEOaXdCSurfi/jIHeiCsJzoUOcyCyhGIn6mmv6W6Fnt/yKWkpGV+iSglEUnKO CJB1Zwm7MvTNE+qop85ioMpgarJ4qBRF/V1UMaQtymJj8EZz33Nu9YTblNtIgzmmG6qD 5Gyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7HOfjY0L26eK44LD6tGV6//dMuk5neSdvIXqfYdU4sk=; b=av/Y/mEOoZ0QueKR5tpe5luWDNqpR406hIygPgyVqTRlwYEte327VvHrrRf7xXWbgX xtsCKAi6dOlXNeuLFW0wEN5U0Saj+USNKadfjgb8FeH9mu0mDaDsaMoH6j4dqOhX1G4i xfykk7D6RWfZV4XnhhHUMz038CwCibPqBTnwdqZI2Age40FP5tsTnmeH6GueehWCDaDW Vd63l/QPxcJPRI4CQ8c8k6pcmxagR5/Ys37YqMMVpJH+UceKDBAXOkNfq3JP7t2nL4QE dO1lRcuuFJZsL8k1dFpOPcMBx2PvDr45J7y4o55/V8Oz6dPnRsbtT7RPhGm30eoUIlWM 7Qnw== X-Gm-Message-State: APt69E3rIC+3FZO0ohcykJNluSzrjUq6JdBemXqJLWH3ueXp72bdzaHQ SVpC3xZd+Gc7LPTRjyVpRoxQaQ== X-Google-Smtp-Source: ADUXVKJEYlF6m9ZLnPK4wlaF5jBqMBky0VNVMniCBckLL0YqgB2fTYtcPVusC8qTo9vnYhYj9e6D2g== X-Received: by 2002:a62:8703:: with SMTP id i3-v6mr655250pfe.115.1528748981533; Mon, 11 Jun 2018 13:29:41 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id u47-v6sm79579126pgn.70.2018.06.11.13.29.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jun 2018 13:29:40 -0700 (PDT) To: Spencer Dawkins at IETF Cc: Joe Hall , Barry Leiba , rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <4a9acd7f-9889-af04-29d3-284d54e79361@gmail.com> From: Brian E Carpenter Message-ID: <9d5f522a-162c-7f24-43dd-e3905c52aaf0@gmail.com> Date: Tue, 12 Jun 2018 08:29:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 20:29:45 -0000 On 12/06/2018 02:42, Spencer Dawkins at IETF wrote: ... > Yeah, based on my experience and John Loughney's experience, we proposed > https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01. I should have cited that in my draft, too. I still think it was the best proposal around at that time. Brian From nobody Fri Jun 15 22:38:35 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E35130FB7 for ; Fri, 15 Jun 2018 22:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 zLZyWr3hFaBq for ; Fri, 15 Jun 2018 22:38:30 -0700 (PDT) Received: from mx3-int.auckland.ac.nz (mx3-int.auckland.ac.nz [130.216.125.244]) (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 620FF130FBA for ; Fri, 15 Jun 2018 22:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1529127510; x=1560663510; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=JwuyqOg/TiGWY7FNz9r/vzte41ohKPAM5rLSV2eSshI=; b=yWXKsZPi5FU8B/3haoq+eSpsiiFhdHJ3rLWHyYYSUBONLJGwftRR/Qzg 3O3zhdnhxpS4lPOiLyBYO4DJTgZn96qNIIfvvg4/Va/4c9m+cZzggl1eM 7bxRI/Wv7N46ODRgzzg0ShbM9Qwp5QD++TLi4BXva3Fl26L/YiBOsaFXt WYXKYUyWjcRZZKCX456spgA3Ae4CSjmlKMUYW9oCf9x+uHHxnDaskxTiz EdqjwOksIVzgb2BqpBBggvTNqNgrSOzQYuKTK6RG23d/4ACjgC7LAgqa4 HqU6jZvB9DPLfjSzJscqIHHCL3qVhBb+N8P2+vYX7T27psvDpeXYir+bE w==; X-IronPort-AV: E=Sophos;i="5.51,228,1526299200"; d="scan'208";a="29398193" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.98.240.212 - Outgoing - Outgoing-SSL Received: from dynamic-cpe-pool.orcon.net.nz (HELO [192.168.20.4]) ([121.98.240.212]) by mx3-int.auckland.ac.nz with ESMTP; 16 Jun 2018 17:38:26 +1200 To: rfcplusplus@ietf.org, Nevil Brownlee From: Nevil Brownlee Message-ID: Date: Sat, 16 Jun 2018 17:38:19 +1200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfcplusplus] Comments on "exactly what are RFCs?" X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 05:38:34 -0000 Hi all: I seem to recall someone on this list saying 'it's not obvious what RFCs one needs to be compliant with to "implement TCP"'. That's not really surprising for TCP. RFC 793 defines the protocol, so every implementation must conform to that. Then there are lots of other RFCs covering the TCP options, etc, etc. However, my favorite networking textbook (Peterson & Davie) says "TCP is defined by an implementation." Congestion control algorithms like Vegas,Tahoe, Reno, BIC, CUBIC and BBR don't have RFCs - they're all described in academic papers. The one really important thing is that any new TCP implementation must interwork well with all the other existing ones. That example reminds us that an 'Internet Standard' represents a consensus that it is a workable way to do something, and all of us (the 'Internet Community') agree that if we implement that Standard, we'll be able to interwork with other existing implementations. Maybe we need an explanation of what 'Internet Standard' really means on the IETF home page? Moving on to the RFC series, it's an archival record of all the ideas considered within the Internet Community, with a very simple set of rules, i.e. 1. a single numbering sequence, and 2. once published, RFCs never change, so their RFC number is a unique identifier. Of course "not all RFCs are standards", but that's a design feature! Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Mon Jun 18 19:10:14 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F8B131045 for ; Mon, 18 Jun 2018 19:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QYs0cleBDQfB for ; Mon, 18 Jun 2018 19:10:10 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 99056131030 for ; Mon, 18 Jun 2018 19:10:10 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id q4-v6so8413464pgr.1 for ; Mon, 18 Jun 2018 19:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Vca8CfG7f5I0bxpIwxMc7Rqhl+UgP55NIERjchg0isk=; b=tHGlBvyOtIOwjxjwCSah5bYMx9nZdR4TguBZwuvndPoicyPdiNxcBnbcpdhIQAssxC n3aHuMhtTv6pN+4F3lMflbcw6LJAc58AKnw9q/FYefXx6gJLJFDR2onscYjjIh+VNqKE R2SSN1LfRGnduCgq6z3iU95LCUo6I3nZDHJ93ugykhT6a1ayXizKtqlxBR3jVFZybrt6 sMC9ha3QiAEQJu98ECem3uHyKp7DFSjS8VGRHZSSsip/MrA/PM0cEM28BXh+NscCpbpk hN4WAw2ojo+grBpR2DT1aU+AUgFg43Ni/8yJ8J7J1ujE/KX3fQx4dzpdpWr74kFH2FCq cgAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=Vca8CfG7f5I0bxpIwxMc7Rqhl+UgP55NIERjchg0isk=; b=VxrKtwb0Eb2VZe0Fe7GGUj2dHweMGS57+iV9BxuI5q6t04MUWBnjxDmIg1lbEnogGM 2zXfDPnPju8HqOh6ZISjkG6mntK7nr8uWCK/jtVGxhWDKL8kIvaDYJdlg4a1eo8W+6A0 kdJbOYAqtwemd/Xqh+y52unYtMICFBWK7gYmVgnSNj6MHwbsxeJ5zbAjlDDBh2s0Zzw4 arbqpHD2YHlNaIjWrUVDxTiGIQdIeE/v29zsknmxIn+JQCmkeuTp2brrF3eN3yIoQptb uNfkUAgwT2v0Fd8ooLUdwr/wORk5LqBZYKfNUReawgZ8b7d7hbAvL5o0waMaHumNO8Su DptQ== X-Gm-Message-State: APt69E1aj/mrFuqZ7DGXOOfDzM1deH3+N5r8u6o8RgUQjLMrSgTFhurz jBbc2XrePes8Yr85YC/GG4ncoQ== X-Google-Smtp-Source: ADUXVKLYJogsBhm4eoY670UV5e+DDvi1lUXh373HSKAzlc507f2MMDnjhLPJKKpZjxDJ0mb2+8H4dg== X-Received: by 2002:a65:4081:: with SMTP id t1-v6mr13310287pgp.32.1529374209818; Mon, 18 Jun 2018 19:10:09 -0700 (PDT) Received: from [172.24.55.30] ([202.36.244.189]) by smtp.gmail.com with ESMTPSA id 82-v6sm27428389pft.74.2018.06.18.19.10.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 19:10:09 -0700 (PDT) To: rfcplusplus@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <1b21d436-135a-8224-bd35-11b66397e8f8@gmail.com> Date: Tue, 19 Jun 2018 14:10:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfcplusplus] BOF agenda X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 02:10:13 -0000 The agenda looks pretty thin: Problem Description (15) Discussion (45) Conclusion (15) Who might be defining the problem? Will others be allowed to show a few slides, since there may be multiple views of the problem? Regards Brian Carpenter From nobody Tue Jun 19 11:07:48 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFDA1311B1 for ; Tue, 19 Jun 2018 11:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 5EMEG1vZ6uTL for ; Tue, 19 Jun 2018 11:07:43 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 9D15D130DCA for ; Tue, 19 Jun 2018 11:07:43 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id l6-v6so1729093iti.2 for ; Tue, 19 Jun 2018 11:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=h0PFmaNm0IOKsCYBXOBHLeEZfaUhUAkboH+GzmF+0aA=; b=G/AAwInBwm5e+jP8Tn3EgyXT8n96mdiTQPUueplDYgJkB7Jrouha9EX51h51naB1WE L7eQ8J/BvVybw/T/mOQWbKcsf5GpPcfdsMEx0s1Fmeg9UhsxbcJeFyhzo0v9PBMYIiSx ZJKBacuGLBhQnmKmvIUGANZKCbk9PQS8BwRRs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=h0PFmaNm0IOKsCYBXOBHLeEZfaUhUAkboH+GzmF+0aA=; b=lNYvxKIu0jPHtuvyQpVW7UVHHRKZiLXvDgUwB4YjEw2Qymj02D89jHsP4osLO13bio TjrKevK/F58t5PDDIUJ/UsFv0p6jNu70KV1728NE45em/vct3A43DAsWvuf1d9dfjEBx 8GNZ88ttLTFFPRDLItuh5vJUZ2xjflcS4zTYtrGwpwKij7bIrP3R24kN+h45LcFfUW5i Vtw7dSX+v4p88o3iH+PGPtU5U3LNiEmwTgsEoG2kzFMnvEJ22e4wMIJTGTnGTLUfMpKT A+auKUemNS+3LWMkFGaqFGI5zHzzM6XjLAg2zveYhJfATEtMW3BES+dd4H86SlMePthm UwnQ== X-Gm-Message-State: APt69E3tO4F+ROizh7ycqGjEULddnkzVB0JESfmb04CMP9eWYzDBi51t lkqR5OphIluftit49r6U6rTF5w== X-Google-Smtp-Source: ADUXVKJrIpzyCRM5BryUVgoTxH0v9yEZBEHZ7RSaqiAKUtggoYUGupjoaxtXo67x24XGUWYKEA0ubw== X-Received: by 2002:a24:dd3:: with SMTP id 202-v6mr14042846itx.77.1529431662828; Tue, 19 Jun 2018 11:07:42 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id x123-v6sm123452iod.60.2018.06.19.11.07.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 11:07:42 -0700 (PDT) To: rfcplusplus@ietf.org From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Tue, 19 Jun 2018 12:07:41 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NtM4vY2nBvp4Qi0ZOfM1rCf9dtugTKdJk" Archived-At: Subject: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 18:07:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NtM4vY2nBvp4Qi0ZOfM1rCf9dtugTKdJk Content-Type: multipart/mixed; boundary="SMeRnoCssgF5uho81exTlPMjZlKMSO4Jd"; protected-headers="v1" From: Peter Saint-Andre To: rfcplusplus@ietf.org Message-ID: Subject: problems and solutions --SMeRnoCssgF5uho81exTlPMjZlKMSO4Jd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable (Just joined the list, sorry about the new thread.) The primary problem folks here have pointed to is confusion among people who write RFPs. Both Barry and Adam provided entertaining anecdotes, the likes of which I've seen as well. However, those problems were solved fairly easily by educating the customer (less easily, perhaps, in large organizations with poor communication - what's new?). To judge the proposal, could the proposers provide a basic cost-benefit analysis, preferably including data and an accounting of risks? As to solutions, Andrew Malis proposed some clearer boilerplate text at the top of each document. Some years ago, we added text like this to specs in the XMPP Standards Foundation's XEP series, and it helped to educate people who were confused about document status. [1] Peter [1] Here is the text we use at the XSF... For a Final XEP (like an Internet Standard RFC), green text stating: NOTICE: The protocol defined herein is a Final Standard of the XMPP Standards Foundation and can be considered a stable technology for implementation and deployment. example: https://xmpp.org/extensions/xep-0030.html For a Draft XEP (like a Proposed Standard RFC), green text stating: NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard. example: https://xmpp.org/extensions/xep-0176.html For an Experimental XEP (like an Internet-Draft), red text stating: WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft. example: https://xmpp.org/extensions/xep-0400.html For a Humorous XEP (published on April Fool's Day), green text stating: NOTICE: This document is Humorous. It MAY provide amusement but SHOULD NOT be taken seriously. example: https://xmpp.org/extensions/xep-0076.html And so on... --SMeRnoCssgF5uho81exTlPMjZlKMSO4Jd-- --NtM4vY2nBvp4Qi0ZOfM1rCf9dtugTKdJk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlspRm0ACgkQZWGMGH9o FKngyw//Z7/w5UvGWGcBPP3Am7+k33p5XFYgLhZpn80gblcv1FQzSVAGAIn6MCHV memHgGzk2kmz2byEXBZnS6fa+e77K4gpRteu+NhIZvp2V99sA85f/OTGhZFjAiy9 XIkkfAWCHZvcIMdCxZlyJKlIzoXsho4EZy+/hu9QVGBwU6zvpvGqNGxSIq+5Ezus fFjADrh2lJ7bZPSHcuu8K6doMj6dJ4ZOz1ET/L38qYDosSgzwThZOR1KLX7XAWdQ FKkXR3PXXb//9WGLKnQk5ri5BA5qWeY2TI6V3JNZI7LZOx2BwBvvvssxqF965Orz TR1Nzr9HSaHVjQwSC8M5ZCRXXQfpWuwvG2MqM8JrhZ1KQ770bIfdTun8Ea3xu8+J yXMjvZIC6TBVZURyPhyYjUYuPozhHeHhFVDqLlO1tu9G+dZPO971Db58i8/+o1S+ Bb0+S2sSnO+NT2HDrtref3W177B8pJlrTYva6ufClrYaZVOTfSgoDQxCcBrsWwfS f0NN5gnq49RFVUxcV5tG2+t9HIIMPCZDtHqtIfwbHuviHIwicwwQxg090my69r6e NPYPyXU46YxJHlebgfmhiDb7YRFc830MwgRkIXTyeIJL7Y5Mo7psbv00cGF7N9CU e6vFiPNMUgWvNHlk69S5HAhST/7EYKApyVN7WGe5RgOcsCBC3H0= =hPBM -----END PGP SIGNATURE----- --NtM4vY2nBvp4Qi0ZOfM1rCf9dtugTKdJk-- From nobody Tue Jun 19 11:16:14 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128A61311B5 for ; Tue, 19 Jun 2018 11:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 987Pk4QVm7gd for ; Tue, 19 Jun 2018 11:16:08 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 B2354130E1F for ; Tue, 19 Jun 2018 11:16:08 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id h6-v6so760323otj.0 for ; Tue, 19 Jun 2018 11:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VehNqa0rgJVL6ezsm1S2WuWSmaGIPtWHajm70IBhO6A=; b=YvY95d3VRfW0LVMs4Rg6EMH5sikGrevmXQYSS/tsDAY4OvxiZNu+yTGqtZrXT0m3T4 XseFPvXSzQcTvBp+qjDer3uVuPy3R7aH4rdJjrrkC6wmwa+4iwPqDTuSTw7RuQRwl1mn xgEv83kMkY8iGqjvqcKCuXi6H8PjDPFJyUFlQhIuRGYlOxZa77Zr3JU+0fgoxHJklKkK VTisiZN8u9JpoV9YaIg5K28JKDWOwU7Nzk120XbYRCdMQeEJaILn22nhqfQi20WYUOEr Kgfg+eUFzaFQg0P8p8tzNeSvZeX72vkJ6AqIFOrYObUOjV8qLTgySrnPWqC0rUIYtHFf K46w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VehNqa0rgJVL6ezsm1S2WuWSmaGIPtWHajm70IBhO6A=; b=Td7+HfCjumAC8U1+Cul9jY/BlgHC9/ikbG+6spxVXa4nZU6F+ItJPBDM2rJKCDixNX F4T5ct4yiOWC40gCUoaC5nHekLc5F11fyEUemflzFu7nV1FfjeuyXmuehCmPW4rtimM9 8wbI2GM6mUN+IRniGv4NHJHS+PhqjjXqne4q9CR13ddwpOvXNyd12j9wq0SDw1pBvCkK +aFERQ7bupi3T/g5MhJ+u40LN9rLIHxZ0UAS71LZQboywux0IJmr/qpZL6QPfy9+gGEY s4GddVwmK+Py97ddFJQejmHMr6Q7T/urrfpgVemSiF+eySf7Wzsys+i7Q/dg4i5dILkt /Clw== X-Gm-Message-State: APt69E1eE5vWMUqKpRfKb0dK2uF80avvfAxdqhv9i3X+3rQ0JrDsWDeI C3K/SIOIJjW1mAhFvEo9bNQTXTWts2XQ2wEGsXE= X-Google-Smtp-Source: ADUXVKI++kEa0pq5IdjERlIx6418FYFHLZJzgRArUYmCgIxBRotsXXX3ZxFAAKgvu5YiifPG5bjLtJoJ0tRPlhzE0BI= X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr11845733otb.371.1529432168092; Tue, 19 Jun 2018 11:16:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 11:15:47 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 19 Jun 2018 14:15:47 -0400 Message-ID: To: Peter Saint-Andre Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000001658fa056f02ad6b" Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 18:16:12 -0000 --0000000000001658fa056f02ad6b Content-Type: text/plain; charset="UTF-8" Needless to say, +1! Cheers, Andy On Tue, Jun 19, 2018 at 2:07 PM, Peter Saint-Andre wrote: > (Just joined the list, sorry about the new thread.) > > The primary problem folks here have pointed to is confusion among people > who write RFPs. Both Barry and Adam provided entertaining anecdotes, the > likes of which I've seen as well. However, those problems were solved > fairly easily by educating the customer (less easily, perhaps, in large > organizations with poor communication - what's new?). > > To judge the proposal, could the proposers provide a basic cost-benefit > analysis, preferably including data and an accounting of risks? > > As to solutions, Andrew Malis proposed some clearer boilerplate text at > the top of each document. Some years ago, we added text like this to > specs in the XMPP Standards Foundation's XEP series, and it helped to > educate people who were confused about document status. [1] > > Peter > > [1] Here is the text we use at the XSF... > > For a Final XEP (like an Internet Standard RFC), green text stating: > > NOTICE: The protocol defined herein is a Final Standard of the XMPP > Standards Foundation and can be considered a stable technology for > implementation and deployment. > > example: https://xmpp.org/extensions/xep-0030.html > > For a Draft XEP (like a Proposed Standard RFC), green text stating: > > NOTICE: The protocol defined herein is a Draft Standard of the XMPP > Standards Foundation. Implementations are encouraged and the protocol is > appropriate for deployment in production systems, but some changes to > the protocol are possible before it becomes a Final Standard. > > example: https://xmpp.org/extensions/xep-0176.html > > For an Experimental XEP (like an Internet-Draft), red text stating: > > WARNING: This Standards-Track document is Experimental. Publication as > an XMPP Extension Protocol does not imply approval of this proposal by > the XMPP Standards Foundation. Implementation of the protocol described > herein is encouraged in exploratory implementations, but production > systems are advised to carefully consider whether it is appropriate to > deploy implementations of this protocol before it advances to a status > of Draft. > > example: https://xmpp.org/extensions/xep-0400.html > > For a Humorous XEP (published on April Fool's Day), green text stating: > > NOTICE: This document is Humorous. It MAY provide amusement but SHOULD > NOT be taken seriously. > > example: https://xmpp.org/extensions/xep-0076.html > > And so on... > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --0000000000001658fa056f02ad6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Needless to say, +1!

Cheers,
= Andy


On Tue, Jun 19, 2018 at 2:07 PM, Peter Saint-Andre <stpet= er@mozilla.com> wrote:
(Jus= t joined the list, sorry about the new thread.)

The primary problem folks here have pointed to is confusion among people who write RFPs. Both Barry and Adam provided entertaining anecdotes, the likes of which I've seen as well. However, those problems were solved fairly easily by educating the customer (less easily, perhaps, in large
organizations with poor communication - what's new?).

To judge the proposal, could the proposers provide a basic cost-benefit
analysis, preferably including data and an accounting of risks?

As to solutions, Andrew Malis proposed some clearer boilerplate text at
the top of each document. Some years ago, we added text like this to
specs in the XMPP Standards Foundation's XEP series, and it helped to educate people who were confused about document status. [1]

Peter

[1] Here is the text we use at the XSF...

For a Final XEP (like an Internet Standard RFC), green text stating:

NOTICE: The protocol defined herein is a Final Standard of the XMPP
Standards Foundation and can be considered a stable technology for
implementation and deployment.

example: https://xmpp.org/extensions/xep-0030.html=

For a Draft XEP (like a Proposed Standard RFC), green text stating:

NOTICE: The protocol defined herein is a Draft Standard of the XMPP
Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to
the protocol are possible before it becomes a Final Standard.

example: https://xmpp.org/extensions/xep-0176.html=

For an Experimental XEP (like an Internet-Draft), red text stating:

WARNING: This Standards-Track document is Experimental. Publication as
an XMPP Extension Protocol does not imply approval of this proposal by
the XMPP Standards Foundation. Implementation of the protocol described
herein is encouraged in exploratory implementations, but production
systems are advised to carefully consider whether it is appropriate to
deploy implementations of this protocol before it advances to a status
of Draft.

example: https://xmpp.org/extensions/xep-0400.html=

For a Humorous XEP (published on April Fool's Day), green text stating:=

NOTICE: This document is Humorous. It MAY provide amusement but SHOULD
NOT be taken seriously.

example: https://xmpp.org/extensions/xep-0076.html=

And so on...



_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus


--0000000000001658fa056f02ad6b-- From nobody Tue Jun 19 13:16:50 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1BD130E32 for ; Tue, 19 Jun 2018 13:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 1s7HyXuo93hA for ; Tue, 19 Jun 2018 13:16:46 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 72692130E30 for ; Tue, 19 Jun 2018 13:16:46 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id q1-v6so394538pff.13 for ; Tue, 19 Jun 2018 13:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tr7LnkAq16lCACES0tYh4T3I7wI9bg7ZItqaOQC1/0A=; b=ZJIv0WwPh3HLgmSy4k6koIP2CESRp8ixXH9lK5MgyWO3/40HB2aGsLCHomqc43UCJZ aaRyahgVvktSvjdE4HIfRlvO+dwa4m2o//40RJvcvt0O1dVA6nJ3paNRb930O4xE/3Ry hTIf22+0X0dW8ARLAGx97j1TLH0YBe+SK5/xdDtFg5XUEHxBf9KJLMw32q05rh9xckXk 3BCvvtLAh28zrX6hoz0ZzZd3Hhz4sAo6sxUXcpY8p7pY0BvrY7iPa2ZUUyuT6jIalu9v SpL6Dysbv7Tn4+Jy2LObWGdXHFCbiwF7i4Fdf9iU7iPmL4S8X7HQtm179nvEo2k6P/UV brcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tr7LnkAq16lCACES0tYh4T3I7wI9bg7ZItqaOQC1/0A=; b=D8YOmWYi/BMKgzC0TX6zYCPDQHaLP4z6UkZSkfbcB2syjr3WpWnPWzix3ckeEZKk6s tJjtXt1tHDX6Gnlu0CgAfcV2mD8XrH45/dQKkQhis9+Rtg8dPICNEzwsJZ4fPZ6rDTw5 xKdlW5KxX9zvzneCWFdau/PV295LolsiHpH1UHu20kffr3U4o/4/Ts7X7wzCQ14+19// iSESpkv0sbsnQLlD0wfPbmjuZuzbuDpZYoOtFkrhsQmllMzzrd8RexCoGe2pCPPL/kco PCotIb9qUrsJi+NqLJvQcsOnvmPA7SSV4aAV6I/+TsF2ZnhT62XR7qSGAIyN/KP3EexB S7KQ== X-Gm-Message-State: APt69E2XRueph1LwYNgVnA2n65tYKKkP25clRnDI3+ac5LAQDs8i6myT y6vnuG6zpjCH4BxqHQEiOEM= X-Google-Smtp-Source: ADUXVKI86xCvEV4FX7Lc0MiNjLL7YIn8PFg+t5+5G54DOWV2bYYZ9JCSsBEAbrXdE30eJYYLaJKW6w== X-Received: by 2002:a62:2281:: with SMTP id p1-v6mr19679968pfj.53.1529439406001; Tue, 19 Jun 2018 13:16:46 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id m83-v6sm645854pfi.188.2018.06.19.13.16.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 13:16:45 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4A23FAA9-B926-43C3-A6B0-233549414E38"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 19 Jun 2018 13:16:43 -0700 In-Reply-To: Cc: Bob Hinden , Peter Saint-Andre , rfcplusplus@ietf.org To: "Andrew G. Malis" References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:16:49 -0000 --Apple-Mail=_4A23FAA9-B926-43C3-A6B0-233549414E38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 19, 2018, at 11:15 AM, Andrew G. Malis = wrote: >=20 > Needless to say, +1! I also agree, and would support clearer boilerplate. This would do no = harm, as compared to what is proposed in the BOF description that I = think would create more confusion. Bob >=20 > Cheers, > Andy >=20 >=20 > On Tue, Jun 19, 2018 at 2:07 PM, Peter Saint-Andre = wrote: > (Just joined the list, sorry about the new thread.) >=20 > The primary problem folks here have pointed to is confusion among = people > who write RFPs. Both Barry and Adam provided entertaining anecdotes, = the > likes of which I've seen as well. However, those problems were solved > fairly easily by educating the customer (less easily, perhaps, in = large > organizations with poor communication - what's new?). >=20 > To judge the proposal, could the proposers provide a basic = cost-benefit > analysis, preferably including data and an accounting of risks? >=20 > As to solutions, Andrew Malis proposed some clearer boilerplate text = at > the top of each document. Some years ago, we added text like this to > specs in the XMPP Standards Foundation's XEP series, and it helped to > educate people who were confused about document status. [1] >=20 > Peter >=20 > [1] Here is the text we use at the XSF... >=20 > For a Final XEP (like an Internet Standard RFC), green text stating: >=20 > NOTICE: The protocol defined herein is a Final Standard of the XMPP > Standards Foundation and can be considered a stable technology for > implementation and deployment. >=20 > example: https://xmpp.org/extensions/xep-0030.html >=20 > For a Draft XEP (like a Proposed Standard RFC), green text stating: >=20 > NOTICE: The protocol defined herein is a Draft Standard of the XMPP > Standards Foundation. Implementations are encouraged and the protocol = is > appropriate for deployment in production systems, but some changes to > the protocol are possible before it becomes a Final Standard. >=20 > example: https://xmpp.org/extensions/xep-0176.html >=20 > For an Experimental XEP (like an Internet-Draft), red text stating: >=20 > WARNING: This Standards-Track document is Experimental. Publication as > an XMPP Extension Protocol does not imply approval of this proposal by > the XMPP Standards Foundation. Implementation of the protocol = described > herein is encouraged in exploratory implementations, but production > systems are advised to carefully consider whether it is appropriate to > deploy implementations of this protocol before it advances to a status > of Draft. >=20 > example: https://xmpp.org/extensions/xep-0400.html >=20 > For a Humorous XEP (published on April Fool's Day), green text = stating: >=20 > NOTICE: This document is Humorous. It MAY provide amusement but SHOULD > NOT be taken seriously. >=20 > example: https://xmpp.org/extensions/xep-0076.html >=20 > And so on... >=20 >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus >=20 >=20 > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus --Apple-Mail=_4A23FAA9-B926-43C3-A6B0-233549414E38 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlspZKsACgkQrut0EXfn u6ibdwf/f2ooytyPKqXP4dvdy1rFCRwpAK2CLa+P60NXxQ1EFBMG0Gdbp81JnT+E XB1Uz59Ik+dQ1UjOVMNI4nDgXuhEKdCVRDwLO1F0eMqowNzvnPLT9jEmLGWJZFYE FlhQuHeLDz/GBslDU/TJky+QOk+aoikbLUCxEa/K8PW9vBNOD6TddgvSxBHHzOMy oZxJWOuYDxxYGUdKOnglR32Xtc+iZ2+L3eHRHO0ioS9UuHClu1meKoM8/t+/H4M6 t+9VcJlpFr/bim1+7c6uog2wv+GYIA8LkDqXeE3iahoQ1cg+euniPez+GzLlz8B5 goHFrWrfXsq26Z3plutHwGAMGBFqDA== =xhHn -----END PGP SIGNATURE----- --Apple-Mail=_4A23FAA9-B926-43C3-A6B0-233549414E38-- From nobody Tue Jun 19 13:58:41 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283BE130F39 for ; Tue, 19 Jun 2018 13:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lf2heaksZ6uN for ; Tue, 19 Jun 2018 13:58:37 -0700 (PDT) Received: from mail-pl0-x244.google.com (mail-pl0-x244.google.com [IPv6:2607:f8b0:400e:c01::244]) (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 5AF5D130F2C for ; Tue, 19 Jun 2018 13:58:37 -0700 (PDT) Received: by mail-pl0-x244.google.com with SMTP id d10-v6so492322plo.5 for ; Tue, 19 Jun 2018 13:58:37 -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=3+AfMpJxbDbI62fsur/K+LQN0sYNacHBJP12DX7CfJ0=; b=jncHn568QObeOnbHnIMWqBfi4umZlx5ArBtbwhM1E23WhSbKCHxePUfqHJWAFjB8fJ /V9nLm+I+rlIe8pvjQB4ygSxt/dhS4KkyiGwdNjSQ9wqkFzEhH59b6Ldg4jlnqObaMOv ha6AyBe/uF5GTPLTA2aQ2vCuhYDh40HlW9/M1YoUeUcg7aaT0XISZo5YvjHmEw1ALhMV 1RDsiuyQEYrMtxHTIcF6BwFXhLR6Yx/yeN5+fD+cqZAdmv2Gjp7vgYVeCd4SYhhYNa5t suKBu641umbMM5ghCFlx+7opuBhupJUnTimbhtwOV/O6P7TISYi0IzYNFYyGxtkefryY 5l1w== 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=3+AfMpJxbDbI62fsur/K+LQN0sYNacHBJP12DX7CfJ0=; b=W1uc7Qi437WM0IdgV3GYvUYRbBo9REElbolr8Xvx/Wj72z40PmmWlLZ3HmiPllEqA1 kTvFBvXvA7xlPAWWF2YGWdm+5bkT8sPY8QIaqIAqXhPB2lcehe03IOZHvRWijYlL6w7x SIjQI3+ldboLo4I3e70kD2kAvMJkrgANJm++Ehugxf1eqpFx4sVbRk0o7KgzME/Y+1nk Pbf4HSVlUUWtQya519MCxDThpzQAAFh7D/IDIds9RWA8kmqxN1d9TxNDbzJychqnLVWO fUPzC4hU+JUG+CyF2pVDhBTt/zVBZC1xOtlZxgddjXKPCgZuZN+lnzJT2ZCqDZmFs5hH jQYg== X-Gm-Message-State: APt69E3LZmIfibXl1+BjoZaLk41nZOVJjygafwWi032BbtdjSpMDPlSz dY7xV08CQNhaJf/KkycPeLxmVg== X-Google-Smtp-Source: ADUXVKKLC/shMDzBOHBK6wv2ZTeeTVpsDSH2lSQfGqAkCWfCPcORXk52ThOReP3bGs4mkK7NyLgqIw== X-Received: by 2002:a17:902:2864:: with SMTP id e91-v6mr20091461plb.240.1529441916679; Tue, 19 Jun 2018 13:58:36 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id p20-v6sm615064pfn.181.2018.06.19.13.58.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 13:58:35 -0700 (PDT) To: rfcplusplus@ietf.org References: From: Brian E Carpenter Message-ID: <6b99d27f-7945-cc52-2e72-5c3c6c521ca1@gmail.com> Date: Wed, 20 Jun 2018 08:58:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:58:40 -0000 Yes. I put a rough and ready list of problems in https://tools.ietf.org/html/draft-carpenter-request-for-comments-00#section-2 and I would expect a BOF to start by considering a complete problem set and prioritising before trying to pick a solution. https://www.brainyquote.com/quotes/h_l_mencken_129796 Regards Brian On 20/06/2018 08:16, Bob Hinden wrote: > >> On Jun 19, 2018, at 11:15 AM, Andrew G. Malis wrote: >> >> Needless to say, +1! > > I also agree, and would support clearer boilerplate. This would do no harm, as compared to what is proposed in the BOF description that I think would create more confusion. > > Bob > >> >> Cheers, >> Andy >> >> >> On Tue, Jun 19, 2018 at 2:07 PM, Peter Saint-Andre wrote: >> (Just joined the list, sorry about the new thread.) >> >> The primary problem folks here have pointed to is confusion among people >> who write RFPs. Both Barry and Adam provided entertaining anecdotes, the >> likes of which I've seen as well. However, those problems were solved >> fairly easily by educating the customer (less easily, perhaps, in large >> organizations with poor communication - what's new?). >> >> To judge the proposal, could the proposers provide a basic cost-benefit >> analysis, preferably including data and an accounting of risks? >> >> As to solutions, Andrew Malis proposed some clearer boilerplate text at >> the top of each document. Some years ago, we added text like this to >> specs in the XMPP Standards Foundation's XEP series, and it helped to >> educate people who were confused about document status. [1] >> >> Peter >> >> [1] Here is the text we use at the XSF... >> >> For a Final XEP (like an Internet Standard RFC), green text stating: >> >> NOTICE: The protocol defined herein is a Final Standard of the XMPP >> Standards Foundation and can be considered a stable technology for >> implementation and deployment. >> >> example: https://xmpp.org/extensions/xep-0030.html >> >> For a Draft XEP (like a Proposed Standard RFC), green text stating: >> >> NOTICE: The protocol defined herein is a Draft Standard of the XMPP >> Standards Foundation. Implementations are encouraged and the protocol is >> appropriate for deployment in production systems, but some changes to >> the protocol are possible before it becomes a Final Standard. >> >> example: https://xmpp.org/extensions/xep-0176.html >> >> For an Experimental XEP (like an Internet-Draft), red text stating: >> >> WARNING: This Standards-Track document is Experimental. Publication as >> an XMPP Extension Protocol does not imply approval of this proposal by >> the XMPP Standards Foundation. Implementation of the protocol described >> herein is encouraged in exploratory implementations, but production >> systems are advised to carefully consider whether it is appropriate to >> deploy implementations of this protocol before it advances to a status >> of Draft. >> >> example: https://xmpp.org/extensions/xep-0400.html >> >> For a Humorous XEP (published on April Fool's Day), green text stating: >> >> NOTICE: This document is Humorous. It MAY provide amusement but SHOULD >> NOT be taken seriously. >> >> example: https://xmpp.org/extensions/xep-0076.html >> >> And so on... >> >> >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus >> >> >> _______________________________________________ >> Rfcplusplus mailing list >> Rfcplusplus@ietf.org >> https://www.ietf.org/mailman/listinfo/rfcplusplus > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > From nobody Tue Jun 19 15:48:01 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45BA130FCD for ; Tue, 19 Jun 2018 15:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 at4fqy4lfqMS for ; Tue, 19 Jun 2018 15:47:58 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 CF320130FA6 for ; Tue, 19 Jun 2018 15:47:57 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id i19-v6so1549668otk.10 for ; Tue, 19 Jun 2018 15:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zpkLYuX49dsCNZCoCMjQbBKBpHPWnYHdYJOZByvibVI=; b=vgvRrfrPEMIZmqF9T9Mq2kC1O5M7NQo5o3j6/J49fHN9AOuK9ksgQKLHi1CfFXWN0Z MEquqFzQni0zSwSKLIB+QFhKgysNXwSWextLv72Xc4qK+2AoNELrIXOgBfMgsOzXFaD4 +9NJ9f1nTLO2yr0AUJtl08E97dMzGckQH0Dny3OtttZLXXEZHGh8hhLVPEzusgyiFmRB pwu0WysLz2X12aqIjaaO3iEifzs/uAT1RFcs6r/M6dEV+q9KGlGyKV3Wk7jB83aXUB5Q rXTFHkKpPEBYjcRMPdqKI8nDef2/Ik0WfPRpy/O/qxIoUcTH2iUqP2nQlTx3xq24799/ 9P9w== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zpkLYuX49dsCNZCoCMjQbBKBpHPWnYHdYJOZByvibVI=; b=bQKSPIbVi8CQAR6QtPRNXUrO/3K8pxFpg6QX52ztzYv5yyfz4SUhV9ckeX31CVzuLf o8VdX+rQuwO1dkLI/cTFWpjZuCiknSvwd4a5xtRhKvj/1IGMPKM7JbUZa/GZ+SMU2jxb bY0/z584GhPJyaiuGfikpiezlEqz1GosCYHUEMJziwTXWEvplpJpX9gqAC1kFZvsHim2 8gPv+dTmFzSbNcv3Ze8o2WZcuMeCykaOY4iKaYchcW5e6ZlNbtrZm143FkDYf1o8dFn3 Gm4MDImtLYCPEQEEm6teEUahAKg2PW/99QeYFZH8zJ/kZmIkLT0hUwwI1R4CMLyMYErX WTUQ== X-Gm-Message-State: APt69E0NCLLy7UaWl6biBRI43w9gr+KOCHqk60iVgPnrTAJSCeesfXOM eDbuV1bnNCNdLczGlP2YFpKL/YsRba5k X-Google-Smtp-Source: ADUXVKJ5LpospyK2wI/16bwKIXa9zKz9dq3dJEt+1nOCJjc6v6e6/HBOZ8vzm+AGmGHEwsxO9aPRqQ== X-Received: by 2002:a9d:1553:: with SMTP id z19-v6mr10778003otz.135.1529448477057; Tue, 19 Jun 2018 15:47:57 -0700 (PDT) Received: from [192.168.1.7] ([174.27.40.214]) by smtp.googlemail.com with ESMTPSA id f14-v6sm768481ote.53.2018.06.19.15.47.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 15:47:56 -0700 (PDT) To: rfcplusplus@ietf.org References: From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> Date: Tue, 19 Jun 2018 16:47:53 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 22:48:00 -0000 On 06/19/2018 12:07 PM, Peter Saint-Andre wrote: > (Just joined the list, sorry about the new thread.) > ... > As to solutions, Andrew Malis proposed some clearer boilerplate text at > the top of each document. Some years ago, we added text like this to > specs in the XMPP Standards Foundation's XEP series, and it helped to > educate people who were confused about document status. [1] > Published RFCs can not be edited, so, any "Final Standard" in the document text will be obsolete at some point. Is this just not kicking the can down the road a few more years? Would it be a better solution to log them with something like an IANA registration? Perhaps grouped by area and protocol. Documents intended to be standard would then just refer the reader to the standard registration page that would point to the latest hopeful document(s). -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135 From nobody Tue Jun 19 16:18:39 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574BE130FEC for ; Tue, 19 Jun 2018 16:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RtSllXtfivoT for ; Tue, 19 Jun 2018 16:18:35 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 6BF57130E4D for ; Tue, 19 Jun 2018 16:18:35 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id w12-v6so553022pgc.6 for ; Tue, 19 Jun 2018 16:18:35 -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=KP/61AWai5nAssuTwJt2AVBTCr44jCixA6Lw91HOv1c=; b=cBo/FP5Kd90FntBPKXu+rr0CU+7hwXn7nY9Ou665Cc51HbDj+jIyJXxPQqIDPug7It fXUyGt5NbQXz0sSBhUWrvb0H9EAzVYtdIRGd5mrzqORDghBuzC5uCbl51dnGGN0BLPRg sdPMoB4I02bgEdASGGr3HwFelbCfNOlXshYHzXcHWux5FDQdgwzvMqMHWGlMIacSE1L9 4ifwwQQjKb5UTj3iE8J1XTAycpH4t9nKxvhBc+VoN1RIzIwv6dVNi+X0x9YrFF703aSY 3VuDFrvoFwUv0WwRL5t4G65bxB6O1iHWOP9zF/q9HHzJecDEF7SZ1TtxL1LrHIldpZwj oALQ== 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=KP/61AWai5nAssuTwJt2AVBTCr44jCixA6Lw91HOv1c=; b=nqTb6hZbJsrWez1/hC95ThAKR+hS8z+5rdZSunfpdJWo+GpSHl3WPySHC9ZXVIqRlU rtUI2LQNlUYHdyCSAEar8E/7dlhCuFBiBACzoeMan2LLUyreLvG+gnMz8zyg3siBknRx fyNsiZCmIuDcrEm5iZHUnsdUzufjZlhVSArlW6THX63xPjEw0Kim+MmCHeTdBZD5AgzJ QlhauodX7EELQzPet233b2E6LOx9QqgFtHNHI5C+bLUrVbN3jQjCGyihImpv9fvChvMQ oZQ3Vv6oOXJFw737F5BeX9uVy+TIEohqrG9xIYUQAw/2u8G8AGFWNVs1SudJ1aHrMqps Tgdg== X-Gm-Message-State: APt69E3Nd7oreuprjjmMK16GXljpkSdX4+yoX9wljmfSxUk57mFYyu2Y o6u+ME52XtvhpvMFWtlE7Ei5mw== X-Google-Smtp-Source: ADUXVKIKk6YYVCem/JY2U3O20Xgsl4HSW6cCo+6/8fZ7vAKGvbBdy+JpQx9sAwbrt0Xp7dUv6iwSjQ== X-Received: by 2002:a62:9385:: with SMTP id r5-v6mr20107668pfk.59.1529450314707; Tue, 19 Jun 2018 16:18:34 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id h9-v6sm1081401pfj.77.2018.06.19.16.18.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 16:18:33 -0700 (PDT) To: Doug Royer , rfcplusplus@ietf.org References: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> From: Brian E Carpenter Message-ID: Date: Wed, 20 Jun 2018 11:18:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:18:38 -0000 On 20/06/2018 10:47, Doug Royer wrote: > On 06/19/2018 12:07 PM, Peter Saint-Andre wrote: >> (Just joined the list, sorry about the new thread.) >> ... >> As to solutions, Andrew Malis proposed some clearer boilerplate text at >> the top of each document. Some years ago, we added text like this to >> specs in the XMPP Standards Foundation's XEP series, and it helped to >> educate people who were confused about document status. [1] >> > > Published RFCs can not be edited, so, any "Final Standard" in the > document text will be obsolete at some point. Is this just not kicking > the can down the road a few more years? > > Would it be a better solution to log them with something like an IANA > registration? Perhaps grouped by area and protocol. > > Documents intended to be standard would then just refer the reader to > the standard registration page that would point to the latest hopeful > document(s). We don't need to wake up IANA for this. We already have the STD designation, which for some reason we've never chosen to use for the PS documents that the Internet runs on. A proposal for this was made 14 years ago: https://tools.ietf.org/html/draft-klensin-newtrk-std-repurposing and not much has changed since then. Brian From nobody Tue Jun 19 16:45:56 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79771130FDE for ; Tue, 19 Jun 2018 16:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sr59SQSEHrR4 for ; Tue, 19 Jun 2018 16:45:48 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 8AE86130E4F for ; Tue, 19 Jun 2018 16:45:48 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id l22-v6so1390770oib.4 for ; Tue, 19 Jun 2018 16:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sumTuBlpcZS72VjoyuijmtBP64I1tPWbkZlx0nLcumQ=; b=N3KcovVbx2LfnPFFSEUFmRmVzme4tYGXEUDlfwvXLeX982mkIlViVMyUH79IfO/Sf6 BzXz5Xxcqb8KM0uxMkPNQrbS9E4s4fkhufb1BT/olDbx5amc/Q38RMUCQL9XYMX/PtPd PuXpa8rQ7eXkIeVR5S3jdCQYB+hL3Vgqf+f1c5/unDclLtoFb8XUOW0cxy1iz5UfyTFL 5x+Ektj/+Rz5pt/NcpHuh/rbOa9qtyfD4eoWAfHVG4orWKtzrdUFZbKY0kVECoNNNJkj WCCnN/s+T2tVIRQ8NmhqhERWvPmV2oZV1GT/GIzhA8IEMy+dFPb09+YVemkFdb9XKbQ+ dwyw== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sumTuBlpcZS72VjoyuijmtBP64I1tPWbkZlx0nLcumQ=; b=SnYp4i9FkMlBV3tKGThpapJPWwXk8BimID24c7gi2sDA3Q9kOn3sqOAnYE5onrn1vQ +T8BxN51fPLLD6WXAHdWcEo5qX99G8a8fM2E8R9qry4hU1X/O9WlfnH5m0EyPiTGi6uA vWfFoDXkG7R5lg51bs7A0HSefshia1UEjC9XcDQkTaiiAHDWxopazOLtZrm+9oGSCAjS OkF01lh7Wrhpws8yuVft0/kJuebsmsw2MAM5+r8OKd+/kLE8C2HLJdTdFrKjKjo/g+Wo BTvs9+eFjyzOk4H2k1gClu96oaSy4/GY4hyQUtpvckgKu23VM3MLkFUIyHfC+DKNcihu Ipiw== X-Gm-Message-State: APt69E2ZQLZ1S6o8NgdQ0/bVsg2dbzkvQOVVPgrh+hOhyQmMwIZefRjo 5fpA4kppoSOUzLKtcnBNGSpYdkbbnxlA X-Google-Smtp-Source: ADUXVKJTfRY2ILYHsWOYN37bqFJToX/WsSZK6kBAu8ifrP+hM9edkvvQJ5SvPk8M9wGEvrjG9jH+Jg== X-Received: by 2002:aca:4c0d:: with SMTP id z13-v6mr9853050oia.343.1529451947763; Tue, 19 Jun 2018 16:45:47 -0700 (PDT) Received: from [192.168.1.7] ([174.27.40.214]) by smtp.googlemail.com with ESMTPSA id q7-v6sm601696otq.39.2018.06.19.16.45.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 16:45:47 -0700 (PDT) To: rfcplusplus@ietf.org References: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <4c4282f9-74d6-6b1d-7613-d57517749dc0@gmail.com> Date: Tue, 19 Jun 2018 17:45:44 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:45:53 -0000 On 06/19/2018 05:18 PM, Brian E Carpenter wrote: > On 20/06/2018 10:47, Doug Royer wrote: >> On 06/19/2018 12:07 PM, Peter Saint-Andre wrote: >>> (Just joined the list, sorry about the new thread.) >>> ... >>> As to solutions, Andrew Malis proposed some clearer boilerplate text at >>> the top of each document. Some years ago, we added text like this to >>> specs in the XMPP Standards Foundation's XEP series, and it helped to >>> educate people who were confused about document status. [1] >>> >> >> Published RFCs can not be edited, so, any "Final Standard" in the >> document text will be obsolete at some point. Is this just not kicking >> the can down the road a few more years? >> >> Would it be a better solution to log them with something like an IANA >> registration? Perhaps grouped by area and protocol. >> >> Documents intended to be standard would then just refer the reader to >> the standard registration page that would point to the latest hopeful >> document(s). > > We don't need to wake up IANA for this. We already have the STD designation, > which for some reason we've never chosen to use for the PS documents that > the Internet runs on. A proposal for this was made 14 years ago: > https://tools.ietf.org/html/draft-klensin-newtrk-std-repurposing > and not much has changed since then. I used IANA as an example. I don't care if it is IANA or not. A live document would be great along with the prohibition of any future RFC calling itself a standard in its text or Category on the title page. -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135 From nobody Wed Jun 20 08:58:04 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B84131000 for ; Wed, 20 Jun 2018 08:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 MUy9kxYUgfSu for ; Wed, 20 Jun 2018 08:58:01 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 27FB9130E32 for ; Wed, 20 Jun 2018 08:58:01 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id t133-v6so40406oif.10 for ; Wed, 20 Jun 2018 08:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ys2tk1+tdSYtHChRB5JCCGZ/7wSf6aV8sbqWSjP/24s=; b=WhlU+Td+cILzZLphK8aI/neur0nomMDz6vxcrj6DvJtyJMik+BgldV+eyW7Lq1NqFH hJ0+zF/KEyXLkJyjbw/Mag9kP7yov/HpczT5CrtZYIU0Q9RunQ2kAkd0QKlVNvtsWZ6W xoIUpHQhDEEXS8hbUYDiLzgmYRdhoD6KZuN8uAu9OLC9nY3TrRsCNuhKUogZAXCGUlrw D83eQvnSHj8rrjNf2qHPIl1lSG9v1+zzBExqQv4OO/5Si/EPZnZKmxoAljAnLars+9eI JyjIFvCgLEBbNNnIOm+SQ3KpsBmxlb12DZbY1capPD+dTXgzXrYYc5pUa0kROsQ+acKz Oidw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ys2tk1+tdSYtHChRB5JCCGZ/7wSf6aV8sbqWSjP/24s=; b=XNkclLlCmrfJM9vSq/PjctK4pp2k7+iWpkIdN0ibngwlMsjvPU9bOFyeJ8Kp8qP8gD YG3evA1XDhNS7+4TStzlhThGSCE6zbB+VN4+QkgNRVVK0trIl5hUyfBzQeFYeQce9Me2 c093d1J7qbfGGMbgmN4+iSRm42jysqofpLM++WUpGT0uB1Sx04Rql4TRsmHiM3/r+XJC t1INAb3ZIAwhlR1NkC+hP1/z9Hqix0pLGilEFcgXsSyGfxnJM6AfTIztLPm39yqHiTRt QhAFXibZnOfEACp37heD0+5mq8EVUImeibJUh1Ir7cB+wdCkXRAd938VDC59yZqexWl8 7Crw== X-Gm-Message-State: APt69E17Ss6sioR+V7SZSEs4AngMxifUZYTAHwGm/LKukr0iD8v6TRSl Y+K/dOMUFw5+Eskp3u4ZyyLVzLsLQbxohrz3Q0Y= X-Google-Smtp-Source: ADUXVKKo8ieGDDf5lP9RhN0ZmuryxFPl0wseFK9UndnyIUUPdVZyamqYm5tBuNxgwuYm15iWylDeAsrKSdJ0DiGJEoA= X-Received: by 2002:aca:fc82:: with SMTP id a124-v6mr12756871oii.69.1529510280495; Wed, 20 Jun 2018 08:58:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:605:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 08:57:19 -0700 (PDT) In-Reply-To: <4c4282f9-74d6-6b1d-7613-d57517749dc0@gmail.com> References: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> <4c4282f9-74d6-6b1d-7613-d57517749dc0@gmail.com> From: Kathleen Moriarty Date: Wed, 20 Jun 2018 11:57:19 -0400 Message-ID: To: Doug Royer Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:58:04 -0000 On Tue, Jun 19, 2018 at 7:45 PM, Doug Royer wrote: > On 06/19/2018 05:18 PM, Brian E Carpenter wrote: >> >> On 20/06/2018 10:47, Doug Royer wrote: >>> >>> On 06/19/2018 12:07 PM, Peter Saint-Andre wrote: >>>> >>>> (Just joined the list, sorry about the new thread.) >>>> ... >>>> As to solutions, Andrew Malis proposed some clearer boilerplate text at >>>> the top of each document. Some years ago, we added text like this to >>>> specs in the XMPP Standards Foundation's XEP series, and it helped to >>>> educate people who were confused about document status. [1] >>>> >>> >>> Published RFCs can not be edited, so, any "Final Standard" in the >>> document text will be obsolete at some point. Is this just not kicking >>> the can down the road a few more years? >>> >>> Would it be a better solution to log them with something like an IANA >>> registration? Perhaps grouped by area and protocol. >>> >>> Documents intended to be standard would then just refer the reader to >>> the standard registration page that would point to the latest hopeful >>> document(s). >> >> >> We don't need to wake up IANA for this. We already have the STD >> designation, >> which for some reason we've never chosen to use for the PS documents that >> the Internet runs on. A proposal for this was made 14 years ago: >> https://tools.ietf.org/html/draft-klensin-newtrk-std-repurposing >> and not much has changed since then. > > > I used IANA as an example. I don't care if it is IANA or not. A live > document would be great along with the prohibition of any future RFC calling > itself a standard in its text or Category on the title page. > I like Peter's suggestion and think to solve the problems raised, we just need to word this type of boilerplate carefully for the IETF streams. I am not in favor of an experiment that cannot be backed out of, so I don't think RFC# assignments should stop during an experiment. And also feel strongly that we should be thinking more about the problem, objectives, and how to measure to points already made on the various threads. Best regards, Kathleen > -- > > Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) > DouglasRoyer@gmail.com > 714-989-6135 > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus -- Best regards, Kathleen From nobody Wed Jun 20 08:58:49 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3C6130E32 for ; Wed, 20 Jun 2018 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 5TNR-iWNzmM7 for ; Wed, 20 Jun 2018 08:58:45 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9637F126DBF for ; Wed, 20 Jun 2018 08:58:45 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q4-v6so221013iob.2 for ; Wed, 20 Jun 2018 08:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=dgi+mb8egObSUYGL7nHTjo9eoeUDcEa5+u+XfCO4yXk=; b=RDzSCu82AyYB+jOvJT/r6HjUS0Z376EWN1Glt1zUHSFtfjbaE0xSa/p7zskxAOHMI8 3FxCunSDijNLxZBjH7Fln5+/bWV7soTNyx6xjcAx0J7f1m9mb80dgQ6yzO9KT73/Kjwm Ot4I5fTsYkYTwDpnGKp5hdMjrNpVqSiDBAEdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=dgi+mb8egObSUYGL7nHTjo9eoeUDcEa5+u+XfCO4yXk=; b=BEu5nwaBq74En9V4Xr7A28HA9HqaSPPlSGUrksy5ommkqvWfxb2SBBoNNbx84MP9QD HTUeqTPeBxuqUlFfCUzTsPaesiHyjSWz6X/BayA9CAB7X2lcrnKIK2WNPJF7O6UG2vPn ouGZXxyXmuiu+Xf3+iBHie/xC0Cz+pNRpgF9QzDgnoWBdY7J3QxxxBEVS5TvYfwnIpeq MmEFc69hOBzbsQ1XZHlbEcjRYVl6/JgpH70JWG39rbuLLGSYBWurJO8eOL1RtLOFhL8r 6oaykQrdjU/jylvdcF1itpRNA3/p1PmuAC8VJ6YNIVIlrSiA8LkbYZ41hEz6bthdIUuo zISw== X-Gm-Message-State: APt69E3sUDVsHp+PWvMAquU9oO4mBpg1/8WRJHnLPFZIl354tCNAKt82 LCOkILy7kvX69CTXbDruS8Phv6IwnMU= X-Google-Smtp-Source: AAOMgpfFGObPP96kgcORZySA6BGyed2sBEodq6cqaX+6CCVN3qVwUQD6/dU6ssQI3kxylxEaq53gKA== X-Received: by 2002:a6b:bc03:: with SMTP id m3-v6mr44977iof.44.1529510324948; Wed, 20 Jun 2018 08:58:44 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id y33-v6sm1326550ita.24.2018.06.20.08.58.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 08:58:44 -0700 (PDT) To: rfcplusplus@ietf.org From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> Date: Wed, 20 Jun 2018 09:58:42 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ttINLibZP7wztgfDPiVIIYIvKzkOk1Hqg" Archived-At: Subject: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:58:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ttINLibZP7wztgfDPiVIIYIvKzkOk1Hqg Content-Type: multipart/mixed; boundary="WgHA3UUO3UB3igCIstdrX97Yp8EebAmtu"; protected-headers="v1" From: Peter Saint-Andre To: rfcplusplus@ietf.org Message-ID: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> Subject: RFC 1796 revisited --WgHA3UUO3UB3igCIstdrX97Yp8EebAmtu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable The BoF proposal references RFC 1796, which I'd never looked at. The RFC makes for interesting reading and takes us back to a time (1995) when the Internet was being actively invented but was not all that usable for online publishing. For instance, the document suggests that we: Utilize the "web" hypertext technology to publicize the state of the standardization process. This newfangled "web" thing sure has taken off, hasn't it? The following claim also has not aged well: The IAB believes that the community benefitted significantly from having a single archival document series. Documents are easy to find and to retrieve, and file servers are easy to organize. This has been very important over the long term. Experience of the past shows that subseries, or series of limited scope, tend to vanish from the network. Many document series are now published on the web and have been for years, even including things like IESG and IAB statements. Yes, some of what's been published has vanished from the network, but the more valuable series are actively maintained. From this angle, there is no absolute necessity for, say, IRTF documents to be published as RFCs (e.g., the IRTF could curate a separate journal). And many independent submissions could be submitted to technology journals, presented as conference talks, or posted to weblogs. The Internet has made possible a robust publication ecosystem, so an RFC monoculture makes less sense now than it might have in 1995. The mailing list posts from Barry and Adam led me to believe that the primary concern here is customer confusion. The more significant confusion is one mentioned in, but denied by, RFC 1796: It is a regrettably well spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than the publication in a regular journal. In fact, each RFC has a status, relative to its relation with the Internet standardization process: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic. This status is reproduced on the first page of the RFC itself, and is also documented in the periodic "Internet Official Protocols Standards" RFC (STD 1). But this status is sometimes omitted from quotes and references, which may feed the confusion. The claim about recognition might have been true in 1995; however, due to years of hard work in defining and implementing high quality standards for IETF documents in particular, nowadays publication as an RFC does indeed provide "some level of recognition" (actually a great deal of it). As I understand things now, the problem folks have in mind for this BoF is that we continue to pursue a one-size-fits-all publication strategy when at the least that is no longer necessary and at the most that might be actively harmful because of widespread confusion about the nature and goals of the RFC Series or the status of a particular document. If I'm off-base, corrections are welcome. Peter --WgHA3UUO3UB3igCIstdrX97Yp8EebAmtu-- --ttINLibZP7wztgfDPiVIIYIvKzkOk1Hqg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsqebMACgkQZWGMGH9o FKn8XBAAmSshTEI5k1FqHOKJSgLVs8wvtP4bu/vg2N3pgaKtDT5E0bKkvR0QJXat DQi6Bnr3S56Y1saZpoqrscJj49EIvw66Bkr/OH57vxgTiJ2PxEWefiLs1+faGNEU gktLxWn99H8fA4aRTN54v5V6jCnnJbhXvY6JhtASiFAEvLWuoPtBhWCjJLyxUm5i di/uN0ECFOXNy22Px+BWgNJSFzyjg5m1Yal+ygQ5j6Ekg0SNAKPWcgfBTmi8UPRy HoOTiCpSPDlz/EhxDCQ0YwVICrKJwQgw54hj+b82oLWNBftvCHsfk61leMnTTLGD 6ETllaFw4ZmjhzEfEvnN6LRpZtYpawkT25HyBZdguZSE5YFzgdqvTNl3h3Nxc7Ib AKXRMTrqEI0oqEQFZSupNc9DFmIPkudiZBkTzPSYcIaU1V2UoPAboN9TjEyjkaTt LGePMXvSKSD4xFjzOMK25UIcgsZYjFmr1OEgyk+aP6CGzO7HwjF1leQ6dqc8hy4D zSU1Yt/yit87nTjQVWDqeoDNMQNS8F4Ux7tmRajIozykyoUAI0xNb5u/LM57v+IY mTmi7GbjJxpHkKimfJzbm+1z4Q/yzOxAY+JxOcdJrV9R3Tl6Rn0mRCbY35nxjhOp 7njfnufuhq5C7q0TQBw9PjyDnQ07A0qpzx+wgQjhWUKKLKavVgE= =dfYv -----END PGP SIGNATURE----- --ttINLibZP7wztgfDPiVIIYIvKzkOk1Hqg-- From nobody Wed Jun 20 09:37:16 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F71B131000 for ; Wed, 20 Jun 2018 09:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 1c8AbcFJvKWu for ; Wed, 20 Jun 2018 09:37:12 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 49DAD12F1A2 for ; Wed, 20 Jun 2018 09:37:12 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id v24-v6so189606otk.13 for ; Wed, 20 Jun 2018 09:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F++YO9ny+i5P0fDvEJnVysXSY5HG0ly0o+7Sadk6JOY=; b=TA8N+ngAjPQRDhbIrXvMF/V9mjfeN59XdkWgEki0CADms1KkXoeZVu4VM2EfIzQwz4 S2/FJn1wG2TncWtq1LdNsEonURRYoNH5wJJ0FPX/67Ab6Bzd/pj1bKdPbWeGRNVQwpTg Td8rQby070rQTUr3i6egG9VNwRruCKG+8NO59mg3G5cPlRO+07/rTV2PaCPtjHJfqldx vo0siTTJRghMof5XOifM5Uxj6zkv7DUFJnUsNbh4+g2DPhSjLeH4CdHrkaRFpAk306OC jPwYacAZAkuLRk2zySGClO6aL/snI1jFDw/n/Req92L7A+twP9XK06cq6vJwDirKtHqD 6LxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F++YO9ny+i5P0fDvEJnVysXSY5HG0ly0o+7Sadk6JOY=; b=DrJMSh3+WQtDi2V0a7E7cDycwGYGXgmfPIcWG8QZDhp+1tamsOo0e7GHFpRe0wkyyt JVrLoaE8Tv3qxEMwDzRHjCl6ts7OAwzEMtjx4HzxXYH9fAPBiJaIjnHhgbd1d8ry0SWi 2ghGe8issxVGcraTJgJsSVHj4QRwpM+3dg+k4rAl8A46f/cg0WQKKeJ9bvY9rgbAPelN R7+mhkvcpixKvFgp9HCC/el/D7AdbXus/vhmC1LyGH25kp6BSRwakIni9MMiCl9ZhPns LySIVEorpFrLaQdrBRv11v80sO9kbQRCSGndIcZLZoog2+/WVBt2q5e2L6vEZkhP8ArQ 6ejg== X-Gm-Message-State: APt69E1nFsRqePTfyjpbnYISgUQ0udUOtDyUHPfo2qUA6UgNSRGuZA4i KJhTZxtvm+0cyKWCCpaewcZ7Dd9DW+AX1SVjLxI= X-Google-Smtp-Source: ADUXVKJrBHgw8EH5AfIq0QWBETFqhCDknTtARrnX+hQYwGXuu2M7LWl5JlGosqEu9yq759kJK/MvbtaAEfrmDwbiCOI= X-Received: by 2002:a9d:282e:: with SMTP id m43-v6mr14219007otb.393.1529512631455; Wed, 20 Jun 2018 09:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 09:36:41 -0700 (PDT) In-Reply-To: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> From: Ted Hardie Date: Wed, 20 Jun 2018 09:36:41 -0700 Message-ID: To: Peter Saint-Andre Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="00000000000013d42b056f1569b7" Archived-At: Subject: Re: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 16:37:15 -0000 --00000000000013d42b056f1569b7 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 20, 2018 at 8:58 AM, Peter Saint-Andre wrote: > > > As I understand things now, the problem folks have in mind for this BoF > is that we continue to pursue a one-size-fits-all publication strategy > when at the least that is no longer necessary and at the most that might > be actively harmful because of widespread confusion about the nature and > goals of the RFC Series or the status of a particular document. > > If I'm off-base, corrections are welcome. > > Peter I would put this slightly differently. We have formalized a system that has multiple streams and multiple stream managers. Each stream has different input characteristics and its output should be judged, in part, by that input. To take the IAB example, IAB documents represent the consensus of the IAB. That consensus takes into account community commentary, but the output can easily be the IAB's (sometimes unpopular) opinion rather than the consensus opinion. An IETF RFC on the same topic might easily be very different and it would represent a different, larger community's consensus. At the moment, readers distinguish between the streams using in band signals (boiler plate and status). For any reader who is used to the series, those are significant and likely sufficient. It is clear, though, that those are less effective signals for those not used to the series. The BoF has two questions: is this problem, now 25 years old or so, worth tackling? If so, would a method that moved to a much more explicit signaling mechanism (e.g. a new name for the output of the IAB stream) help? Additional questions that are part of exploring the second question are: how would you test that the method has helped? If you decide it has not or decide it has damaged the visibility of a stream's output, how would you revert to the status quo ante? My take as an individual, Ted --00000000000013d42b056f1569b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 20, 2018 at 8:58 AM, Peter Saint-Andre <stp= eter@mozilla.com> wrote:

=C2=A0
As I understand things now, the problem folks have in mind for this BoF
is that we continue to pursue a one-size-fits-all publication strategy
when at the least that is no longer necessary and at the most that might be actively harmful because of widespread confusion about the nature and goals of the RFC Series or the status of a particular document.

If I'm off-base, corrections are welcome.

Peter

I would put this slight= ly differently.=C2=A0 We have formalized a system that has multiple streams= and multiple stream managers.=C2=A0 Each stream has different input charac= teristics and its output should be judged, in part, by that input.=C2=A0 To= take the IAB example, IAB documents represent the consensus of the IAB.=C2= =A0 That consensus takes into account community commentary, but the output = can easily be the IAB's (sometimes unpopular) opinion rather than the c= onsensus opinion.=C2=A0 An IETF RFC on the same topic might easily be very = different and it would represent a different, larger community's consen= sus.

At the moment, readers distinguish betwee= n the streams using in band signals (boiler plate and status).=C2=A0 For an= y reader who is used to the series, those are significant and likely suffic= ient.=C2=A0=C2=A0 It is clear, though, that those are less effective signal= s for those not used to the series.

The BoF has tw= o questions:=C2=A0 is this problem, now 25 years old or so, worth tackling?= =C2=A0 If so, would a method that moved to a much more explicit signaling m= echanism (e.g. a new name for the output of the IAB stream) help?

Additional questions that are part of exploring the second = question are:=C2=A0 how would you test that the method has helped?=C2=A0 If= you decide it has not or decide it has damaged the visibility of a stream&= #39;s output, how would you revert to the status quo ante?

My take as an individual,

Ted
--00000000000013d42b056f1569b7-- From nobody Wed Jun 20 10:04:10 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B720B130DEF for ; Wed, 20 Jun 2018 10:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 ZPgXXbLcwSRQ for ; Wed, 20 Jun 2018 10:04:06 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 424BF12F1A2 for ; Wed, 20 Jun 2018 10:04:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.176.250.254; From: "Susan Hares" To: Cc: , "'Bob Hinden'" Date: Wed, 20 Jun 2018 13:04:02 -0400 Message-ID: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B9_01D40897.29C112B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdQIuLBIrsJTiGpHQPuoBUORRXPN+A== Content-Language: en-us X-Antivirus: AVG (VPS 180620-2, 06/20/2018), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Rfcplusplus] (no subject) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 17:04:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B9_01D40897.29C112B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit BOF individuals: I am a part of the independent editors review board. Members of this board thought my note to them might be helpful in your discussions. I will be attending this BOF. Susan Hares ---------------- Adrian and Heather: I've thought a long time before sending in this BOF response. I apologize if it comes late in your thinking cycle. The real question is who has the authority over the RFC stream as editors rather than content providers. IMHO, the social engineering proposed by the BOF goes against the best practices in most excellent publications streams - that the group gives general guidance and then trusts the editors (ISE and RFC editors) to do the right thing with publication. The real question is does the IETF want to make clear the categorization in the RFC stream it operates on the following categories (we know and love): Agreed by consensus: Standards (proposed, internet), information, experimental standards, Best common practices, and historical standards. Published by (ISE) as non-consensus (aka individual) standards and information regarding standard. If we do, then why are we not allowing the RFC editor and ISE Editor to simply do the "right thing" in making it clear in a different set of publication streams. Micromanaging excellent people is either done by mistake, by inflated ego, by intent to provide wanton destruction of an organization/process. I suspect this statement will be unpopular at the microphone. Tired of micromanagement by BOFs, Sue Hares ------=_NextPart_000_01B9_01D40897.29C112B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BOF = individuals:

 

I am a = part of the independent editors review board.   Members of = this board thought my note to them might be helpful in your discussions. =   I will be attending this BOF.

 

Susan = Hares

 

----------------

 

Adrian = and Heather:

 I've thought a long time before sending in = this BOF response.   I apologize if it comes late in your = thinking cycle.

 The real question is who has the authority = over the RFC stream as editors rather than content = providers.   IMHO, the social engineering proposed by the BOF = goes against the best practices in most excellent publications streams - = that the group gives general guidance and then trusts the editors (ISE = and RFC editors) to do the right thing with = publication.

 

The = real question is does the IETF want to make clear the categorization in = the RFC stream it operates on the following categories (we know and = love):

 Agreed by consensus: = Standards (proposed, internet), information, experimental standards, = Best common practices, and historical standards.  Published by = (ISE) as non-consensus (aka individual) standards and information = regarding standard.    If we do, then why are we not = allowing the RFC editor and ISE Editor to simply do the "right = thing" in making it clear in a different set of publication = streams.

 Micromanaging excellent people is either done = by mistake, by inflated ego, by intent to provide wanton destruction of = an organization/process.    I suspect this statement will = be unpopular at the microphone.

 

Tired = of micromanagement by BOFs,

=

 Sue Hares

 

 

------=_NextPart_000_01B9_01D40897.29C112B0-- From nobody Wed Jun 20 10:40:10 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0606F1310DD for ; Wed, 20 Jun 2018 10:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 9FxHwRAiIUGD for ; Wed, 20 Jun 2018 10:40:05 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 4CB741310AE for ; Wed, 20 Jun 2018 10:40:05 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id d185-v6so518823ioe.0 for ; Wed, 20 Jun 2018 10:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=ncPOD6+TuLf33djkIhIu6twzly7fEqOvDauDitz0ims=; b=FRCKcyxkbf5JRbDguDuDVUK5wQLAW2TTCtOkXfpB6LdHM25kNxfKxubWOP84OqE/fD ruxjHpvDrzZK9sgp/n8qrL7XrELcGhF9xSviSxgGVUgwx4yStgJ8CcRcoPl3pdwoC3aQ AeCn+yjA59PJJwfPLDg5fLXQXjuuKW1vav3zk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=ncPOD6+TuLf33djkIhIu6twzly7fEqOvDauDitz0ims=; b=JmqmCc4fhE5I0ihltLkNsaDyWQOhkIpFg8fyu21rfLIunXwiH6F7J1TaztFaWnK645 K5fUrSh9UxYj7zhd5YSDaER7xuUihtobZMwnzl3Vbcodo8joMP38jKSxkC2SYGfar+Lm TGvh74CBZ1dI57Kgfa2WD+T7wP5KL0YZz03zU3gcXyp2f+5IdDurkU+TuWDlTHmv9I07 kC2pUnmOcBumikDDRzdaIOleXDsToBjuy2bm33XLuQXvm7nhXV1CukWXIm8hN4GhKfAt V09vUQC4MwXFnzUgZYt4mHZKwgqXe59PbzIJYWmYqR5KiQRnlVrSHN4LZwQZ3QK7+jZt 7wwA== X-Gm-Message-State: APt69E2oFdX4//0gLJaxWRpZt0sZs59g1ro9R60eE7agWuB0mjoGx9nU ZJgO3iajTqrt7ZN1PbDJvnQITA== X-Google-Smtp-Source: ADUXVKI8ZWMBSDp73MgpiAj/xGls8gly2PXSm3or2ft6GYR+QJ7MUvws3AKanWGpw/0oA80fRh3plg== X-Received: by 2002:a6b:960d:: with SMTP id y13-v6mr19137490iod.161.1529516404646; Wed, 20 Jun 2018 10:40:04 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id x97-v6sm1689189ita.18.2018.06.20.10.40.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 10:40:03 -0700 (PDT) To: Ted Hardie Cc: rfcplusplus@ietf.org References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> Date: Wed, 20 Jun 2018 11:40:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q97lkWGS6blDZDLHcMpamMf00rJZUYNc9" Archived-At: Subject: Re: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 17:40:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q97lkWGS6blDZDLHcMpamMf00rJZUYNc9 Content-Type: multipart/mixed; boundary="o4tLKwKog7qbLzeHO4FdHsa6lFN6EWIQM"; protected-headers="v1" From: Peter Saint-Andre To: Ted Hardie Cc: rfcplusplus@ietf.org Message-ID: <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> Subject: Re: [Rfcplusplus] RFC 1796 revisited References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> In-Reply-To: --o4tLKwKog7qbLzeHO4FdHsa6lFN6EWIQM Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/20/18 10:36 AM, Ted Hardie wrote: > On Wed, Jun 20, 2018 at 8:58 AM, Peter Saint-Andre > wrote: >=20 >=20 > =C2=A0 > As I understand things now, the problem folks have in mind for this= BoF > is that we continue to pursue a one-size-fits-all publication strat= egy > when at the least that is no longer necessary and at the most that = might > be actively harmful because of widespread confusion about the natur= e and > goals of the RFC Series or the status of a particular document. >=20 > If I'm off-base, corrections are welcome. >=20 > Peter >=20 >=20 > I would put this slightly differently.=C2=A0 We have formalized a syste= m that > has multiple streams and multiple stream managers.=C2=A0 Each stream ha= s > different input characteristics and its output should be judged, in > part, by that input.=20 Right. Another way to put this is that we have different document creation processes (with different goals, levels of review, etc.) resulting in publication to the same document series. How is that working out for us and the readers of these documents? A quick look at rfc-editor.org reveals the following data: IETF stream - 5782 RFCs IRTF stream - 71 RFCs IAB stream - 105 RFCs Independent stream - 326 RFCs "Legacy" stream (pre RFC 3600 in 2003) - 2012 RFCs So 92%+ of RFCs in the last 15 years were produced by the IETF. That might be relevant to our thinking about what customers we're serving. > To take the IAB example, IAB documents represent > the consensus of the IAB.=C2=A0 That consensus takes into account commu= nity > commentary, but the output can easily be the IAB's (sometimes unpopular= ) > opinion rather than the consensus opinion.=C2=A0 An IETF RFC on the sam= e > topic might easily be very different and it would represent a different= , > larger community's consensus. >=20 > At the moment, readers distinguish between the streams using in band > signals (boiler plate and status).=C2=A0 For any reader who is used to = the > series, those are significant and likely sufficient.=C2=A0=C2=A0 It is = clear, > though, that those are less effective signals for those not used to the= > series. Indeed. > The BoF has two questions:=C2=A0 is this problem, now 25 years old or s= o, > worth tackling?=C2=A0 If so, would a method that moved to a much more > explicit signaling mechanism (e.g. a new name for the output of the IAB= > stream) help? As hinted, I suggest that we also explore different output methods. For instance, the IAB could publish documents at its website, which for some kinds of documents it already does: https://www.iab.org/documents/correspondence-reports-documents/ Perhaps IAB and IRTF folks have already explored such avenues? > Additional questions that are part of exploring the second question > are:=C2=A0 how would you test that the method has helped?=20 Because we are working with a paucity of data, the testing methods are not yet clear to me. > If you decide it > has not or decide it has damaged the visibility of a stream's output, > how would you revert to the status quo ante? Given the customer base mentioned above, I suggest that the key documents here are those produced by the IETF (~92% compared to IAB at ~1%, IRTF at ~2%, and independent at ~5%). Is visibility the right measure? And visibility to whom? Do we have a clear picture of the user base for IAB or IRTF or independent stream documents (or, for that matter, IETF stream documents)? It's not hard to imagine that the audience for IRTF documents might skew somewhat differently, and that the IAB audience overlaps significantly with the IETF audience. The audience for independent stream documents strikes me as the least well defined. Are measures other than visibility relevant? (For instance: stability, accessibility, distribution.) Peter --o4tLKwKog7qbLzeHO4FdHsa6lFN6EWIQM-- --Q97lkWGS6blDZDLHcMpamMf00rJZUYNc9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsqkXIACgkQZWGMGH9o FKkmqQ//Sn4iSBcVfniqrgvFSHNwaQZBE3oIGArNRAVmfV84Sc6Jboyo/Ltr2sWr lQDNGfaUhO1UEShd0V4aOIB6CAeX64RY4z7/sEEP8bLcdyoLTUdiIpYbOpPIpT+4 CnYa1Vdq1J1+hAchs2DqCOg3y94JewDg3X3shSwOxd3CtozkZOd9SNDEb7UNAVch 6hiqW8ZEtsP/L2/h3WneTlbnPgAgqyOWEdY8GnwzPzwlavN25iOcfjdG7ncQ26pM PiXy+RnzMok+ea6KgT7zEyZANaNdkpiJR5uwthGjR6httOxFBL0gJlHYW2Aqc7eo MdiYKsX5HEsn+LRxoGHsXlk/z4U2u3bpaG0FvAv6i8A9t+06l666r1utJNBqWuSF k9WETlJFaPA3KutpBnDX+RrsZBX40cC8ydqs6EIz2j/cH6oxgNy7pnvksGxMsD8B P6Qo73W8Yv8dvipYeu5eWXNdU4TnE6B/u0kMJjI3S9gm54xjnPxsp3W0Q72knuaq CT/o3GruKgeVQ70TMtS6L51tuBUOr01Gtp9xcA59bhb6ysYomRdCf9b3i0otTALc bGL0OIJTBUv62Y31gsG/bewXAcnBAniP0/FFKrevqQ00bmqbwU+fJN3L4xN6lEps /5kahgrJTWH/y1gmm7HomkL/RMjWb8ob1diaZdDTz8LZh364Zzs= =bC+Y -----END PGP SIGNATURE----- --Q97lkWGS6blDZDLHcMpamMf00rJZUYNc9-- From nobody Wed Jun 20 11:33:02 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E43130E05 for ; Wed, 20 Jun 2018 11:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 6zCk5iy3UIx1 for ; Wed, 20 Jun 2018 11:32:57 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 690BA130DFA for ; Wed, 20 Jun 2018 11:32:57 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id d5-v6so507471oib.5 for ; Wed, 20 Jun 2018 11:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l6zAAkmlax7kwbEC0era+tXIGVamgSdwaIq48SYvScc=; b=apQalKq+AiaLx/AwXsXhV+++d16FVgkxaQ8KZ5evHRqWnFl88H+lCJKVLrtIIzptMN t4G2MLDfzrKgPLYb53yXA8aAB2U7H2LE6s0fMoaTmzwUsHd9zvNlxPYg4nuDdzYi5ExY wgBLCjcyH0qdS1r/u92lmvPky7Qgo1vcWimJlVJu28Wj3U039TUKMCUPGLeWqzCECSRW VN5dIu4hff9mYdgOdZX6jL9mx43x1dgH9qQRSWjTNioi2Chei3XpCkk7c5PJGKYBFLwK Qp/BX8rg2ZraxACZqj2K9gX16RKdrbh9YHaT/HHoc3Sl2ZCSeJ0gp69lBYjGkrruHElX tHsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l6zAAkmlax7kwbEC0era+tXIGVamgSdwaIq48SYvScc=; b=l7EfCVup5C2c0TkEBieoQjzQ7lIfehWkeMbO6sxr2RDbg46WQM2786GMqB5vZlltyc S9zGg00skNp4dIGIFXjK2MbsAmRKeuD5v8jOnpSU/8lehmqKzdzTqGxgspgj7CHnHjKx cB3yvKflV2OWq4GY3gmUPmvpysbBsYwmsQh4JPSG8IPxGhA5KRzqN1m07BnPrAtm8zTN AisfuplZEq9XZzP/bNMcC/XL4CrQzOco0g+EP9qkuRGD8KBXFPi2lxizCWnb2WRiqhg1 tNFqV0Gnhxyh3MkNsnHiHTU5bwXHWCPt8ug7sqClNZpp5vmJlaUui+fS8XLKShpIERP+ j/JA== X-Gm-Message-State: APt69E0RVgCe0+Q0jP/Znpq3v5DLNBJ9JDmj3674TvGe/Hoa+Cx9uy/w cOkch2C4zAkRQtvGBlM8//XNhBRglGhMkKiSG6c= X-Google-Smtp-Source: ADUXVKJ5/oWjhpEMD/hgCmqAq1dGztaOSG/g/87kAEUDNJxyxertZFn5rUsPM+ep7/5UhGprwXlEketPv83A7pzD1dw= X-Received: by 2002:aca:f404:: with SMTP id s4-v6mr12961759oih.204.1529519576784; Wed, 20 Jun 2018 11:32:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 11:32:36 -0700 (PDT) In-Reply-To: <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> From: "Andrew G. Malis" Date: Wed, 20 Jun 2018 14:32:36 -0400 Message-ID: To: Peter Saint-Andre Cc: Ted Hardie , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d23b9056f170754" Archived-At: Subject: Re: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 18:33:00 -0000 --0000000000000d23b9056f170754 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve yet to see any suggestions on how we objectively measure the c= urrent =E2=80=9Cproblem=E2=80=9D. All we=E2=80=99ve been discussing are anecdotal = experiences. We certainly can=E2=80=99t measure the results of changes if we can=E2=80=99t = measure what we want to change. That=E2=80=99s why a low-cost, safe, approach that certainly can=E2=80=99t = make anything =E2=80=9Cworse=E2=80=9D (assuming that it needs improvement) is to make the= boilerplate text very clear to a naive reader regarding the status of a particular RFC. As Sue suggested, we should be able to trust the editors to do their job and produce suitable wording. Cheers, Andy On Wed, Jun 20, 2018 at 1:40 PM, Peter Saint-Andre wrote: > On 6/20/18 10:36 AM, Ted Hardie wrote: > > On Wed, Jun 20, 2018 at 8:58 AM, Peter Saint-Andre > > wrote: > > > > > > > > As I understand things now, the problem folks have in mind for this > BoF > > is that we continue to pursue a one-size-fits-all publication > strategy > > when at the least that is no longer necessary and at the most that > might > > be actively harmful because of widespread confusion about the natur= e > and > > goals of the RFC Series or the status of a particular document. > > > > If I'm off-base, corrections are welcome. > > > > Peter > > > > > > I would put this slightly differently. We have formalized a system tha= t > > has multiple streams and multiple stream managers. Each stream has > > different input characteristics and its output should be judged, in > > part, by that input. > > Right. Another way to put this is that we have different document > creation processes (with different goals, levels of review, etc.) > resulting in publication to the same document series. > > How is that working out for us and the readers of these documents? > > A quick look at rfc-editor.org reveals the following data: > > IETF stream - 5782 RFCs > IRTF stream - 71 RFCs > IAB stream - 105 RFCs > Independent stream - 326 RFCs > "Legacy" stream (pre RFC 3600 in 2003) - 2012 RFCs > > So 92%+ of RFCs in the last 15 years were produced by the IETF. That > might be relevant to our thinking about what customers we're serving. > > > To take the IAB example, IAB documents represent > > the consensus of the IAB. That consensus takes into account community > > commentary, but the output can easily be the IAB's (sometimes unpopular= ) > > opinion rather than the consensus opinion. An IETF RFC on the same > > topic might easily be very different and it would represent a different= , > > larger community's consensus. > > > > At the moment, readers distinguish between the streams using in band > > signals (boiler plate and status). For any reader who is used to the > > series, those are significant and likely sufficient. It is clear, > > though, that those are less effective signals for those not used to the > > series. > > Indeed. > > > The BoF has two questions: is this problem, now 25 years old or so, > > worth tackling? If so, would a method that moved to a much more > > explicit signaling mechanism (e.g. a new name for the output of the IAB > > stream) help? > > As hinted, I suggest that we also explore different output methods. For > instance, the IAB could publish documents at its website, which for some > kinds of documents it already does: > > https://www.iab.org/documents/correspondence-reports-documents/ > > Perhaps IAB and IRTF folks have already explored such avenues? > > > Additional questions that are part of exploring the second question > > are: how would you test that the method has helped? > > Because we are working with a paucity of data, the testing methods are > not yet clear to me. > > > If you decide it > > has not or decide it has damaged the visibility of a stream's output, > > how would you revert to the status quo ante? > > Given the customer base mentioned above, I suggest that the key > documents here are those produced by the IETF (~92% compared to IAB at > ~1%, IRTF at ~2%, and independent at ~5%). > > Is visibility the right measure? And visibility to whom? Do we have a > clear picture of the user base for IAB or IRTF or independent stream > documents (or, for that matter, IETF stream documents)? It's not hard to > imagine that the audience for IRTF documents might skew somewhat > differently, and that the IAB audience overlaps significantly with the > IETF audience. The audience for independent stream documents strikes me > as the least well defined. > > Are measures other than visibility relevant? (For instance: stability, > accessibility, distribution.) > > Peter > > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > > --0000000000000d23b9056f170754 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve yet to see any suggestions on how we objectiv= ely measure the current =E2=80=9Cproblem=E2=80=9D. All we=E2=80=99ve been d= iscussing are anecdotal experiences. We certainly can=E2=80=99t measure the= results of changes if we can=E2=80=99t measure what we want to change.
That=E2=80=99s why a low-cost, safe, approach that certainl= y can=E2=80=99t make anything =E2=80=9Cworse=E2=80=9D (assuming that it nee= ds improvement) is to make the boilerplate text very clear to a naive reade= r regarding the status of a particular RFC. As Sue suggested, we should be = able to trust the editors to do their job and produce suitable wording.

Cheers,
Andy


On Wed, Jun 20, 2018 = at 1:40 PM, Peter Saint-Andre <stpeter@mozilla.com> wrote:=
On 6/20/18 10:36 AM, Te= d Hardie wrote:
> On Wed, Jun 20, 2018 at 8:58 AM, Peter Saint-Andre <stpeter@mozilla.com
> <mailto:stpeter@mozilla.com>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0
>=C2=A0 =C2=A0 =C2=A0As I understand things now, the problem folks have = in mind for this BoF
>=C2=A0 =C2=A0 =C2=A0is that we continue to pursue a one-size-fits-all p= ublication strategy
>=C2=A0 =C2=A0 =C2=A0when at the least that is no longer necessary and a= t the most that might
>=C2=A0 =C2=A0 =C2=A0be actively harmful because of widespread confusion= about the nature and
>=C2=A0 =C2=A0 =C2=A0goals of the RFC Series or the status of a particul= ar document.
>
>=C2=A0 =C2=A0 =C2=A0If I'm off-base, corrections are welcome.
>
>=C2=A0 =C2=A0 =C2=A0Peter
>
>
> I would put this slightly differently.=C2=A0 We have formalized a syst= em that
> has multiple streams and multiple stream managers.=C2=A0 Each stream h= as
> different input characteristics and its output should be judged, in > part, by that input.

Right. Another way to put this is that we have different document creation processes (with different goals, levels of review, etc.)
resulting in publication to the same document series.

How is that working out for us and the readers of these documents?

A quick look at rfc-editor.org reveals the following data:

IETF stream - 5782 RFCs
IRTF stream - 71 RFCs
IAB stream - 105 RFCs
Independent stream - 326 RFCs
"Legacy" stream (pre RFC 3600 in 2003) - 2012 RFCs

So 92%+ of RFCs in the last 15 years were produced by the IETF. That
might be relevant to our thinking about what customers we're serving.
> To take the IAB example, IAB documents represent
> the consensus of the IAB.=C2=A0 That consensus takes into account comm= unity
> commentary, but the output can easily be the IAB's (sometimes unpo= pular)
> opinion rather than the consensus opinion.=C2=A0 An IETF RFC on the sa= me
> topic might easily be very different and it would represent a differen= t,
> larger community's consensus.
>
> At the moment, readers distinguish between the streams using in band > signals (boiler plate and status).=C2=A0 For any reader who is used to= the
> series, those are significant and likely sufficient.=C2=A0=C2=A0 It is= clear,
> though, that those are less effective signals for those not used to th= e
> series.

Indeed.

> The BoF has two questions:=C2=A0 is this problem, now 25 years old or = so,
> worth tackling?=C2=A0 If so, would a method that moved to a much more<= br> > explicit signaling mechanism (e.g. a new name for the output of the IA= B
> stream) help?

As hinted, I suggest that we also explore different output methods. = For
instance, the IAB could publish documents at its website, which for some kinds of documents it already does:

https://www.iab.org/documents/co= rrespondence-reports-documents/

Perhaps IAB and IRTF folks have already explored such avenues?

> Additional questions that are part of exploring the second question > are:=C2=A0 how would you test that the method has helped?

Because we are working with a paucity of data, the testing methods a= re
not yet clear to me.

> If you decide it
> has not or decide it has damaged the visibility of a stream's outp= ut,
> how would you revert to the status quo ante?

Given the customer base mentioned above, I suggest that the key
documents here are those produced by the IETF (~92% compared to IAB at
~1%, IRTF at ~2%, and independent at ~5%).

Is visibility the right measure? And visibility to whom? Do we have a
clear picture of the user base for IAB or IRTF or independent stream
documents (or, for that matter, IETF stream documents)? It's not hard t= o
imagine that the audience for IRTF documents might skew somewhat
differently, and that the IAB audience overlaps significantly with the
IETF audience. The audience for independent stream documents strikes me
as the least well defined.

Are measures other than visibility relevant? (For instance: stability,
accessibility, distribution.)

Peter



_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus


--0000000000000d23b9056f170754-- From nobody Wed Jun 20 11:41:35 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26090130E17 for ; Wed, 20 Jun 2018 11:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SqSCGcMr08MD for ; Wed, 20 Jun 2018 11:41:30 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 5C029130FD7 for ; Wed, 20 Jun 2018 11:41:30 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id q4-v6so221487pgr.1 for ; Wed, 20 Jun 2018 11:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZRePTaAFZ850qfSQC6ZQ8ClDOFTEyo/YOdd1R2/TJwA=; b=jF2jve/twIcSz+12so3jIxuJeZaC7jehThqVMf3772KvioTSMdz9TA36sdeRhqPZEV tkhpWb9qeyg/RWxkyoTHSXZrByG5qzzA/RA3qqBAAY6fQCRN7fRpRGjNLSjkgeIRCxgg 242/aKZ1gNR/mlbMzPIYaUxFgKDBKfq3xtTn4aAwcmgCpxIKYlO2exvGWkljANASPdmf RHGmLncZspvbjDJWlafq7U7sjrnPkSx/fh6u7oF8Q+Uo+k21HlP2wfqXe67Fm5P9ubkT eKxi4HztyLGflyLTvNu6W3UeJRgo54QY/Ez4wXCKBFNNdrraXdkaQ07YvVoFoRzaWMa/ 1/nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZRePTaAFZ850qfSQC6ZQ8ClDOFTEyo/YOdd1R2/TJwA=; b=soBUU8nd17nbaYPLLpmuf+eJTntwKiymRY+qV0l1/28/mJ0kS2sn1WCAtsHf3RtDvW 3cucI4T8D99mibYSP9M5NKOtplhk5gLQS1+/LgG0f5MAVaD8LedkZ9jTPKWKXnRVI0eT wE9RGzambGiPxClyZZCMDa8G5EbxIxjOUTCmv61/SZAOb7MobIR2tOgm6kePzMg4xYO5 KXPsf1N/VNU6wLdIkbzHt524cBMW7Ls3ECCNTnzl6HixdsKRKbQ9QU8Ur6AR/7jVX7B4 aq99iuOWd/iLd20YWqmLusItug/UPUUdbk0ICO6CgZ4RP0AIJjS/gJB3IeaBFe5OOE2b z2ig== X-Gm-Message-State: APt69E35/L5uOWE27oTuAuv1gdS9i3VVV5OJESnnE3a+aKd3VZjNUmA/ 5Nknr7BjefBxTBUNOcafgH8gNljP X-Google-Smtp-Source: ADUXVKIWo9XaMe4rRe+gVSbKFcLvIxZyX0pBUNY63CdsUpyJj+b7qqUjFmmUzPA7xnUhbhNBpxSuKw== X-Received: by 2002:a62:ae06:: with SMTP id q6-v6mr9156653pff.17.1529520089990; Wed, 20 Jun 2018 11:41:29 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id w7-v6sm3483317pgs.68.2018.06.20.11.41.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 11:41:29 -0700 (PDT) From: Bob Hinden Message-Id: <20FDAF92-16C7-4EE4-A2CA-1179A8AEBA19@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_30CA90B4-5A2C-48FD-8BAF-C1E949AB125B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 20 Jun 2018 11:41:27 -0700 In-Reply-To: <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> Cc: Bob Hinden , Ted Hardie , rfcplusplus@ietf.org To: Peter Saint-Andre References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 18:41:34 -0000 --Apple-Mail=_30CA90B4-5A2C-48FD-8BAF-C1E949AB125B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Peter, > On Jun 20, 2018, at 10:40 AM, Peter Saint-Andre = wrote: >=20 > A quick look at rfc-editor.org reveals the following data: >=20 > IETF stream - 5782 RFCs > IRTF stream - 71 RFCs > IAB stream - 105 RFCs > Independent stream - 326 RFCs > "Legacy" stream (pre RFC 3600 in 2003) - 2012 RFCs >=20 > So 92%+ of RFCs in the last 15 years were produced by the IETF. That > might be relevant to our thinking about what customers we're serving. Given these numbers, I am finding it difficult to think the purported = problem is very serious. After all, as you report, more than 92% of the = RFCs are from the IETF stream. Could 326 RFCs from the Independent = Stream be causing that much of a problem? Bob >=20 >> To take the IAB example, IAB documents represent >> the consensus of the IAB. That consensus takes into account = community >> commentary, but the output can easily be the IAB's (sometimes = unpopular) >> opinion rather than the consensus opinion. An IETF RFC on the same >> topic might easily be very different and it would represent a = different, >> larger community's consensus. >>=20 >> At the moment, readers distinguish between the streams using in band >> signals (boiler plate and status). For any reader who is used to the >> series, those are significant and likely sufficient. It is clear, >> though, that those are less effective signals for those not used to = the >> series. >=20 > Indeed. >=20 >> The BoF has two questions: is this problem, now 25 years old or so, >> worth tackling? If so, would a method that moved to a much more >> explicit signaling mechanism (e.g. a new name for the output of the = IAB >> stream) help? >=20 > As hinted, I suggest that we also explore different output methods. = For > instance, the IAB could publish documents at its website, which for = some > kinds of documents it already does: >=20 > https://www.iab.org/documents/correspondence-reports-documents/ >=20 > Perhaps IAB and IRTF folks have already explored such avenues? >=20 >> Additional questions that are part of exploring the second question >> are: how would you test that the method has helped? >=20 > Because we are working with a paucity of data, the testing methods are > not yet clear to me. >=20 >> If you decide it >> has not or decide it has damaged the visibility of a stream's output, >> how would you revert to the status quo ante? >=20 > Given the customer base mentioned above, I suggest that the key > documents here are those produced by the IETF (~92% compared to IAB at > ~1%, IRTF at ~2%, and independent at ~5%). >=20 > Is visibility the right measure? And visibility to whom? Do we have a > clear picture of the user base for IAB or IRTF or independent stream > documents (or, for that matter, IETF stream documents)? It's not hard = to > imagine that the audience for IRTF documents might skew somewhat > differently, and that the IAB audience overlaps significantly with the > IETF audience. The audience for independent stream documents strikes = me > as the least well defined. >=20 > Are measures other than visibility relevant? (For instance: stability, > accessibility, distribution.) >=20 > Peter >=20 >=20 >=20 >=20 --Apple-Mail=_30CA90B4-5A2C-48FD-8BAF-C1E949AB125B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlsqn9cACgkQrut0EXfn u6hatwf/WAPSDhaakfO21ss/FU1ChzGb/ig+WW+Yd9zCYZN69qvdiHRRVA3ZkuhE we2UL/cg41hl69TIdnsRYsRILho2k6ESom6bv5aZAn3Ge5odHG/4wTTH9zw1iVee jxBQPdHWejP3DRgkcSSlXwHbX/0IPpnxXslNeKL75rx6y+iPdVrbGda4zpx52PvS OS3YPbOqOUiLYe2bP1cw1wavnEBNlYYU1PIToykC23qndj2HrCfXXTkRm5FT/Ure 3/Ll/afbtn57gckgdcVKfGGZpXHBiFkYDbfaqK7m8Aa6L/Sbw/sE+nT3ZFWGLk2R aNcVB0EkIEC9d81H4x64JZ4sAxMlRQ== =c8OD -----END PGP SIGNATURE----- --Apple-Mail=_30CA90B4-5A2C-48FD-8BAF-C1E949AB125B-- From nobody Wed Jun 20 11:53:30 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA137130DFB for ; Wed, 20 Jun 2018 11:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 aFT3wRSjT6ii for ; Wed, 20 Jun 2018 11:53:27 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5BB12777C for ; Wed, 20 Jun 2018 11:53:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 101EB1CAE2F for ; Wed, 20 Jun 2018 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mzd858oHxbO for ; Wed, 20 Jun 2018 11:53:22 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:ad4c:5b92:670d:7880]) by c8a.amsl.com (Postfix) with ESMTPSA id D43AF1CAE2E for ; Wed, 20 Jun 2018 11:53:22 -0700 (PDT) To: rfcplusplus@ietf.org References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> From: "Heather Flanagan (RFC Series Editor)" Message-ID: Date: Wed, 20 Jun 2018 11:53:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 18:53:30 -0000 On 6/20/18 11:32 AM, Andrew G. Malis wrote: > I’ve yet to see any suggestions on how we objectively measure the > current “problem”. All we’ve been discussing are anecdotal > experiences. We certainly can’t measure the results of changes if we > can’t measure what we want to change. > > That’s why a low-cost, safe, approach that certainly can’t make > anything “worse” (assuming that it needs improvement) is to make the > boilerplate text very clear to a naive reader regarding the status of > a particular RFC. As Sue suggested, we should be able to trust the > editors to do their job and produce suitable wording. If we as a community decide that this is a serious enough problem to assign resources to it (which means either deprioritizing other work or throwing more money at the problem), I think we need to start with a basic market research effort. I know this community tends to prefer using community-based resources, but market research is a whole field of endeavor that has people who are actually experts in that area. Marketing is often a dirty word to engineers, but it has its place and would give us the kind of baseline we need to figure out if and how to make changes to the Series in a data-driven way. -Heather From nobody Wed Jun 20 12:46:09 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B6D130F58 for ; Wed, 20 Jun 2018 12:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 USTAinwYhtSb for ; Wed, 20 Jun 2018 12:46:05 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 962C3130DC2 for ; Wed, 20 Jun 2018 12:46:05 -0700 (PDT) Received: from [10.32.60.124] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w5KJk1TF038375 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Jun 2018 12:46:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.124] From: "Paul Hoffman" To: "Peter Saint-Andre" Cc: rfcplusplus@ietf.org Date: Wed, 20 Jun 2018 12:46:03 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 19:46:08 -0000 On 20 Jun 2018, at 10:40, Peter Saint-Andre wrote: > A quick look at rfc-editor.org reveals the following data: > > IETF stream - 5782 RFCs > IRTF stream - 71 RFCs > IAB stream - 105 RFCs > Independent stream - 326 RFCs > "Legacy" stream (pre RFC 3600 in 2003) - 2012 RFCs > > So 92%+ of RFCs in the last 15 years were produced by the IETF. That > might be relevant to our thinking about what customers we're serving. ...but maybe not specific enough. One of the components of the proposed experiment is to publish informational, procedural, and experimental documents not in the main stream. Of that 92%, a not-insignificant number are informational, procedural, or experimental. Just to be clear, I'm not proposing that this is a good idea. If the IESG wants to segregate out all their non-standards documents into separate publishing streams (hopefully well-collected with long-lived URLs), that should be their choice. As author of a bunch of those documents, I would prefer being able to keep the future ones in the RFC series, but it really is up to them. --Paul Hoffman From nobody Wed Jun 20 13:15:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0F5130E13 for ; Wed, 20 Jun 2018 13:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 vwAxkPDUZYQa for ; Wed, 20 Jun 2018 13:14:56 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 19A23130DCA for ; Wed, 20 Jun 2018 13:14:56 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id n7-v6so1471035itn.1 for ; Wed, 20 Jun 2018 13:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=VXYsVtEhtaaXi09bOtPDc5iWwhaEpscWyhHtbGkb5+E=; b=IPohFiDtK0UddAYItLWqPngWdSsLzJsEGtsORivLd4qu+1kqK6VSOZ+ipXW7cBKwf5 0VRDVzX82VkGqn/NtWDdoKgZIvLYwREIT9JDGuQ5KV+RuD+XNdJkSmyoC/ZaYPHnhqnN fGI3JMJfvuX18cmAi4hL88qZ9t/B6Y0NtmcHs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=VXYsVtEhtaaXi09bOtPDc5iWwhaEpscWyhHtbGkb5+E=; b=Tt/V75JY2bBgFyh4YI6VW5SADjmHst60boz0H2HlT33TQWIMmuwUYhJxC3L4Il3l9b 2MFESgSPF7Jfbm2wyID5bx3R2XPH7QI9H/4iUJa6eEWiluE5nnlNAOeGbiUqOv/VV3MV 7xu8F3B6wBL8BhG3gv8Mdr95tyTKm1NEjNVv7z0TdsmkilY/LGy33eYDqY64p2ctu97e sV8h6Pi6MP394bRDCwBnph0sMNc5ExeZzNCr3WGeR6N2K51b8fuz6cWqDVZgzFvhzGND Grs4DkEJ68cno9XEZSrpoQSKZQFdKaRP/ItVOoMovI4bb64xUxvZjI/lsyQKx2yAFWj/ KwlA== X-Gm-Message-State: APt69E1s1FRsCPCJN6lVMEOqK4OlfFHBfKc3+UueYq8JWLUGTtlS5srf vgo9vaWZRaNtDOX57yNY76ecUA== X-Google-Smtp-Source: ADUXVKLNIYzBGzDRRhvDul77nI5WkLmQ1jJBevb+Hqkk2vy66WA2SMvvN0f67ONfE1PKCWm2ofVwhw== X-Received: by 2002:a24:a309:: with SMTP id p9-v6mr2830065ite.92.1529525695362; Wed, 20 Jun 2018 13:14:55 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id y62-v6sm2661580ioy.88.2018.06.20.13.14.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 13:14:54 -0700 (PDT) To: Paul Hoffman Cc: rfcplusplus@ietf.org References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Wed, 20 Jun 2018 14:14:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lg5hZyJUuwPKKWjmYRTvTgkhaicfSsvqU" Archived-At: Subject: Re: [Rfcplusplus] RFC 1796 revisited X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 20:14:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lg5hZyJUuwPKKWjmYRTvTgkhaicfSsvqU Content-Type: multipart/mixed; boundary="Au06TCQaUt7pMay9IrODAVh0JfepGBDZN"; protected-headers="v1" From: Peter Saint-Andre To: Paul Hoffman Cc: rfcplusplus@ietf.org Message-ID: Subject: Re: [Rfcplusplus] RFC 1796 revisited References: <4f19b041-a46e-ee12-17b2-5a71abb1e9e3@mozilla.com> <6d84812c-c3ec-bf1a-7b98-6335a28b990d@mozilla.com> In-Reply-To: --Au06TCQaUt7pMay9IrODAVh0JfepGBDZN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/20/18 1:46 PM, Paul Hoffman wrote: > On 20 Jun 2018, at 10:40, Peter Saint-Andre wrote: >=20 >> A quick look at rfc-editor.org reveals the following data: >> >> IETF stream - 5782 RFCs >> IRTF stream - 71 RFCs >> IAB stream - 105 RFCs >> Independent stream - 326 RFCs >> "Legacy" stream (pre RFC 3600 in 2003) - 2012 RFCs >> >> So 92%+ of RFCs in the last 15 years were produced by the IETF. That >> might be relevant to our thinking about what customers we're serving. >=20 > ...but maybe not specific enough. One of the components of the proposed= > experiment is to publish informational, procedural, and experimental > documents not in the main stream. Of that 92%, a not-insignificant > number are informational, procedural, or experimental. Good point, Paul. I was thinking about the creation process (IETF consensus or at least last call, IESG review, etc.), not the document types within the IETF stream. I'm not yet sure which of these dimensions is relevant. Peter --Au06TCQaUt7pMay9IrODAVh0JfepGBDZN-- --lg5hZyJUuwPKKWjmYRTvTgkhaicfSsvqU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsqtb0ACgkQZWGMGH9o FKnFgw/+JKs7zMf+5N3mKnf0Po3Vu8x+qsf8lSUTl/JGt/vBxk+/3P8AwI5qIKc/ +8T/uL4Xu30ulNGGoT6sHvKjZ5bHsV06KdW/6Ux0+4PND7MuuBv6/jFMY8fV1ve4 iIZVqPgJRNjmH0M/0fzKMy1dkgrz5px9BSAokp8ZeYsfK+XjenOWbXvusSCAT6aj WknZjpbC55xuBA14XNjR3Jc0y5Y/cNHK71q+wLO1aWJpn+fPNIztb5Me+S1deuus odqM0iWK/alq63JMyGNzFiuxHenKYfkdB9GuBNdsOi+roo4CvOV5BRiSomC+7IVR WoCcasGiO0eQ9GPzBDAYqFM4eHMf/Of6ii6MGPITHY2/lRde+Hn+yfj4A0KAPC6+ gHM4SXbMbb0JHNRyeD0HKPycsCNBIbhP3ZJSuAtIGXt4ianDe0gdWzudDGLOtdOO Zo8JB9b2U+Mc/hF2/n/ntfM28cHA3s2JWtAyfE3Ui3dmi/1WQZHwjstoByrtMXk5 VvqNvTWujM/iEcQ5uje9C3tjvnh4WHgOLQWD40R6CCD0OHVA6jYo91qS2GsWEHSN 5BLTgAhcGs85+50d4xbPfJD99SzbRXJzWaHtaHUIA6I0YjbUn+T6C8l0KbCR/Gox Q24Dzbjow7qVvafaiv3DWDKqvRbZ7dS+EwEA7UPdiFSm3WgB4PE= =lJOR -----END PGP SIGNATURE----- --lg5hZyJUuwPKKWjmYRTvTgkhaicfSsvqU-- From nobody Wed Jun 20 13:18:53 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73645130E21 for ; Wed, 20 Jun 2018 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 UBqE0aGQj4yj for ; Wed, 20 Jun 2018 13:18:50 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 1F983130E20 for ; Wed, 20 Jun 2018 13:18:50 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id m194-v6so1483122itg.2 for ; Wed, 20 Jun 2018 13:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=O+a1ps7nKe6cL2VKeZwX/l6Fi+9cMdwuda7TK5k6dB4=; b=JMWOes2f6jK5qDQhPg9kCcUf5yCblwBRJkbFkugsfYDQ6aipCCI6LmQ+tknWHvgHnz fdwlTzvihMVsHbqqQLOuq6wEeWAkFvZZ8Kct4hviJTg1KEFb45fYPMCLhm1JcMf0Xw1p qbVtRgaeVbU4N+goUiHCnjEuc0S8LkqXoTs/w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=O+a1ps7nKe6cL2VKeZwX/l6Fi+9cMdwuda7TK5k6dB4=; b=GqZjPvBFcusaf15JcQIcA/2grWqVXo8irHNRKRtU3w5Lqpl5NHOM4dq3uvysg2a85t 9SmqVAlGzrch5Q/Xk99/arz+ENvTUWY/DV9LI+2bwClVrcRaobDfR8COq5dzR/I2guR8 zP0/zKe51Yven9DUroVHbUUQTWH3R/QIlOxRFKcQ+6k25sR5XSSzmupBbVLneC+HARyL jQNSxRK2bR48ZIpW5q7W6Q6YNsHhRP92MHJ7fWUbj+U2wxFMUhvz8c6whBzdhiBHsJ/q 917JB7DxdM59HVQLpeFy1mg9i2QCOhT5P5piVCT9Zrdhj1N+PezIZCXWHXQAdW88LUOM RAmw== X-Gm-Message-State: APt69E2lHvw2WnUTk4bbjnGApi6hPwkavZyoO9VZqxYxcj/j1B6jEqMU xWvVnBuNcLChg22qFfN2CSv/Lw== X-Google-Smtp-Source: ADUXVKJq6D9Qdqn3vgXGReRr4NKSXKbb+hs3XaEf/+5ytxkxrkdybw6taTNVFU9N5obsuHFXKuuX9g== X-Received: by 2002:a02:105:: with SMTP id c5-v6mr19337340jad.130.1529525929453; Wed, 20 Jun 2018 13:18:49 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id l13-v6sm1196538iob.82.2018.06.20.13.18.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 13:18:48 -0700 (PDT) To: Kathleen Moriarty , Doug Royer Cc: rfcplusplus@ietf.org References: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> <4c4282f9-74d6-6b1d-7613-d57517749dc0@gmail.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Wed, 20 Jun 2018 14:18:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jp0fJNFuVmddsXhwIkpR2qXTG21mOhfqt" Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 20:18:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jp0fJNFuVmddsXhwIkpR2qXTG21mOhfqt Content-Type: multipart/mixed; boundary="972oxViCpVybIMbABOI4F2OZXBNP5Gnry"; protected-headers="v1" From: Peter Saint-Andre To: Kathleen Moriarty , Doug Royer Cc: rfcplusplus@ietf.org Message-ID: Subject: Re: [Rfcplusplus] problems and solutions References: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> <4c4282f9-74d6-6b1d-7613-d57517749dc0@gmail.com> In-Reply-To: --972oxViCpVybIMbABOI4F2OZXBNP5Gnry Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/20/18 9:57 AM, Kathleen Moriarty wrote: > On Tue, Jun 19, 2018 at 7:45 PM, Doug Royer wr= ote: >> On 06/19/2018 05:18 PM, Brian E Carpenter wrote: >>> >>> On 20/06/2018 10:47, Doug Royer wrote: >>>> >>>> On 06/19/2018 12:07 PM, Peter Saint-Andre wrote: >>>>> >>>>> (Just joined the list, sorry about the new thread.) >>>>> ... >>>>> As to solutions, Andrew Malis proposed some clearer boilerplate tex= t at >>>>> the top of each document. Some years ago, we added text like this t= o >>>>> specs in the XMPP Standards Foundation's XEP series, and it helped = to >>>>> educate people who were confused about document status. [1] >>>>> >>>> >>>> Published RFCs can not be edited, so, any "Final Standard" in the >>>> document text will be obsolete at some point. Is this just not kicki= ng >>>> the can down the road a few more years? >>>> >>>> Would it be a better solution to log them with something like an IAN= A >>>> registration? Perhaps grouped by area and protocol. >>>> >>>> Documents intended to be standard would then just refer the reader t= o >>>> the standard registration page that would point to the latest hopefu= l >>>> document(s). >>> >>> >>> We don't need to wake up IANA for this. We already have the STD >>> designation, >>> which for some reason we've never chosen to use for the PS documents = that >>> the Internet runs on. A proposal for this was made 14 years ago: >>> https://tools.ietf.org/html/draft-klensin-newtrk-std-repurposing >>> and not much has changed since then. >> >> >> I used IANA as an example. I don't care if it is IANA or not. A live >> document would be great along with the prohibition of any future RFC c= alling >> itself a standard in its text or Category on the title page. >> >=20 > I like Peter's suggestion and think to solve the problems raised, we > just need to word this type of boilerplate carefully for the IETF > streams. Yes, this is a great bikeshedding opportunity. :-) I suggest that we'd want boilerplate for all RFCs, not just those produced in the IETF stream. Peter --972oxViCpVybIMbABOI4F2OZXBNP5Gnry-- --jp0fJNFuVmddsXhwIkpR2qXTG21mOhfqt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsqtqcACgkQZWGMGH9o FKnugQ/6A4VFJLwbqR6ZYoT6Qi/oeTD0uijN3JXgZl7W4RFthB/kLBLW8xz2qaz/ mBKFwOocRF0QaEMOC6SLRgsVs1FMnxGS2kb2hRXG4HOEflj3qnHOFeU/46kuDVSd SxdsvLlnp205QnlNPffscxfx9cX1UomW+bZo1JMnTKqcZWwztnsEjokC/9BjyZxf cxFjhCM11n+6UfsAX/pYcxq55LNZxUA+DhZhKnaKdfciBN08ZVvjhxytqDB1/vpB e4w7UgugU8giKzD3f0QBf5oYJPQEjptiR3/KmCBIRUmB0PURSKw3fXXs0NmoufvM VUTDE+A6vL9eG+lgkMyqiBRzyd96xa9RsQlTvHAySiT4sPfKG5JaaE1DEV+juPbJ HgsC2CuqCfYnB/pXBzJCePr5CHIs05tEdSbwE8zpH8oZmtHEEIq7kaEbeVN0zi+V gihyov/CODHFgwV53lPuGx/iAdvfs49FS5c3cdYih7LdKMy71NVqhN1XvrBd42Sy MrY/XKyLD8OhOCPhAIKLuZ6RU5N843E3+EIV4ZUb9dtEg4rGj6JXyJqPYw8G1uxw IYzx6KVETZclsg0ppzPwqezYacNVk5e8f7wugxI1FW5pMQwfEFSIsFtpCFcnJosF eTQuWQudt8aUU+Fjuo2UyTD01d+FYDv6TtUHlkXamh0FNzKURYI= =T/cZ -----END PGP SIGNATURE----- --jp0fJNFuVmddsXhwIkpR2qXTG21mOhfqt-- From nobody Wed Jun 20 13:32:40 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE85D130E20 for ; Wed, 20 Jun 2018 13:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VAzKXZ9t0EZa for ; Wed, 20 Jun 2018 13:32:36 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 2363A12785F for ; Wed, 20 Jun 2018 13:32:36 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id x4-v6so793215wro.11 for ; Wed, 20 Jun 2018 13:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=alXWf9O6wHUyMVUr1H8sNXMxbRjueirGU45hNI/GyLs=; b=GuWS86gCTIqK88tg4OTtSjNw8ZvRWj02NBxQavcK4kfDOqEwYQTN48RswScqZGtun0 NKC9jRTzi3wX3SzWaN0t6wd6ogfrYsgaV+OFK/PIpwB9Ax5ZKLhtPhfuS+egZikfDKz0 n7jAtFsE199xg1ufoJJrwTIWvben37OrUx9cC/StVcVBOBVPOXxiNXspaTEMYUled7am vg7/jSbA2VNDByRSutKD06Tmu4qfzKQumwXNnqxn0kzzRo8Izyf8ICsEFgaqwPdfkbm0 B2RKV1AssBJiwGh8bR9bKftSOa2uWSzr+uUrROERsA0rXwqFDGGHS8lqLoX6bUulCdTZ YjWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=alXWf9O6wHUyMVUr1H8sNXMxbRjueirGU45hNI/GyLs=; b=THPXeElH5XfVMXLkYdcY0cLSfVwVuv0cQ0RUQry6I7cCkLtAojGDZF4XpoqrbKwReP Pj+I6mPDQKMCvbPcVwqMlQ2pF2wkbbg2tdoK6U9u1PxkDRzHn4YMBlGtyxnERaFAj96L GFqDd2XqpM1AfVbNSbFZ+soN5lrOUGFjfVvaZLSrtHvW+5JFzrMDIgAqmNRzdCrxF5OL r3QeFJUL0Y4Pb8k7PfXHaxtiiIzxwTSd3fqwSLxWkLIPzzkz77s11fTPczWumbggko9M ISGoPrUeCv8qxWZWkNT6NiT/TpGCCitHb+5oCTIj8xipjFc44Me4VR8Aa7BYlDm4jht7 BKMA== X-Gm-Message-State: APt69E2KYISU0fClQN+sjBC6mHZW83tOR9TPGTaHKenXIh5SUyfMftV7 hhCMHD1zVgaF6LKi7QKMPzqfcjFR X-Google-Smtp-Source: ADUXVKIAFpnEfDJ6gqmTFgxgigy7yiGLMhq9UGXJdaTbk2J59tBd6yTWAW/ErAYosgCz4TXtkTK9TA== X-Received: by 2002:adf:fe4c:: with SMTP id m12-v6mr18396330wrs.171.1529526754458; Wed, 20 Jun 2018 13:32:34 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c11-v6sm4523513wrm.65.2018.06.20.13.32.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 13:32:33 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_0DFB34B4-4D55-4E71-993F-E121862D27BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1B6A0C86-DC1F-479F-97A2-F1EB18CA0B98@gmail.com> Date: Wed, 20 Jun 2018 13:32:31 -0700 Cc: Bob Hinden To: rfcplusplus@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Rfcplusplus] April 1 RFCs collateral damage X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 20:32:38 -0000 --Apple-Mail=_0DFB34B4-4D55-4E71-993F-E121862D27BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As far as I can tell from reading the BOF description, what is proposed = would effectively end the April 1 RFCs. I doubt the IESG would approve = them, and they wouldn=E2=80=99t make any sense coming from a new series = from the ISE. I am an author of a few of these, and reader of most of them. I think = it would be a significant loss to the community if we were to stop = publishing April 1 RFCs. Are we taking ourselves so seriously that we = have lost our sense of humor? Bob --Apple-Mail=_0DFB34B4-4D55-4E71-993F-E121862D27BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlsqud8ACgkQrut0EXfn u6iOwQgAwx7YpuCRkJsLV8DeBObsi3rWR49Bl7lS6P9i5Y0Ql0jURpnu0AgIoHnu MZqlg7YO42m0aF4ZAg980QPqyhEpMaMJk2/yIoNtYHogP4GkvVqrrZfmcaZFb5gI 0TrqgEyxYx6lAtFDzL+8AmPwNYYQrw6fj7Agt3ZXbc+XSGJgTiJcdhuJ+v53ar6D xN9ynpTKo6ItSieTl/ziGZ8M0fNL3seqf3SOntvyRwrivDjG8u2BHj29A6Je2JWq iOdSivdOxKjM6Q3QJa35ijjEIRmzeibHgwVQKsR/QlLbX+26HnibJdq+/tNblvKj OMTpSw/bC7akL24swfhIIG9M218uIw== =0DWF -----END PGP SIGNATURE----- --Apple-Mail=_0DFB34B4-4D55-4E71-993F-E121862D27BA-- From nobody Wed Jun 20 13:42:13 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C3D1311A0 for ; Wed, 20 Jun 2018 13:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 FCtT4c4BvB2E for ; Wed, 20 Jun 2018 13:41:54 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 5B42B13117B for ; Wed, 20 Jun 2018 13:41:54 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 76-v6so1548258itx.4 for ; Wed, 20 Jun 2018 13:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=/WXQU5MPCBUf8Uv1KvH7Be6F32HkvSCQdny+RbO8jjA=; b=OqeROpelr62c1CPhjfNevnc5B+KsZWVpfhl4Y7NC+siurvE3xz/4AObSSW9xozrmcv WfV4AsqjGl1XFYBfCxJbyeElk9yi7FwDFHpVBJFvRQNKakguKfgQx4E+GISuA2Wf6TrG 236YYMJIw30S7TrkExPUr5PBM3mtYLplYQ/ek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=/WXQU5MPCBUf8Uv1KvH7Be6F32HkvSCQdny+RbO8jjA=; b=AoQjImaiLiGFxwvNrXRPVVy94VYfLX+zGbglFV7nHSE8cI3tMX45NOTwWlgYN/ajDe UOR9VVm/YSLY8pXH98hOi8lyi7TzjsDK+35GijCMNQLMoVHzlg/x8ccTmNXYNb/cqUL3 TRQVAnesz8s0eLjekUVhmK1tpki33hKHdLYTei9ysbwiqu7wiHR9XRFQ7sZiZv+TOk+f g2dXpWG18U+zTfUI7HUU3s+DRG44ZFyQ/KHTWwp4revuuw3CFOkNMwYPIiCOFB6RQ9EO KdliVMPSy5Wq4mtFaCN4BEQWeUjUujKXB3+mhpZkHlbIShIbM1bgKe2PRZ5zKA75yHqv DbJA== X-Gm-Message-State: APt69E3WlNdURp+6gSnAvin+Zt4ckpPOYZgffss+XOck7EmtxqoaZHzG UMvhl9vN7BaMVgZWnYDKcYpNZUgz1Dk= X-Google-Smtp-Source: ADUXVKIWoBkgib5ereh6NOT8h87Bo6fCHCFE2uXDshIaify/33YW8x31s03wLQBtt3tcQi4HLmvtxg== X-Received: by 2002:a24:1d4:: with SMTP id 203-v6mr2684478itk.97.1529527313693; Wed, 20 Jun 2018 13:41:53 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id o20-v6sm1266715ioa.83.2018.06.20.13.41.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 13:41:52 -0700 (PDT) To: Susan Hares , rfcplusplus@ietf.org Cc: adrian@olddog.co.uk, 'Bob Hinden' References: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> Date: Wed, 20 Jun 2018 14:41:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3hbozFVL0LEh1WXKH29VKBmOw36qju1Rg" Archived-At: Subject: Re: [Rfcplusplus] (no subject) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 20:42:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3hbozFVL0LEh1WXKH29VKBmOw36qju1Rg Content-Type: multipart/mixed; boundary="NpV4OzvuZwhOTmwTtS9VlWxBrprPSjeoM"; protected-headers="v1" From: Peter Saint-Andre To: Susan Hares , rfcplusplus@ietf.org Cc: adrian@olddog.co.uk, 'Bob Hinden' Message-ID: <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> Subject: Re: [Rfcplusplus] (no subject) References: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> In-Reply-To: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> --NpV4OzvuZwhOTmwTtS9VlWxBrprPSjeoM Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/20/18 11:04 AM, Susan Hares wrote: > BOF individuals: >=20 > =A0 >=20 > I am a part of the independent editors review board.=A0=A0 Members of t= his > board thought my note to them might be helpful in your discussions. =A0= =A0I > will be attending this BOF. >=20 > =A0 >=20 > Susan Hares >=20 > =A0 >=20 > ---------------- >=20 > =A0 >=20 > Adrian and Heather: >=20 > =A0I've thought a long time before sending in this BOF response.=A0=A0 = I > apologize if it comes late in your thinking cycle. >=20 > =A0The real question is who has the authority over the RFC stream as > editors rather than content providers.=A0=A0 IMHO, the social engineeri= ng > proposed by the BOF goes against the best practices in most excellent > publications streams - that the group gives general guidance and then > trusts the editors (ISE and RFC editors) to do the right thing with > publication. The phrase "social engineering" brings to mind a certain kind of psychological manipulation (cf. "social engineering attack"): https://en.wikipedia.org/wiki/Social_engineering_%28security%29 Was that intended? > The real question is does the IETF want to make clear the categorizatio= n > in the RFC stream it operates on the following categories (we know and > love): >=20 > =A0Agreed by consensus: Standards (proposed, internet), information, > experimental standards, Best common practices, and historical > standards.=20 Those categories are, of course, fairly well-defined in BCP 9. > Published by (ISE) as non-consensus (aka individual) > standards and information regarding standard.=A0=20 It seems to me that the notion of an "individual standard" borders on an oxymoron. > If we do, then why are > we not allowing the RFC editor and ISE Editor to simply do the "right > thing" in making it clear in a different set of publication streams. Would you mind expanding upon your suggestion? I read it as perhaps saying what I understand the BoF proponents to be saying: we might need or want to have multiple output streams (IETF, IAB, IRTF, ISE) to accurately reflect the different natures of the input streams. > =A0Micromanaging excellent people is either done by mistake, by inflate= d > ego, by intent to provide wanton destruction of an > organization/process.=A0=A0=A0 I suspect this statement will be unpopul= ar at > the microphone. Those are rather strong accusations - so far I have not seen anyone nihilistically arguing for wanton destruction. And opening up a perceived problem for community discussion is what we do at the IETF; that's not exactly micromanagement. Peter --NpV4OzvuZwhOTmwTtS9VlWxBrprPSjeoM-- --3hbozFVL0LEh1WXKH29VKBmOw36qju1Rg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlsqvA8ACgkQZWGMGH9o FKmXFhAA0H/ECGponRwsg9slBaEd592XRO8kjpi09VJ2HfjupJr6Ds9cOiScUC4t woSF+j5wa/qFJMcgEztQjYNPH5yfflienfLzMhYAigkUAVAykLUlDmHJI3A7r8Hp 140Q87LtyJBF1npaCbvxJPkmDUE1HueLLnicJkREJ3iNsUN+xQUSX6yWEXqkSAdD Izwdgd3W6UBwsIuXObwnctA9EagEXY5oo38TT91o0DEkYHatCUe/RUjRlUvcpEnl goOfakbwMKmCWQhKJZSSHTyAWO+1bxj8bYJR5NAqmyWWuCT7UIBaVMmlLdNNvZ9S kqN9PbhCORNuBuU/SPGe5pyFS5lSUUlOoz6ZdATIs4/c8nHMnD+TOGSF8/0L67NV R6WjjWTUXutpuzgSiHRaNp2w/Q4TtOa+Rfu7QuGis0pVCLesBYCkU5xz5Eqyusxn A5HIyt/8SAmEcjfDejrMuRoatl1NjwWZg7d5MKxencyHw/T6Ma4AiBvn7pBNhQx1 vWGWspu5ZMV+guNUvHZ2qQZvDK+22sPysqGJlSnpLGTH4EtJ+GsEf5yUX6CZfvEv JfIRZwmNapQWbZPC5zXzOD6oyGLQxH/T6M7+QdhMK/0ddN6U/TEKgOOnDdnW1l7Z qRWUYal9CpVl/KZ+zhH3+6Zem7RNVqobgCCt/tPVR5/rcO79Thw= =HM3B -----END PGP SIGNATURE----- --3hbozFVL0LEh1WXKH29VKBmOw36qju1Rg-- From nobody Wed Jun 20 16:40:10 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4924130E45 for ; Wed, 20 Jun 2018 16:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ysislvJcrbFm for ; Wed, 20 Jun 2018 16:40:05 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (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 687BE130E3D for ; Wed, 20 Jun 2018 16:40:05 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id w8-v6so599104ply.8 for ; Wed, 20 Jun 2018 16:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dnDvqX+qksnMhImSJ4SVl2CzDPSRbl6K8WIDlZxwpwA=; b=gBcWCRdZki0GwItp4xs35jyePt02BK85BYhDAFkJ4iryX+qn3q00hRswXAlSQPBXZg FTvpFI8sfgwWaB3UsM40+l/2080r5nCzwiKs1vnR2cKBGJ4ywKDHPUIujDM6//j1MYKE pjFLdx2MH8g9uTROEvmVA9ybZXq28fpNZNwxrOUaavDFSf9qOZsS0F5ge42amfZ6FKpx nAmdmPa9iJrNAgUyS5iQctmgmax/3q/mDCklBlt31wf3kTsIgSWD8a4W4L5r3RtboA9e sovn2TlZba9yzmvqs82Jzrlpoe7jsw7bc1KS/2mXzl0aWW/NRpFgJ0Lk/2FddJtWjq8G /I8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dnDvqX+qksnMhImSJ4SVl2CzDPSRbl6K8WIDlZxwpwA=; b=moAK/++4bGnuUU8/HddxWGGJCuNHsJ7eW+GXyMUPDqlEHdXFn3zFlxaGxxRnV538cx 7oHC1eh7G9W6PmdCWmwlF2wpqaimEFnvnz/j2p7C/pcEpCn0IRxuhT34t51i1BZojJjH MiKYdxt0JClJY95xl8+4UcG4m3cvLPcvh0w70XyCl/M7IFlMF+V21++fWJpzxHcL15nL +UhnfY6vFTpC37zG/E6AJR3xoT4JYfyFoEiRU5VkRJS3xpKVpH/tfJHQM4zxwB6WhQSn XV9o2jaTe3rUog+LMmBcZf2bWONkn6ldYPVMUZNtwuI2n/uTjBhao3BKsB4P1fSLOS9q Nufg== X-Gm-Message-State: APt69E0T7PDvT4FBu8cjghqxIQfi/feO+oRPa4w/IB+vyjTbkVahTu4c Az4oT/lS0I2zWlPLyReVCe0= X-Google-Smtp-Source: ADUXVKImXvQzpkaZBNuFDqlo86uDaDJLFdlFSa0ZYVGs0+KuHTKFL7HbbUHl9Mc4wrphnuTm0crSQQ== X-Received: by 2002:a17:902:b110:: with SMTP id q16-v6mr25938585plr.286.1529538004819; Wed, 20 Jun 2018 16:40:04 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id x14-v6sm363911pge.85.2018.06.20.16.40.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 16:40:03 -0700 (PDT) To: Peter Saint-Andre , Susan Hares , rfcplusplus@ietf.org Cc: adrian@olddog.co.uk, 'Bob Hinden' References: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> From: Brian E Carpenter Message-ID: <995c9aaa-34d4-e5a1-a8be-c5ac11797db7@gmail.com> Date: Thu, 21 Jun 2018 11:40:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] (no subject) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 23:40:08 -0000 On 21/06/2018 08:41, Peter Saint-Andre wrote: > On 6/20/18 11:04 AM, Susan Hares wrote: >> BOF individuals: >> >> =C2=A0 >> >> I am a part of the independent editors review board.=C2=A0=C2=A0 Membe= rs of this >> board thought my note to them might be helpful in your discussions. =C2= =A0=C2=A0I >> will be attending this BOF. >> >> =C2=A0 >> >> Susan Hares >> >> =C2=A0 >> >> ---------------- >> >> =C2=A0 >> >> Adrian and Heather: >> >> =C2=A0I've thought a long time before sending in this BOF response.=C2= =A0=C2=A0 I >> apologize if it comes late in your thinking cycle. >> >> =C2=A0The real question is who has the authority over the RFC stream a= s >> editors rather than content providers.=C2=A0=C2=A0 IMHO, the social en= gineering >> proposed by the BOF goes against the best practices in most excellent >> publications streams - that the group gives general guidance and then >> trusts the editors (ISE and RFC editors) to do the right thing with >> publication. >=20 > The phrase "social engineering" brings to mind a certain kind of > psychological manipulation (cf. "social engineering attack"): >=20 > https://en.wikipedia.org/wiki/Social_engineering_%28security%29 >=20 > Was that intended? >=20 >> The real question is does the IETF want to make clear the categorizati= on >> in the RFC stream it operates on the following categories (we know and= >> love): >> >> =C2=A0Agreed by consensus: Standards (proposed, internet), information= , >> experimental standards, Best common practices, and historical >> standards.=20 >=20 > Those categories are, of course, fairly well-defined in BCP 9. >=20 >> Published by (ISE) as non-consensus (aka individual) >> standards and information regarding standard.=C2=A0=20 >=20 > It seems to me that the notion of an "individual standard" borders on a= n > oxymoron. True, but probably Sue meant de facto standards. It's worth recalling that the other SDOs we love to hate, such as ISO and ITU-T, for many years referred to the IETF's product as "de facto standards". The Interne= t has a long and successful history of running on de facto standards. I greatly fear that worrying too much about what is or isn't officially blessed as a *real* standard is a clear sign of both hubris and ossification in the IETF. Ultimately it doesn't matter, I suppose, because if the IETF ossifies, some new thing will appear to produce the next generation of de facto standards. >> If we do, then why are >> we not allowing the RFC editor and ISE Editor to simply do the "right >> thing" in making it clear in a different set of publication streams. >=20 > Would you mind expanding upon your suggestion? I read it as perhaps > saying what I understand the BoF proponents to be saying: we might need= > or want to have multiple output streams (IETF, IAB, IRTF, ISE) to > accurately reflect the different natures of the input streams. I don't know Sue's answer, but mine (as noted in my draft) is that it doesn't really matter how large and bright we make the labels on the documents, because the underlying problem (if there is one) is human nature. That said, I strongly support using the new RFC format to make the labels larger and brighter. >> =C2=A0Micromanaging excellent people is either done by mistake, by inf= lated >> ego, by intent to provide wanton destruction of an >> organization/process.=C2=A0=C2=A0=C2=A0 I suspect this statement will = be unpopular at >> the microphone. >=20 > Those are rather strong accusations - so far I have not seen anyone > nihilistically arguing for wanton destruction. And opening up a > perceived problem for community discussion is what we do at the IETF; > that's not exactly micromanagement. True, but there are very deep reasons why the current *intentionally modest* designation of all IETF, IRTF and IAB output as requests to the wider community for comments has persisted for 50 years and resulted in a pretty robust network out there. It wasn't an idle choice of name for the document series, and it shouldn't be casually discarded. Brian From nobody Wed Jun 20 16:51:42 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79023130E46 for ; Wed, 20 Jun 2018 16:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 o93g0aynTiT6 for ; Wed, 20 Jun 2018 16:51:37 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 D76AA130E3D for ; Wed, 20 Jun 2018 16:51:37 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id w7-v6so555956pfn.9 for ; Wed, 20 Jun 2018 16:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Fv/oRpvRzX6vgG+636nCIVYNee6ZIGeMRMa4ognSi0A=; b=GuMVjyWhHfsIhQ7zkiWykX56O5J0uop1iNqPC1zUM2kdxY/MfBPRmA0mDOEB4umLJK +d8hQDOQBtUJgea4Q6v8soYqBpd76sAbD4mqfzAPemcHqWuswYsqrex6urFrsBi1+PsV 9EI8W2BjS0LizMRmjF4SIN+UoD+rypP9gv2/c+RtLqsouqv8GKxeb81z+sA4FMOKZjRy /AmliFV5cmvmnXWolnJrl6ObF1UHBeGaIMT95cQ8+t23y3fA1QIoFKQwQIO8xBpoMDse WZnin2jzReIg8rTfEfm05X36N+5QZ6DZavH9TQm2iGJj9RTOKuHodXTJtr+16VDQO95Z K22w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Fv/oRpvRzX6vgG+636nCIVYNee6ZIGeMRMa4ognSi0A=; b=oHo4n20dV2UoopOIA/mSG2Xl/cJ64lZgv8Nt6pxdj8vpd4J6JJt9hEaI+d5mBjvKDV hc3oD6f0jtOHh2ViMcRzAc9Znt9I79gTz1fzctguNPsbi58+uRBRLDVz04ygAf8Q2acq jXNXm4DNK82BqopJy2rrDJc5IBwxv6J80lcO4cP6lcqU6N5flsbleIqJXT3FK2EtxWEK USQJkQLXWSrbJN5ThacNNyv2/iSvHAcAy708fSCZGpj7eHRZUwnDmOdqjHkoC0IsBktc sR0tz506NqxyMfBm70dLremF3AboBA6uZ90Zp4WemdX+wLdD1Ft3EJ4/qB9AwKRUNKPo v0Tg== X-Gm-Message-State: APt69E2DQvQx5hUUZRC8f4Fb+p/cwRppGjG3yX03wPC2lxWCKdfrWMB8 JMARzUkrC0ZeaHLJLf0mBZ2LwQ== X-Google-Smtp-Source: ADUXVKLq0ACr0e1YDw0ubpo000t6F6pjbAejB2HqMo6qsJISBvg0hzUT/vJF3X91AyMkRG6i5YaB2w== X-Received: by 2002:a63:7b07:: with SMTP id w7-v6mr19806549pgc.199.1529538697056; Wed, 20 Jun 2018 16:51:37 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id x5-v6sm4941765pfh.67.2018.06.20.16.51.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 16:51:35 -0700 (PDT) To: Peter Saint-Andre , Kathleen Moriarty , Doug Royer Cc: rfcplusplus@ietf.org References: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> <4c4282f9-74d6-6b1d-7613-d57517749dc0@gmail.com> From: Brian E Carpenter Message-ID: <78f156f0-19de-5123-0f21-ec618c08da93@gmail.com> Date: Thu, 21 Jun 2018 11:51:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 23:51:40 -0000 On 21/06/2018 08:18, Peter Saint-Andre wrote: > On 6/20/18 9:57 AM, Kathleen Moriarty wrote: >> On Tue, Jun 19, 2018 at 7:45 PM, Doug Royer wrote: >>> On 06/19/2018 05:18 PM, Brian E Carpenter wrote: >>>> >>>> On 20/06/2018 10:47, Doug Royer wrote: >>>>> >>>>> On 06/19/2018 12:07 PM, Peter Saint-Andre wrote: >>>>>> >>>>>> (Just joined the list, sorry about the new thread.) >>>>>> ... >>>>>> As to solutions, Andrew Malis proposed some clearer boilerplate text at >>>>>> the top of each document. Some years ago, we added text like this to >>>>>> specs in the XMPP Standards Foundation's XEP series, and it helped to >>>>>> educate people who were confused about document status. [1] >>>>>> >>>>> >>>>> Published RFCs can not be edited, so, any "Final Standard" in the >>>>> document text will be obsolete at some point. Is this just not kicking >>>>> the can down the road a few more years? >>>>> >>>>> Would it be a better solution to log them with something like an IANA >>>>> registration? Perhaps grouped by area and protocol. >>>>> >>>>> Documents intended to be standard would then just refer the reader to >>>>> the standard registration page that would point to the latest hopeful >>>>> document(s). >>>> >>>> >>>> We don't need to wake up IANA for this. We already have the STD >>>> designation, >>>> which for some reason we've never chosen to use for the PS documents that >>>> the Internet runs on. A proposal for this was made 14 years ago: >>>> https://tools.ietf.org/html/draft-klensin-newtrk-std-repurposing >>>> and not much has changed since then. >>> >>> >>> I used IANA as an example. I don't care if it is IANA or not. A live >>> document would be great along with the prohibition of any future RFC calling >>> itself a standard in its text or Category on the title page. >>> >> >> I like Peter's suggestion and think to solve the problems raised, we >> just need to word this type of boilerplate carefully for the IETF >> streams. > > Yes, this is a great bikeshedding opportunity. :-) > > I suggest that we'd want boilerplate for all RFCs, not just those > produced in the IETF stream. s/boilerplate/updated boilerplate/ We already have stream-specific boilerplate, so you must be referring to re-bikeshedding it. If there's a problem today, it proves that people either do not read or choose to disregard the current boilerplate. I don't really see how that will change if the documents are split into "Requests for Comments" and "IETF Edicts", or whatever the new ones would be called. If the RFC did a better job of describing what their customers wanted, the vendors would implement the RFC instead of the Edict. Brian From nobody Wed Jun 20 19:24:36 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EC513103C for ; Wed, 20 Jun 2018 19:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 tU5M0PYO50zX for ; Wed, 20 Jun 2018 19:24:18 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 9E203131012 for ; Wed, 20 Jun 2018 19:24:18 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w5L2OFk9019698 for ; Thu, 21 Jun 2018 03:24:15 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A15702203A for ; Thu, 21 Jun 2018 03:24:15 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 8C30322032 for ; Thu, 21 Jun 2018 03:24:15 +0100 (BST) Received: from 950129200 ([184.81.92.59]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w5L2ODx2022098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jun 2018 03:24:14 +0100 Reply-To: From: "Adrian Farrel" To: Date: Thu, 21 Jun 2018 03:24:13 +0100 Message-ID: <051d01d40906$f2e5b0a0$d8b111e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdQJBukdxg2kjOScQXiBxV+1yGH/Ag== Content-Language: en-gb X-Originating-IP: 184.81.92.59 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23920.004 X-TM-AS-Result: No--17.592-10.0-31-10 X-imss-scan-details: No--17.592-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23920.004 X-TMASE-Result: 10--17.592100-10.000000 X-TMASE-MatchedRID: 0YPC3G6Huly6lIBLPjRk6T1DLc/yBifY45DaLqXoDrLpwKubFPziovdQ 3ETtBTk8sGtyKrCR3DGvcDneGBEyWZb5x/qcSShKtqLtKRVDGDlA8JZETQujwr8n+6cRYLu8j+v Rrcokg+V0w+0DaaVgyvhWSnHooF/yD4znV4WzAa7ThGbP9qB93BC26qzoFs8nFp7kniXxovPImJ UezF9c+I+pAn19BHXOocqM/C4V1Ta7JfBr9Xl5CuBwaWMnkCdnGSqdEmeD/nUNXfxUfMGYaGgza 1s8LhU4HYsp0E+BDecjWj2NzptCUagQOuSjPsjIwCZxkTHxcckaJDwYgQY/f5mYMJy8tkdLi93e iI6kEc1quEx00+0cdwXvegw5s3+5fu2IDPs/Er3v9TsmYymKIY+YVJqrrEz4c7nSUtJ5mt7y67H GlbS8BIGZs2vG7od/ast1POi0OWkT6F/I3FhqMLE3FpMbg63Se7Z0UyQO5TMj/BgXooqgw3Jbm0 9q85zvIdCH4bmy/g9JZQHHGVmVR/v56LnPzk3y7DzBuedLDxujL8htRuVF2iS30GKAkBxWP3gdf biCq0LznpZ1LFrvCIVOjT1T8KvPUv4rCBFxg7/8sslxtZarKB9fNWA7SFWq/ZNsWvQIY4OUW6E/ Bpf7EpsKHIHEUsdhfXxjffS+mRsBuGJAWqomlamukiZOfPi2bYoYNIScYY6bKItl61J/ycnjLTA /UDoAxpQ77C1A1tqOhzOa6g8KrZRMZUCEHkRt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfcplusplus] Apocrypha and Other Herrings X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 02:24:30 -0000 Hi, I wanted to pile in on the lengthening list of anecdotal stories relating to "confusion" about what is and is not an "RFC of merit". Companies and their marketing machines will portray documents in any way they see fit. At the moment we label things as RFCs and the company is tempted to say or imply that all RFCs are equal and carry full IETF blessing. Many companies have done this at one time or another whether through disingenuity or confusion. But changing labels will at best only have a partial beneficial impact on this - if I can call black white, then you renaming black to red will not stop me calling red white. It is certainly true that all sorts of RFCs show up in procurement specs. I recall the RFI that asked whether our software implemented RFC 2119 (I think we responded that it SHOULD do). But actually, anything might turn up on an RFI: I have seen RFCs of any maturity and level, plenty of Internet-Drafts, and assorted other documentation. Also plenty of undocumented requirements. And do what? Sometimes this is a good opportunity to engage with the customer; other times it simply is a statement of what the customer wants implemented and the maturity or documentation level is not relevant. There are no Internet Police in this theatre and no one proposes changing the label of an Internet-Draft just because someone is "confused" about its status. We might observe further that individual contribution Internet-Drafts are sometimes perceived as being IETF work. This confusion spreads through the whole community although may be seen most among newcomers. We've had some sticky moments in our relationships with other SDOs as a result of such drafts being assumed to represent IETF opinion. But no one seems to be suggesting that we change the filename or labels of such drafts. Additionally, we should note that the IETF has published one or two poor ideas as Standards Track RFCs over the years. No blame attached to anyone, but sometimes the RFCs are not implementable, sometimes they lack sufficient detail to achieve interoperable implementations, sometimes they have bugs (often well known, but rarely written up), and from time to time they describe protocols that will never be coded let alone deployed. The Internet Standard numbering system does address this, but the reluctance that we seem to have to push work to full standard has kept the number of such documents quite small. Furthermore, as was noted elsewhere, this numbering system is neither well understood nor widely used. Now, in all this I want to suggest a little more rigour. Not only should we try more carefully to articulate the problem being addressed, but we should try to understand the experiment that is proposed. Any experiment must have measurable outcomes to be in any way valid. It seems to me that this experiment as designed can only determine whether it does measurable harm in any as-yet-unknown way: it cannot measure any benefits. This can be reasoned as follows: - There is no quantified statement of the problem. What harm can actually be shown to be being done? How damaging is that harm to how the Internet works such that this experiment can be examined to see whether it has successfully "made the Internet work better"? - There is no attempt to address the existing cannon. But in the 3 years the experiment is supposed to run for we can expect around 230 new documents per year (thus around 700 over the 3 years) in what is currently the whole RFC series. That will represent 7.5% to 8% of the total documents (RFCs and RFC++ documents) ever published. Presumably, therefore, over 90% of whatever problem is believed to exist will continue even at the end of the 3 year period. That would make the proposed change very hard to measure. Only by changing the labelling of existing RFCs could we expect to see a properly measurable change. Thanks, Adrian PS. Please note that I am in a somewhat delicate position contributing to this discussion. I hope it can be clear that as ISE I serve as appointed (or removed) by the IAB and strive to deliver according the current definition of the Independent Submissions stream and the documented duties of the ISE. If those definitions change and I continue to serve as ISE I would strive to deliver according to the new definitions. The opinions expressed in this email are my own based on several years in the IETF and time developing and selling standards-based networking products in the wider community. From nobody Thu Jun 21 06:25:05 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A22F130E3B for ; Thu, 21 Jun 2018 06:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 AGdeJASCW_yB for ; Thu, 21 Jun 2018 06:25:00 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7168D130E2B for ; Thu, 21 Jun 2018 06:25:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 9BB9E1CAE0C; Thu, 21 Jun 2018 06:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCkq-9g-QodD; Thu, 21 Jun 2018 06:24:54 -0700 (PDT) Received: from www.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 369CE1CAE09; Thu, 21 Jun 2018 06:24:54 -0700 (PDT) Received: from 12.49.238.142 (SquirrelMail authenticated user rfcpise) by www.amsl.com with HTTP; Thu, 21 Jun 2018 06:24:54 -0700 Message-ID: <376dcfaa970fc1bb23e71b83472df25c.squirrel@www.amsl.com> In-Reply-To: <78f156f0-19de-5123-0f21-ec618c08da93@gmail.com> References: <95d4daa6-53b0-689a-0d00-f3fc9ea4d556@gmail.com> <4c4282f9-74d6-6b1d-7613-d57517749dc0@gmail.com> <78f156f0-19de-5123-0f21-ec618c08da93@gmail.com> Date: Thu, 21 Jun 2018 06:24:54 -0700 From: "RFC ISE (Adrian Farrel)" To: "Brian E Carpenter" Cc: rfcplusplus@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: Re: [Rfcplusplus] problems and solutions X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 13:25:03 -0000 This ISE would not be opposed to a change in prominence and content of streams boilerplate if anyone believes that would make them feel less uncomfortable. Maybe a little bit of a shame that it is only two years since 7841 and possibly not enough people paid attention at that time (given that the claim is that the problem is long-standing), but we're engineers, so if something is broken, it should be fixed. Adrian >>> I like Peter's suggestion and think to solve the problems raised, we >>> just need to word this type of boilerplate carefully for the IETF >>> streams. >> >> Yes, this is a great bikeshedding opportunity. :-) >> >> I suggest that we'd want boilerplate for all RFCs, not just those >> produced in the IETF stream. > > s/boilerplate/updated boilerplate/ > > We already have stream-specific boilerplate, so you must be referring > to re-bikeshedding it. > > If there's a problem today, it proves that people either do not read > or choose to disregard the current boilerplate. I don't really see > how that will change if the documents are split into "Requests for > Comments" and "IETF Edicts", or whatever the new ones would be called. > If the RFC did a better job of describing what their customers wanted, > the vendors would implement the RFC instead of the Edict. -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Thu Jun 21 08:41:48 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F172130DF3 for ; Thu, 21 Jun 2018 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Lnt-H-Er8SaQ for ; Thu, 21 Jun 2018 08:41:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2656130EE3 for ; Thu, 21 Jun 2018 08:41:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2862920090 for ; Thu, 21 Jun 2018 11:56:00 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C49DF177D for ; Thu, 21 Jun 2018 11:38:40 -0400 (EDT) To: rfcplusplus@ietf.org References: <152825497269.19360.8656508092644282096@ietfa.amsl.com> <892d73a0-b069-79c7-9fd9-ef8be07bbf61@gmail.com> <25f6487b-854c-beb0-b18a-e573628325f0@gmail.com> <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> From: Michael Richardson Message-ID: Date: Thu, 21 Jun 2018 11:38:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <2beb4024-4762-a9c0-a64a-b9e856d60d2d@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:41:46 -0000 On 07/06/18 01:22 AM, Adam Roach wrote: > On 6/6/18 3:33 PM, Brian E Carpenter wrote: >> Better labels are a good idea, within that series, for sure. > > > As a thought experiment (and taking care to note that I am not proposing > this, merely laying it out as a hypothetical): Would you be opposed to > the prospect of issuing no further documents with designations of > RFCXXXX, and instead starting the numbering over with, say, RFC-S0001, > RFC-B0001, RFC-N0001, RFC-I0001, RFC-E0001, RFC-R0001, and RFC-A0001 for > "standard", "BCP", "informational", "ISE", "experimental", "IRTF", and > "IAB", respectively? I think that this has some merit. I don't think it solves the STD 7 vs STD 3 problem that Spencer mentioned, which I think perhaps is a more fundamental problem that we haven't solved yet. It does solve the RFC9999 problem :-) From nobody Thu Jun 21 11:40:54 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8751310CA for ; Thu, 21 Jun 2018 11:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vo5RosyabuYh for ; Thu, 21 Jun 2018 11:40:47 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 7131913110B for ; Thu, 21 Jun 2018 11:40:39 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id c22-v6so1952281pfi.2 for ; Thu, 21 Jun 2018 11:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Pgqd44x4TVCVRs7Vg0qXNfHRPdwCfrECtYmQcQ8UZbs=; b=Y1eDAx6Es9K24x5Uh/q09VN8drCWeI257bDerSgdlVxkazh9PzQ0r9mrdBCIshLY44 Ad/9DUmhmYnyNtnO3yLlQB/GVxTwTmFFGLkgjhWuxINgBTWK6r3w4TP4ft1Vb9ZPxJxe 9n6X/pRdnmB7T4pCtWhmV1JZxFQxeY4Jv8sG8/w9mTYKTsmzsNZvciCTIjqdiC92pE/6 lhtmSlYUPp4t/7ijSFpVXgN1cpFj1zaHvnWg/KqezqJaY4p+cwjcS8kfvokkveuek5+T Twy2ySRbDDd862kuk71EDVuzX3Zy40IrF3uP/rGQxMAf4F9P9UkfgHXkak/MVTa0HK52 uIfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Pgqd44x4TVCVRs7Vg0qXNfHRPdwCfrECtYmQcQ8UZbs=; b=VdV9clCEf8QQa8JnWeT134iibolTpGhtWGClaOn90BckpUIsOCgy8hW6fyJFWfoONe 5BMsytCfPti3duD92PMqQZJrTZIblflaitXQJqMn8EbgnhEXxBn04GHMYghMePqBKGYG fMQJYflFVQUpuPn5LTNy6Bc1KHQj6cOr290/rr1qzuMvAj6OmOo6X+ZRwTD8J6RxvGYw o2QFnNIZ7bqkth+P/EbzD9Y6yfq3OOqDnFczcgRIzh/km5EYvwrlAjIB1fbFAbAIDnhA EWcsfbYtq0bOz4UI5l4xgm1nhoZNJHFdjCYiNLyMHq7feTJDvVo4Irly7Vx/inSIzxIK 2LZg== X-Gm-Message-State: APt69E0xlZB2zUlv/SN410cwSZZlFWiMSAb9RY6f52RlSpG1oU6KNv90 U/uXnvVGE4yFIlqscu2Lo9U= X-Google-Smtp-Source: ADUXVKJtFXB89dqLldJhKY0iJpbBtCe0H16UNmsmYF7bDA/s/sizXwzOZ1Jk24zoRqCwGsDce/WQQg== X-Received: by 2002:a62:701:: with SMTP id b1-v6mr28704514pfd.252.1529606439052; Thu, 21 Jun 2018 11:40:39 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id x5-v6sm8300271pfh.67.2018.06.21.11.40.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 11:40:38 -0700 (PDT) From: Bob Hinden Message-Id: <19BA68C8-1401-4178-A137-25AA8EFF5973@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9D03F351-58D5-4E27-A1A2-CE5B5750E742"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 21 Jun 2018 11:40:36 -0700 In-Reply-To: <995c9aaa-34d4-e5a1-a8be-c5ac11797db7@gmail.com> Cc: Bob Hinden , Peter Saint-Andre , Susan Hares , rfcplusplus@ietf.org, adrian@olddog.co.uk To: Brian Carpenter References: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> <995c9aaa-34d4-e5a1-a8be-c5ac11797db7@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Rfcplusplus] (no subject) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:40:54 -0000 --Apple-Mail=_9D03F351-58D5-4E27-A1A2-CE5B5750E742 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Jun 20, 2018, at 4:40 PM, Brian E Carpenter = wrote: >=20 >=20 > I don't know Sue's answer, but mine (as noted in my draft) is that it > doesn't really matter how large and bright we make the labels on the > documents, because the underlying problem (if there is one) is human > nature. That said, I strongly support using the new RFC format to make > the labels larger and brighter. >=20 I think that=E2=80=99s an excellent suggestion. We will soon be able to = use the new formatting tools to make the status of the document much = clearer. I think that much better than attempting to start new number = series for each type of RFC, which I think will only cause more = confusion to the community of people us use the RFC series. Once we decide how to do this using the new formats to do this, I = suspect we could change the tools that create html and PDF from the = existing base of txt RFCs to make them similarly make the status much = clearer. This approach will do something with the existing RFCs, = nothing in the current BOF proposal does that. Bob --Apple-Mail=_9D03F351-58D5-4E27-A1A2-CE5B5750E742 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlsr8SQACgkQrut0EXfn u6hRNwf8DLiyhH5ZWTIe9ayBJbPM3roP5vxCWcg43KiMTyOvTENdn0Z+Warojq1w J45n/umls0R9jIhYcKpqyTIpkGR8xylvffK8Q25kVV3aKPNWURJAPqL4Zj1J9l/8 XU/Achiqql0KNUnB5F4RtBY9OHA4fmuBM6ZUNNJ+OxOkUg/4vqiiSajgSBU0p/rE iSzCCAnZUlXI+B+TRXPPa/YBDTa2DeLvWS4bJLa1sHQagfP0lDwHrc0f1YBZa4/6 6OdolQtAA1PsRzlqvrbRF8RQtuZUcLdgT/rfc+u1vFnaRCDrbH/rGTeGLM3RvX+V c/cAdvqAulkVBG3rqhTRLX8F1Kj3cA== =WpnY -----END PGP SIGNATURE----- --Apple-Mail=_9D03F351-58D5-4E27-A1A2-CE5B5750E742-- From nobody Thu Jun 21 11:57:30 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E978713123F for ; Thu, 21 Jun 2018 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Z2o4BU_Impq6 for ; Thu, 21 Jun 2018 11:57:03 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B27131105 for ; Thu, 21 Jun 2018 11:57:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 26E591C392C for ; Thu, 21 Jun 2018 11:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM4jVoy4TsLU for ; Thu, 21 Jun 2018 11:56:57 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [IPv6:2603:3023:30a:e7e0:8c2b:2c01:1597:ebb7]) by c8a.amsl.com (Postfix) with ESMTPSA id ECFC11CADDF for ; Thu, 21 Jun 2018 11:56:56 -0700 (PDT) To: rfcplusplus@ietf.org References: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> <995c9aaa-34d4-e5a1-a8be-c5ac11797db7@gmail.com> <19BA68C8-1401-4178-A137-25AA8EFF5973@gmail.com> From: "Heather Flanagan (RFC Series Editor)" Message-ID: Date: Thu, 21 Jun 2018 11:57:02 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <19BA68C8-1401-4178-A137-25AA8EFF5973@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfcplusplus] (no subject) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:57:13 -0000 On 6/21/18 11:40 AM, Bob Hinden wrote: > Brian, > >> On Jun 20, 2018, at 4:40 PM, Brian E Carpenter wrote: >> >> >> I don't know Sue's answer, but mine (as noted in my draft) is that it >> doesn't really matter how large and bright we make the labels on the >> documents, because the underlying problem (if there is one) is human >> nature. That said, I strongly support using the new RFC format to make >> the labels larger and brighter. >> > I think that’s an excellent suggestion. We will soon be able to use the new formatting tools to make the status of the document much clearer. I think that much better than attempting to start new number series for each type of RFC, which I think will only cause more confusion to the community of people us use the RFC series. > > Once we decide how to do this using the new formats to do this, I suspect we could change the tools that create html and PDF from the existing base of txt RFCs to make them similarly make the status much clearer. This approach will do something with the existing RFCs, nothing in the current BOF proposal does that. > > That has been one of my expectations, that after we had a bit of experience with the new format that we could discuss if and how to use the new CSS to modify the look of different statuses and/or streams. The W3C has some experience with this, though they go as far as to have different CSS for everything from drafts to Recommendations and every possible point in between. There are several ways we could approach solving for the confusion problem(s). I'd rather make sure we're clear on the problem(s) before diving into any particular solution. -Heather From nobody Thu Jun 21 12:01:10 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745B1131246 for ; Thu, 21 Jun 2018 12:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 0Ord4qpXpdNQ for ; Thu, 21 Jun 2018 12:00:59 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 20FDF131261 for ; Thu, 21 Jun 2018 12:00:56 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id c131-v6so2378027qkb.0 for ; Thu, 21 Jun 2018 12:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=PoX98rzuu4TeQMHtoEy7aKYarqoHWQgZsaFpfLuM/dU=; b=mXfTvoOKMh30N81tF7WMIMy2h6vgK8MrqRiFwmR6XAKmusCdQfOQgYv6Q9Nnhw2RML 4Ktcs5S6+bxLEMY+npos0keI71ao394ADGc5fAqC1aD8/TNXun9LkT+FHyOm9ZBpQ2Jo Y+/Y7vZkyRjZvwOYCa1b24hITHVMfinvTDoo41w8/5XeI3oVCuulY4AfRbEBE/+tukMl SuSDmR+PiiUjKWJqjAFfyeA03SllYQmxmbsJQIn9xVBD9LBtThZpCXNPsFnaYpPFkh3B pzAFVX9WwKwzxwDsySSBu/UiIrmJF1SSQT5PDngXn89fZj1ucepdPg8JbWfl5qotJ6SX W3vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=PoX98rzuu4TeQMHtoEy7aKYarqoHWQgZsaFpfLuM/dU=; b=humrrQJU0djhOXG6/esmkVVFoBZiIdPB5DbSfxKnMMcye18I0qEOKANXC2gsujTmlv O4dmlf7tDUheY81z5cE743qgtMGSa+KLh75zMCy65OFafjlO/kOz/3bMmosW+ahl+EQM v7ZqWGSn+bzvzfKEkZAW5w+eRBvFPr7A+0mbUNhKR3Q0u/l8haAxbUBZq4XYsPM4f/+c 9OL9Z26sOcJN/WCYsH2XYO+K60B2Y8feYdE2C3G6O/BVaLqMlc3JjM8NDxkb/FTgK3bi qw776kq4gAqaHT/u/mcrx1Fg66I8GpP5R/RiA1/RZkWhZjuOsMBljnVBhANBK4aQprzO KY1g== X-Gm-Message-State: APt69E2oycs68248PYQoAUnQHnp671lpHr2Eg6T+TcOQoehBsHGD93fI jAcWRlfEGKxSY/IVMlwwior6Oc3t X-Google-Smtp-Source: ADUXVKKbJ7YjeCjSJceLWSf0FNpmtDuNd8yUL+Xr4uUjJ8EwPjZM3FOfkg1z138t1MGfqH0HM5RJgQ== X-Received: by 2002:a37:c0c5:: with SMTP id v66-v6mr23370099qkv.194.1529607655059; Thu, 21 Jun 2018 12:00:55 -0700 (PDT) Received: from [172.19.36.45] ([2001:4878:a000:3000:e468:d5bd:bb72:eb78]) by smtp.gmail.com with ESMTPSA id g57-v6sm4046397qte.52.2018.06.21.12.00.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 12:00:54 -0700 (PDT) From: "Aaron Falk" To: "Heather Flanagan" Cc: rfcplusplus@ietf.org Date: Thu, 21 Jun 2018 15:00:52 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: References: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> <995c9aaa-34d4-e5a1-a8be-c5ac11797db7@gmail.com> <19BA68C8-1401-4178-A137-25AA8EFF5973@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B5DFE98B-06DD-46C8-933C-7F37B521A9D8_=" Archived-At: Subject: Re: [Rfcplusplus] (no subject) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:01:09 -0000 --=_MailMate_B5DFE98B-06DD-46C8-933C-7F37B521A9D8_= Content-Type: text/plain; format=flowed > That has been one of my expectations, that after we had a bit of > experience with the new format that we could discuss if and how to use > the new CSS to modify the look of different statuses and/or streams. > The W3C has some experience with this, though they go as far as to > have different CSS for everything from drafts to Recommendations and > every possible point in between. > > There are several ways we could approach solving for the confusion > problem(s). I'd rather make sure we're clear on the problem(s) before > diving into any particular solution. > > -Heather simple: if $RFCTYPE = "IndSub" then { font-color = "white" } --=_MailMate_B5DFE98B-06DD-46C8-933C-7F37B521A9D8_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= br>

That has been one of my expectat= ions, that after we had a bit of experience with the new format that we c= ould discuss if and how to use the new CSS to modify the look of differen= t statuses and/or streams. The W3C has some experience with this, though = they go as far as to have different CSS for everything from drafts to Rec= ommendations and every possible point in between.

There are several ways we could approach solving for the confusion proble= m(s). I'd rather make sure we're clear on the problem(s) before diving in= to any particular solution.

-Heather


simple:

if $RFCTYPE =3D "IndSub" then {
font-color =3D "white"
}

--=_MailMate_B5DFE98B-06DD-46C8-933C-7F37B521A9D8_=-- From nobody Fri Jun 22 19:11:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DBA130DC3 for ; Fri, 22 Jun 2018 19:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=d72bg19r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p92i6pIL 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 g4a8Fpd-MzZl for ; Fri, 22 Jun 2018 19:10:57 -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 97DDF130934 for ; Fri, 22 Jun 2018 19:10:57 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E7A2921AE1 for ; Fri, 22 Jun 2018 22:10:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 22 Jun 2018 22:10:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=lbV/WLKMvWTGmxZhWKVCCLxiLEuwSpVTYrk/MPr9XXQ=; b=d72bg19r SjL48cNdJIJ6DH9O2B5i7pNKv+HJsCBqIuwupcU6vC4lDSfio0XNlWqyOFjV7HcF 5s9b9z7LTuQM0+RyBn6cJUqSIFnh+biCj+UUFh2nrQtFDangZJIWdptP1O+84l6O ZWe1QNUmMBRJxWtz+M3OHtihNd2RUmxi8se39aNBkY5jvAAboVyVfQJKuFVa+Sq+ qJx+koKHfrGc4zoDrGs+zJsFeUsTY385zkVyykjuanPuj/a/3cX7p3/D9htwFvDW YSEdtFgvwxe3ckYzjGc+HCuC7K/Z5IppQ+f7SaYTyTDnlggRPxEplPMNG23W99jk w2u4Br+gAma3Qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=lbV/WLKMvWTGmxZhWKVCCLxiLEuwS pVTYrk/MPr9XXQ=; b=p92i6pILYncQFc0rauc7/j81p3DVPWF3iKRwOTgV5zn9/ D+1cDvflPa59bPueQCbndDHj2b+9krgHOj/9njaaHQL8RphquD1HDPuln2OtDQA4 0wXMmo+TQ2vkvii8yiaMca93dZrtTw3w6EjtorRyaSOlRMI9BjMxQFJkxvfAGyQv 5fd4vdlK66zXFzHIPQVEOSwgOZd15rq8C4so7dnSJmuii/XpKOZUM1CvO7b8u1Qo 3ERP5HGLsIulLCbwpyS6ewIM05PFiOkQQAfT6CO1OPv4s6+zZBE2vYFRx1HW7Eaq pMnD3gQ9XBT2DgaClcyOF3qqKE02zCwZM2ZU4vrhg== X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.75]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B23EE4270 for ; Fri, 22 Jun 2018 22:10:56 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <05946ECC-02CA-4754-AE40-9DCD0A13218E@cooperw.in> Date: Fri, 22 Jun 2018 22:10:55 -0400 To: rfcplusplus@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Rfcplusplus] a few thoughts X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 02:10:59 -0000 Thanks to all for your engagement on this. A couple of thoughts from my = perspective: In some ways people seem hung up on the notion from the proposal in the = BOF description being an =E2=80=9Cexperiment=E2=80=9D with defined exit = criteria, and in other ways not. For example, people interested in the = boilerplate update idea don=E2=80=99t seem to be proposing exit criteria = whereby something would be measured and then we would decide to go back = to the previous boilerplate. Personally I hope the discussion doesn=E2=80=99= t get too stuck in the =E2=80=9Cexperiment=E2=80=9D frame despite that = being in the BOF description, largely because the RFC series hasn=E2=80=99= t really evolved in that fashion. We didn=E2=80=99t propose an = experiment with 19 different possible combinations of status and stream = (as used to be allowed, I think) and define a date by which we would = decide to reduce it to 16 (what we have today). That doesn=E2=80=99t = mean eliminating those 3 was a mistake or was unjustified. I suspect = that most of the changes to the series over the years have been based on = shared recognition of some phenomenon in the community or the world = rather than on quantitative metrics of some sort, and it might be useful = to keep that history in mind. (Happy to be corrected if folks have data = to share about past decisions, however.) It might also be helpful to keep in mind that misperception is a human = problem, not an engineering problem. Since human beings are imperfect = and varied, whether misperception is a problem for them will vary and no = =E2=80=9Csolution=E2=80=9D will actually rid misperception from all = human consumers of RFCs. I hope people don=E2=80=99t view that as a = reason not to try to make improvements. This reminds me a little bit of = privacy discussions where the claim is often made that an identifier at = one layer doesn=E2=80=99t need to be obfuscated because identifiers = exist at other layers. Partial improvements are still improvements. (And = IMO communities that aren=E2=80=99t willing to discuss, consider, and = adopt changes because they are deemed imperfect are destined for = irrelevance, so I=E2=80=99m glad we=E2=80=99re having this discussion.) Alissa From nobody Fri Jun 22 21:17:39 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6433B130F73 for ; Fri, 22 Jun 2018 21:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] 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 3_4hg3GHiTZD for ; Fri, 22 Jun 2018 21:17:35 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (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 60714130F72 for ; Fri, 22 Jun 2018 21:17:35 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id 6-v6so4356898plb.0 for ; Fri, 22 Jun 2018 21:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language; bh=gMSA1sWkZswP4NRLI95gNDJoowVC5/N9k+h2QTjyAmo=; b=pREqXvxGaBbp7mF0u6bOWIwKQ6UNyxDqZIZ2q+G5XpXXXJ533Eo1BTPiiZ9WT20TLd r4ALdmlzd4DkSmooaLEBMXoui/DlhKfLvLj0dQoTtb9Bqdo70pZuHg/qaoUkLGHvMfI1 kfg/5aTWDGsqsO4B9FDqgIu1MGZoIUFe68Xd8Vo/hkHfqtjz/iycDJ3NWQtr8Zr78RR5 rPwNSZonLkh7KHOO8S/Q6rSTK55vEgg0meyxfHTPpiKSxQGPFoFpoCTvkAzX8Wet3m9R tNF2r52qezbSn4rvhu+hd4WMnIg682ZwyLEERrA3I+BCflJse3K39KHqBWhW+Lptd2/3 6fUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language; bh=gMSA1sWkZswP4NRLI95gNDJoowVC5/N9k+h2QTjyAmo=; b=N6Db7DncL0Aoelbst2nCEb4Y1UK9UHBlHO0nTe7CMa4aBvwUv8WR4+crodzA/caf+w 5QowOToRf/DQKTje9Qn4UQWZ/dsePNaKhcRxqXZ/YpawWwMwqfDpFdG19n5sC0OQTpRU UgELsR2QM+n1nSduJDOu7LMzPkNhwkq7FEAs+Nlr324NUdN2nmAo0xFJSKn6UmfrkJYI 08wi/EPVb7jOiGaWvS6ATr16MxaB37nYigQN+8NNFaF00pjty0xeV6BIA4Tqf6QbQtRJ ipUn5ui6FPI6TtlNuH+IXe1Z3/fvBQx1zt47NacC49I2PzPtgG4PXk4ByrDT9oxjnest bw9w== X-Gm-Message-State: APt69E1864uu7/TuC5V17duLYP60I7stCwZtQKmUFIu1LAbTOMathujl m87J+jXaXSkMJdZtg7LqWD070A== X-Google-Smtp-Source: ADUXVKKaRakwXbErduSTCTYYa5OknKHzLjhfw8dtgGLemRhMDaI1EUASPEdrH5WYyoGfvJh5JYwYsQ== X-Received: by 2002:a17:902:6bca:: with SMTP id m10-v6mr4198123plt.6.1529727454518; Fri, 22 Jun 2018 21:17:34 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id 84-v6sm23153410pfl.186.2018.06.22.21.17.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 21:17:32 -0700 (PDT) To: rfcplusplus@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 23 Jun 2018 16:17:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------9253BC2C8CF1DFFC54E1BDC9" Content-Language: en-US Archived-At: Subject: [Rfcplusplus] The problem space X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 04:17:38 -0000 This is a multi-part message in MIME format. --------------9253BC2C8CF1DFFC54E1BDC9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Here are 3 slides attempting to offer an overview of the problem space. There are some blanks for everybody to fill in on slide 2. I fear that the problem the BOF proponents are aiming is a small subset of one part of the space, but it seems to me we have to put it in context. Regards Brian --------------9253BC2C8CF1DFFC54E1BDC9 Content-Type: application/pdf; name="IETF102-rfc.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IETF102-rfc.pdf" JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PAovQ3JlYXRpb25EYXRlIChEOjIwMTgwNjIzMTYw OTQzKzEyJzAwJykKL0NyZWF0b3JUb29sIChQREYtWENoYW5nZSBMaXRlIFwoNy4wIGJ1aWxk IDMyMy4yXCkgW0dESV0gW1dpbmRvd3MgNyBIb21lIFByZW1pdW0geDY0IFwoQnVpbGQgNzYw MTogU2VydmljZSBQYWNrIDFcKV0pCi9Nb2REYXRlIChEOjIwMTgwNjIzMTYxMDA2KzEyJzAw JykKL1Byb2R1Y2VyIChQREYtWENoYW5nZSBMaXRlIFwoNy4wIGJ1aWxkIDMyMy4yXCkgW0dE SV0gW1dpbmRvd3MgNyBIb21lIFByZW1pdW0geDY0IFwoQnVpbGQgNzYwMTogU2VydmljZSBQ YWNrIDFcKV0pCj4+CmVuZG9iagoyIDAgb2JqCjw8Ci9NZXRhZGF0YSAzIDAgUgovUGFnZXMg NCAwIFIKL1R5cGUgL0NhdGFsb2cKPj4KZW5kb2JqCjMgMCBvYmoKPDwKL0xlbmd0aCAzMTE1 Ci9TdWJ0eXBlIC9YTUwKL1R5cGUgL01ldGFkYXRhCj4+CnN0cmVhbQo8P3hwYWNrZXQgYmVn aW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHht bG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjUuMCI+Cgk8cmRm OlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRh eC1ucyMiPgoJCTxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCgkJCQl4bWxuczpkYz0i aHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iCgkJCQl4bWxuczp4bXBNTT0iaHR0 cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIKCQkJCXhtbG5zOnhtcD0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wLyIKCQkJCXhtbG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNv bS9wZGYvMS4zLyI+CgkJCTxkYzpmb3JtYXQ+YXBwbGljYXRpb24vcGRmPC9kYzpmb3JtYXQ+ CgkJCTx4bXBNTTpEb2N1bWVudElEPnV1aWQ6N2ExY2U4YmQtYTlmNC00NjQ1LTgwMjUtNTY0 OTQ5NWRjNGNiPC94bXBNTTpEb2N1bWVudElEPgoJCQk8eG1wTU06SW5zdGFuY2VJRD51dWlk OmZhNzUzOThkLWRjNTQtNDg4MS1hODUxLTVjZmQ2ZDZkMzY5NjwveG1wTU06SW5zdGFuY2VJ RD4KCQkJPHhtcDpDcmVhdGVEYXRlPjIwMTgtMDYtMjNUMTY6MDk6NDMrMTI6MDA8L3htcDpD cmVhdGVEYXRlPgoJCQk8eG1wOk1vZGlmeURhdGU+MjAxOC0wNi0yM1QxNjoxMDowNisxMjow MDwveG1wOk1vZGlmeURhdGU+CgkJCTxwZGY6UHJvZHVjZXI+UERGLVhDaGFuZ2UgTGl0ZSAo Ny4wIGJ1aWxkIDMyMy4yKSBbR0RJXSBbV2luZG93cyA3IEhvbWUgUHJlbWl1bSB4NjQgKEJ1 aWxkIDc2MDE6IFNlcnZpY2UgUGFjayAxKV08L3BkZjpQcm9kdWNlcj4KCQkJPHBkZjpDcmVh dG9yVG9vbD5QREYtWENoYW5nZSBMaXRlICg3LjAgYnVpbGQgMzIzLjIpIFtHREldIFtXaW5k b3dzIDcgSG9tZSBQcmVtaXVtIHg2NCAoQnVpbGQgNzYwMTogU2VydmljZSBQYWNrIDEpXTwv cGRmOkNyZWF0b3JUb29sPgoJCTwvcmRmOkRlc2NyaXB0aW9uPgoJPC9yZGY6UkRGPgo8L3g6 eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+CmVuZHN0cmVhbQplbmRvYmoKNCAwIG9iago8PAov Q291bnQgMwovS2lkcyBbNSAwIFIgNiAwIFIgNyAwIFJdCi9UeXBlIC9QYWdlcwo+PgplbmRv YmoKNSAwIG9iago8PAovQ29udGVudHMgOCAwIFIKL01lZGlhQm94IFswIDAgODQxLjkyIDU5 NS4yXQovUGFyZW50IDQgMCBSCi9SZXNvdXJjZXMgPDwKL0ZvbnQgPDwKL0YwIDkgMCBSCi9G MSAxMCAwIFIKL0YyIDExIDAgUgovRjMgMTIgMCBSCj4+Cj4+Ci9UeXBlIC9QYWdlCj4+CmVu ZG9iago2IDAgb2JqCjw8Ci9Db250ZW50cyAxMyAwIFIKL01lZGlhQm94IFswIDAgODQxLjky IDU5NS4yXQovUGFyZW50IDQgMCBSCi9SZXNvdXJjZXMgPDwKL0ZvbnQgPDwKL0YwIDkgMCBS Ci9GMSAxMCAwIFIKPj4KPj4KL1R5cGUgL1BhZ2UKPj4KZW5kb2JqCjcgMCBvYmoKPDwKL0Nv bnRlbnRzIDE0IDAgUgovTWVkaWFCb3ggWzAgMCA4NDEuOTIgNTk1LjJdCi9QYXJlbnQgNCAw IFIKL1Jlc291cmNlcyA8PAovRm9udCA8PAovRjAgOSAwIFIKL0YxIDE1IDAgUgovRjIgMTEg MCBSCi9GMyAxNiAwIFIKPj4KPj4KL1R5cGUgL1BhZ2UKPj4KZW5kb2JqCjggMCBvYmoKPDwK L0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoIDM1MQo+PgpzdHJlYW0KeNptkUtLAzEU hff5FWdnu8jtzaOZzEqwdMSCGw24EBelnZm22FbTEdFfbxIfiAghi+Scm/OdKPTCMdUOuiKH SjOmlhFb0YmLIBg9GGGVt1coZmLlDMJ7PoiThqEM1RqhQ6U0eUw9TR3CWozUOOzEL8ekUdA2 K6XxnthD1RVVn+KLuF0eMFvGp/YwtDFbJ42G4azXNbGF9I6cLeqreWhSGP3fCyZrk0kxGQ2p p2SL6X60eHl8G2szgmblxw9hIeZBkEZeHjeXUFgkrB0MeYtMi2vcPzDWoi4NpWIoETjHaS6X NKmn29zTz5jY40+iZEqsGcMqch7W12TcZ6S7zXI4O+EuHg9jVY96vG6HTYmmLVUpvq1I+8I8 bFrcNDPctnHbns4zevqcSWOQh6VSlfWFOL3yVeo6LrtBrr5LlbF9fmlPg+yOUZbqfCGV1qTs 2bA67vdJepLM+T7V8wFtl3/4CmVuZHN0cmVhbQplbmRvYmoKOSAwIG9iago8PAovQmFzZUZv bnQgL1RpbWVzTmV3Um9tYW5QU01UCi9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nCi9GaXJz dENoYXIgMzIKL0ZvbnREZXNjcmlwdG9yIDE3IDAgUgovTGFzdENoYXIgMTIxCi9TdWJ0eXBl IC9UcnVlVHlwZQovVHlwZSAvRm9udAovV2lkdGhzIFsyNTAgMCAwIDAgMCAwIDAgMCAzMzMg MzMzIDAgMCAwIDMzMyAyNTAgMAo1MDAgNTAwIDUwMCA1MDAgNTAwIDAgNTAwIDUwMCAwIDUw MCAwIDI3OCAwIDAgMCAwCjAgNzIyIDAgNjY3IDcyMiA2MTEgNTU2IDAgNzIyIDMzMyAwIDAg NjExIDAgMCAwCjU1NiAwIDY2NyA1NTYgNjExIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDQ0 NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCAwIDI3OCAwIDUwMCAyNzggNzc4IDUwMCA1MDAK NTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiAwIDUwMF0KPj4KZW5kb2JqCjEwIDAg b2JqCjw8Ci9CYXNlRm9udCAvQXJpYWwtQm9sZE1UCi9FbmNvZGluZyAvV2luQW5zaUVuY29k aW5nCi9GaXJzdENoYXIgMzIKL0ZvbnREZXNjcmlwdG9yIDE4IDAgUgovTGFzdENoYXIgMTIx Ci9TdWJ0eXBlIC9UcnVlVHlwZQovVHlwZSAvRm9udAovV2lkdGhzIFsyNzggMCAwIDAgMCAw IDAgMjM4IDAgMCAwIDAgMCAwIDAgMAo1NTYgNTU2IDU1NiAwIDAgMCAwIDAgNTU2IDAgMCAw IDAgMCAwIDYxMQowIDAgNzIyIDcyMiAwIDAgNjExIDAgMCAwIDU1NiAwIDAgMCAwIDAKNjY3 IDAgNzIyIDY2NyAwIDAgMCA5NDQgMCAwIDAgMCAwIDAgMCAwCjAgNTU2IDYxMSAwIDAgNTU2 IDAgNjExIDYxMSAyNzggMCAwIDI3OCA4ODkgNjExIDYxMQo2MTEgMCAzODkgNTU2IDMzMyA2 MTEgNTU2IDc3OCAwIDU1Nl0KPj4KZW5kb2JqCjExIDAgb2JqCjw8Ci9CYXNlRm9udCAvQXJp YWxNVAovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZwovRmlyc3RDaGFyIDMyCi9Gb250RGVz Y3JpcHRvciAxOSAwIFIKL0xhc3RDaGFyIDEyNwovU3VidHlwZSAvVHJ1ZVR5cGUKL1R5cGUg L0ZvbnQKL1dpZHRocyBbMjc4IDAgMzU1IDAgMCAwIDAgMTkxIDAgMCAzODkgNTg0IDI3OCAw IDI3OCAwCjU1NiA1NTYgNTU2IDU1NiAwIDAgMCA1NTYgMCA1NTYgMjc4IDAgMCAwIDAgMAow IDY2NyA2NjcgNzIyIDAgNjY3IDYxMSA3NzggMCAyNzggMCAwIDAgMCA3MjIgNzc4CjY2NyAw IDcyMiA2NjcgNjExIDAgMCAwIDAgMCAwIDI3OCAwIDI3OCAwIDAKMCA1NTYgNTU2IDUwMCA1 NTYgNTU2IDI3OCA1NTYgNTU2IDIyMiAwIDAgMjIyIDgzMyA1NTYgNTU2CjU1NiAwIDMzMyA1 MDAgMjc4IDU1NiA1MDAgNzIyIDAgNTAwIDAgMCAwIDAgMCAzNTBdCj4+CmVuZG9iagoxMiAw IG9iago8PAovQmFzZUZvbnQgL0NvdXJpZXJOZXdQUy1Cb2xkTVQKL0VuY29kaW5nIC9XaW5B bnNpRW5jb2RpbmcKL0ZpcnN0Q2hhciA0NQovRm9udERlc2NyaXB0b3IgMjAgMCBSCi9MYXN0 Q2hhciAxMTcKL1N1YnR5cGUgL1RydWVUeXBlCi9UeXBlIC9Gb250Ci9XaWR0aHMgWzYwMCAw IDAgNjAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDYwMCAw IDYwMCA2MDAgNjAwIDYwMCAwIDAgMCAwIDAgMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMF0KPj4KZW5kb2JqCjEzIDAgb2JqCjw8Ci9GaWx0ZXIgWy9GbGF0ZURlY29k ZV0KL0xlbmd0aCA2MzUKPj4Kc3RyZWFtCnjafVNNc5swEL3zK/YIBxStkARMTq0bt/akM56Y W5IDMZgh5SMFxRn311drcIzjtB6Px7v73tu3KwmhcDRnsQYRMg2h4KAkhy53ts7XxOFQAIdk Qz9vgJwzjjqA5A8luqs5BwxYLCDZQoiCRaAipjQkmeMKL3l2JgwCi4jxiMC+5hHTEuKYoSD4 vbs2XZ7W4KF2N22zfe3LtoEHN2eUKZj3mCytHT8ImB4JyTfY9VClJu89jFwDq/U1LG4SD5U7 /4h3LbRpG9/W5w8eebPecfBDal/Ws8UCqrL2MHRLkxrbftQIJZMD6EfaZWBa2JZNBhUZo+YG qOMu7/oTZ+Lzwb2bz4TUHErSJhsGFqudtjYGMB5N3KabX9BuYdGYvCP5JjfQm7ShBplt3l/K Z3m/6coXU9IO2qY/7KxgkMxWpwao2Ljm2/YNfr+mVUnyZk/d2iqDOwrnswt9d1QLYxy2ZnXo G0FXXM3xdKLSMgRNQndpOJ+22qVP5LysSuP5At39KF/Ax4uhxltErZFJeeyd9nvGWFm/tH1f PlX5hYlzpYkhH4W0iJPaOrdHVJr9cPbF2X08nxgZC/4/rR/YQSW8c1Zda83VRLmhV/MdBCwB 4RkEQw30dOAn3D9yyJxY04qUVIxLqJ1QxkyJY1w5a0tfAkEsyxqzpwdEUbH9gNQx0xHnIoBN 7VC1drQS9Oi4Jds5IrSe3pNDeCigmuYpOqRFwJmcFIZ4KFmyiKa1IUEmab7jbKNLWmIUWwDn KP9hT2pJ736ofT4srRZpWj2iOZ8Ma5uMGpWD4rAzSo9/T7VPHfqSK4ZotRX4w8ateIwkf34O 73E0bGPt/AWkrjBNCmVuZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKPDwKL0ZpbHRlciBbL0Zs YXRlRGVjb2RlXQovTGVuZ3RoIDU4OQo+PgpzdHJlYW0KeNp9k02P2jAQhu/5FaO9NGmL13YS k1RVK0CwoodltUTqAe0hEAOpQozsUJRe+tc7NuFrD5WSyHI8z7zzeobBxhOUpAJ4nwjocwpx REFLb+0NM4/CBihkK/s5AqOUUCZCyP7YDf04ocBCknLI1tBnnCQQJyQWkBWeHwbZL49wsE8C enMb/ThhEJ0De3GcEpHgBu1iF/7PrQJ1rA00WwmvkxGYoMdiX+pSmu/BW/bDKbsjcuAJoYkj hoJECfSihPDoBPwb9AQCnlXjkNNxNgGlAyZ8XM+fHNIxIgsIBTJiEvNLcJykvtXB4JgbYH1o Za4NLOVaobK+r0/MAHMAu9JuFOGbklDcyRm8vgzgYGThhDQK9nn7GZaHBrZ5XcgC1DpA+Nr+ ms4tfDbqqu9FlIT8jjadTx3Mnt4q0wQs8d/RHMkip/PZ6NN0MB/c4GLxDjcbfTCwK40pVQ2l sTzYHVZbWGqVF1KjlXl98fM/wgZD0KqSyABVV23Aqav2Id/vtfotHQLXqqybnawbW7aFYUsy jr6FpFO2wINvth+cz+OibJQGrM0BNrKWOq9gr6py1cJaVZU6Biz10d5O2pW0bM+t5aw/ocgD LIajlzB9624wvLnBTsyluq+UDsffAJv87qZPx+gpy0jVq+pg7fsSICD1L+3sOhlKW4eBldrt DnXZtC7tOPN4SkmEo8XtYIZCACNRdBlKhqPTxz0a2rFxidDGvdRNS+BZ1RL9O93KR1fcRjbG 2l3IVVmg0RUeIedUHSx1vRnHAmf1muwf4YMSDgplbmRzdHJlYW0KZW5kb2JqCjE1IDAgb2Jq Cjw8Ci9CYXNlRm9udCAvQXJpYWxVbmljb2RlTVMKL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rp bmcKL0ZpcnN0Q2hhciAzMgovRm9udERlc2NyaXB0b3IgMjEgMCBSCi9MYXN0Q2hhciAxMTkK L1N1YnR5cGUgL1RydWVUeXBlCi9UeXBlIC9Gb250Ci9XaWR0aHMgWzI3OCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYK MCAwIDAgNzIyIDAgMCA2MTEgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDcyMiAwIDAgMCAwIDk0 NCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDU1NiAwIDAgNTU2IDIyMiAwIDAgMCAwIDU1 NiA1NTYKMCAwIDMzMyA1MDAgMjc4IDAgMCA3MjJdCj4+CmVuZG9iagoxNiAwIG9iago8PAov QmFzZUZvbnQgL1VVVk1RUitXaW5nZGluZ3MtUmVndWxhcgovRGVzY2VuZGFudEZvbnRzIFs8 PAovQmFzZUZvbnQgL1VVVk1RUitXaW5nZGluZ3MtUmVndWxhcgovQ0lEU3lzdGVtSW5mbyA8 PAovT3JkZXJpbmcgKElkZW50aXR5KQovUmVnaXN0cnkgKFBYQ1ZpZXdlcikKL1N1cHBsZW1l bnQgMAo+PgovRFcgNzk0Ci9Gb250RGVzY3JpcHRvciAyMiAwIFIKL1N1YnR5cGUgL0NJREZv bnRUeXBlMgovVHlwZSAvRm9udAo+Pl0KL0VuY29kaW5nIC9JZGVudGl0eS1ICi9TdWJ0eXBl IC9UeXBlMAovVG9Vbmljb2RlIDIzIDAgUgovVHlwZSAvRm9udAo+PgplbmRvYmoKMTcgMCBv YmoKPDwKL0FzY2VudCA4OTEKL0NhcEhlaWdodCA2NjIKL0Rlc2NlbnQgLTIxNgovRmxhZ3Mg MzIKL0ZvbnRCQm94IFstNTY4IC0zMDcgMjAwMCAxMDA3XQovRm9udE5hbWUgL1RpbWVzTmV3 Um9tYW5QU01UCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAwCi9UeXBlIC9Gb250RGVzY3JpcHRv cgo+PgplbmRvYmoKMTggMCBvYmoKPDwKL0FzY2VudCA5MDUKL0NhcEhlaWdodCA3MTYKL0Rl c2NlbnQgLTIxMgovRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjI4IC0zNzYgMjAwMCAxMDE4XQov Rm9udE5hbWUgL0FyaWFsLUJvbGRNVAovSXRhbGljQW5nbGUgMAovU3RlbVYgMAovVHlwZSAv Rm9udERlc2NyaXB0b3IKPj4KZW5kb2JqCjE5IDAgb2JqCjw8Ci9Bc2NlbnQgOTA1Ci9DYXBI ZWlnaHQgNzE2Ci9EZXNjZW50IC0yMTIKL0ZsYWdzIDMyCi9Gb250QkJveCBbLTY2NSAtMzI1 IDIwMDAgMTAwNl0KL0ZvbnROYW1lIC9BcmlhbE1UCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAw Ci9UeXBlIC9Gb250RGVzY3JpcHRvcgo+PgplbmRvYmoKMjAgMCBvYmoKPDwKL0FzY2VudCA4 MzMKL0NhcEhlaWdodCA1OTIKL0Rlc2NlbnQgLTMwMAovRmxhZ3MgMzIKL0ZvbnRCQm94IFst MTkyIC03MTAgNzAyIDEyMjFdCi9Gb250TmFtZSAvQ291cmllck5ld1BTLUJvbGRNVAovSXRh bGljQW5nbGUgMAovU3RlbVYgMAovVHlwZSAvRm9udERlc2NyaXB0b3IKPj4KZW5kb2JqCjIx IDAgb2JqCjw8Ci9Bc2NlbnQgMTA2OQovQ2FwSGVpZ2h0IDcwMAovRGVzY2VudCAtMjcxCi9G bGFncyAzMgovRm9udEJCb3ggWy0xMDExIC0zMzAgMjI2MCAxMDc4XQovRm9udE5hbWUgL0Fy aWFsVW5pY29kZU1TCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAwCi9UeXBlIC9Gb250RGVzY3Jp cHRvcgo+PgplbmRvYmoKMjIgMCBvYmoKPDwKL0FzY2VudCA4OTkKL0NhcEhlaWdodCA3MDAK L0Rlc2NlbnQgLTIxMQovRmxhZ3MgNAovRm9udEJCb3ggWzAgLTIxMSAxMzU5IDg5OV0KL0Zv bnRGaWxlMiAyNCAwIFIKL0ZvbnROYW1lIC9VVVZNUVIrV2luZ2RpbmdzLVJlZ3VsYXIKL0l0 YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL1R5cGUgL0ZvbnREZXNjcmlwdG9yCj4+CmVuZG9iagoy MyAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMjM2Cj4+CnN0cmVh bQp42l1QwU7DMAy95yt8HEIo3bhwqHrZNKmHwVgZcE0Tt4q0JpGTHvr3OGH0gCXHsv3e04vl vj20ziaQZ/K6wwSDdYYw+pk0Qo+jdWK7A2N1unfl1ZMKQjK5W2LCqXWDF3Ut5IWXMdECm/Ph +L1/rh6EfCODZN0Im9agSzYtedrNIdxw4gFUommEwYEFTyq8qglBXq+fp/fL4xfzDGd8YuX5 pghW3McSEHal3/5a095gDEojKTeiqCuOBuojRyPQmX/7O6sfVniPDF+LeSmsv30WyL9ePeqZ iO2X0xRH2Yt1uF4v+JBZJX8A14d3GgplbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqCjw8Ci9G aWx0ZXIgWy9GbGF0ZURlY29kZV0KL0xlbmd0aCA0MzMwCi9MZW5ndGgxIDc4MTIKPj4Kc3Ry ZWFtCnja7Vl7eFTlmf/ec+Zc5pIL4ZYSlQkjqCQBE8JFQAghCZC0FQQ1443M5SQzZjIzzJnJ BS+LRQUHtLFiq7YKalFAoicENVhb8QLStV3L7mprseq67Op2ZZ+nz2rdy6Ps7zvfzDSwq9s/ +jy7f/R8/M57Pe/3vd/lzHkDI8aYi+lMZveHetPep2bv3QvNfsaUhZ3Jrp5XP1lkgf+IMcf6 rthA597esufwwEr43B8xAuG36TXYXO9DnheBomy8627G3OWQz4/0pPtXNWbvhLyYMXlrLBEK KA8o7YwVv8oYHe0J9CflK9WZjJVuh783mTDT/tjCqyCjf9dtyZSRvOy1C9YzVnExnl/H/r9d x7/UUosWonbpVulqcN9nQdwfBMLAA2wH2yGNCB82B7DAtbIPlWOsjqVs/Rx2E+5N7N9oD7vD 1ixmQdiD8D4CugS2ECjZMXbQdpvezG5D7N9JI9LL0su2dSnitnIP0aQR5Rj0PN5m9hR7lw7D 50Z2L2yH2HH+FCLvYEPsM7oQbRv9A52SVkNLvH/E6Yb3Doz3J+xt9q80gZZQll6AT5l0qz0W 0dsm+BxBO25H4e0bFKMEpehOxDwpydJcRE1IW6VdkiW9LPsdS5Rjapk6X4shCjEJu3EcMuTR vsnWoucg21CIKtovSKI1tI4i9F3ahTEcoVNon0g10lLMOm/3yR0Oj+MjpVt5FO2YeoX2kK4i tsJUNoV52XRWj6ya0ccajDnMbmAb7XYj2k2Yy2+xnWwXe4TtZcPsefYS75OdYO+yzzA7JWg8 r/l0CV2F5kdL0S10G+Zj25h2F/2ARuh5jO91elOaiqxFiyF7McrN0oPSQel16WfSe9JJ6bfS 72QmO+X1clA25d3yPvkN+Q3HSscuxyOOdxzvKKRY9kyVqRPU69RtaNs1p9at3abdoz2kPeua xSYjr2rk1cquQlYDyOQmtpVl7VUbRjvInkE7xn7L80A7ncuEt0uoiVroCjQ/XU0d1EMm9Rcy +iE9TnvoIHJ5E+1XdIL+jv6Z/sVun0mqNEmqKuS3WlorXSV1S9+VHpB+ID2JHTkivSD9SnoX OZ6UPkWObrlMniifJzfLLWjr5GvkfnmzPCS/LJ+QT2HdPI5LHUscVziuQ+5HHScdH2ElJUVW pitzlYVoESWu3KJsUx7Gjj6lnFI99qyUqePVReoWdac6or6tfq5N1CZp09BmabXaWi2m9Wr7 tJPah/p+5zJn1JlyVbN97GL23Fmn9xns7lek69TZbAqdwG7YIJfAy8vPnuTRYs6oNMJHp62l C7FSv2GfyU7W5jjKrpKvYTElKLu1j9keMh230pNyC96lu7VeekHukE/Ju5Xp6iIxn9KD8j5t QOvQPsRIP5HvVSLaLFqmbKM90lKc6BStYb+nT9n16DktzWRH2Z1sK/XiTb1D309FOGtHpKm0 TXlUPuDYJTcrt9BFWMEK5Zh8O5vLJjIPu5BNw15X2ASANcxfML9+Tl3txbNn1VRXzbzowgtm TD/fN63SO/W8c8+pmPK18smTJk4YXzautKS4yON2OXVNVRyyRKy62dfS4bVmdFiOGb6VK2u4 7AtAERij6LC8ULWc6WN5O2w375meDfDsPMuzQXg2FDyp1LuYLa6p9jb7vNbPm3zeUbp6TTv4 u5p8fq91yua/YfOOGbZQBKGyEk94m8sjTV6LOrzNVktvJNvc0YR4w27Xct9yw1VTzYZdbrBu cFaLLzlMLUvIZqSW5oXDEtOLMCqr1dfUbK3yNfEhWPL05kDYWr2mvbmporLSX1Nt0fKQL2gx X6NVUmW7sOV2N5a63NLsbrxRng7b5h2uPpzdPlrKgh1VnrAvHLi23ZIDft7HuCprha/JWrHx ZHlN9Sg9vq7dci4fJbau/RBrPb1peNWmpiY/761sefsW230y3CdvPFkhZ5vLo14uZrNbvNau Ne1jrZX87vcjaE112+XtlRi1r3m7l6dxebudAYJS+WwMkut4miJhw9fMNR03eC2nr9EXyd7Q gcWakrXY5QOVB6a0Nhw6/T5rbfZm17X7Kq2lFT5/oOmc4Qkse/nAyKoG76ozLTXVw6XjxEwP F5fkGE/RWMYo2GzOduccRp2fauIj8q3CFrG8IS9G0u6zpOkL+M1YwLKhBXDD5SfMaBTz15Et XcgXQple6vNmP2XYCL5TH5+pCeQ06vTSTxln+XYpbDnY87xVVWXNnMl3irYcS4uRLbHluTXV vVabL1nqtdowZWx1Ox7yL5yNKa+s5Ku8bbSBBSFYm9a0C9nLghUHWMPsKr8ldXDL4bxl4hXc silvKTze4cN2Psj4B9pES59R+FdSOml8c2ShRZO+wmwIO45Ps3fYoUzPrm6fEchuq5jRkd3u x9K04Chmsy0+b0u2IxsYPb0p6POW+rLDbW3ZZHNHPqXR04e3VVgN2/0RwqRac8RsWOOXt8sV kl9wUoXsr2H4XR3Cd+LT+LqQ8ft65QFFVUelOxqKJHmCpDokWXXghcI15SRNIJIcJDugfwwf lt+WZEV1sEOEb4jZ/zj5klNsKe6zay/eosyq0m8ufXWLPqu8SgFT6ZQqK0l5+j++UKQv1n3u kX5E1/NflM/Pka4/fbowghXsx+q1jB1mDcyeH7z/qvoM7/qSxZ/qFbr9it89dO8XnL7U+E8R xr5Y7XpPq4Xosf35BarVfrEa3674Nj39huu9giV/feBg+CbBpQI8qr6EtTovZDtcUeAwa9Vm sB3OF9iQvI8d0fezIW0aG3KW5LBewL0F2M6G9CNsyPUiG1K+J8B9HQngOGz4ItPuY636LsS8 DXylsNvg/AroAccIG1Lb8bwhoN0p4AgLcH/1RXZlHvrfw28ldK+jj2dhrwDc0NVDdyvoRLZD XcV25PtS/j2HYwDGrF4D/cTcOGaKsTgbEAvj1hBPPwSK/LQ+4B7Ic0DjIlf9djx/KWgnG3FV sa0OzB1Hvi/MZ+tZWHAGboTPjWfNxZ8Y+KYdkveKnO1+zsZOgf/Nz8H9To71odKc7Tj4kv8x tg0KnqXb8uW+fxz04FlAraKL/Vv7VXCp2J+qWHN73c+M+8sC/1YOOVmdeyb0rEDB/p9noqC/ iR3h4Gts88tAx0A+wULyRBbSV+DL/c/X/921jH39T9TEu/oD8rDZ7C5WjF+UUnCXQP2xY32u LrSv0wu+ZM0/yL26JZLJQQqppJFOTnKRmzxURMWodUppHJXReNSuE2kSTaZy+hpNoQo6h86l 82gqeamSppGPzqfpNIMuwDf1RTSTqqiaamgWzaaLqZbqaA7V01yah/pvAaqmhbSIFtOlqIaX UgMto0ZajkqqGbXUClpJq6iV2ujrqIG/SZfRalStl9NaVK5X0JWoHNvtWusaupauo+tpPb5D AhSkEIXJoE7qQn0bpRuoG/VzD8VRQydpA2oDk9KUoV7qQ302QBvpRrqJbkb9+Re0iW6lb9Fm VKK30x20hbai5uYV3HbUonfTt2mQ7qHv0L20g+5D5fw9up8eoAfp+6hTH6KHaSdq6UfoUXoM 1d5u1HtPoOLbS/voSdpPQ/QUPU0WDdMB1LQH6Rl6lp6jUTqE+vZHqAp/TD+hF+kwvUQv0yv0 Kiryo/QaHaOf0l+i+v0Z/Zz+it6gX9Bx+mv6G/pb1JBv0S9RR75Nv0Yt+Q79ht6l9+h9xUwG QoaaNOKhaEw3Q1HTTKTMkjwTyqTT0XhXccoIhEG7YgHTNExH0IjFHMFEolsNBeLhmFGcNmJG MpKIG2YiFg1zMQKDaaRD0VTIY8R7jVgiaQQDoe6ivNCZSsTTxT2BaCyY6O+MBbrCffGiMWIm KYz9iWS8MwaxZKwIZ7UzEQsbKZcgiBgv6ozGjHQgFksb/elaz1jpDNMcN5dCgWA0bqSdkUQm ZSemdxsDwUQgFfb0JDKmURdE8om4M4inkoloPC0lQ3oE5nDU7NY6kUNyYE6OztXTgaSRMoyY kyfel4qmjaICFzM60wqXelV+T3Rr6UimJ5hJOm0aTvTFXdyQTHNPt2BT0a5IWhc8PAWDtG1V JBBLO80eZNGJ5XPHjUw6FYhx3ol57YtzDgvUEywxuzOxWCiVMM0gXx4Hn1oNcxUPxNN6IJpK xgJxQzczcTOC2dDCmEhMlNOMJ/rg2m3o/T2BVHcwFtZDESPEGTcWKK/kfF7vsXtJZNIxBHLb ghkJIDnBh4xYOhoSTj0YvmEabjMdSCU6w4HeKH/agE88zXXaQDQ+EIh3SYkepS+CWVUCqahh qulAJpUx1S6jJxqP8r0XMlJyzEgovdFUV0KJRYOpgGaGEqlkNOE2A11dUQSLZkxnKJBMRaGP 64ENGVulJqPoziwK9GDdTExpNB0LucdIxRsyibQRDsZinWlkV5QXU1zSkIWRThueHLW3vTOY wVkIdMaNAteX58w/cEZxLyaIs0Hs3PhZYt8ZonmWaCgh8CkVU4X9poUSPT0YrL4R+x+jNjW+ xJym+2wZ+wt7knN6J3a5YKK9wseM9ts+ptFrxG3O4FvOdopH84GEyZ3vIRrvdeU64WyuH7Ce QlcQ3PnebD7XIffP9cn9C91yodAzfyDfud1BwUfjr5KYUZej9Tk6T0nhxVRn3+vt+zw3v4vD W4ctk+oy0sXCWexHvErGijhTmsl3BWILWp+j83CE+uv4bQ6/1fPdng/hKfD8TKYiOGsZsz7P zNNjiY1GvMuozzPzdJxovrfrnPYR4JwL5zAdsFk9YvQLayKUU7nDiTBeUpyfU9DW41XchTjY pfYQC6LISA9lzCR/FTrzTK3enxuTsiFjpAZcudQRy8VvIgcn1jQRiiVC3U4sqeDc9ooK3sUX NM9iPXO+WM6cr72aOd5ezJwzX8t84LyDB/u54O1J9xmxfMCiQCplTyh/D9a681IKL3ObzyRt gysnFPRcm0nm9CnOFhX0eD4XKWXzng2ZaCydW/CSsQI2mZOftFCoD8c1x8ULnGkUdIYqTrcq jraQhNI0XGHkJ176bsHar3In/w+cOq512Zyt1GyWv945tX8IxPrYTwtW/BAIPpPM2bkrfplS QRHR5kREm0VEm3I3oYn35aghqJmTkRWn9YUw9X8IU58LU18IU58LU58LU58LU483U5CHUIP2 4zJ+3BTxw2arczEzSa6Sg/E+wJCDJqhpqMFwwIzUClLn7oviJ7LPjCW6Eg0e1tKCb8yycXrD Su+oNO/AyjqQzTah/YI8KcheQfYI8oQgjwnyiCA7BVklyEpBVgjSKEiDIEsEWSzIJYKogjgE kQWhhstA3wFOAL8G3gJeAZ4FngGeBoaA/cAe4AlgJ/Aw8BCwHdgMhID1dsynReghQfYJ8rgg uwX5oSAPC9IkyDJBLhVkgSCaIIogkiCsoQH0beBN4BjwGnAUOAI8BxwERoCngF3Ad4ABILyy boJzgnP+4Cj1NqzSBh/RBu/VBu/SBhPaYEwb7NQGDW3wWm3wam3Qrw22a+fr03Svfp5+jj5F L9cn6RP0Mr1UL9Y9ukvXdVV36JKOetgaL7dJbWsbqc06HGJtQa/1+7W+UXKtudpSfI1klbWx tnWN5daCKkvaav/VdpRODxPdfXsF/4PtIUZ0+va7KnLU72eTqv77VX6G1LZ64AU2leYzDfc5 I9rUVzWuXQvtoK0d5NpBW1tOB1azurbAto5zWdVXXVT1x17UHOXprm4f1lmjf/m1go5Ibhfy 6aio9DdOKk0usZNbVFl+S8XzDkZ7mLvKb3l8jVYRwE01y2qWcZOD2aZi/jfynKn8lkWVFc/T npypFOpxmMr/Ao8UFh4KZW5kc3RyZWFtCmVuZG9iagp4cmVmCjAgMjUKMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDE1IDAwMDAwIG4NCjAwMDAwMDAzNDQgMDAwMDAgbg0KMDAwMDAw MDQwOSAwMDAwMCBuDQowMDAwMDAzNjA2IDAwMDAwIG4NCjAwMDAwMDM2NzUgMDAwMDAgbg0K MDAwMDAwMzgzOSAwMDAwMCBuDQowMDAwMDAzOTgyIDAwMDAwIG4NCjAwMDAwMDQxNDcgMDAw MDAgbg0KMDAwMDAwNDU3MiAwMDAwMCBuDQowMDAwMDA1MDE3IDAwMDAwIG4NCjAwMDAwMDU0 MjggMDAwMDAgbg0KMDAwMDAwNTg4MiAwMDAwMCBuDQowMDAwMDA2MjMyIDAwMDAwIG4NCjAw MDAwMDY5NDIgMDAwMDAgbg0KMDAwMDAwNzYwNiAwMDAwMCBuDQowMDAwMDA3OTc5IDAwMDAw IG4NCjAwMDAwMDgzMTAgMDAwMDAgbg0KMDAwMDAwODQ5MCAwMDAwMCBuDQowMDAwMDA4NjY1 IDAwMDAwIG4NCjAwMDAwMDg4MzUgMDAwMDAgbg0KMDAwMDAwOTAxNiAwMDAwMCBuDQowMDAw MDA5MTk1IDAwMDAwIG4NCjAwMDAwMDkzOTUgMDAwMDAgbg0KMDAwMDAwOTcwNiAwMDAwMCBu DQp0cmFpbGVyCjw8Ci9JRCBbPDEwODU1OUFDQURBNDI4ODhFMTZCMzRGMzNCRThBRkJCPiA8 MTA4NTU5QUNBREE0Mjg4OEUxNkIzNEYzM0JFOEFGQkI+XQovSW5mbyAxIDAgUgovUm9vdCAy IDAgUgovU2l6ZSAyNQo+PgpzdGFydHhyZWYKMTQxMjYKJSVFT0YK --------------9253BC2C8CF1DFFC54E1BDC9-- From nobody Sat Jun 23 01:23:47 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CB0126F72 for ; Sat, 23 Jun 2018 01:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6IHx0GtcZKcR for ; Sat, 23 Jun 2018 01:23:44 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CBC126CC7 for ; Sat, 23 Jun 2018 01:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3515; q=dns/txt; s=iport; t=1529742224; x=1530951824; h=to:from:subject:message-id:date:mime-version; bh=MzWKzJ1VANYjH0K1jG1LhyaxKQYxt7h/TqOLs0ZjA6U=; b=nLYmuuDjwac0hFUjJAHvNCu/mGHjMbJ0ItjuMpZdmFEhc67O165/T8uG Bk9EDXWDldiADmTWGaylsv+iJherWVOsNm//Qe/V4K2Hpg83MDzYHCsJ4 SYjEDbAgGsdJOw55spNzBKK4CgpORJ8xges7AX0F3SabNaeUJ0n408bL1 c=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAwBfAi5b/xbLJq1bGQEBAQECAQE?= =?us-ascii?q?BAQEIAQEBAYUZEoQhiGSNPJAxhn0IA4gSOBQBAgEBAQEBAQJtKEIBBAsBhEw?= =?us-ascii?q?zdAE+AlMZCAEBgyEBgX+tMoIcH4gpcw+LAIE2iC+CNIJVApFUh1sJg1OBWIl?= =?us-ascii?q?gBogMhT2RbYFYIYFSMxoIGxWDJZBSPYIchUiHXQEB?= X-IronPort-AV: E=Sophos;i="5.51,260,1526342400"; d="asc'?scan'208,217";a="4728874" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2018 08:23:41 +0000 Received: from [10.61.192.222] ([10.61.192.222]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w5N8NfYA004882 for ; Sat, 23 Jun 2018 08:23:41 GMT To: rfcplusplus@ietf.org From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <3cadd2ea-c5e7-5a1a-0feb-8f686721e0c4@cisco.com> Date: Sat, 23 Jun 2018 10:23:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VumCTo8hoICcCmw5KFEnBBbZNbDdjg5FE" Archived-At: Subject: [Rfcplusplus] downrefs and labeling X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 08:23:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VumCTo8hoICcCmw5KFEnBBbZNbDdjg5FE Content-Type: multipart/mixed; boundary="o2cgFm3sHbqw1zDnAUUwi904tsgHdy6xe"; protected-headers="v1" From: Eliot Lear To: rfcplusplus@ietf.org Message-ID: <3cadd2ea-c5e7-5a1a-0feb-8f686721e0c4@cisco.com> Subject: downrefs and labeling --o2cgFm3sHbqw1zDnAUUwi904tsgHdy6xe Content-Type: multipart/alternative; boundary="------------288F8EBA08CAD07E3D9ED1DB" Content-Language: en-US This is a multi-part message in MIME format. --------------288F8EBA08CAD07E3D9ED1DB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't have a strong opinion about whether to do this, but if we do here is some food for thought around downrefs. IETF standards occasionally normatively reference works that are informational.=C2=A0 These are marked in the downref wiki.=C2=A0 Maybe th= at's because even though those documents were marked informational, over the course of time, they really turned out to be more than that.=C2=A0 We cou= ld say that some of those informational documents are really de facto standards, but that their marking in the downref wiki makes them de jure.=C2=A0 If we consider this from a labeling perspective, it might be = No Big Deal.=C2=A0 But one might also want to reclassify such documents back= to RFCs when they hit the wiki. Just some food for thought. Eliot ** --------------288F8EBA08CAD07E3D9ED1DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't have a strong opinion about whether to do this, but if we do here is some food for thought around downrefs.

IETF standards occasionally normatively reference works that are informational.=C2=A0 These are marked in the downref wiki.=C2=A0 Mayb= e that's because even though those documents were marked informational, over the course of time, they really turned out to be more than that.=C2=A0= We could say that some of those informational documents are really de facto standards, but that their marking in the downref wiki makes them de jure.=C2=A0 If we consider this from a labeling perspective, = it might be No Big Deal.=C2=A0 But one might also want to reclassify suc= h documents back to RFCs when they hit the wiki.

Just some food for thought.

Eliot
--------------288F8EBA08CAD07E3D9ED1DB-- --o2cgFm3sHbqw1zDnAUUwi904tsgHdy6xe-- --VumCTo8hoICcCmw5KFEnBBbZNbDdjg5FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlsuA40ACgkQh7ZrRtnS ejPqOwf/e9pOJ3JAj6zimOwamRybiD3UpxAS79dLHGrNLZHIheUEwzovUBWR6+lv shDvQmFQit7JsNUXUZCwKpIfc5Rd1/M0gMfqhOT0NOHUrjyKaqr76e7Otfic5yYD 4OkcvMr0C9qeUZYn2XLhJWnuyrUF/DWYTICt2NCU3q6YM6RgpqxmAMpvZPVQvTRM whuaYLbV68kN9w3czufc3BSvl+JhnkPF913/iNZv7c7MENccHmHSkz81PQoGXhpE BAbj/WWLjG1bAxCTKtxH8HpOpiFbhY1GT2mRWCuCN8sPMG7jtcKclmVy9UnlVcJY D0ari00ZsEo+0NlOTh50IzS3O4arnQ== =XT4d -----END PGP SIGNATURE----- --VumCTo8hoICcCmw5KFEnBBbZNbDdjg5FE-- From nobody Sat Jun 23 19:52:44 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE421294D0 for ; Sat, 23 Jun 2018 19:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NlcAOe4CrQ2f for ; Sat, 23 Jun 2018 19:52:39 -0700 (PDT) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 53D6A129619 for ; Sat, 23 Jun 2018 19:52:39 -0700 (PDT) Received: by mail-pl0-x22d.google.com with SMTP id t12-v6so5207969plo.7 for ; Sat, 23 Jun 2018 19:52:39 -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=UYJXGC/dOQHfCCjdDJ1b4hUD/DK+vPZaJvQbupZWdp4=; b=IQsRhJ0hbCzSnMxf15MxXfiXpIhviJL7CPcST66gh+YjIwcxlE3c57acIiIL7QTbhd +E29zOmxdyzhpi+95MhmaVGa0QldjX6PN/ylqwkMyWCtv5V3/F6FPDn/aAvQs74xpsnO +so4/ZP+no34LeoFu2IFAPWBCBTk097hWq/iDSXtsSa0+JNoTqbQlq0bBV+2i2VW94+t A+8Pn4/TyurZ5ekeYvA2uFbcT2JAAz08vYeHx5LYK3OU9EtkuNGeisuwCdHK2rvEeDzG ZnVsXkDRuNKwV2B3vh/H1FeVDMJ/aNumwBpPbrosp5ejA7kijZQRxf2BCvUEK0YvD2SN ubZw== 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=UYJXGC/dOQHfCCjdDJ1b4hUD/DK+vPZaJvQbupZWdp4=; b=fFt4iCu+JDLOfrPpF2MCfYuP4nDf7d9cC0IPbrOxFOZDE5vqNYx777qEWMpne9TEe3 lUSk9XzG++3fgJzZce0q3TToaw2lhXjIP3lkvQXTvwmH1oPNL48vsEsNrBC0okHNNmMr gdNTlAtU88k3BJQEitgVtyenZkUJajDHsD4rRCV1RTPdjdXdS5nq6ic5KRCq3jltKv5F Hv5uCUZ8pabZ3xcHcLzv7oOCjVUXmSZjQoYbMRwoRHfxCmuLCTzwmvLeN4rW5oZTl21P 0gOqW9FUcV6TbrJXmo4FT5foWpkUMv4vwxpEVt0cuU8FFEosh5ShjU3C1+aYgAaHpp2C SO+w== X-Gm-Message-State: APt69E1SyTqWLvmeoKzrwBzoswzceWKYuzB3wzQhWvfTxd4k+f8F1nv/ 40bNyzq4VL2bUuJ6khOaV/Oqsg== X-Google-Smtp-Source: ADUXVKKC3tIZP/4rl3luYF7iZiXfwvKMykFtoTktnwWe75o6MyXaro8yWbYQB7ustXbHzTKAA7PHMw== X-Received: by 2002:a17:902:d808:: with SMTP id a8-v6mr4156312plz.188.1529808758628; Sat, 23 Jun 2018 19:52:38 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id y15-v6sm16566313pfm.136.2018.06.23.19.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jun 2018 19:52:37 -0700 (PDT) To: Eliot Lear , rfcplusplus@ietf.org References: <3cadd2ea-c5e7-5a1a-0feb-8f686721e0c4@cisco.com> From: Brian E Carpenter Message-ID: Date: Sun, 24 Jun 2018 14:52:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <3cadd2ea-c5e7-5a1a-0feb-8f686721e0c4@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfcplusplus] downrefs and labeling X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 02:52:42 -0000 On 23/06/2018 20:23, Eliot Lear wrote: > I don't have a strong opinion about whether to do this, but if we do > here is some food for thought around downrefs. >=20 > IETF standards occasionally normatively reference works that are > informational.=C2=A0 These are marked in the downref wiki.=C2=A0 Maybe = that's > because even though those documents were marked informational, over the= > course of time, they really turned out to be more than that.=C2=A0 We c= ould > say that some of those informational documents are really de facto > standards, but that their marking in the downref wiki makes them de > jure.=C2=A0 If we consider this from a labeling perspective, it might b= e No > Big Deal.=C2=A0 But one might also want to reclassify such documents ba= ck to > RFCs when they hit the wiki. (Nit: it's no longer a wiki, it's in the datatracker) Yes, that does indicate the benefit of having a single archival series with consistent document identifiers. As soon as we hypothetically deviated from that, we would create inconsistencies. It's true that adding a document to the downref repository is a form of promotion (following a Last Call) so it would be rational to represent it in the document's external metadata. But we can't mess with its archival ID; that would be a dataclasm. Things and their attributes are different. 'When is it good sense to put "is" or "are" between two names?... 'When one is the Name of a Thing, and the other the Name of an Attribute (for example, "these Pigs are pink"), since a Thing cannot actually BE an Attribute.' [The Game of Logic, Lewis Carroll, 1897] RFC7292 is the name of a thing. "Informational" is an attribute of the thing. "IETF Stream" is an attribute of the thing. "In downref registry" is an attribute of the thing. RFC3174 is the name of a thing. "Informational" is an attribute of the thing. "Independent Stream" is an attribute of the thing. "In downref registry" is an attribute of the thing. I'm struggling to see a problem here, except that if we disrupt the document ID mechanism, we create a problem. Brian From nobody Sun Jun 24 07:38:22 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDBB130DE5 for ; Sun, 24 Jun 2018 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 yAm-gnFt2g2L for ; Sun, 24 Jun 2018 07:38:17 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 A14EA130E01 for ; Sun, 24 Jun 2018 07:38:17 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id d19-v6so12394950oti.8 for ; Sun, 24 Jun 2018 07:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8vYZqZ0iZ0Lg5FALGWjyf5SQuQQe1R1fKvwjRmWpFYc=; b=PnKQjUZW9ZlWrc0g04m9K7RDKaZ3bjG3PWkgyDw9jVosgxM4eQ3WRJCBiAt4TL7rwJ Wcoc0EZM14Aeu0CNa2MkfB9vfA8SlcmMuQRqddaL1cl5M0QsDdqrJ0lrG3ZhuvNITrtp RNVULDCrBlYSsiw5E3+BcjkziOYwketXuJsy+ny0TweI/Nq7rMNLYroSKeq+zpz4aqkb +p6lmoRscUPuDUN+V2Bd+vZL+wjDHs+zqceKmmhq+HfJj1jVbABKNqYaLKrUcEpmEnOV qahK3WdLbjFCpYocsFpkVhwticuxzRpRXWr6pzHaj/q8BjoDq+RUMVotGi7JUBr7aDzJ 6bOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8vYZqZ0iZ0Lg5FALGWjyf5SQuQQe1R1fKvwjRmWpFYc=; b=Yfs65OQXflRJBQrc4HU/dwZCM54q7Ceor5yZOtgZfPTcBrvvna1h694iNQ+cWy4lC7 x8ZIdrsfz+U4fhwODt6CWiNDMAVLamCiCXh0zlBWeGX96o6NrRQZw99lAkz/NU0UsiZo Jw9appwIg63nTbVniuEL0qSpO0+OHpV8NADzV9if2jh+RHvTotod8Vw5urIk7r1XPuO4 g1sAltNw0QvLAtQoh2401R3xevloECpHLuz1gM5AxBy13u0z1/IznED4DS/wflWVfnZm JpC22BmPXQdZgIbM03ifsU3iBo5L+SIgLDgilYAIA9O9u6Qv+rud0CAZrICRqvhNIj+3 zyBw== X-Gm-Message-State: APt69E0LNzSmajgybTIjM9VLVFaJh7Add51wFBluxWcvHl5cC0z9IB+N BD4CbK6A+tZ0XCqWg2jWoArq7Bw9YL/gkL7R+eQ= X-Google-Smtp-Source: ADUXVKI3ZvncQ7dRVKE2SHM5NNiZlwJeRYxvAuDbisMp/ReLWp0mwZFhi0WiYW89MDCH8Sip95VkaqJ3EDLYYGdWKEQ= X-Received: by 2002:a9d:27a6:: with SMTP id c35-v6mr5761488otb.56.1529851096940; Sun, 24 Jun 2018 07:38:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 07:37:56 -0700 (PDT) In-Reply-To: References: <3cadd2ea-c5e7-5a1a-0feb-8f686721e0c4@cisco.com> From: "Andrew G. Malis" Date: Sun, 24 Jun 2018 10:37:56 -0400 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="000000000000314753056f643701" Archived-At: Subject: Re: [Rfcplusplus] downrefs and labeling X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 14:38:20 -0000 --000000000000314753056f643701 Content-Type: text/plain; charset="UTF-8" +1. Cheers, Andy On Sat, Jun 23, 2018 at 10:52 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 23/06/2018 20:23, Eliot Lear wrote: > > I don't have a strong opinion about whether to do this, but if we do > > here is some food for thought around downrefs. > > > > IETF standards occasionally normatively reference works that are > > informational. These are marked in the downref wiki. Maybe that's > > because even though those documents were marked informational, over the > > course of time, they really turned out to be more than that. We could > > say that some of those informational documents are really de facto > > standards, but that their marking in the downref wiki makes them de > > jure. If we consider this from a labeling perspective, it might be No > > Big Deal. But one might also want to reclassify such documents back to > > RFCs when they hit the wiki. > > (Nit: it's no longer a wiki, it's in the datatracker) > > Yes, that does indicate the benefit of having a single archival series > with consistent document identifiers. As soon as we hypothetically > deviated from that, we would create inconsistencies. > > It's true that adding a document to the downref repository is a form > of promotion (following a Last Call) so it would be rational to > represent it in the document's external metadata. But we can't mess > with its archival ID; that would be a dataclasm. Things and their > attributes are different. > > 'When is it good sense to put "is" or "are" between two names?... > 'When one is the Name of a Thing, and the other the Name of an > Attribute (for example, "these Pigs are pink"), since a Thing > cannot actually BE an Attribute.' > [The Game of Logic, Lewis Carroll, 1897] > > RFC7292 is the name of a thing. > "Informational" is an attribute of the thing. > "IETF Stream" is an attribute of the thing. > "In downref registry" is an attribute of the thing. > > RFC3174 is the name of a thing. > "Informational" is an attribute of the thing. > "Independent Stream" is an attribute of the thing. > "In downref registry" is an attribute of the thing. > > I'm struggling to see a problem here, except that if > we disrupt the document ID mechanism, we create a problem. > > Brian > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus > --000000000000314753056f643701 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1.

Cheers,
Andy

On = Sat, Jun 23, 2018 at 10:52 PM, Brian E Carpenter <brian.e.carpen= ter@gmail.com> wrote:
On 23/06/2018 20:23, Eliot Lear wrote:
> I don't have a strong opinion about whether to do this, but if we = do
> here is some food for thought around downrefs.
>
> IETF standards occasionally normatively reference works that are
> informational.=C2=A0 These are marked in the downref wiki.=C2=A0 Maybe= that's
> because even though those documents were marked informational, over th= e
> course of time, they really turned out to be more than that.=C2=A0 We = could
> say that some of those informational documents are really de facto
> standards, but that their marking in the downref wiki makes them de > jure.=C2=A0 If we consider this from a labeling perspective, it might = be No
> Big Deal.=C2=A0 But one might also want to reclassify such documents b= ack to
> RFCs when they hit the wiki.

(Nit: it's no longer a wiki, it's in the datatracker)

Yes, that does indicate the benefit of having a single archival series
with consistent document identifiers. As soon as we hypothetically
deviated from that, we would create inconsistencies.

It's true that adding a document to the downref repository is a form of promotion (following a Last Call) so it would be rational to
represent it in the document's external metadata. But we can't mess=
with its archival ID; that would be a dataclasm. Things and their
attributes are different.

'When is it good sense to put "is" or "are" between= two names?...
'When one is the Name of a Thing, and the other the Name of an
Attribute (for example, "these Pigs are pink"), since a Thing
cannot actually BE an Attribute.'
[The Game of Logic, Lewis Carroll, 1897]

RFC7292 is the name of a thing.
"Informational" is an attribute of the thing.
"IETF Stream" is an attribute of the thing.
"In downref registry" is an attribute of the thing.

RFC3174 is the name of a thing.
"Informational" is an attribute of the thing.
"Independent Stream" is an attribute of the thing.
"In downref registry" is an attribute of the thing.

I'm struggling to see a problem here, except that if
we disrupt the document ID mechanism, we create a problem.

=C2=A0 =C2=A0 Brian

_______________________________________________
Rfcplusplus mailing list
Rfcplusplus@ietf.org
https://www.ietf.org/mailman/listinfo/rfcplusp= lus

--000000000000314753056f643701-- From nobody Sun Jun 24 23:14:00 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB40130E96 for ; Sun, 24 Jun 2018 23:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 citoOqf1W6Or for ; Sun, 24 Jun 2018 23:13:56 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 14DAA124D68 for ; Sun, 24 Jun 2018 23:13:56 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id w9-v6so13801384otj.7 for ; Sun, 24 Jun 2018 23:13:56 -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=dC9d0BCOMrbYWkKzWaDJScIbDgxsdNR8GZN0V7RqZ0Q=; b=AiBd0iFM95GMr5wckQGxwAWnwrwULeh65w0288xMjdhWCGq+/yyXzW1rnZoye8GuXO Tn7CYSkpkcics66BRcVl+Nkj8mTVKxbGXbLd+Mfolo04v6Fx9kBv05OWOPfvP5Jv2aK6 UiMISXxezEbqOaw2qrHrusWV2/6lMRrxf9HLO0QWCWkK8Z4FQdTMsWip846P6RfZlppW 0bdIIqeHh0BBR3cKwNY34kJYn85AtsNZy9JkyxA4J6wQOAf1VR1En/CyYYU7WrJdlcJC 4k4DQdLQ7N+a8gZyEOgji8XwgAOsT5Ly72GHVBY0ACGmILcZLRpWciWmV5FeqtpgTbPL iBgg== 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=dC9d0BCOMrbYWkKzWaDJScIbDgxsdNR8GZN0V7RqZ0Q=; b=UnnKMeqbib0PZB7YoJ5ZUhD/s7o85d6Yo3EDGSF7/s7vOmxo0LAVM8NTcYk3h/u9KO l/ewmtSWpZ9nwdQkHVaDzE1qgF/6Clh43BGAtE05m2Qk2uPXsfxFevbvC2UbRp2W8+db 1DrZK9RoxoVFMV/t1oGaP2xU4b4VO/wVbfKc3r+EDwSTvFPBXfsndWc5+jFD8gGWFccC 2DRayzBwuTWnLb0VgPJiLMauX7+notdBAUmLKaM0klr7pbI196KwWZni3pRc50Snq8wH k9+x/H0mvMZnMMYTB37HuhwwAFJqU7xs2naweXMAFf3X7smYOPgej73CNDMBd8uEFeAi WaTw== X-Gm-Message-State: APt69E3jMik8e2h9m9ysUf38O0zrskhvkCpsLn4Vmv2/Zb7cItU0kgB0 MSw0KsJmG/GaNPBKAFHixKVDvk2UE1V59gMLvI4= X-Google-Smtp-Source: AAOMgpeaj5N/wQ3qyPqxmv0CBa3DCoYI9m4ZOu26+xCT8vp15bO4XEZkZWardUz//fX35UWrYHhGrKPVQRrFNt/rdz4= X-Received: by 2002:a9d:4044:: with SMTP id o4-v6mr6179300oti.283.1529907235259; Sun, 24 Jun 2018 23:13:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Mon, 25 Jun 2018 16:13:44 +1000 Message-ID: To: Brian E Carpenter Cc: rfcplusplus@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rfcplusplus] The problem space X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 06:13:58 -0000 One thing I've learned from the mail on this list is that there are a lot of problems, not just the one that this BOF was created to examine. For the questions you ask here, the question of quality and status for old RFCs is an issue, certainly. We might improve the situation with the addition of better metadata, and I know the IESG are actively discussing options there, but nothing is concrete. The challenge there is the same root problem: metadata is not part of the immutable record, and is therefore effectively invisible (c.f., STD designations). Of course we could decide that this is a lost cause and rather continue to provide new, relevant publications; including updates to old RFCs (as is happening with TCP now). That way we safeguard the quality of those publications with the constantly fine-tuned processes we use in producing those updates. That compounds some problems, leading to questions over the role of immutable specifications and their interaction with constant refinement of their subjects. Or we could do as we prefer to do with other maintenance efforts and keep the scope small and aim to make incremental improvements. On your scale the problem this group was formed to look at is small, but it could also be easy - not significantly more complex than the RFC 7841 update to RFC boilerplate. I agree that the I* can't decide in isolation, but they have not done so. Nor do the individuals on those bodies strictly agree that the stated goal is the right one. The point of this BOF was to start a discussion with something concrete as a basis. On Sat, Jun 23, 2018 at 2:17 PM Brian E Carpenter wrote: > > Hi, > > Here are 3 slides attempting to offer an overview of the problem space. > There are some blanks for everybody to fill in on slide 2. > > I fear that the problem the BOF proponents are aiming is a small subset > of one part of the space, but it seems to me we have to put it in context. > > Regards > Brian > > > _______________________________________________ > Rfcplusplus mailing list > Rfcplusplus@ietf.org > https://www.ietf.org/mailman/listinfo/rfcplusplus From nobody Tue Jun 26 05:06:32 2018 Return-Path: X-Original-To: rfcplusplus@ietfa.amsl.com Delivered-To: rfcplusplus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECABB130DC9 for ; Tue, 26 Jun 2018 05:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=W2/eEB+H; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CKk19HkK 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 QBHhMw1JU8Mx for ; Tue, 26 Jun 2018 05:06:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 9A146130DC2 for ; Tue, 26 Jun 2018 05:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530014778; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mmtUWMr+hifXaFU28VBHrWb07hs9mmJ7qC2o7hQYfjk=; b=W2/eEB+HYevitV80fUzSjQHksXduP0sIi3b0CghKp/jt9gElAYIF7FhW8Gc34oNu YkGGjSjUSkjp6KjUBnLDDBOg8h06NhSJRlUik2Xbg2ldBUCqwIeTu99XqQ7f70mi i5xEP+DfrfRJi+Xpv305U8XSUFwpvhmtg159PRwljvs=; X-AuditID: c1b4fb25-97bdd9c000007b3f-9b-5b322c392e66 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 61.29.31551.93C223B5; Tue, 26 Jun 2018 14:06:18 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 26 Jun 2018 14:06:17 +0200 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 26 Jun 2018 14:06:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K9FmY/Y5Gjpv6HPMh5FDu61r48JJFD4f4M1gVKJftpc=; b=CKk19HkKGfkuCrGZy9vlBmf3Ovn5733ctkQnNH9yp+EDusDv2bMQ98ZVghMoV8NxliWqYPbdnEfXOkpYVp75V4tEmGUiwUeW4M+BTJyR7hD34/ZlypWoRufwfz0tiHwgUeWnW7QVxvxIjDVYZnED5XOfdGqeW5UkNQAZnE2EMHM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; Received: from [192.168.1.7] (87.93.58.193) by AM4PR0701MB2098.eurprd07.prod.outlook.com (10.167.132.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.13; Tue, 26 Jun 2018 12:06:16 +0000 To: Peter Saint-Andre , Susan Hares , CC: , 'Bob Hinden' References: <01b801d408b8$b0d068c0$12713a40$@ndzh.com> <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> From: Gonzalo Camarillo Message-ID: <5746360b-364e-a77d-56cc-c7767d06a25c@ericsson.com> Date: Tue, 26 Jun 2018 15:06:15 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <794e44e7-3d99-0911-48d2-4592c3ed8293@mozilla.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [87.93.58.193] X-ClientProxiedBy: HE1PR0701CA0078.eurprd07.prod.outlook.com (10.168.122.22) To AM4PR0701MB2098.eurprd07.prod.outlook.com (10.167.132.25) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5f28bd9e-16e0-4914-5c9d-08d5db5d3884 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:AM4PR0701MB2098; X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2098; 3:ZipIPX1LXbfzFmSA6V0apBSNjTlccOBnjZc/eVh/t/dOEWLJ+ruN3f6GUmTnyqzYrwjLWE5J0tX4Xq2pkpV8lHpKFrTLZhmN6A4x7WxzpT6VdJKjMM8HzcyhvqAP1hY40G1rroH+NADO+lHx2eWx7vx3i4PFOEutjXQVWaxVhCzU55Czbvzum8asO42MCkers69wl2BWJciFThK1A5zTaoBUpA+ohDmukl8u6haig4YKTZAStzU6ujvsEet2FtiB; 25:+XVRgXktS2bzzlzVQfIqSRZdbQnB0TKzvUrfwoKXKp/S7nvLwc+elKhV03uFbfy1p/kEoSUjxi0YSV6yWNJFt/Hxl2nVX39/g9EIdlNhieN9WjszAUzZnkHx1bqhKfzZ9FMspBavJnoMi5lzKHJ1TmJuMtuiScZmFkevgIT8CqJv6KejXpvFzTaSReEix8ZVJhZ3aGdXdwKw8Hl+6R2QpvsWDYNIBevDExS3QXC5HuwwdONJ+r3lUFlaHYrMrqj3PFyrRmvYalf8xpWUPhXNwcnQ/SbpLHq/WuxdXaXIRBMNKPpCDCNLBxTfDlBtskKIAUlz/2rNxMgiKWTXuRYMSw==; 31:4fJYhY0xRsFhe70yRdX0jPrMQ1X5swyaM2Bs+H/dSaTUWUegFhg60OLtIXJt93BqhaOd/XcZzA9iafBwJKVNu8bQDaoiOP+BYUqc9iT8hULgS/LzTCgmGgtwfsGR8mMbLzpmCHr3cEcrDXGwdimRg8yw67y95+Gu6h8kJl19i2iREdrtrZjaXgq4uH3++lggZKfN4oVSgvO1BRg9hiqkWOkuS7vLXTuJflwMJ0HuKR4= X-MS-TrafficTypeDiagnostic: AM4PR0701MB2098: X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2098; 20:MPKLdbOKgUXxxKEM8AXKF8DnR9wOH+9e56UFQYgWFQtxnBsNnCuMA1veU6eoNYXrQD5UdFo8fLDFZV0q8mEbNuDvDGDg/kNWaAULUwyhEd0pQbEGvqec3UDCjJgoqb78w753ksjrMK8v7xpwUX0pDlYASxseit7ql9XOmjzJufgURtI+k7HDkDHxHSgRHCURnHmLaRTGC+dDV9QuZB3UnYi+DyXcFSTZ603kjQFX3R9X7MOSsBUqka0nTXKgoWViJpc+es70aFh2t8UFHqmmaIRNi5jaXuu5IZBVvdm6akJOy2Hprfxl99d0uiHzp/1AhzIFndfMeNMQDBfB/VYJYHb4KLWjVo/MF1mfZGctgBV8y2fn+kJgdaZq0S//ic1yxqHD+e1N8aoOiMHQguKARAxcikMKPdRgu88KIAC/rv8hyfkv3AwoQeN0p5BkBmUPhGA6cv+oFcydMWJMUMZVYJ6c/qLAvOv8abau+7UqHxZfy/mBg/he/r0c49t1FYiV; 4:wVNHk+XzGXwpFJZMYVTFlEUxUj3ao3JwKfQnle5q1kZRWq4w49yl9FWx/vkMqdxc0paHKGnSzprmy5U2Q5mXwcEY/ryhswiIoHjxe/tWZFQ/g/XsSB1hGIdAXUT2i+Ju8G+YYhms87/POxqrcYw8yHkLeAu9uqX11w0dW14yULgHIT/7cgLCI3YoiojJH0586fUv6vJxsGuxQOCdEzNdGc/7/Rv6mArwRBwsgXzK4ohnRQM/hdz6Evp+GdcR02QIsGfos+mZKX4lPxHnUhfBkg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:AM4PR0701MB2098; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0701MB2098; X-Forefront-PRVS: 071518EF63 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(136003)(39860400002)(376002)(366004)(396003)(346002)(199004)(189003)(53936002)(50466002)(486006)(11346002)(2616005)(97736004)(186003)(305945005)(446003)(956004)(8936002)(81156014)(478600001)(6246003)(31696002)(86362001)(81166006)(36756003)(77096007)(26005)(16526019)(65826007)(221163002)(64126003)(2906002)(23746002)(476003)(7736002)(31686004)(52116002)(6486002)(6116002)(76176011)(106356001)(8676002)(117156002)(105586002)(110136005)(4326008)(65956001)(5660300001)(65806001)(16576012)(58126008)(66066001)(39060400002)(90366009)(68736007)(47776003)(316002)(230700001)(3846002)(25786009)(386003)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0701MB2098; H:[192.168.1.7]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM4PR0701MB2098; 23:uWYPVIuSvlYnzx5I8CqB5JKyA8D6YgEPF6+?= =?Windows-1252?Q?mvhoUAsLwJARWKFXq9cS0MCC1WI/QuulZXoYWACioI+yP7wwReBIZUDM?= =?Windows-1252?Q?4MzyY5gSKsmkw9ObEovMcoBys1oR5zYIaYcSP3V6UK4ZGZtwA9soKqsO?= =?Windows-1252?Q?7olX51S3xlV5IWldN3l1/Fqvh3CJEEcF6XzxAb7bTi0A1RBqEaUT3Ifc?= =?Windows-1252?Q?0DOABf3aiLk/INtvIHPllGIq7jzJVhDn34THZq6ElGrExxnjp+f5X5bF?= =?Windows-1252?Q?+T5j8Se0+UJE6IY4KYv9dYdGIRibwIprVsjPOnB9ObTDMJ3MWnTglNZG?= =?Windows-1252?Q?b3dSYvnNIrXPBU84h2hWL0SbH9I7mxP/THqTRpsvhJAzbmp23v7ZbSTa?= =?Windows-1252?Q?6Kcy2HUL6ORIcFSGaigwyqKYvsPq+bkiZhrkBPGyWO9y2Swo37YC+FOU?= =?Windows-1252?Q?yb4X5sv5HicoL2fGWGbwd7kg4WxWIa6pZXIWGYbYjl6mLVTvUVDqZk3j?= =?Windows-1252?Q?OvDioOjaebr5PJBXmovGt1POt6BNJNUivYfwIoQ5q8cUlOViCMz2D4RI?= =?Windows-1252?Q?83SKUtX1WWpu44mROCENh4vfF0KyuhXqzjPcN03K0+0SKi0mEjYtrndD?= =?Windows-1252?Q?mZclIttHRAdDaW3dEf+vujtLq+CG2zh3U/ly6EdEAIDu8HNygq0XTwJm?= =?Windows-1252?Q?GmruK5n2bpu+maSIqcd2i0x2T2S40MtEifnSrI3kLa33HGhXBufm+6vm?= =?Windows-1252?Q?yYkZD+PSjw1oIuCe3uUnFM80A4zzJGeIiIDoWjzOoGZwA01Bcs2OTObt?= =?Windows-1252?Q?YTYqLBcNaWCi6ssJ/zRBws2MjPFzBSmzyN8DutnpVmzJZrGAbqej2qtY?= =?Windows-1252?Q?ihijU6w8KYCn/RVbY2CvRAt9EWe71KCq+FnmRi8pshLjSsXsesagiPE0?= =?Windows-1252?Q?9AmN+dof/pw9xR5fvdphNQ7m+0WXL9eNPGCEn1ee85HdRi2ihsNFBKQ3?= =?Windows-1252?Q?Bu+jXMs0UP5IVboMhDmuOHaTpLC3THLDNl1qtKfNrBUebWmHycHu0SiB?= =?Windows-1252?Q?R9us9tXFS+4HsunFFVf85tl7phI9Reui6ALJEftyE+K0DIjkk1qwdDXf?= =?Windows-1252?Q?/GABfvq8U6M5KOWHD+i3D+vKNSdUoZ3Pm602bi+PPFxJARk4Z0859xWf?= =?Windows-1252?Q?Ck5KQV5xQKRmeshwwGqZFn0dA6X/loPwoRo+nXKER5thoYBpPf/NoQKR?= =?Windows-1252?Q?RQbdb1tsk8JQ16t0AbOkapGrFBRFDyf3sQOQVQ+mdLnD+gak7AIxEA/U?= =?Windows-1252?Q?yY6NEVWBtTgku+O3FWSLnsTHkNyXA56ztzUdZ3jbSGifs0GTTV4E/m3e?= =?Windows-1252?Q?Nd8NsJ6iwj0Z9A2+CkTz7G2qD71CDb3NvBqQD3kI4OEcFnTOvH/irYGx?= =?Windows-1252?Q?a2qBHJhz7gRmH7TEEX+8dEm0toc9CN2FcKAzL8jWJjnh8dDMimJw0kZo?= =?Windows-1252?Q?H2GONC6YUG66heiZqdbs/GJxNkZ1YwYGJL8WxLlpKuxqEVnLxGQ=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Antispam-Message-Info: vJ1icxIclLNA0n33bmtU6XuID0na0bgTdo6/3ng0SM/S0DSzT8eIe+ySU8QUw5Wy+WNd4GcIBDA1wDPsuQXIH00hKUCRRxWDXsnCK3DuqqePpuVzckoKUw3HayRGZ4Fd467F7BI27/a02+d7VHHhngXUZZr/eHJpzQViEOsqJFpYZp+zNmvarFtX+sxj1x86zhOCK3smqS1aklvpPi3oxOpIIV2nXCDXRXWnGWuF2J5p2nqg8v3ZpscOuDr+K+JauBmhQrG4Yu/b9ZsITwl6hplWRzGWoJHxy6KpDZFjstj/WkuQT8AN/KnR+KDmu0GC3aLhEpIGNTWYf2K3Y1tM1+k7CohyI9vANmUbGdMXD04= X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2098; 6:x9XbfJnNzmBeN10B/bHI1gB5iTSwVrjnm04ZgtywbGZm902QTbZI4goFJR6iKuv/VLKc40WEIJYT5B63lXq8FoVcwECCJokWziqWLbz9bq2S9fj/mIdb361zucHcTejaxXpsJUZ9YduuiL9xN7vkSJPwSi4k5qwSm6jXgDc+p3BAcqT4TEmuYxQkuSLFQGC3A5JpLd8mZFNg/piEGi2kk/iL6HmgiEOYwlfpLWZtdc5+oC0LPspwvPiMpxYvoKpClOEACXQHMV335lDc0syZKjoUXs+f03VNXdR0PO0Ro3Flam6Oe5q3J84R/PqiM6ruynMuy7EaZpa2dwKzgWPgi54WYmRmm8KnskauKmS+9u3eiDf1Ya5GyFBTtabQln5vWGcYlCk085D8bwgVJOh27ayDaiNHfrDKNWbDVGVWokJCWLLbPU6iq5mwzN3huDEKCQ+qJ1OWBHaExBZuXHIl9A==; 5:hBOekYcyDm+sxzG6EQUeZrG2pw9KE5X2Nop9AyZqEcfy1YQYLDVnzDdDZQsJ9qF3ylW+j8UGvRUexk3mlVXPV31b180wUDaWNYosfUhXZ8z4sIUkRsc70J0XhjI5w941u0tXMXLJz6oWZNasK7u6MhkvFgMblMYQ475oyIhu1r8=; 24:WAAEaLpXNIr23Sw6At/LVbCPezLLdqJgRzIJN5FtuiP2EOn/MBTGytxxCpq1vmNr5W5HGR7W5v2TkZtvVwcTtGvMxernX/Xaf9HdgZYDvzo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2098; 7:83fjZ9XADUOi9A3Ry4VNa0F/7cA2TOcIc3IQcTTf9cdOKizy2n29TyWsD3wtO7OvGdy0QRnkhxp1j3SpEUOGX23AjUg/d9F5fmZwAhzaRAEgG7W02KU6QBoBxPFeWQeh+4izPoN7rprTUgSuVesLV5BvAhv32nNf9nxwo0bMe0x1BCjD8Fs92Pu9Pmo6jHUPIxKyr7/a9k8+bVuO/w9lMPJ90wBR5n5UA4gjsNk7or8OrN3LDD2bvMRpXar7xVX0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2018 12:06:16.4745 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5f28bd9e-16e0-4914-5c9d-08d5db5d3884 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2098 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUyM2J7ua6VjlG0wavZHBY/em4wW2x9v4/N 4uX2Oos/b16xWDxbeYrRgdVj56y77B5Llvxk8ug70MXqMfv1dVaPFZtXMgawRnHZpKTmZJal FunbJXBl7F94jLVgG2vF8umzmBsY17B0MXJySAiYSMw4vA3I5uIQEjjKKHGh8zAzhPONUWL9 nLtsEM4SJonn+9eClbEITGCWONq4jg2kn1EgUeLvvbdQVT8ZJXbt/8QKkhAWUJdYfuAEM4gt IpAi8XvHE7AGZgE7ic4rbUwgtpBAtsThH+fAatgELCS23LoPdhSvgL3Ez89/wWpYBFQljnZN BKsRFYiRWL3xMjtEjaDEyZlPwOo5geovTVvCBDFfT2LH9V+sELa4xK0n86Hi8hLb385hhnha QeLR8xawbyQEuhkl5j09yQhxkLbE5jWnGCGKZCWOnp0DVMQBZPtKTD2lDFF/iVFixvpdbBA1 TewSqyZ4QtToSJx8oAgRvsQmsWGrJoSdL7Fj8iVoYGtJrLv6EeoGOYlTveeYJjAazELyziwk L8xC8sIsJC8sYGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiRGYcA5u+a26g/HyG8dDjAIc jEo8vN4aRtFCrIllxZW5hxglOJiVRHiPvTWMFuJNSaysSi3Kjy8qzUktPsQozcGiJM770Hxz lJBAemJJanZqakFqEUyWiYNTqoHRVPTB10X7Xl31bl27/XDz6x96tfO+fJN9/cVK//1Kdu/u c3PmLN65X/3GlT8OCp8DJs598PYj999zMvGtm0JuONwOnMmwaupTJ9FlsXdXNStOCWP6Ynqv Y0a1u9rs5+/sHOIPxSyKWP/F/Eoldxbr8okajy07ln+1+Vo867rV0fzoWW9mv9zooKDEUpyR aKjFXFScCACkevAVNAMAAA== Archived-At: Subject: Re: [Rfcplusplus] (no subject) X-BeenThere: rfcplusplus@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: For discussion of the RFC++ BoF proposal and related ideas List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 12:06:31 -0000 Hi, >> Micromanaging excellent people is either done by mistake, by >> inflated ego, by intent to provide wanton destruction of an >> organization/process. I suspect this statement will be unpopular >> at the microphone. > > Those are rather strong accusations - so far I have not seen anyone > nihilistically arguing for wanton destruction. And opening up a > perceived problem for community discussion is what we do at the > IETF; that's not exactly micromanagement. Right, let's focus on discussing the issues at hand *constructively*. Let's try and avoid accusations that are unlikely to help advance the conversations we want to have. Thanks! Cheers, Gonzalo