Re: [hrpc] draft-irtf-hrpc-political - current determination regarding RG last call.

avri@doria.org Tue, 15 October 2019 14:22 UTC

Return-Path: <avri@doria.org>
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 <hrpc@ietfa.amsl.com>; 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 <hrpc@ietfa.amsl.com>; 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 <hrpc@irtf.org>; 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 <hrpc@irtf.org>; 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 <hrpc@irtf.org>; 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: <https://mailarchive.ietf.org/arch/msg/hrpc/Qyf5bRt7Dbn4IoSKjteQMiNCpxI>
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" <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2019 14:22:01 -0000

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.  I want to take issue with two points you made:
>
>> On 14 Oct 2019, at 16:44, avri@doria.org <mailto: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 “sides”.  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’t recommend the practice.  One gets into all
> sorts of arguments about methodology and reference quality etc with
> one’s co-authors, and for what?  What 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.  A document
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.  I think a well balanced work informs without prejudicing.

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. 
>
> 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.

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.  If, e.g. the HRPC RG decided it wanted
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.  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.  I never
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
> <http://people.csail.mit.edu/wlehr/Lehr-Papers_files/Lehr Lear Vest
> TPRC08 Internet Address Running on Empty.pdf>
>
>
>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc