From nobody Mon Oct 14 07:44:58 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D07120106 for ; Mon, 14 Oct 2019 07:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 F9L-asqQiFZZ for ; Mon, 14 Oct 2019 07:44:54 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C01812002F for ; Mon, 14 Oct 2019 07:44:54 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id CFABC182CED34 for ; Mon, 14 Oct 2019 14:44:52 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:41:152:355:379:854:973:988:989:1260:1261:1277:1311:1313:1314:1345:1381:1437:1513:1515:1516:1518:1521:1535:1544:1593:1594:1605:1711:1730:1747:1777:1792:2198:2199:2393:2559:2562:2691:2693:2731:2895:2898:2906:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3874:4031:4119:4184:4250:4362:5007:6117:6119:7652:7901:7903:8660:10004:10848:11658:11914:12109:12114:12297:12663:12679:13019:13148:13160:13161:13192:13200:13229:13230:13618:13869:14180:14195:14877:21060:21063:21067:21080:21212:21324:21433:21627:21740:21790:30005:30041:30054:30070, 0, RBL:72.221.122.28:@doria.org:.lbl8.mailshell.net-62.14.0.100 64.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:24, LUA_SUMMARY:none X-HE-Tag: rifle29_2a8af28d48824 X-Filterd-Recvd-Size: 8188 Received: from [192.168.0.7] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf14.hostedemail.com (Postfix) with ESMTPA for ; Mon, 14 Oct 2019 14:44:52 +0000 (UTC) From: avri@doria.org Autocrypt: addr=avri@doria.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemi yf8Pp8BdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K 1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV 5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOG B8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO7 6/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanx Fk4vCRfjfl8wt27n9xt27ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2HOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmEqG/rIj0w3XfV3bQsDBUU dH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrMMqO7SYUTB6Tx8vIoqmy/ T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq3lrUp2mRzDXBWZLhPVUq x6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006QeZQKfAZinaq3ICEyimWZ bLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wjzrwwsxypxUiEac/7bVwg Ev5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemiyf8Pp8BdIAQZAQIABgUC UleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K1oIc+pxGmr7RUfpOcB63 +1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV5mPBI7kWYNbD99278ZtY TO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOGB8par+/2zKx1MwrZFCnT tlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO76/QFmerwwN89qLAh1pAN oJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanxFk4vCRfjfl8wt27n9xt2 7ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWaSy7OQDKa1N838tTsRVLO MpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBslZea+G2UUV2WSXZPiTci 8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+GjqFR3R2AMLhwK/Nu9uw +cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z6yQ42xcvoUbQ6lLXW0fj NNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPgDoZoktZXmyHIh2E= To: hrpc@irtf.org Message-ID: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> Date: Mon, 14 Oct 2019 10:44:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Antivirus: Avast (VPS 191012-6, 10/12/2019), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 14:44:56 -0000 Hi, Now that the conversation has paused, I believe it is time to say something about the draft and its readiness for RG last call.=C2=A0 In or= der not to bury the lead, my conclusion is that at this time is that it is=C2= =A0 not yet ready.=C2=A0 I will explain First I want to say that I think this is an important piece of work and one that needs to be done right.=C2=A0 I think the most value can be achi= eved by having a document that does justice to the various sides of this important question, and one that points the way to have further discussions about the implications of the question in a balanced,=C2=A0 informed and considered manner. I think the document does a decent job of expressing one side of the argument, though there are places in that discussion that are shy on references and on arguments that logically show why that view should be considered the right argument. Nonetheless the basics of that argument are well established. What I think is missing is an equivalent basis for opposing views. I think the various detailed discussions of disagreement support that view.=C2=A0 Opposing views, while in some cases mentioned an= d even described briefly, are not given the same depth of analysis that is given to the predominant view. In terms of the HRPC RG's view on the document, the group of respondents was split. There are several who think the document is ready to go. There are also as many who think it is not. In my opinion, we have not yet reached rough consensus for publication. I appreciate the speed with which Niels put out versions with the specific fixes he believed necessary to satisfy the arguments, but feel they sometimes missed the point about the document not being a balanced discussion of the issues. I also think we saw that those with a different point of view did not agree with the updated presentation. Regarding the discussion of whether we need RG consensus to publish in the IRSG stream: as I have said several times, I believe that in becoming a RG draft, a private draft becomes subjected to the RG rough consensus process.=C2=A0 It is not that all the issues in the doc need to= have rough consensus agreement, but the document itself needs to be something the RG supports publishing in the IRSG track. This is the same process we followed with RFC8280. It is not as if the IRSG RFC track is the only opportunity people have to publish their ideas or their advocacy. I believe the IRSG RFC track serves as a way for a RGs to publish documents that are supported by the RG's research and discussions. This is something I try to make clear to people when they request that a private draft become a RG draft, I ask whether people wanted the draft to become subject to RG rough consensus because that is a criterion I use in moving the document forward. As I said above, I think this is an important piece of work and think that this RG should be able to produce a well researched and broad document on this subject; one which has often been an elephant in the room in technical discussions. At this point, I think it is only part way there. My current thought is that I would like to see work on this draft continue. I think it might be good to find an additional editor or two to work alongside Niels on taking the next steps on the doc. I am interested in hearing from volunteers for this task.=C2=A0 I would also l= ike to devote some time in Singapore to a discussion of what content is needed to complete the draft and to develop a plan for its completion. The discussion brought up many issues.=C2=A0 I am still working on trying= to abstract a brief view of the issues that people brought up and plan on presenting that as part of the discussion. There were also a few suggestions of what the document still needed, which I would like to explore in open discussion. I appreciate the amount of thought and effort people put into responding to my call for feedback. I also appreciate the amount of Niels' work that has gone into the draft to date. thanks avri From nobody Mon Oct 14 15:18:29 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8014B120907 for ; Mon, 14 Oct 2019 15:18:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yKvd0pNeop62 for ; Mon, 14 Oct 2019 15:18:19 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 251621208FA for ; Mon, 14 Oct 2019 15:18:18 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iK8ew-0001UK-7N for hrpc@irtf.org; Tue, 15 Oct 2019 00:18:16 +0200 To: hrpc@irtf.org References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> From: Niels ten Oever Openpgp: preference=signencrypt Autocrypt: addr=mail@nielstenoever.net; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtChOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+iQJZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI7kCDQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <3ece4eac-7061-23bd-c361-fce9e04deb90@nielstenoever.net> Date: Tue, 15 Oct 2019 00:17:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 63453eee11fb90e6254115624a40dc2b Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 22:18:28 -0000 Thanks for this Avri. May I suggest that the RG appoints a document shepherd that can help advise on the (progress of the) content of the document? The shepherd could identify on which points there is consensus, where it needs more work, and which points are contentious (which might mean they need more work, or that they should be described in the document as points of contention). That could probably help the RG iterate in a constructive and structured fashion, as described in RFC 4858: The shepherd must keep the document moving forward, communicating about it with parties who review and comment on it. The shepherd must obtain the working group's consensus for any substantive proposed changes. The shepherd is the leader for the document and for the working group, and maintains a critical and technical perspective. In summary, the Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has done while responsible for the document in the working group. Best, Niels On 10/14/19 4:44 PM, avri@doria.org wrote: > Hi, > > Now that the conversation has paused, I believe it is time to say > something about the draft and its readiness for RG last call.  In order > not to bury the lead, my conclusion is that at this time is that it is  > not yet ready.  I will explain > > First I want to say that I think this is an important piece of work and > one that needs to be done right.  I think the most value can be achieved > by having a document that does justice to the various sides of this > important question, and one that points the way to have further > discussions about the implications of the question in a balanced,  > informed and considered manner. > > I think the document does a decent job of expressing one side of the > argument, though there are places in that discussion that are shy on > references and on arguments that logically show why that view should be > considered the right argument. Nonetheless the basics of that argument > are well established. What I think is missing is an equivalent basis for > opposing views. I think the various detailed discussions of disagreement > support that view.  Opposing views, while in some cases mentioned and > even described briefly, are not given the same depth of analysis that is > given to the predominant view. > > In terms of the HRPC RG's view on the document, the group of respondents > was split. There are several who think the document is ready to go. > There are also as many who think it is not. In my opinion, we have not > yet reached rough consensus for publication. > > I appreciate the speed with which Niels put out versions with the > specific fixes he believed necessary to satisfy the arguments, but feel > they sometimes missed the point about the document not being a balanced > discussion of the issues. I also think we saw that those with a > different point of view did not agree with the updated presentation. > > Regarding the discussion of whether we need RG consensus to publish in > the IRSG stream: as I have said several times, I believe that in > becoming a RG draft, a private draft becomes subjected to the RG rough > consensus process.  It is not that all the issues in the doc need to > have rough consensus agreement, but the document itself needs to be > something the RG supports publishing in the IRSG track. This is the same > process we followed with RFC8280. It is not as if the IRSG RFC track is > the only opportunity people have to publish their ideas or their > advocacy. I believe the IRSG RFC track serves as a way for a RGs to > publish documents that are supported by the RG's research and > discussions. This is something I try to make clear to people when they > request that a private draft become a RG draft, I ask whether people > wanted the draft to become subject to RG rough consensus because that is > a criterion I use in moving the document forward. > > As I said above, I think this is an important piece of work and think > that this RG should be able to produce a well researched and broad > document on this subject; one which has often been an elephant in the > room in technical discussions. At this point, I think it is only part > way there. > > My current thought is that I would like to see work on this draft > continue. I think it might be good to find an additional editor or two > to work alongside Niels on taking the next steps on the doc. I am > interested in hearing from volunteers for this task.  I would also like > to devote some time in Singapore to a discussion of what content is > needed to complete the draft and to develop a plan for its completion. > The discussion brought up many issues.  I am still working on trying to > abstract a brief view of the issues that people brought up and plan on > presenting that as part of the discussion. There were also a few > suggestions of what the document still needed, which I would like to > explore in open discussion. > > I appreciate the amount of thought and effort people put into responding > to my call for feedback. I also appreciate the amount of Niels' work > that has gone into the draft to date. > > thanks > > avri > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Niels ten Oever Researcher and PhD Candidate DATACTIVE Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Mon Oct 14 15:44:08 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426A81208A7 for ; Mon, 14 Oct 2019 15:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.20150623.gappssmtp.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 qMUErgfgrha7 for ; Mon, 14 Oct 2019 15:44:04 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 2DBA7120893 for ; Mon, 14 Oct 2019 15:44:04 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id x127so11163684pfb.7 for ; Mon, 14 Oct 2019 15:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=BVA35QeRd/klL2L9d7kAMy0lpUHpcw9DF3w2WbkpkJE=; b=oPl/GAMc5Bhe9GixgIIpBMJmGH/woS+pwLzc4pDlbOU1b2/DsFHxRdQeQHxYBhq/1H Vz5bWLRM8sL2mX7PwieZkVpJYCG0qQ6vTbPXV+KDEsG16SNV9zB6Vc5SRQeBowNVxKpQ sStP6Jr2q1G3IFDPwd0hYHX5RWTc3HglpvlH5kmkfNwsx7dGo39MxgsEYwnY7zLOhb6C SBrUo2E2vZhbNbqdkiPu1OZhlGuB62hwNopWjMGw9045Gn2wOpV6Z5Ccl0dUguclDgqg N6kiubXhJfWg//JfkGhDJI5x505N4E6si/N1MPX2Lqqsn5WSjCBF9YijAgIIqItoR6lV UhQw== 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=BVA35QeRd/klL2L9d7kAMy0lpUHpcw9DF3w2WbkpkJE=; b=LOnsN9YD+lTlF8Y/Kvc+NdJCjzUDQW/KjBT/gCFWHtukQbJTMhk2phxbwENJkHvEc2 KDpvMCi1pyqfucn+RmSjFuQYDmi+CmD6J0gyv0JNW4S/iXzdS3KTT3KLWEJIIRFcQMx9 CNPsBmYQP7RdxlKC3hfXusJJWuR1L81z9uJKJX6ZhzCD+rVnY/Fxr88zKt29tJQQeL75 fTAVSkDIKIfHZMyKvetncrMSAKcHiv1IwZqBnB/++u2qZ/bKfVKK5d3D85NNmsDC78ro b/VIpNJWJeWs1E/E1URXL1ypX8Tf2splU0daW3BVqN26MM6Xc1UNDczsPLMfFcPToFyt CbMA== X-Gm-Message-State: APjAAAUCSZOHH+FehoTNXmkFdvK3RV7MIR25K306oWvFxZAjakyeBskY tXgeBpnOZYAts3a4UbCD7+YqXLJ4YQ== X-Google-Smtp-Source: APXvYqynDe37skQ3kxOKb0IunRNZCunIkKYotfUJImD3xBIi8Ar45ea7Tk4aXFScBJD+/QvfHDFziQ== X-Received: by 2002:a65:50c5:: with SMTP id s5mr33467271pgp.52.1571093042633; Mon, 14 Oct 2019 15:44:02 -0700 (PDT) Received: from aspen.local (63-140-65-24.dynamic.lte.acsalaska.net. [63.140.65.24]) by smtp.gmail.com with ESMTPSA id 11sm18201089pgd.0.2019.10.14.15.44.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Oct 2019 15:44:01 -0700 (PDT) To: hrpc@irtf.org References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> <3ece4eac-7061-23bd-c361-fce9e04deb90@nielstenoever.net> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: Date: Mon, 14 Oct 2019 14:43:59 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <3ece4eac-7061-23bd-c361-fce9e04deb90@nielstenoever.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ouINnKIxQs6chCE68sfdAKl4kCC9hUqkO" Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 22:44:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ouINnKIxQs6chCE68sfdAKl4kCC9hUqkO Content-Type: multipart/mixed; boundary="eD9z87IAixKZhwpKWLb5z40eKMHARmDFK"; protected-headers="v1" From: Melinda Shore To: hrpc@irtf.org Message-ID: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> <3ece4eac-7061-23bd-c361-fce9e04deb90@nielstenoever.net> In-Reply-To: <3ece4eac-7061-23bd-c361-fce9e04deb90@nielstenoever.net> --eD9z87IAixKZhwpKWLb5z40eKMHARmDFK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/14/19 2:17 PM, Niels ten Oever wrote: > That could probably help the RG iterate in a constructive and > structured fashion, as described in RFC 4858: RFC 4858 describes a document shepherd's responsibilities once a document has cleared WG last call and is moving through IESG review, IETF last call, and so on, and I'm not sure is quite the right model for dealing with contentious documents. It's also the case that at the working group level, only chairs determine consensus. That said, this is an RG and not an IETF working group and I think (and Colin can correct me if I'm wrong) RG chairs have broad latitude when it comes to process. Personally, I'm not fond of institutionalizing more roles and more process than is really needed, and I think that many if not all of the concerns you've raised here and that Avri raised in her message can be addressed by the addition of a suitable (fsvo) co-editor. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --eD9z87IAixKZhwpKWLb5z40eKMHARmDFK-- --ouINnKIxQs6chCE68sfdAKl4kCC9hUqkO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl2k+i8ACgkQ37iRcpp2 24/lYhAAmm1fhkLQ4lZID9RNNKZMEe3JZimxHZEESL6EyeE37Fse5dJWzM5zDTLN 4hjnvpkO0HlpUb8n+g6hMjAxuwEqZNIdfD8nw5LauCMPiKkWCnFRthlrv+3ZNoK7 d2+L5UN9vKtuJl3/TAQ5RnhA9z6i/Ub9iyuqMsraSkbrxd07GbdT+TOoiulegXnN u+1dFwF93Vh/UnXQWjZz+WqpJBrA7Nj5yveT6R3UHXWKXoWYkIAjYguQUIBI0Uqh 1hP+hHB3r6cYW8LrZ3lHMZ/4RwBgxXw3bL2RR2SeZn1zrTN+imOVNP4gQltUzWKZ hpahPCE3TFZsYG85QXVREubDiqiWmhU3Moj/KYkG0jiWrTr14UCQJqbk7jm3k6ZC ZEScKL5UZdsfQxCcCBZ863iU8IR3JOwtj4rHNcz80nLclI6sqEJLQdeHT481Y+wC g41sKD17qpgUD6ovJOdXtX6rAjMLzl1+6IJDQrvZGivjfTKaUrWNzIiX/Fie1jJL K8EHE/sRtVnOr4xmRq0YZKSInRqX6Fh3f2/u3Zptb7AaWVFab8nQmliBpIgZ/AN8 Q05b6D698Do+2QaPqmlD1tWVf+Uanau3wYXqwtLzuje5ZBzvOq883gOEs7ZkWgPV BymILMMisHKlRhSOX8bUWV87hfbmAQPdjh9Sv/3Inq4JWy364Pw= =NVlR -----END PGP SIGNATURE----- --ouINnKIxQs6chCE68sfdAKl4kCC9hUqkO-- From nobody Mon Oct 14 20:59:54 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D9712009E for ; Mon, 14 Oct 2019 20:59:52 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uohYSCShM2K for ; Mon, 14 Oct 2019 20:59:50 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 33A0F120077 for ; Mon, 14 Oct 2019 20:59:50 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id m15so28660436qtq.2 for ; Mon, 14 Oct 2019 20:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aANg5tyyG97fONreb3h8HzCOQLMghXdR4AZnozlGvuA=; b=ILcw9DhZWBGQ6GoHBNmxAAuwBKGHlT0YgGV95/myGZHcTW1l/2UKyBSRUialSkswz8 mnS5vW6qiPUhQo+ZklXPdg+Jc5sRCiqfTJAZaR6DK0fETXGzTCDnwtJ1fzgp0e0cbn+0 jkxJ92tmNJL3TpDqmARjErfhVYwN1iatHRuTpWlza16Z/DqEvKhFBlv/USlS3VD9CRCM B31rxrldSUNk3d8HGhzDL002Fy9n9v3zgJ5rJ8ft7GLMAYkN3PiBO5li/+CTpxM729bw D5G/JgPTW+V4x1XNg121EpwlMUs7Pd3aNUGLFGyattcFihvE4GWZJMwH3Iraj6pAJZER f4Kw== 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=aANg5tyyG97fONreb3h8HzCOQLMghXdR4AZnozlGvuA=; b=D0d8yCvAwP3R6ijZTQsmgVRaVTx6IrDFBXzbGbe+PkPiLUtWOyGR+Njwnh9f13vTWE NQiXLxmt5REy6BHqzj/EOqVjGXyiWCz2GDOv2Rmv42lTH/G82iw15eDDwmy0TsSRyjED yylUcdnqZhUR1Gc9UEP2oycxVPtexo7q7pcxFzRBQztUdAfRHMkIbAEuXKDlghBGqpFa jHrrLeI18TW5KvPgLT/uFr9vEPv5qb+mqtKnUs51JcQckUniF8oz18Z+541Q4ZVRsgpa 9JPyNzfC8pbN9IoK5hGVSia+lGqpfrsmn4ANbHvgO7E0uAE1TJbUf7L/7XnZxM02G7/3 4UgA== X-Gm-Message-State: APjAAAXxg6g7N/y3DnxuKXlcx0kEqFwKnj8EiN88porivprq4Lr8KxIQ gqDoIS1rYI6EBisFNhAyCB1mYZ3gHkRuXDaVogASaIMB X-Google-Smtp-Source: APXvYqwPq0etYfzBJ/9Coe0Qrq6leMZHk3pKWR06Tr88RbtniHZv6jWgQgmRu+wiUZYiujs3degs66Th7JRVKg2hUgs= X-Received: by 2002:ac8:3823:: with SMTP id q32mr35787987qtb.20.1571111987875; Mon, 14 Oct 2019 20:59:47 -0700 (PDT) MIME-Version: 1.0 References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> In-Reply-To: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> From: farzaneh badii Date: Mon, 14 Oct 2019 23:59:19 -0400 Message-ID: To: "avri@acm.org" Cc: hrpc@irtf.org Content-Type: multipart/alternative; boundary="000000000000f093920594eb033d" Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 03:59:52 -0000 --000000000000f093920594eb033d Content-Type: text/plain; charset="UTF-8" I think Avri has accurately captured the discussion. Having a couple of co-editors would be good. Best Farzaneh On Mon, Oct 14, 2019 at 10:45 AM wrote: > Hi, > > Now that the conversation has paused, I believe it is time to say > something about the draft and its readiness for RG last call. In order > not to bury the lead, my conclusion is that at this time is that it is > not yet ready. I will explain > > First I want to say that I think this is an important piece of work and > one that needs to be done right. I think the most value can be achieved > by having a document that does justice to the various sides of this > important question, and one that points the way to have further > discussions about the implications of the question in a balanced, > informed and considered manner. > > I think the document does a decent job of expressing one side of the > argument, though there are places in that discussion that are shy on > references and on arguments that logically show why that view should be > considered the right argument. Nonetheless the basics of that argument > are well established. What I think is missing is an equivalent basis for > opposing views. I think the various detailed discussions of disagreement > support that view. Opposing views, while in some cases mentioned and > even described briefly, are not given the same depth of analysis that is > given to the predominant view. > > In terms of the HRPC RG's view on the document, the group of respondents > was split. There are several who think the document is ready to go. > There are also as many who think it is not. In my opinion, we have not > yet reached rough consensus for publication. > > I appreciate the speed with which Niels put out versions with the > specific fixes he believed necessary to satisfy the arguments, but feel > they sometimes missed the point about the document not being a balanced > discussion of the issues. I also think we saw that those with a > different point of view did not agree with the updated presentation. > > Regarding the discussion of whether we need RG consensus to publish in > the IRSG stream: as I have said several times, I believe that in > becoming a RG draft, a private draft becomes subjected to the RG rough > consensus process. It is not that all the issues in the doc need to > have rough consensus agreement, but the document itself needs to be > something the RG supports publishing in the IRSG track. This is the same > process we followed with RFC8280. It is not as if the IRSG RFC track is > the only opportunity people have to publish their ideas or their > advocacy. I believe the IRSG RFC track serves as a way for a RGs to > publish documents that are supported by the RG's research and > discussions. This is something I try to make clear to people when they > request that a private draft become a RG draft, I ask whether people > wanted the draft to become subject to RG rough consensus because that is > a criterion I use in moving the document forward. > > As I said above, I think this is an important piece of work and think > that this RG should be able to produce a well researched and broad > document on this subject; one which has often been an elephant in the > room in technical discussions. At this point, I think it is only part > way there. > > My current thought is that I would like to see work on this draft > continue. I think it might be good to find an additional editor or two > to work alongside Niels on taking the next steps on the doc. I am > interested in hearing from volunteers for this task. I would also like > to devote some time in Singapore to a discussion of what content is > needed to complete the draft and to develop a plan for its completion. > The discussion brought up many issues. I am still working on trying to > abstract a brief view of the issues that people brought up and plan on > presenting that as part of the discussion. There were also a few > suggestions of what the document still needed, which I would like to > explore in open discussion. > > I appreciate the amount of thought and effort people put into responding > to my call for feedback. I also appreciate the amount of Niels' work > that has gone into the draft to date. > > thanks > > avri > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > --000000000000f093920594eb033d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Avri has accurately captured the discussion.=C2=A0

=
Having a couple of co-editors would be good.

Best=C2=A0
=

<= div>
Farzaneh


=
On Mon, Oc= t 14, 2019 at 10:45 AM <avri@doria.org= > wrote:
= Hi,

Now that the conversation has paused, I believe it is time to say
something about the draft and its readiness for RG last call.=C2=A0 In orde= r
not to bury the lead, my conclusion is that at this time is that it is=C2= =A0
not yet ready.=C2=A0 I will explain

First I want to say that I think this is an important piece of work and
one that needs to be done right.=C2=A0 I think the most value can be achiev= ed
by having a document that does justice to the various sides of this
important question, and one that points the way to have further
discussions about the implications of the question in a balanced,=C2=A0
informed and considered manner.

I think the document does a decent job of expressing one side of the
argument, though there are places in that discussion that are shy on
references and on arguments that logically show why that view should be
considered the right argument. Nonetheless the basics of that argument
are well established. What I think is missing is an equivalent basis for opposing views. I think the various detailed discussions of disagreement support that view.=C2=A0 Opposing views, while in some cases mentioned and<= br> even described briefly, are not given the same depth of analysis that is given to the predominant view.

In terms of the HRPC RG's view on the document, the group of respondent= s
was split. There are several who think the document is ready to go.
There are also as many who think it is not. In my opinion, we have not
yet reached rough consensus for publication.

I appreciate the speed with which Niels put out versions with the
specific fixes he believed necessary to satisfy the arguments, but feel
they sometimes missed the point about the document not being a balanced
discussion of the issues. I also think we saw that those with a
different point of view did not agree with the updated presentation.

Regarding the discussion of whether we need RG consensus to publish in
the IRSG stream: as I have said several times, I believe that in
becoming a RG draft, a private draft becomes subjected to the RG rough
consensus process.=C2=A0 It is not that all the issues in the doc need to have rough consensus agreement, but the document itself needs to be
something the RG supports publishing in the IRSG track. This is the same process we followed with RFC8280. It is not as if the IRSG RFC track is
the only opportunity people have to publish their ideas or their
advocacy. I believe the IRSG RFC track serves as a way for a RGs to
publish documents that are supported by the RG's research and
discussions. This is something I try to make clear to people when they
request that a private draft become a RG draft, I ask whether people
wanted the draft to become subject to RG rough consensus because that is a criterion I use in moving the document forward.

As I said above, I think this is an important piece of work and think
that this RG should be able to produce a well researched and broad
document on this subject; one which has often been an elephant in the
room in technical discussions. At this point, I think it is only part
way there.

My current thought is that I would like to see work on this draft
continue. I think it might be good to find an additional editor or two
to work alongside Niels on taking the next steps on the doc. I am
interested in hearing from volunteers for this task.=C2=A0 I would also lik= e
to devote some time in Singapore to a discussion of what content is
needed to complete the draft and to develop a plan for its completion.
The discussion brought up many issues.=C2=A0 I am still working on trying t= o
abstract a brief view of the issues that people brought up and plan on
presenting that as part of the discussion. There were also a few
suggestions of what the document still needed, which I would like to
explore in open discussion.

I appreciate the amount of thought and effort people put into responding to my call for feedback. I also appreciate the amount of Niels' work that has gone into the draft to date.

thanks

avri



_______________________________________________
hrpc mailing list
hrpc@irtf.org
https://www.irtf.org/mailman/listinfo/hrpc
--000000000000f093920594eb033d-- From nobody Tue Oct 15 00:13:01 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A8912004F for ; Tue, 15 Oct 2019 00:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, 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 9_hmQ5uVMNgN for ; Tue, 15 Oct 2019 00:12:57 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF383120041 for ; Tue, 15 Oct 2019 00:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7241; q=dns/txt; s=iport; t=1571123576; x=1572333176; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=yzDpwJf/ZX3rvo86Oco+Ru/0XoQBaHnfI2+l4+xRRAg=; b=S99zCsUb8DvmjGkfXH8ve+I2Vk5QN1e94Caa4IOo6065jBsl+A5xQNJI lEaCsmVE49hJ90fZlCWFrsCSEGpF/zc0LIeZydkpTg6y51sduGet8R3wK lSBgySwYHJXsf5sxxg6O28KEObvI3qf+fOETsonEq9bt4GM8RGRLbFFFU I=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AgAucKVd/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFqAgEBAQELAYMLUwEgEiqEJYkChUOCKpMdiAo?= =?us-ascii?q?CBwEBAQkDAQEnCAEBhEACTAEEgjg3Bg4CAwkBAQQBAQECAQUEbYUtDIIogyM?= =?us-ascii?q?BAQEBAQEBI1YFCwsYKgICVxmDIgGCVyAPrWJ1gTKFTYRjEIE0AYFSihU+gX+?= =?us-ascii?q?BEScfgU5+PoJhAwGEbTKCLASWKJccgiyCL4ETg0aOERuCOnKGXI84hDiSGY4?= =?us-ascii?q?DgxMCBAYFAhWBPykjgUMNCDMaCBsVZQGCQQk1EhAUgVsXFYQliWs/AzABAZB?= =?us-ascii?q?uAQE?= X-IronPort-AV: E=Sophos;i="5.67,298,1566864000"; d="asc'?scan'208,217";a="17949302" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2019 07:12:54 +0000 Received: from ams3-vpn-dhcp6299.cisco.com (ams3-vpn-dhcp6299.cisco.com [10.61.88.154]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x9F7Cqba016635 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Oct 2019 07:12:53 GMT From: Eliot Lear Message-Id: <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D20E7B01-2C85-46D7-9DCA-242AB106BD7A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 15 Oct 2019 09:12:51 +0200 In-Reply-To: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> Cc: hrpc@irtf.org To: avri@doria.org References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.88.154, ams3-vpn-dhcp6299.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 07:12:59 -0000 --Apple-Mail=_D20E7B01-2C85-46D7-9DCA-242AB106BD7A Content-Type: multipart/alternative; boundary="Apple-Mail=_93C4D75C-36A0-47CD-988C-F9F1A7705487" --Apple-Mail=_93C4D75C-36A0-47CD-988C-F9F1A7705487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Avri, First, I appreciate the level of effort that Niels is putting into this = work. I want to take issue with two points you made: > On 14 Oct 2019, at 16:44, avri@doria.org wrote: >=20 > I think the document does a decent job of expressing one side of the > argument, though there are places in that discussion that are shy on > references and on arguments that logically show why that view should = be > considered the right argument. To me this was never about =E2=80=9Csides=E2=80=9D. To begin with there = may be a great many sides. Regardless, once there is a clear and bounded research question, = reasonable argumentation and references, and a bounded conclusion, = regardless of whether I agree with the work, I am comfortable with it = being published. Some might want to publish opposing argument. So long = as we as a group are open to those publications as well, why would it be = necessary to hold up this work? Having written an economic and policy paper with people who had opposite = views[1]*, I don=E2=80=99t recommend the practice. One gets into all = sorts of arguments about methodology and reference quality etc with = one=E2=80=99s co-authors, and for what? What is the value of such a = work over two separate works? Which brings me to my next point: >=20 > Regarding the discussion of whether we need RG consensus to publish in > the IRSG stream: as I have said several times, I believe that in > becoming a RG draft, a private draft becomes subjected to the RG rough > consensus process. Yes, you have said this. I do not recall you saying why you would take = this approach. Can we please have a discussion as to whether this is = the best way forward? What is the value of rough consensus in this = case? Or perhaps I should ask that question differently: on what do you = seek rough consensus: the positions in the document or whether it is = simply in good enough form to be sent up to the IRSG? The latter is a = whole lot easier to get to. Eliot *I did it once and not again because of the arguments between authors. [1] = http://people.csail.mit.edu/wlehr/Lehr-Papers_files/Lehr%20Lear%20Vest%20T= PRC08%20Internet%20Address%20Running%20on%20Empty.pdf = --Apple-Mail=_93C4D75C-36A0-47CD-988C-F9F1A7705487 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Avri,

First, I = appreciate the level of effort that Niels is putting into this work. =  I want to take issue with two points you made:

On 14 Oct 2019, at 16:44, avri@doria.org wrote:

I think the document does a decent job of = expressing one side of the
argument, though there are = places in that discussion that are shy on
references and = on arguments that logically show why that view should be
considered the right argument. =

To me this was = never about =E2=80=9Csides=E2=80=9D.  To begin with there may be a = great many sides.

Regardless, once = there is a clear and bounded research question, reasonable argumentation = and references, and a bounded conclusion, regardless of whether I agree = with the work, I am comfortable with it being published.  Some = might want to publish opposing argument.  So long as we as a group = are open to those publications as well, why would it be necessary to = hold up this work?

Having written an = economic and policy paper with people who had opposite views[1]*, I = don=E2=80=99t recommend the practice.  One gets into all sorts of = arguments about methodology and reference quality etc with one=E2=80=99s = co-authors, and for what?  What is the value of such a work over = two separate works?

Which brings me = to my next point:


Regarding the = discussion of whether we need RG consensus to publish in
the= IRSG stream: as I have said several times, I believe that in
becoming a RG draft, a private draft becomes subjected to the = RG rough
consensus = process. 

Yes,= you have said this.  I do not recall you saying why you would take = this approach.  Can we please have a discussion as to whether this = is the best way forward?  What is the value of rough consensus in = this case?  Or perhaps I should ask that question differently: on = what do you seek rough consensus: the positions in the document or = whether it is simply in good enough form to be sent up to the IRSG? =  The latter is a whole lot easier to get to.

Eliot

*I = did it once and not again because of the arguments between = authors.

=


= --Apple-Mail=_93C4D75C-36A0-47CD-988C-F9F1A7705487-- --Apple-Mail=_D20E7B01-2C85-46D7-9DCA-242AB106BD7A 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2lcXMACgkQh7ZrRtnS ejPk/QgAmCo1IoKD0SgCvOJYTft3xKklIkJZgfwCE0j0iSqH+trJEnwZukKn+Q8g g/DdNC9yZJHjzQOWK2+LzrbWXiHWzSw+GSxPZHbhpQ3yC6godIc/UGtr+uKY6kz8 akjrC6eJFHEAVvyynvJG2cN5IYhw5BFNc1ZbkcocW6qfkXvEoJL9JqHvKnP2izow TuudrfN9oz70M+K+308gE2DdSXD94K9X+J7fS5bwl9xBzvak2I5F1wweS/xuFX67 pzBFOsEFNI+l3KC3umSKs9b9GgNhv9e6mVMx0Zlldlexd1/cqCCFf5F8bXb9NHda 8a5Rca9CYU/iOeLe/HQ/nlqLwmZiGQ== =3ChC -----END PGP SIGNATURE----- --Apple-Mail=_D20E7B01-2C85-46D7-9DCA-242AB106BD7A-- From nobody Tue Oct 15 06:21:46 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F76B1200FB for ; Tue, 15 Oct 2019 06:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 0gZnyf-6iwVQ for ; Tue, 15 Oct 2019 06:21:38 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 359E212004C for ; Tue, 15 Oct 2019 06:21:38 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id a22so20256699ljd.0 for ; Tue, 15 Oct 2019 06:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z9iWhDzmJ2/12viiXSiC0GLFXUfkw22LPtV2SNzmIyc=; b=XFFPYTOyfed0wRg4hnvw6bYcoAc15HXFNzVV5ThUpJCyjM7iXsDHjbKPMCs+hlETjK ae87vlQexcxaob5TRKhPJozdEmwpthfPo3jwMGPuOlPdrx6J16dCHY4k4HKfPk/lW2bf yUQzb+l84EfSZiQ20LAaysS2Fhywb1rmczQ22/q17GTL7MQ7gGzWk093nD9q+Y1XBIK1 VQUwtSkAMr1W8dKieNIHefijLrRBLA/RwhC0GFKbbMiX6PL3MhRxCT3KKHu3e2R/HMTM KwcQx8udk7wPU2ivnkyBqrl0j27Hfj7C+3kk+kjIbdh5MrlPcGJla927TtFoV3XgI0Gd ZX/Q== 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=Z9iWhDzmJ2/12viiXSiC0GLFXUfkw22LPtV2SNzmIyc=; b=Ddvqa1gAfQAab9unBcKVvyqYT0Hwew3oPX3KP0XY5e5uvY8MCHRAF9fLU1y6LkM/H7 2X/zxB2o9Zcazf/Umgt3F5q2iwKnnHJYrHJSs0/UMhb8h8RHZpOL1ME2uIAUDp62b0Kk 5IzZUF05ZF8E8zCEbbTsgXdnc4pA/2ebsSt4fp1k6miVdNbGLPDAO+EenZOUjIJEQMi9 Wc+BvtO0cLpWHRvVZsgbzDUkinU3UITaEGQrsP8ZD3mzeNmRVfVpeYgmGS+UVG2qeO0B GSllAGH8Sg8ZJ9FlVTK9Tt3MtordV+DdMbrNNcxgoTKWCGZ6VFiilu3rQE44aQtk7Doh wCGw== X-Gm-Message-State: APjAAAXKlQROwN92SgTnJUOlMqYEnj0aaY21RUst4c5PDHCNQUtuavq3 +1P2/X0K0i98LrsRGt01hBQ9icpa5IX3VJaxgAN3ZA== X-Google-Smtp-Source: APXvYqwfUIt9QE7gGs7fC3mx4hblyIOU1pPZNT1n32+HU9f2LpsKVrV7yVUQNnrOwTZJJPSN+HUlKHWj1faPQEO/wsY= X-Received: by 2002:a05:651c:237:: with SMTP id z23mr16536276ljn.93.1571145696282; Tue, 15 Oct 2019 06:21:36 -0700 (PDT) MIME-Version: 1.0 References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> In-Reply-To: <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> From: Eric Rescorla Date: Tue, 15 Oct 2019 06:20:59 -0700 Message-ID: To: Eliot Lear Cc: avri@doria.org, hrpc@irtf.org Content-Type: multipart/alternative; boundary="0000000000001e1f640594f2dd77" Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 13:21:43 -0000 --0000000000001e1f640594f2dd77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I concur partially with Eliot: i don't think this is about sides. I actually suspect that Niels and I agree to a fair extent about the political nature of standards development. My concern is not that but rather whether this document makes interesting/useful claims and whether it supports them with evidence. At present, it's not clear to me that it does so, or really even what point it is trying to make. On Tue, Oct 15, 2019 at 12:13 AM Eliot Lear wrote: > Hi Avri, > > First, I appreciate the level of effort that Niels is putting into this > work. I want to take issue with two points you made: > > On 14 Oct 2019, at 16:44, avri@doria.org wrote: > > I think the document does a decent job of expressing one side of the > argument, though there are places in that discussion that are shy on > references and on arguments that logically show why that view should be > considered the right argument. > > > To me this was never about =E2=80=9Csides=E2=80=9D. To begin with there = may be a great > many sides. > > Regardless, once there is a clear and bounded research question, > reasonable argumentation and references, and a bounded conclusion, > regardless of whether I agree with the work, I am comfortable with it bei= ng > published. Some might want to publish opposing argument. So long as we = as > a group are open to those publications as well, why would it be necessary > to hold up this work? > > Having written an economic and policy paper with people who had opposite > views[1]*, I don=E2=80=99t recommend the practice. One gets into all sor= ts of > arguments about methodology and reference quality etc with one=E2=80=99s > co-authors, and for what? What is the value of such a work over two > separate works? > > Which brings me to my next point: > > > Regarding the discussion of whether we need RG consensus to publish in > the IRSG stream: as I have said several times, I believe that in > becoming a RG draft, a private draft becomes subjected to the RG rough > consensus process. > > > Yes, you have said this. I do not recall you saying why you would take > this approach. Can we please have a discussion as to whether this is the > best way forward? What is the value of rough consensus in this case? Or > perhaps I should ask that question differently: on what do you seek rough > consensus: the positions in the document or whether it is simply in good > enough form to be sent up to the IRSG? The latter is a whole lot easier = to > get to. > Well, "good enough to send to the IRSG" needs to be judged against some standard. In any case, having the document be an RFC under the IRTF stream involves a certain amount of endorsement and so I would want there to be some level of consensus that the we had confidence in the statements in the document (just as I would want if I were to be on the PC of a conference which was considering this as a submission). -Ekr --0000000000001e1f640594f2dd77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I concur partially with Eliot: i don't think this= is about sides. I actually suspect that Niels and I agree to a fair extent= about the political nature of standards development. My concern is not tha= t but rather whether this document makes interesting/useful claims and whet= her it supports them with evidence. At present, it's not clear to me th= at it does so, or really even what point it is trying to make.

On Tue, Oct 15, 2019 at 12:13 AM Eliot Lear <lear@cisco.com> wrote:
Hi Avri,
First, I appreciate the level of effort that Niels is put= ting into this work.=C2=A0 I want to take issue with two points you made:

On 14 Oct 2019, at 16:44, avri@doria.org wrote:

I think the document does a decent job of expressing one sid= e of the
argument, though there are places in that discussion that are s= hy on
references and on arguments that logically show why that view shou= ld be
considered the right argument.

<= /div>
To me this was never about =E2=80=9Csides=E2=80=9D.=C2=A0 To begi= n with there may be a great many sides.

Regardless= , once there is a clear and bounded research question, reasonable argumenta= tion and references, and a bounded conclusion, regardless of whether I agre= e with the work, I am comfortable with it being published.=C2=A0 Some might= want to publish opposing argument.=C2=A0 So long as we as a group are open= to those publications as well, why would it be necessary to hold up this w= ork?

Having written an economic and policy paper w= ith people who had opposite views[1]*, I don=E2=80=99t recommend the practi= ce.=C2=A0 One gets into all sorts of arguments about methodology and refere= nce quality etc with one=E2=80=99s co-authors, and for what?=C2=A0 What is = the value of such a work over two separate works?

= Which brings me to my next point:

<= div>
Regarding the discussion of whether we need RG consensus to publish= in
the IRSG stream: as I have said several times, I believe that in
= becoming a RG draft, a private draft becomes subjected to the RG rough
c= onsensus process.=C2=A0

Yes, yo= u have said this.=C2=A0 I do not recall you saying why you would take this = approach.=C2=A0 Can we please have a discussion as to whether this is the b= est way forward?=C2=A0 What is the value of rough consensus in this case?= =C2=A0 Or perhaps I should ask that question differently: on what do you se= ek rough consensus: the positions in the document or whether it is simply i= n good enough form to be sent up to the IRSG?=C2=A0 The latter is a whole l= ot easier to get to.

Well, "good enough to send to the IRSG" needs to be judged agai= nst some standard. In any case, having the document be an RFC under the IRT= F stream involves a certain amount of endorsement and so I would want there= to be some level of consensus that the we had confidence in the statements= in the document (just as I would want if I were to be on the PC of a confe= rence which was considering this as a submission).

=
-Ekr

--0000000000001e1f640594f2dd77-- From nobody Tue Oct 15 06:38:01 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CDD120119 for ; Tue, 15 Oct 2019 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Bf50wB37Tsrw for ; Tue, 15 Oct 2019 06:37:57 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 D03EC12004C for ; Tue, 15 Oct 2019 06:37:56 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id n7so30544871qtb.6 for ; Tue, 15 Oct 2019 06:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E1j1VKOmFxAABJY4KjHLKPIaVNzO9rLrob5NE+1MaaE=; b=JY52Sf1dOy7QD8wDx2Lb/ISM0CuNr7NnqU1LfTecb6vEi0druAUQlinCCJwI3TWT3s zhtndl4HNZbHigF8ynGXsBR+Qu0LgqQg3mCaW4HBL8yV4f6avfD/tgOdubOT677X9/rc rYjawVOcK3E/5o5j2tBpaplkLul7xYdvvMRN+t5JeHfdaeCnwNP1RM1erxrziDIW8Lr9 rA8xXTnZYS9GZH6vyIlzMCQLnTkOw4JN1pXnazSdsyOW5TM+f5ckguCPxyp6MXmTZR5i ESMInmhOgOKLW7/+R0CCv3wl2Q+m/0d5P34bKkFyagIrD7PpTEDl/ITZo+YHMvz9rlsw ym6w== 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=E1j1VKOmFxAABJY4KjHLKPIaVNzO9rLrob5NE+1MaaE=; b=rKMBcuYgrFyxTTbCBBq7vgH5jHO/PO7GnGRkhFLxZmkv3Ywtl5aerciBVYoyc4oD6J vMsKCTT9nURd5Wo9jHFM2JUck5vtBi4fzTFSCc4Q5VGRBY4ilLXxrCcUb91wOUzD7UNx zarJtd+e+sachZO5sE2aKhKtGdBcd4d1chCEX/88eam3NHuWjHJ5MG/s0s0sXfSDLL76 Ti73ETiGy6qvjUFt0hXyUgkuZ/JfUxOtxYTYLNsXRule7l7OjAcUTt1TRpNK9hT8yKKE +KdjcrQ8JbwnEsSWzA+cvlIUEqxMG5+rHNUvN6C+PyEDKNRY36U4npfiqBMrlukKO1Hy H1xA== X-Gm-Message-State: APjAAAVnGhDQopUnPvFjR8mujcgACoGMVRihj+GgcZPCl45mh9/fPFxt AbLW5J8LtJgl4JlonCIIPsbUMQ== X-Google-Smtp-Source: APXvYqwOKe7iIGVmutpSrOIJRPpXnXql3LXyj6L7q4v3UYUw7w28KeUDRaS+J6u+lEqnS0nn7jc7UA== X-Received: by 2002:ac8:2b48:: with SMTP id 8mr25412923qtv.166.1571146675758; Tue, 15 Oct 2019 06:37:55 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id m186sm9521612qkd.119.2019.10.15.06.37.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2019 06:37:55 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A05C12AC-1BBC-477C-B12B-C59970BC58D2" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.4\)) Date: Tue, 15 Oct 2019 09:37:53 -0400 In-Reply-To: Cc: Eliot Lear , avri@doria.org, hrpc@irtf.org To: Eric Rescorla References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> X-Mailer: Apple Mail (2.3601.0.4) Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 13:38:00 -0000 --Apple-Mail=_A05C12AC-1BBC-477C-B12B-C59970BC58D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 15, 2019, at 9:20 AM, Eric Rescorla wrote: > I concur partially with Eliot: i don't think this is about sides. I = actually suspect that Niels and I agree to a fair extent about the = political nature of standards development. My concern is not that but = rather whether this document makes interesting/useful claims and whether = it supports them with evidence. At present, it's not clear to me that it = does so, or really even what point it is trying to make. Another issue, which I think is leading to you phrasing it this way, is = that what =E2=80=9Cpolitical=E2=80=9D means varies, and it=E2=80=99s = important that the term not be used as if it has a single meaning. = Doing so muddies the communication. Of course all of the meanings of = politics are examples of what is described in the definition that=E2=80=99= s given, but that=E2=80=99s not sufficient. It would vastly improve = the document if section two actually enumerated the various meanings of = =E2=80=9Cpolitical=E2=80=9D and then if those meanings were used = explicitly later in the document. Examples: political in effect: because things are a certain way, this affects = politics political in development: because there are competing interests, = consensus is reached through politics historically political: the status quo was arrived at through politics, = but those politics are no longer relevant etc. I=E2=80=99m leaving it here because there was a really good = enumeration of these issues earlier in the discussion, and that would = probably be a better taxonomy than one I=E2=80=99d come up with here off = the cuff. --Apple-Mail=_A05C12AC-1BBC-477C-B12B-C59970BC58D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 15, 2019, at 9:20 AM, Eric Rescorla <ekr@rtfm.com> = wrote:
I concur partially with Eliot: i = don't think this is about sides. I actually suspect that Niels and I = agree to a fair extent about the political nature of standards = development. My concern is not that but rather whether this document = makes interesting/useful claims and whether it supports them with = evidence. At present, it's not clear to me that it does so, or really = even what point it is trying to make.

Another issue, which I think is leading to = you phrasing it this way, is that what =E2=80=9Cpolitical=E2=80=9D means = varies, and it=E2=80=99s important that the term not be used as if it = has a single meaning.  Doing so muddies the communication.  Of = course all of the meanings of politics are examples of what is described = in the definition that=E2=80=99s given, but that=E2=80=99s not = sufficient.   It would vastly improve the document if section two = actually enumerated the various meanings of =E2=80=9Cpolitical=E2=80=9D = and then if those meanings were used explicitly later in the = document.

Examples:

political in effect: because things are a certain way, this = affects politics
political in development: because = there are competing interests, consensus is reached through = politics
historically political: the status quo was = arrived at through politics, but those politics are no longer = relevant

etc. =   I=E2=80=99m leaving it here because there was a really good = enumeration of these issues earlier in the discussion, and that would = probably be a better taxonomy than one I=E2=80=99d come up with here off = the cuff.

= --Apple-Mail=_A05C12AC-1BBC-477C-B12B-C59970BC58D2-- From nobody Tue Oct 15 07:11:59 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF2B120119 for ; Tue, 15 Oct 2019 07:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 sQneU5OdApTv for ; Tue, 15 Oct 2019 07:11:57 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD291120043 for ; Tue, 15 Oct 2019 07:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1605; q=dns/txt; s=iport; t=1571148716; x=1572358316; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=yshnigK/gduRLlrnGFrV3CP/r1qdQQxSsaz1KeWmoec=; b=FGdWrwtEXKAy7QZphCrQ0IYqhWsRZNkRLn0OQ49sikz5Da+xObMIGh+v Z2lORFb6N/qpMxWRRdpVs8SIA5+l5KQex1hS9DDoKQvBRTQXWWppoMHfU 1BKV+sNBiXqD0F8a46zZMYnQxwKCwZ55vGo2v+ICJPUbmZ7MdshN3KNPc g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAP06Vd/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgWcEAQEBAQELAYFugXABIBKMcWCHSSW?= =?us-ascii?q?ZLIF7AgcBAQEJAwEBLwEBhEACgxI0CQ4CAwkBAQQBAQECAQUEbYU5hUwBBAF?= =?us-ascii?q?oEQULCw44VwaDNQGCVyCuT4InhU2EaRCBNAGBUopTgX+BOAwTgkw+iASCLAS?= =?us-ascii?q?WK5cfgiyCMYETkVcbgiqXF4Q6oB6DFAIEBgUCFYFSOYFYMxoIGxVlAYJCPRI?= =?us-ascii?q?QFIIHjhA/A5F5AQE?= X-IronPort-AV: E=Sophos;i="5.67,300,1566864000"; d="asc'?scan'208";a="17965085" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2019 14:11:52 +0000 Received: from ams3-vpn-dhcp6299.cisco.com (ams3-vpn-dhcp6299.cisco.com [10.61.88.154]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x9FEBpWa017444 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Oct 2019 14:11:52 GMT From: Eliot Lear Message-Id: <2E9B4A48-CFD4-4797-946D-07E3CEE51D43@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B34C4E5E-3D69-49BE-8C61-809955CB7656"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 15 Oct 2019 16:11:50 +0200 In-Reply-To: Cc: avri@doria.org, hrpc@irtf.org To: Eric Rescorla References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.88.154, ams3-vpn-dhcp6299.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 14:11:59 -0000 --Apple-Mail=_B34C4E5E-3D69-49BE-8C61-809955CB7656 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Eric > I would want there to be some level of consensus that the we had = confidence in the statements in the document (just as I would want if I = were to be on the PC of a conference which was considering this as a = submission). Yes. My point is simply that it is possible for two or more papers to = be well written that rely on different data sets or different = assumptions to derive different analysis and reach differing = conclusions, and so long as I am not being asked to endorse one over the = other, and so long as I have learned something interesting, then I would = want the work to be published. Eliot --Apple-Mail=_B34C4E5E-3D69-49BE-8C61-809955CB7656 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl2l06YACgkQh7ZrRtnS ejMsNAf/e8Un9Hl2AJ8Ij6+C92nPVf58lAPkK+tbsT+rPjZjUayXQCYPxFU7S4Lk Xly+Cbo85o/ow1QK7LtyagHSbpw3M41hez/BQcoEWUycbnPsZ+axXj4UmxowR81k OiTIbAgzABHc5fTHWT/U6P2p8IQmJPtZ5JRdCVBFHjEg4lgPFh95MM3c40uWUojO uHUU1nUB2U5452xtG13s3fznr1oxg7egZtbn05WzBE0IYTNlrxCS2NgtnMsQ6VWb c3Lu9BfD40cASmIHvsx+/zEuZtMEMV9m8/WVGttX0L+yl8mYAprPQG0wKmY3oynk TvsJbyWQDySImlxOmN9QueTPj9fy4w== =zsnX -----END PGP SIGNATURE----- --Apple-Mail=_B34C4E5E-3D69-49BE-8C61-809955CB7656-- From nobody Tue Oct 15 07:22:02 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1AB120074 for ; Tue, 15 Oct 2019 07:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 50S30CFVxrR0 for ; Tue, 15 Oct 2019 07:21:58 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEA2120043 for ; Tue, 15 Oct 2019 07:21:57 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 9295F837F24D for ; Tue, 15 Oct 2019 14:21:56 +0000 (UTC) X-Session-Marker: 6176726940646F7269612E6F7267 X-Spam-Summary: 2, -15, 0, , d41d8cd98f00b204, avri@doria.org, :, RULES_HIT:1:2:41:152:355:379:421:599:800:854:871:960:967:973:988:989:1000:1260:1261:1263:1313:1314:1345:1359:1381:1437:1516:1518:1575:1594:1605:1730:1747:1777:1792:2194:2199:2393:2525:2553:2560:2565:2612:2682:2685:2691:2692:2693:2741:2859:2861:2898:2910:2933:2937:2939:2942:2945:2947:2951:2954:3000:3022:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4184:4250:4362:4860:5007:6117:6119:6506:6747:6748:7281:7652:7875:7901:7903:7909:9010:9025:9036:9108:9388:11232:11257:11604:11658:11914:12043:12109:12114:12291:12297:12379:12438:12663:12679:12683:12740:12895:13018:13019:13130:13161:13229:13231:13255:13846:14095:14227:14658:14659:14877:21060:21080:21094:21212:21324:21347:21433:21451:21627:21740:21790:21881:21939:30003:30041:30054:30060:30070:30090, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neut X-HE-Tag: stage27_2dfb952c1974b X-Filterd-Recvd-Size: 12364 Received: from [192.168.0.7] (ip72-221-122-28.ri.ri.cox.net [72.221.122.28]) (Authenticated sender: avri@doria.org) by omf14.hostedemail.com (Postfix) with ESMTPA for ; Tue, 15 Oct 2019 14:21:55 +0000 (UTC) To: hrpc@irtf.org References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> From: avri@doria.org Autocrypt: addr=avri@doria.org; prefer-encrypt=mutual; keydata= xsBNBFJXhnsBCADCE9YSMulYfOUptnfTF1uwP2BRzUq87CAUacN6N5H5k8lNffqEXmgI+QWC njF7OwJ71rQLVYV3sIlpCQU9UyQfLHZDZoqV1d+aAJhgmmG6XtSReUi4jgAvsLzj+HkJSSqU 4voepwXs5k2DgRONAXojxvV5rFExDNqz4fn1zj2jf0SMTbCBkhHw1HQ6WXqW5T73LNbEUVys yEJBb+3+ITCVPTeVm7P/dXIEnsIsRVW8yeYoo1+E+jbPJ0OqHXtrWTdqqlU1CUHBgGWEFIIM qT//XVO0Kck8qyir7wqXb37fhSAkw32ZAKrd2NFrq71qk9Yj+SLtgxxqjGVLcbh3WVfRABEB AAHNG2F2cmkgZG9yaWEgPGF2cmlAZG9yaWEub3JnPsLAfAQTAQgAJgIbLwcLCQgHAwIBBhUI AgkKCwQWAgMBAh4BAheAAhkBBQJZvm+gAAoJENWp6aLJ/w+n0uQIAKc9Cb5C7NLtjvu2JvcQ Y8QLiubHVvYHAcTsP2J/JRviFIGeZY7uShuhf6VDI8wYXqAjhLfPGv6KvudwOs1dZ4VvzmUt 4yLWPGMEz7T7cQItc/jcYxJYdtI9g0OfYXQMV4TIIQB2KC40bnLjkd3d5EF+2cQIpivE3RED xQ5DZcsbi5q4E4t0z4Zzg5iskwR58cNnlvbVr+5qlVu1KiDYAMCR+ij4AJtzwpRTkH1l6hrv zOmgsdqqPIzSHWdcZPxWsSOm53sFDE54qABhL6+4fbPzRDZnvObnTP6bukPzX5vzYFGXIcQw RqgGOHi83Wf6dPum6K9YmCzxbdgwRsQGEdbOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmE qG/rIj0w3XfV3bQsDBUUdH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrM MqO7SYUTB6Tx8vIoqmy/T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq 3lrUp2mRzDXBWZLhPVUqx6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006Q eZQKfAZinaq3ICEyimWZbLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wj zrwwsxypxUiEac/7bVwgEv5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemi yf8Pp8BdIAQZAQIABgUCUleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K 1oIc+pxGmr7RUfpOcB63+1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV 5mPBI7kWYNbD99278ZtYTO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOG B8par+/2zKx1MwrZFCnTtlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO7 6/QFmerwwN89qLAh1pANoJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanx Fk4vCRfjfl8wt27n9xt27ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWa Sy7OQDKa1N838tTsRVLOMpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBs lZea+G2UUV2WSXZPiTci8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+ GjqFR3R2AMLhwK/Nu9uw+cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z 6yQ42xcvoUbQ6lLXW0fjNNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPg DoZoktZXmyHIh2HOwE0EUleGewEIAL2hntjt90xA4j9yeFvFMAmEqG/rIj0w3XfV3bQsDBUU dH4rVl3SSPp7rBNhe7drGN+SgQP2lJ6hcikRxfZEj9DnT0/9ERrMMqO7SYUTB6Tx8vIoqmy/ T4nqHpVlnCTyixxJDaohUHtTkN3BEie//PlMnIC2tXt9JRMXSTAq3lrUp2mRzDXBWZLhPVUq x6Uo3MMH1magq888piNJAQdf/P+vSuayjVwPyuG6HEEdG+5Q006QeZQKfAZinaq3ICEyimWZ bLWZRC5bw26PZOKxICUKNA1hAaIhw4OKrGsKRCTOj4cN5T6rr/wjzrwwsxypxUiEac/7bVwg Ev5O/+TipAkAEQEAAcLBfgQYAQIACQIbLgUCWb5voAEpCRDVqemiyf8Pp8BdIAQZAQIABgUC UleGewAKCRDqPi/LQnt+h072B/0V6xovIpgrx6Lu1EvqbmudcE0K1oIc+pxGmr7RUfpOcB63 +1nY8RHQ2iZ29GGZIuSIhMqoRxKvU29CTAsnuK84Fqb3dWfCSdhV5mPBI7kWYNbD99278ZtY TO6rDwk1l859Xh2N4ucwHbRBJNIforC5hLrhVoRjcM8m9AQv4fOGB8par+/2zKx1MwrZFCnT tlcdFvHvxFlA3yyZx7b0xU09RP5KDp1hKyX5ioathuqzL9d17FO76/QFmerwwN89qLAh1pAN oJIVO08B6j5GPRz6HpFF5Uf59dYwUvScMeA57Mne6amkR8aMkanxFk4vCRfjfl8wt27n9xt2 7ltwQ5jX+8wH/0dSUDcbks95ftWatIWFXdtofOTexLvj13dH9BWaSy7OQDKa1N838tTsRVLO MpF3AmbkqNWDqdF37HcWST9aO/Pi8vSFGtIbVHD74aFUG3PlNOBslZea+G2UUV2WSXZPiTci 8IL2mF8hrt92LcE/4AaaXh35d8ngpjx3CqIkFoMUHVEA1iye5YL+GjqFR3R2AMLhwK/Nu9uw +cSJQqeZpzkGulPd4Gccxj8YMLQIiZwMTPIReWgSETohRmzyS04Z6yQ42xcvoUbQ6lLXW0fj NNTBcD93hnlOk1xf+d9tx3fvigMrkxbVGNx/Ob92oRGwz63nnnPgDoZoktZXmyHIh2E= Message-ID: <9b447c04-7c5c-309c-e261-7444ca6e3f54@doria.org> Date: Tue, 15 Oct 2019 10:21:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LBgEMPb9pgjPYCKaE4nOBlSrQuraUjnRO" X-Antivirus: Avast (VPS 191012-6, 10/12/2019), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 14:22:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LBgEMPb9pgjPYCKaE4nOBlSrQuraUjnRO Content-Type: multipart/mixed; boundary="Y6gcK0e7zOHrATl1kv4Xjvx1O25RzNBa3" --Y6gcK0e7zOHrATl1kv4Xjvx1O25RzNBa3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, Thanks for the questions. On 15-Oct-19 03:12, Eliot Lear wrote: > Hi Avri, > > First, I appreciate the level of effort that Niels is putting into > this work. =C2=A0I want to take issue with two points you made: > >> On 14 Oct 2019, at 16:44, avri@doria.org wrote= : >> >> I think the document does a decent job of expressing one side of the >> argument, though there are places in that discussion that are shy on >> references and on arguments that logically show why that view should b= e >> considered the right argument. > > To me this was never about =E2=80=9Csides=E2=80=9D. =C2=A0To begin with= there may be a > great many sides. > > Regardless, once there is a clear and bounded research question, > reasonable argumentation and references, and a bounded conclusion, > regardless of whether I agree with the work, I am comfortable with it > being published. =C2=A0Some might want to publish opposing argument. =C2= =A0So > long as we as a group are open to those publications as well, why > would it be necessary to hold up this work? > > Having written an economic and policy paper with people who had > opposite views[1]*, I don=E2=80=99t recommend the practice. =C2=A0One g= ets into all > sorts of arguments about methodology and reference quality etc with > one=E2=80=99s co-authors, and for what? =C2=A0What is the value of such= a work over > two separate works? Sides: I think of the 'sides' in the definition of a discussion in a debate. Has 'side' joined the list of "bad words?" I can find another word to use. I too have worked on documents where various people came to the discussion with differeing world views and perspectives. I think it can be done. I see several values in doing so, among them: - gives a richer document with well developed perspectives. - the discussion of perspectives in a serious and non antagonistic manner forces all of us in the RG, and those who read the resultant work, to think through issues in greater detail. Often that results in more nuanced ways of looking at issues, often a good thing.=C2=A0 A docum= ent that can do that adds to knowledge and can sometimes be a useful guide to later discussions. - avoids, I hope, any argument that the group is somehow publishing a view that impinges on, or represents, the IETF in any way. We have just weathered a storm of the IETF powers that be, both directly and behind the scenes, over the fear that the RG was somehow impinging on the engineering work of the IETF. I see traces of such concern in some of the comments.=C2=A0 I think a well balanced work informs without prejudic= ing. While I understand that achieving such a goal is difficult and sometimes takes more time than anyone likes, I think it produces better work. > > Which brings me to my next point: > >> >> Regarding the discussion of whether we need RG consensus to publish in= >> the IRSG stream: as I have said several times, I believe that in >> becoming a RG draft, a private draft becomes subjected to the RG rough= >> consensus process.=C2=A0 > > Yes, you have said this. =C2=A0I do not recall you saying why you would= > take this approach. =C2=A0Can we please have a discussion as to whether= > this is the best way forward? =C2=A0What is the value of rough consensu= s in > this case? =C2=A0Or perhaps I should ask that question differently: on = what > do you seek rough consensus: the positions in the document or whether > it is simply in good enough form to be sent up to the IRSG? =C2=A0The > latter is a whole lot easier to get to. The approach was one set at the beginning of the group. At the beginning we discussed that we would, as close as possible, follow IETF practice when engaged in RG process and RFC development, while being completely open to doing work outside of the ISOC umbrella organization in ways appropriate to other contexts.=C2=A0 If, e.g. the HRPC RG decided it want= ed to submit a contribution to the UN General Assembly, the ITU or a journal, I would recommend we produce work that was appropriate to that context. I am not arguing co-chairs prerogative, except in trying to keep to that approach. I am happy to have a discussion about changing the basis on which we work. Perhaps some time in the upcoming meeting could be devoted to process style. Such discussions do seem to be trending and perhaps we should join the trend. As for rough consensus, what I look for is that the document is a fair expression of the issue.=C2=A0 As we did with RFC8280, and though it took= a while, we achieved rough consensus on publishing the document before I shepherded it through the IRSG process. This means, at the least, explaining a variety of perspectives and research approaches, even those we are not focusing on in other work, in a fair manner that those who hold that perspective can accept. RFC8280 took a while and was rough going at times, but I think it was a good outcome. I argue that there are many venues for work that argues a single perspective, whether scientific or advocacy. There are many publication venues for the ping pong of articles that oppose each other.=C2=A0 I neve= r saw the RFC series in that light, maybe my mistake. I see the RFC track as one for well formed work that can stand the test of time. Probably a discussion for a different space. That is, in any case, a criterion I have in mind. While I was employed as an academic, I tried to argue, with sometimes limited success, that RFCs should be seen as the equivalent of published books because they were just as difficult to produce given the arduous process they went through. I still believe that, though there is work published in the series that sometimes makes me doubt my perspective. As of this point, that is still my plan as the co-chair ushering this doc through the process. But if there is rough consensus for doing something else, then that is what I will try to carry forward with. I have not seen a rough consensus for a doc with a single main argument and thus keep looking for balance. > > Eliot > > *I did it once and not again because of the arguments between authors. I personally think it is important to continue trying to do so. Might be wrong. Perhaps my perspective comes from never having started work with the same perspective as my fellow authors and editors, but having been part of works that eventually achieved a balance. thanks avri > > [1] > http://people.csail.mit.edu/wlehr/Lehr-Papers_files/Lehr%20Lear%20Vest%= 20TPRC08%20Internet%20Address%20Running%20on%20Empty.pdf > TPRC08 Internet Address Running on Empty.pdf> > > > > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc --Y6gcK0e7zOHrATl1kv4Xjvx1O25RzNBa3-- --LBgEMPb9pgjPYCKaE4nOBlSrQuraUjnRO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJdpdYCAAoJEOo+L8tCe36HnvsIAJ4sRaHCttThjj7hVRm1bKvQ l5/1gHllx3lR83fbgNfgLWB9Kf5Z1hyyulKRT2e14xgL9L7oWVN3rGFL/MaONBUK eub6F7hl8rIw2JaGCIhJFur+Xf4mnjj3nGFiRC13ULCabNCTlSIBnnguP2OdA8h6 hPFV2MQ8P8bdPx65Nr8UlO1GcuwYdHh7UdXFY3HUWk+iVXysEIaAYHytZpx3H4k+ vKo7G9MJeQ61lIHdMggEeRjAo14Gx3vEo6b2eApR2BM8KDFFUGb9AuhWXsBCRtWR YkkpekEO563oMbdp+L6riEjl0eLHsUFr6E0fmRjeLja9p3hSXBLfRZ2084HlgDc= =avoH -----END PGP SIGNATURE----- --LBgEMPb9pgjPYCKaE4nOBlSrQuraUjnRO-- From nobody Tue Oct 15 09:18:31 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128F612010F for ; Tue, 15 Oct 2019 09:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 jcf3kSav_ceV for ; Tue, 15 Oct 2019 09:18:27 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 03A5312010E for ; Tue, 15 Oct 2019 09:18:27 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id y23so20861469lje.9 for ; Tue, 15 Oct 2019 09:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/X9ZgfeoXdmMWJTuoCbuMzWsRyFcZn4+lApAdDPfts0=; b=LqMyC6bj++5X3VX76cML+anwcD3TdIMN0t31Ux4vcF/MgDMxhTBbAkbIog1AbLWLfs ieXlKLZjVTnjjEhKReikCW3ZoJsjQy1lo2t8uboyNt1W2HrVDuuY81flJqvBkNL/1Itf aNgYxo+1vXGEWrLpqjXSfzUokSwoggk+ZhrOAW85oC+dT6kjQLkTDLUMDjX8BGvLo16F fFxVNLNoMc0OIF+A+wKZgEo23G1s094uCfAzXgojOmOaL8kwkrlSybluqsgAJplsHqYc GaEHrFkBlylYkXQT+b6y/adrzGqJJAKpa3x38dVOfMWa5XtIb/7xL01Rp+oZMC9QKIK3 Brcw== 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=/X9ZgfeoXdmMWJTuoCbuMzWsRyFcZn4+lApAdDPfts0=; b=rqCclw0PUzHRV1h7v6O06qyt7lEi6jQm3TQoZ5S+qDhgdZ1d9t/+EF/HEejKjKGnnL ntSolT2m8nHQ2tlEJIab+kjobqaLcyP+JotKMz8EyMN2lRgK7XFRFW5DhSPHte6naIMw /xrrwh9+CRl0gpbAX7sHbmp38eM5bzvkHDBMo8ZiQqrLl+EYd21yzKfn7Af2QH9KGlI1 JNn9VRTTPmMFe2xgj6IvaIZ1TXBbKCY6RWEHYWo9yOMGP1XGcjxhm/6wasvKLNGChY1t e8pJYzkH/p71yVKDtUaHJL7NUXqhO2Jo3qKiH+w0uYaAgbVjgLPm2FsDlfmzkmIiEOva +j/A== X-Gm-Message-State: APjAAAXFPrB0umU58wZDFCINGJD/yXCyPWrVSTuUc1gdd/26e2kKl2Ks kAg9xzXSI+geIgxnmGn/EPPJyljmmQhpCBTA2ZVkPg== X-Google-Smtp-Source: APXvYqw9rpIts+COBwjYJ1QUxA1Zws8xdr0JpwvCSYGNcN/xwZhxVMO5l6vu/STIU0BGOUS37vHT/Kn+jsqrs0A6Y1c= X-Received: by 2002:a2e:420a:: with SMTP id p10mr12422845lja.16.1571156305258; Tue, 15 Oct 2019 09:18:25 -0700 (PDT) MIME-Version: 1.0 References: <53caa46d-7ea5-f73f-1476-83d8d25555ba@doria.org> <2AE7E345-43BE-436C-BED9-3E39A7909B47@cisco.com> <2E9B4A48-CFD4-4797-946D-07E3CEE51D43@cisco.com> In-Reply-To: <2E9B4A48-CFD4-4797-946D-07E3CEE51D43@cisco.com> From: Eric Rescorla Date: Tue, 15 Oct 2019 09:17:47 -0700 Message-ID: To: Eliot Lear Cc: avri@doria.org, hrpc@irtf.org Content-Type: multipart/alternative; boundary="000000000000763fcb0594f5551e" Archived-At: Subject: Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call. X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 16:18:29 -0000 --000000000000763fcb0594f5551e Content-Type: text/plain; charset="UTF-8" On Tue, Oct 15, 2019 at 7:11 AM Eliot Lear wrote: > Hi Eric > > > I would want there to be some level of consensus that the we had > confidence in the statements in the document (just as I would want if I > were to be on the PC of a conference which was considering this as a > submission). > > > Yes. My point is simply that it is possible for two or more papers to be > well written that rely on different data sets or different assumptions to > derive different analysis and reach differing conclusions, and so long as I > am not being asked to endorse one over the other, and so long as I have > learned something interesting, then I would want the work to be published. > Yes, I agree with this. However, I do not think that this document as currently written is anywhere near strong enough to serve that purpose. -Ekr > Eliot > --000000000000763fcb0594f5551e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 15, 2019 at 7:11 AM Eliot= Lear <lear@cisco.com> wrote:
Hi Eric

> I would want there to be some level of consensus that the we had confi= dence in the statements in the document (just as I would want if I were to = be on the PC of a conference which was considering this as a submission).

Yes.=C2=A0 My point is simply that it is possible for two or more papers to= be well written that rely on different data sets or different assumptions = to derive different analysis and reach differing conclusions, and so long a= s I am not being asked to endorse one over the other, and so long as I have= learned something interesting, then I would want the work to be published.=

Yes, I agree with this. However, I do = not think that this document as currently written is anywhere near strong e= nough to serve that purpose.

-Ekr

Eliot
--000000000000763fcb0594f5551e-- From nobody Tue Oct 22 23:04:44 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A1D120024 for ; Tue, 22 Oct 2019 23:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4LWPYR_kDksS for ; Tue, 22 Oct 2019 23:04:41 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 C6DC712001E for ; Tue, 22 Oct 2019 23:04:40 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iN9l7-000202-Tg for hrpc@irtf.org; Wed, 23 Oct 2019 08:04:38 +0200 To: hrpc@irtf.org From: Mallory Knodel Openpgp: preference=signencrypt Autocrypt: addr=mallory@article19.org; prefer-encrypt=mutual; keydata= mQENBEx0TWcBCAC8sirY3nlDnRwY6XWmsvZtM9kmEK6H8no3ZuQ723PKwHOddw1nOykh0in/ /QGRmwtyVzsfLh6/94UUZTn10oo+xGAfw2gf1on5IJTIiphykk732PNnUakVGWwHNKQquTVc kLrydUaFVMb89BAXqExBKlMg2ciEjzbYMCs3I/qZAZ0Wr5nF3RQS8O78elTNAgWTZ98yKTZV DlRoDpnvbfwtIPqnISoSjDEvEUBdpykvS3jHqlR1f6Mx6Xs97S5CORaer/0qTcDm0PAb1Z9l IhMsFl05tNt2FpgS4/RN8NyLasAQNOlScpTJbAfRuyyvRm1N8GLIL1KX+YYeLyqzhdhZABEB AAG0Jk1hbGxvcnkgS25vZGVsIDxtYWxsb3J5QGFydGljbGUxOS5vcmc+iQFWBBMBCABAAhsD BwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AWIQTj62PgZaOyQLzZsHEMMqJxvTzHgAUCXH1h mgUJEepHrwAKCRAMMqJxvTzHgH3DCAC1sjJmg4+/VcESEzNkiF3KHEDCAssEaQl2FWfuXVvJ /mPliFtjpVv6EhdgUG5lbOcu12TCUWg42wHkE2kbDWXLE3f7HL+Nq0pEPVdMRXLxEfaOs2oR KGx8lh4k1UgYEpnARI486TklOAONKWdJKstEPrtt9LtysnjvhZvYCTzLKJC98c5wUvC46QYy +NdK6GB+uyVzW5kP2uUUBYxiCyHivGBbv77jcJAFVAk96ut1GFpeCCZM2WyYzer95b9n9a1B UGdJgEEVVbbBIQw7yMbMPqEwa8rpfig7QG72GieYItQjllHXGbOECiBcOHrGtrFWsHWxOxJV bZSoVq6sn1UUuQENBEx0TWcBCADiak/YuMW4BbaWL0U9sNg4zO3Qy1OFeye8fJjR8O/wWVSq cqA+sxjzRUee2fHCp6kVLedy6dVfiKmr59p21r4selOdslKaWmEGtz2oYnGpyPB/jKjfleE5 cIkXCdqgDAhfbfuVdF7heHpfhUy4m3yOJl2+CluT/CG9AfaCtyrwqMJzLWK4vmkGXxnBgb92 mGK0WFB2oRydz+SsiobgpCAqJSLcr8ZHQ54SbD9yxxYPv8IsSjt4eJoZCFI7INBsz4i7aj/q 4xcxQ+xiUwyqCZUvrzMxpw7c8TXuPHStDyhnsKkFjxhlY5avNeu0VPwk72C64I+y93gpPrL3 vL0tEmU9ABEBAAGJATwEGAECACYCGwwWIQTj62PgZaOyQLzZsHEMMqJxvTzHgAUCXH1hmgUJ EepHswAKCRAMMqJxvTzHgEDZCACcTamfNdBACpPHsmsJL1hbWertwYZg7h2rZtgmZQ9C2PMT OgkPPSsfi+xZ6PaXlvm2RI/TX51LbJsCJ9Fd2/WxKdtC0s6o7+0Cl3P57AORf3BRfl3zfXuy VhzjLvM9WhDiQM6JBqDuYxiYnjO56l+gozEuBAtUJaPIxGyggyS5eT8kKv8Szpc4g7/skZXq ccVOHj05KCOaFQ774rsIzcwppqJqGjh9X6nX6m2DONuBIYNXjH9U6FxHSJ6gRRxZkiz2/dDZ YqsHYlkKigH82r9gORhIGZkCd7xnRhyLOHnjjeKtIy5pvGwxUohy+y5l8i1155JEPNB7pphY xFxjMOQU Message-ID: <2ad7ed47-f314-1f0f-768e-961e7e6146a7@article19.org> Date: Wed, 23 Oct 2019 09:04:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 2394e6fd9f1e9f86011669f8146dc264 Archived-At: Subject: [hrpc] Draft agenda IETF 106 Singapore X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 06:04:43 -0000 Hi everyone, Please find below a draft agenda. Comments welcome. If you're on the agenda please let me know if you need remote participation. Thanks, -Mallory =3D=3D=3D Agenda HRPC IETF 106 # Welcome and introduction (5 minutes) Scribe, Note takers Agenda Review Research Group status # Talk: Jed Crandall, Arizona State University (30 minutes) Borders and Gateways: Measuring and Analyzing National AS Chokepoints: https://forrest.biodesign.asu.edu/data/publications/2019-compass-chokepoi= nts.pdf # Talk: John Mattsson, Ericsson (30 minutes) 5G Security, false base stations and IMSI catchers, and the great SIM heist and the need for PFS # Updates: Research group drafts (15 minutes each) draft-irtf-hrpc-association, Joe Hall and St=C3=A9phane Couture draft-irtf-hrpc-political, Niels ten Oever draft-irtf-hrpc-guidelines, Gurshabad Grover # Discussion: Consensus building and research group drafts (15 minutes) --=20 Mallory Knodel Head of Digital :: article19.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Fri Oct 25 14:21:07 2019 Return-Path: X-Original-To: hrpc@irtf.org Delivered-To: hrpc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBAC1209CA; Fri, 25 Oct 2019 14:12:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: hrpc@irtf.org, irtf-chair@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793964.2724.953088980872827310.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:19 -0700 Archived-At: Subject: [hrpc] hrpc - Requested session has been scheduled for IETF 106 X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:18:42 -0000 Dear Mallory Knodel, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. hrpc Session 1 (2:00 requested) Tuesday, 19 November 2019, Morning Session I 1000-1200 Room Name: Canning size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/hrpc.ics Request Information: --------------------------------------------------------- Working Group Name: Human Rights Protocol Considerations Area Name: IRTF Session Requester: Mallory Knodel Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: dprive gaia irtfopen pearg Technology Overlap: mls doh regext Key Participant Conflict: capport dnsop People who must be present: Avri Doria Mallory Knodel Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Oct 29 06:06:40 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3000A120805 for ; Tue, 29 Oct 2019 06:06:38 -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, 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=cis-india.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 LL-VE4xkAh7V for ; Tue, 29 Oct 2019 06:06:35 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 A6121120801 for ; Tue, 29 Oct 2019 06:06:35 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iPRCA-0007rb-FM for hrpc@irtf.org; Tue, 29 Oct 2019 14:06:34 +0100 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org 593B458131623 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1572354353; bh=kBAl8780jzZPDGZHswgWRkz1jmL8B5wbrTFI12dQGLs=; h=To:From:Message-ID:Date:MIME-Version; b=JpoVRjbAX04K4mdFBdw3YcC4QU3llv00AnxKyoRicJBKn9EK9Xfin+1ykc15mOSmw uv4sxW44UljqHWitcGUqse/8Pn9vvE0CyFojdZv7BleoxlN4OjfvOAN3oii5dClYka wD0dPfSB2i8JetJ17vTIzVL29u8+Tr8s1IAdxrCHw+gT6/iicu1n/0J1nK/+D86QVX ok9zhYXdbHQYgwOiJ8m7upjQ86ket8xQexGqNsJSVQe1Oj1hJsYA2AbWMnDwhEVumm Dz0Lf4BqOH1mIatwJRSANUEvpA9gal7qJbOnSwQ9kb4DtqVcKjhR3nqsVmbx7zAu/g yCmXqWo1j4fPA== To: hrpc@irtf.org From: Karan Saini Message-ID: Date: Tue, 29 Oct 2019 18:35:52 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B65A6658CD2C69270160C10C" Content-Language: en-US X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 5da6e32037d0514ee08d4e707879a9ed Archived-At: Subject: [hrpc] Applying RFC8280 to draft-ietf-dnsop-serve-stale X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 13:06:38 -0000 This is a multi-part message in MIME format. --------------B65A6658CD2C69270160C10C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, This email documents some of the learnings from the application of the=20 questions in RFC8280 and draft-irtf-hrpc-guidelines to=20 draft-ietf-dnsop-serve-stale. =E2=80=9CServing Stale Data to Improve DNS Resiliency=E2=80=9D=20 (draft-ietf-dnsop-serve-stale) [0] discusses recursive DNS resolvers=20 serving =E2=80=9Cstale=E2=80=9D data, along with use cases and considerat= ions, and an=20 example implementation for the same. In the context of this draft,=20 =E2=80=9Cstale data=E2=80=9D is used to refer to DNS records for which th= e specified TTL=20 have elapsed, and where no authoritative server can be reached=20 immediately for retrieving a fresh answer. A stated motivation behind=20 implementing serve-stale is that of making the DNS =E2=80=9Cmore resilien= t to=20 DoS attacks.=E2=80=9D Connectivity ------------ Serving DNS records past their TTL can have positive implications when=20 recursive resolvers cannot immediately reach an authoritative server for=20 refreshing cached data. The rationale behind serving stale relies on the=20 presumption that the underlying information will be identical to that=20 which is stored in the recursive resolver=E2=80=99s cache. Thus, serving = stale=20 data can act as a failover mechanism for failures or downtime on part of=20 authoritative servers. If implemented properly, serve-stale should not have a detrimental=20 effect on DNS resolution times for clients. Security -------- Stale records can allow malicious actors to keep =E2=80=9Ckeep their [com= mand=20 and control] systems artificially alive even if the parent has removed=20 the C&C domain name,=E2=80=9D as pointed out by Ray Bellis. [1] In the same email, Bellis also stated that serving stale records =E2=80=9C= must=20 be predicated on the presence of a valid delegation from the parent=20 zone.=E2=80=9D [1] The presence of this delegation would provide a layer = of=20 agency to the operators of a given parent zone. Another concern raised by some [2] was that DNS attacks, such as traffic=20 hijacking, tampering or spoofing could potentially be prolonged if=20 serve-stale is used, and that such attacks may potentially be encouraged=20 by the publication of the document. These concerns are broadly acknowledged in the =E2=80=9CSecurity Consider= ations=E2=80=9D=20 section of the draft. Conclusion ---------- This document presents a practice of some major DNS operators, who have=20 had operational benefits from serving stale DNS data. The intended=20 status for this document is that of a =E2=80=9CProposed Standard.=E2=80=9D= (See=20 [RFC7127] for a definition) Davey Song had previously raised the concern that serve-stale may be=20 better suited for publication as an informational or experimental=20 document, rather than it being a part of the standards track [2]. I=20 initially agreed with this point [3], however, considering that the=20 intended status for serve-stale is that of a Proposed Standard, which=20 [RFC7127] defines as a specification that is =E2=80=9Cstable, has resolve= d known=20 design choices,=E2=80=9D which =E2=80=9Chas received significant communit= y review, and=20 appears to enjoy enough community interest to be considered valuable,=E2=80= =9D I=20 believe that the current intended status of the RFC is suitable and=20 appropriate. This, however, has led to an interesting learning that can potentially=20 be adapted to draft-irtf-hrpc-guidelines. The guidelines may benefit=20 from a section exploring the different impacts a specification may have=20 with consideration the intended status of publication. Publication of a particular RFC under a certain status has certain=20 consequences. For instance, publication as an Internet Standard as part=20 of the Standards Track may signal to implementers that the specification=20 has a certain level of maturity, operational experience, and consensus.=20 Similarly, publication of a specification an experimental document as=20 part of the non-standards track would signal to the community that the=20 document =E2=80=9Cmay be intended for eventual standardization but [may] = not yet=20 [be] ready,=E2=80=9D [BCP9]. [BCP9] further defines when a document should be considered for=20 publication as =E2=80=9Cexperimental=E2=80=9D (section 4.2.1) or =E2=80=9C= informational=E2=80=9D=20 (section 4.2.2). I believe the guidelines draft may benefit from the=20 inclusion of text exploring considerations for the intended status of a=20 specification. [0] https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ [1] https://mailarchive.ietf.org/arch/msg/dnsop/7lvN6sLwNzkxWh48wPelAFqWT= Ag [2] https://mailarchive.ietf.org/arch/msg/dnsop/MENMA0etqVTIcBBnpc7RiWhJV= qk [3] https://mailarchive.ietf.org/arch/msg/dnsop/Zxa8EcjlaQtz4z-h7b3bgfyTu= x0 [RFC7127] https://tools.ietf.org/html/rfc7127 [BCP9] https://tools.ietf.org/html/bcp9 Regards, Karan Saini --------------B65A6658CD2C69270160C10C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

This email documents some of the learnings from the application of the questions in RFC8280 and draft-irtf-hrpc-guidelines to draft-ietf-dnsop-serve-stale.


=E2=80= =9CServing Stale Data to Improve DNS Resiliency=E2=80=9D (draft-ietf-dnsop-serve-stale) [0] discusses recursive DNS resolvers serving =E2=80=9Cstale=E2=80=9D data, along with use case= s and considerations, and an example implementation for the same. In the context of this draft, =E2=80=9Cstale data=E2=80=9D is used to refe= r to DNS records for which the specified TTL have elapsed, and where no authoritative server can be reached immediately for retrieving a fresh answer. A stated motivation behind implementing serve-stale is that of making the DNS =E2=80=9Cmore resilient to DoS attacks.=E2= =80=9D


Connec= tivity

------= ------


Servin= g DNS records past their TTL can have positive implications when recursive resolvers cannot immediately reach an authoritative server for refreshing cached data. The rationale behind serving stale relies on the presumption that the underlying information will be identical to that which is stored in the recursive resolver=E2=80=99s cache. Thus, serving stale data can act as a fai= lover mechanism for failures or downtime on part of authoritative servers.


If implemented properly, serve-stale should not have a detrimental effect on DNS resolution times for clients.


Securi= ty

------= --


Stale records can allow malicious actors to keep =E2=80=9Ckeep their [com= mand and control] systems artificially alive even if the parent has removed the C&C domain name,=E2=80=9D as pointed out by Ray Bel= lis. [1]


In the same email, Bellis also stated that serving stale records =E2=80=9C= must be predicated on the presence of a valid delegation from the parent zone.=E2=80=9D [1] The presence of this delegation would provide a = layer of agency to the operators of a given parent zone.=C2=A0


Anothe= r concern raised by some [2] was that DNS attacks, such as traffic hijacking, tampering or spoofing could potentially be prolonged if serve-stale is used, and that such attacks may potentially be encouraged by the publication of the document.=C2=A0


These concerns are broadly acknowledged in the =E2=80=9CSecurity Consider= ations=E2=80=9D section of the draft.


Conclu= sion

------= ----
This document presents a practice of some major DNS operators, who have had operational benefits from serving stale DNS data. The intended status for this document is that of a =E2=80=9CProposed Standard.=E2=80=9D (See [RFC7127] for a definition)


Davey Song had previously raised the concern that serve-stale may be better suited for publication as an informational or experimental document, rather than it being a part of the standards track [2]. I initially agreed with this point [3], however, considering that the intended status for serve-stale is that of a Proposed Standard, which [RFC7127] defines as a specification that is =E2=80=9Cstable, has resolved known design choices,=E2=80=9D which = =E2=80=9Chas received significant community review, and appears to enjoy enough community interest to be considered valuable,=E2=80=9D I believe th= at the current intended status of the RFC is suitable and appropriate.

This, however, has led to an interesting learning that can potentially be adapted to draft-irtf-hrpc-guidelines. The guidelines may benefit from a section exploring the different impacts a specification may have with consideration the intended status of publication.


Public= ation of a particular RFC under a certain status has certain consequences. For instance, publication as an Internet Standard as part of the Standards Track may signal to implementers that the specification has a certain level of maturity, operational experience, and consensus. Similarly, publication of a specification an experimental document as part of the non-standards track would signal to the community that the document =E2=80=9Cmay be intended for eventual standardization but = [may] not yet [be] ready,=E2=80=9D [BCP9].


[BCP9] further defines when a document should be considered for publication as =E2=80=9Cexperimental=E2=80=9D (section 4.2.1) or =E2= =80=9Cinformational=E2=80=9D (section 4.2.2). I believe the guidelines draft may benefit from the inclusion of text exploring considerations for the intended status of a specification.


[0] https://datatracker.ietf.org/doc/= draft-ietf-dnsop-serve-stale/

[1] https://mailarchive.ietf.org/arch= /msg/dnsop/7lvN6sLwNzkxWh48wPelAFqWTAg

[2] https://mailarchive.ietf.org/arch= /msg/dnsop/MENMA0etqVTIcBBnpc7RiWhJVqk

[3] https://mailarchive.ietf.org/arch= /msg/dnsop/Zxa8EcjlaQtz4z-h7b3bgfyTux0

[RFC71= 27] https://tools.ietf.org/html/rfc71= 27

[BCP9] https://tools.ietf.org/html/bcp9<= br>
Regards,
Karan Saini

--------------B65A6658CD2C69270160C10C-- From nobody Tue Oct 29 08:53:15 2019 Return-Path: X-Original-To: hrpc@ietfa.amsl.com Delivered-To: hrpc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC8F120956 for ; Tue, 29 Oct 2019 08:53:05 -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=isoc.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 qDJNv9BCoZ4O for ; Tue, 29 Oct 2019 08:53:02 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740057.outbound.protection.outlook.com [40.107.74.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2467D120962 for ; Tue, 29 Oct 2019 08:53:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lIEx1vN3nueWuqwind7Y9xASUNCpQPD5ySoRn+2jsdMozg9qjiaW6A3xbz3wZbP960c9vh0aUKyTNdqabDPEm0NoLLRHl8wRNbq3fa28tKSC1hYba4qC7CJfxqxoLHsdPJxUKFzQnNlVT6g0U4NZ/dTv9jdUGHSG0plOlnWcTnbZUTTCIQJ3KLmICebhFtselVyT9c0Uu25LZeuYUGJuoMDq3DUtSIbN+2EqMWo12XGI7MtDzyhB9U1zqBrUDF6sp69VgfSSxO3QwCMRYo4FHAgheuEpjRCArGqtvu1u23e9VqAFDLXoVH+AmhFJMRyD7CqFpSC0fe1r5Uw1x8IsEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6hFpKVcKiBjA5ZmHFrN7kpMnZEbel/8aNDsWTVkFW8=; b=WJpl1uCOe+zRjb2aJQmTElXC8onoohaE6LQ6hixdAX5KlSMHrxl8oVqOWDq0oV66uIPgdJxKQ2E+fv933fm4u2O8AVRG3suEBR+fMInTXvIUkDrfP6k1UkLi3pNI0rJgF6ClStHPwQnOT9poeAqsoTilHVellD+Ue0aRmIshkkKD8SJuZFtX/54ivwjDUp8sxWu7HJxClLgHPCstEDRxZQgOO5pyxu/1vj2jAN3x00D1beNPbjoh88ayKrC8T94G2M16kBwjugC2QMMvTeghNL+umbq+SMjA9yQ5aQh/qa9ni/R5XfmOjPK0ll3b7Uv9v5pSJ1GPdF5Zrxor7XQR3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6hFpKVcKiBjA5ZmHFrN7kpMnZEbel/8aNDsWTVkFW8=; b=ZgexNXn9zXgBIvn4F+3m52TjSRzkRYiTwoKVmwn73eV3gzIr4q43cjDjqzSmDqNtvhX3MYyEWIMOw7ARtK4B6lLOhOcjBiZs/G1FDcJTp44gBhxRn+Iu8u0g1xTcpOLMUbNfDCZw7UpIpJkITRc8qc62ZT56Cw04Mpi8M/UGsYE= Received: from CH2PR06MB6743.namprd06.prod.outlook.com (20.180.9.24) by CH2PR06MB6598.namprd06.prod.outlook.com (20.180.8.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.23; Tue, 29 Oct 2019 15:53:00 +0000 Received: from CH2PR06MB6743.namprd06.prod.outlook.com ([fe80::85f7:f1b1:5ad7:3e6d]) by CH2PR06MB6743.namprd06.prod.outlook.com ([fe80::85f7:f1b1:5ad7:3e6d%5]) with mapi id 15.20.2387.027; Tue, 29 Oct 2019 15:53:00 +0000 From: Joseph Lorenzo Hall To: Karan Saini , "hrpc@irtf.org" Thread-Topic: [hrpc] Applying RFC8280 to draft-ietf-dnsop-serve-stale Thread-Index: AQHVjlm3UkIKzzyqQ0uVs1hNj8j+FqdxxPeP Date: Tue, 29 Oct 2019 15:52:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hall@isoc.org; x-originating-ip: [173.226.66.172] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7474ffb-3563-4fcd-db8e-08d75c88130a x-ms-traffictypediagnostic: CH2PR06MB6598: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(376002)(39850400004)(396003)(53754006)(189003)(199004)(11346002)(476003)(52536014)(486006)(71190400001)(71200400001)(966005)(14444005)(5660300002)(229853002)(446003)(3846002)(256004)(2906002)(66066001)(33656002)(6116002)(2501003)(76116006)(66946007)(66476007)(66556008)(64756008)(91956017)(66446008)(66574012)(316002)(8676002)(305945005)(74316002)(14454004)(6436002)(8936002)(81156014)(7736002)(86362001)(81166006)(99286004)(6246003)(102836004)(26005)(478600001)(25786009)(110136005)(55016002)(6306002)(76176011)(186003)(53546011)(6506007)(7696005)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:CH2PR06MB6598; H:CH2PR06MB6743.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R1ejXRmBGaSmcFVA9Tb4+QlgfueR4uV3VKPpIlrgjckt1YRyMzR9a+92Tp16O42tHJw4VrAq8343+I4vZ4xoStFi5HVRrzOwasGb0T3n19MTxK9NAwVq7aA89J1+IIZI+Sqb/bpBAxzL0t9nyq50wKr5r3mQn8OM1p+hX/IcgwKuL+o+nFBp+EU9mOqm2SixC1Z+QanfeIb/FCaoSgLEIklI9N4XfW78Y6dV/6O8gbFRS6zbwoqE+68qRdVhV4MtjcqYrODR/086/I+SBrhKOADY9POffvHqmuDhL0jwoPMUvbE2IHQ+4MHxYW5vTFRU0/aQHo6VMoMx4gUqlzHkwoKkjL334Tfex3iarFlcU9SB4k93R0+Zcj0IDTdGXDFxMNwg+vp0SVciXeRa6L2BNcKYWH8DD8jREX8RqgJEcrqq6RSuxe0znQkKSUuGQ+PsHQX5DaUGQXKhnd68hGY80SzQOrWMfvHSs9ZFLcvJyK8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: a7474ffb-3563-4fcd-db8e-08d75c88130a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2019 15:52:59.8949 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Vt7igxjRWiyIf+mfw972pKCTv5q7mUxnfF/enkK/leHB2D2OHdp8P7qLwfp4A/ts X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR06MB6598 Archived-At: Subject: Re: [hrpc] Applying RFC8280 to draft-ietf-dnsop-serve-stale X-BeenThere: hrpc@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "mail@nielstenoever.net" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 15:53:11 -0000 I definitely think some considerations in the guidelines document about int= ended status sounds good... it's something that I trip up on and would be g= ood to write down for this audience. best, joe ________________________________________ From: hrpc on behalf of Karan Saini Sent: Tuesday, October 29, 2019 9:05 AM To: hrpc@irtf.org Subject: [hrpc] Applying RFC8280 to draft-ietf-dnsop-serve-stale Hi all, This email documents some of the learnings from the application of the ques= tions in RFC8280 and draft-irtf-hrpc-guidelines to draft-ietf-dnsop-serve-s= tale. =93Serving Stale Data to Improve DNS Resiliency=94 (draft-ietf-dnsop-serve-= stale) [0] discusses recursive DNS resolvers serving =93stale=94 data, alon= g with use cases and considerations, and an example implementation for the = same. In the context of this draft, =93stale data=94 is used to refer to DN= S records for which the specified TTL have elapsed, and where no authoritat= ive server can be reached immediately for retrieving a fresh answer. A stat= ed motivation behind implementing serve-stale is that of making the DNS =93= more resilient to DoS attacks.=94 Connectivity ------------ Serving DNS records past their TTL can have positive implications when recu= rsive resolvers cannot immediately reach an authoritative server for refres= hing cached data. The rationale behind serving stale relies on the presumpt= ion that the underlying information will be identical to that which is stor= ed in the recursive resolver=92s cache. Thus, serving stale data can act as= a failover mechanism for failures or downtime on part of authoritative ser= vers. If implemented properly, serve-stale should not have a detrimental effect o= n DNS resolution times for clients. Security -------- Stale records can allow malicious actors to keep =93keep their [command and= control] systems artificially alive even if the parent has removed the C&C= domain name,=94 as pointed out by Ray Bellis. [1] In the same email, Bellis also stated that serving stale records =93must be= predicated on the presence of a valid delegation from the parent zone.=94 = [1] The presence of this delegation would provide a layer of agency to the = operators of a given parent zone. Another concern raised by some [2] was that DNS attacks, such as traffic hi= jacking, tampering or spoofing could potentially be prolonged if serve-stal= e is used, and that such attacks may potentially be encouraged by the publi= cation of the document. These concerns are broadly acknowledged in the =93Security Considerations= =94 section of the draft. Conclusion ---------- This document presents a practice of some major DNS operators, who have had= operational benefits from serving stale DNS data. The intended status for = this document is that of a =93Proposed Standard.=94 (See [RFC7127] for a de= finition) Davey Song had previously raised the concern that serve-stale may be better= suited for publication as an informational or experimental document, rathe= r than it being a part of the standards track [2]. I initially agreed with = this point [3], however, considering that the intended status for serve-sta= le is that of a Proposed Standard, which [RFC7127] defines as a specificati= on that is =93stable, has resolved known design choices,=94 which =93has re= ceived significant community review, and appears to enjoy enough community = interest to be considered valuable,=94 I believe that the current intended = status of the RFC is suitable and appropriate. This, however, has led to an interesting learning that can potentially be a= dapted to draft-irtf-hrpc-guidelines. The guidelines may benefit from a sec= tion exploring the different impacts a specification may have with consider= ation the intended status of publication. Publication of a particular RFC under a certain status has certain conseque= nces. For instance, publication as an Internet Standard as part of the Stan= dards Track may signal to implementers that the specification has a certain= level of maturity, operational experience, and consensus. Similarly, publi= cation of a specification an experimental document as part of the non-stand= ards track would signal to the community that the document =93may be intend= ed for eventual standardization but [may] not yet [be] ready,=94 [BCP9]. [BCP9] further defines when a document should be considered for publication= as =93experimental=94 (section 4.2.1) or =93informational=94 (section 4.2.= 2). I believe the guidelines draft may benefit from the inclusion of text e= xploring considerations for the intended status of a specification. [0] https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ [1] https://mailarchive.ietf.org/arch/msg/dnsop/7lvN6sLwNzkxWh48wPelAFqWTAg [2] https://mailarchive.ietf.org/arch/msg/dnsop/MENMA0etqVTIcBBnpc7RiWhJVqk [3] https://mailarchive.ietf.org/arch/msg/dnsop/Zxa8EcjlaQtz4z-h7b3bgfyTux0 [RFC7127] https://tools.ietf.org/html/rfc7127 [BCP9] https://tools.ietf.org/html/bcp9 Regards, Karan Saini