From nobody Thu Jan 2 21:53:13 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50BA12006D for ; Thu, 2 Jan 2020 21:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ57uIhGmKoO for ; Thu, 2 Jan 2020 21:53:10 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 6352F120019 for ; Thu, 2 Jan 2020 21:53:10 -0800 (PST) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0035qINX083700 for ; Fri, 3 Jan 2020 00:53:10 -0500 Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com with ESMTP id 2x869tg18n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 03 Jan 2020 00:53:09 -0500 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 0035lYbZ002510 for ; Fri, 3 Jan 2020 05:53:08 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma03wdc.us.ibm.com with ESMTP id 2x5xp6pe08-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 03 Jan 2020 05:53:08 +0000 Received: from b03ledav003.gho.boulder.ibm.com (b03ledav003.gho.boulder.ibm.com [9.17.130.234]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0035r8u559310388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 3 Jan 2020 05:53:08 GMT Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0AE476A04D for ; Fri, 3 Jan 2020 05:53:08 +0000 (GMT) Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E53296A051 for ; Fri, 3 Jan 2020 05:53:07 +0000 (GMT) Received: from rotala.raleigh.ibm.com (unknown [9.27.200.19]) by b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTPS for ; Fri, 3 Jan 2020 05:53:07 +0000 (GMT) Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.15.2/8.15.2) with ESMTP id 0035r4h4028721 for ; Fri, 3 Jan 2020 00:53:04 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.15.2/8.15.2/Submit) id 0035r4px028679 for ietf@ietf.org; Fri, 3 Jan 2020 00:53:04 -0500 From: narten@us.ibm.com Message-Id: <202001030553.0035r4px028679@rotala.raleigh.ibm.com> Date: Fri, 03 Jan 2020 00:53:04 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-02_08:2020-01-02,2020-01-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=455 bulkscore=0 malwarescore=0 adultscore=0 impostorscore=0 clxscore=1015 lowpriorityscore=0 phishscore=0 suspectscore=13 spamscore=0 mlxscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001030055 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 05:53:12 -0000 Total of 1 messages in the last 7 days. script run at: Fri 03 Jan 2020 12:53:04 AM EST Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 10376 | narten@us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 10376 | Total From nobody Mon Jan 6 23:00:04 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C455F1200BA; Mon, 6 Jan 2020 22:57:47 -0800 (PST) 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, 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 avWJNij_kYRR; Mon, 6 Jan 2020 22:57:42 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01A2120096; Mon, 6 Jan 2020 22:57:42 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ioio6-0005qR-CL; Tue, 07 Jan 2020 01:57:38 -0500 Date: Tue, 07 Jan 2020 01:57:32 -0500 From: John C Klensin To: iesg@ietf.org cc: art@ietf.org, mnot@mnot.net, ietf@ietf.org, urn@ietf.org Subject: URNs and Last Call: (URI Design and Ownership) to Best Current Practice Message-ID: <87E116C31DAF1434C3C3937F@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 06:57:49 -0000 Hi. My apologies for the extreme lateness of this note. I have tried to pass URN work on to others since RFCs 8141 and 8254 and had assumed that someone else would check through this document to be sure that it appropriately covered both locator-type and name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3). I had assumed that reviews within the ART area and/or a specific ART Area Review would address that topic but, AFAICT, they may not have done so. I've had occasion to look through the document and I'm actually not sure about the name-locator distinction as it may apply to it. This note will be short and is rather more about asking the IESG to be sure that any possible issues are addressed than to try to do a detailed review of the issues. AFAICT, the focus of the I-D is to be sure that applications and elaborations of any URI scheme be firmly under the control and management of the owner of that scheme and that possible deviations from that principle are well-controlled. http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1, cited in the draft as [webarch] is clear that the ownership of a URN is delegated to the owners of URN Namespaces rather than being bound to the "urn" URI scheme itself. I believe it is possible to read this document in a way that has no impact on URNs and URN namespaces. However, it appears to me that, if read without appropriate care, some of the restrictions imposed on queries and fragments may be inconsistent with mechanisms and syntax for use in particular URN Namespaces or URNs generally that were contemplated and extensively discussed during the development of RFC 8141. Those ideas were deferred by the WG for future work but the mechanisms may well be in use in important URN namespaces. Because the last paragraph of Section 1.1 of this I-D essentially declares any existing specification, even a standards-track one or one adopted by other bodies, that does not comply with the recommendations of the I-D to be incorrect and in need of correction, the effects of a reading that retroactively restricts URN Namespace practices that are under the control of the Namespace owners could be quite serious. My preference would be that someone who has been more active with URN work and Namespace registrations in the last couple of years do a careful review of the document to determine whether my concerns justify some tuning of the text. However, given how late it is in the review process (again, my apologies for not catching the issue until now), a reasonable alternative would be to simply insert a sentence early in the I-D that says that it applies primarily to locator-type URIs although name-type ones may find it useful as general guidance _or_ to explicitly call out the difference in ownership between URNs and other URI schemes. thanks, john p.s. It would be, IMO, helpful if the IESG and the community would think about the implications of BCP (or IETF-stream Informational) documents that effectively obsolete or deprecate existing standards without identifying them or explicitly updating them and whose responsibility it is to find the discrepancies. From nobody Tue Jan 7 05:51:27 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF899120116; Tue, 7 Jan 2020 05:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9elndMSc72sa; Tue, 7 Jan 2020 05:51:13 -0800 (PST) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 D29FC1200E9; Tue, 7 Jan 2020 05:51:12 -0800 (PST) Received: by mail-ot1-f51.google.com with SMTP id r9so3138572otp.13; Tue, 07 Jan 2020 05:51:12 -0800 (PST) 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=eghn3hP3jtmuNjohEJYEDOQUrurtsHvXeadmEi9ViJk=; b=kDhYFbIrRTEL+r8iZ355Yyys/peGACUpVYr/gc5ukiCzV92hu8MdYzSV8Mj6Rs/8iW QK/VkkXoxE+4UoPTQZB7iTHHkVNVpp+ukc8u/QNFq9nxEOzXGzQmEDldIAcERpQRFt27 jS23ZL68xppbnn8WscAq7nCl3PutMUA34nwMQIR5Tv2X+GvN3Vr5yOHeES6b6K8AxPMn 2VVnFTPs5aZVPO4PhWT+c/6By6txn+2QJmsZ/8W1QmVSr4QcX2XkOza0joEcYa8k8ODh 0Jz/mUlyUVrza2brukgVbDchTyIvUuac9kzyriNJu3H3GHbYFbMlsTLRb4qyI13N2/40 sHzw== X-Gm-Message-State: APjAAAXKHEeythAjWkaM+ADxWUgoq/bllPce8HlCjyYp0TDFGviGnasA EKallDh1sQZ2+J72BSiQyyWszIapDbUjBeh3LUw= X-Google-Smtp-Source: APXvYqyl2MRtMbSQuAsXASaJwKEuBFtvuaxU0+2sUD7CKJe7T1Kd5/9xT3dKYXvJZb9t3JhNSVWshpd+vE+pOH1ojRk= X-Received: by 2002:a9d:7305:: with SMTP id e5mr116440368otk.64.1578405072086; Tue, 07 Jan 2020 05:51:12 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 08:51:00 -0500 Message-ID: Subject: Re: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: John C Klensin Cc: The IESG , "General Area Review Team (gen-art@ietf.org)" , Mark Nottingham , urn@ietf.org, IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="000000000000a22c17059b8d11e6" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:51:16 -0000 --000000000000a22c17059b8d11e6 Content-Type: text/plain; charset="UTF-8" I remain of the view that the URN/URL distinction is unhelpful because it is meaningless. There are no sharp boundaries between categories of identifier as the distinction supposes. Before making this argument in more detail, I will make a plea for respect. I find that the biggest obstacle to getting clarity on naming is that when faced with an analysis that contradicts deeply held beliefs, the usual response is to tell people to 'do some research' or 'understand the issues'. The URN/URI distinction does not in fact represent an essential distinction between types identifiers as claimed. It describes a difference in source of authority at best, not an essential property. 1) DNS names are names. This is easy to see, it is what the N stands for. The signifier bears no direct relation to the signified. It is a purely conventional relationship. 2) IP addresses are also names Again, the signifier bears no direct relation to the signified. It is a purely conventional relationship. 3) File names are names Again, the signifier bears no direct relation to the signified. It is a purely conventional relationship. 4) HTTP local paths are names See above. So a HTTP URL consists of :// // So a URL is obviously a form of name. The location semantics are not intrinsic to the name itself, they are intrinsic to its mode of use. If you look at practically every UR'N' scheme it has precisely the same form albeit with different syntax. There is a method part and some hierarchical delegation of naming. But (with rare exceptions) it is naming all the way down. The reason URL/URL discussions are so notoriously unproductive is people are attempting to make an intrinsic distinction between classes of name where there is none. The only forms of network identifier that are not pure names are data URIs and the ones that are indexical such as the ni: scheme described in RFC6920. But even that distinction can be bent. The strong Internet Names I propose here: https://www.ietf.org/id/draft-hallambaker-mesh-udf-08.html define a subset of DNS labels that are indexical rather than names. And those have some important and useful properties. They allow the result of a trust decision to be encapsulated as an atomic name. On Tue, Jan 7, 2020 at 1:58 AM John C Klensin wrote: > Hi. > > My apologies for the extreme lateness of this note. I have > tried to pass URN work on to others since RFCs 8141 and 8254 and > had assumed that someone else would check through this document > to be sure that it appropriately covered both locator-type and > name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3). > I had assumed that reviews within the ART area and/or a specific > ART Area Review would address that topic but, AFAICT, they may > not have done so. > > I've had occasion to look through the document and I'm actually > not sure about the name-locator distinction as it may apply to > it. This note will be short and is rather more about asking the > IESG to be sure that any possible issues are addressed than to > try to do a detailed review of the issues. > > AFAICT, the focus of the I-D is to be sure that applications and > elaborations of any URI scheme be firmly under the control and > management of the owner of that scheme and that possible > deviations from that principle are well-controlled. > http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1, > cited in the draft as [webarch] is clear that the ownership of a > URN is delegated to the owners of URN Namespaces rather than > being bound to the "urn" URI scheme itself. I believe it is > possible to read this document in a way that has no impact on > URNs and URN namespaces. However, it appears to me that, if > read without appropriate care, some of the restrictions imposed > on queries and fragments may be inconsistent with mechanisms and > syntax for use in particular URN Namespaces or URNs generally > that were contemplated and extensively discussed during the > development of RFC 8141. Those ideas were deferred by the WG > for future work but the mechanisms may well be in use in > important URN namespaces. Because the last paragraph of Section > 1.1 of this I-D essentially declares any existing specification, > even a standards-track one or one adopted by other bodies, that > does not comply with the recommendations of the I-D to be > incorrect and in need of correction, the effects of a reading > that retroactively restricts URN Namespace practices that are > under the control of the Namespace owners could be quite serious. > > My preference would be that someone who has been more active > with URN work and Namespace registrations in the last couple of > years do a careful review of the document to determine whether > my concerns justify some tuning of the text. However, given how > late it is in the review process (again, my apologies for not > catching the issue until now), a reasonable alternative would be > to simply insert a sentence early in the I-D that says that it > applies primarily to locator-type URIs although name-type ones > may find it useful as general guidance _or_ to explicitly call > out the difference in ownership between URNs and other URI > schemes. > > thanks, > john > > p.s. It would be, IMO, helpful if the IESG and the community > would think about the implications of BCP (or IETF-stream > Informational) documents that effectively obsolete or deprecate > existing standards without identifying them or explicitly > updating them and whose responsibility it is to find the > discrepancies. > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --000000000000a22c17059b8d11e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I remain of the view that the URN/URL distinction is unhelpfu= l because it is meaningless. There are no sharp boundaries=C2=A0between cat= egories of identifier as the distinction supposes.

Before making this argument in more detail, I wil= l make a plea for respect. I find that the biggest obstacle to getting clar= ity on naming is that when faced with an analysis that contradicts deeply h= eld beliefs, the usual response is to tell people to 'do some research&= #39; or 'understand the issues'.

The URN/URI distinction does not in fact represent an essen= tial distinction between types identifiers as claimed. It describes a diffe= rence in source of authority at best, not an essential property.

1) DNS names are names.

This is easy to see, it is what the = N stands for. The signifier bears no direct relation to the signified. It i= s a purely conventional relationship.

2) IP addresses are also names

Again, the=C2=A0signifier bears no direct relation to = the signified. It is a purely conventional relationship.

3) File names are names

Again, the=C2=A0signifier bears no direct re= lation to the signified. It is a purely conventional relationship.

4) HTTP local paths are names=

See above.


So a HTTP URL consists of

<method part> :// <IANA name part> = // <local name part>

So a URL is obviously a form of name. The location semantics are not intr= insic to the name itself, they are intrinsic to its mode of use.=C2=A0


If you look at practically every UR'= ;N' scheme it has precisely the same form albeit with different syntax.= There is a method part and some hierarchical delegation of naming. But (wi= th rare exceptions) it is naming all the way down.

The reason URL/URL discussions are so notoriously= unproductive is people are attempting to make an intrinsic distinction bet= ween classes of name where there is none.


The only forms of network identifier that are not pure names are dat= a URIs and the ones that are indexical such as the ni: scheme described in = RFC6920.

But even that di= stinction can be bent. The strong Internet Names I propose here:
https://www.ietf.org/id/draft= -hallambaker-mesh-udf-08.html=C2=A0define a subset of DNS labels that a= re indexical rather than names. And those have some important and useful pr= operties. They allow the result of a trust decision to be encapsulated as a= n atomic name.


On Tue, Jan 7, 2020 at 1:58 AM John C Klensin <john-ietf@jck.com> wrote:
Hi.

My apologies for the extreme lateness of this note.=C2=A0 I have
tried to pass URN work on to others since RFCs 8141 and 8254 and
had assumed that someone else would check through this document
to be sure that it appropriately covered both locator-type and
name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3).
I had assumed that reviews within the ART area and/or a specific
ART Area Review would address that topic but, AFAICT, they may
not have done so.

I've had occasion to look through the document and I'm actually
not sure about the name-locator distinction as it may apply to
it.=C2=A0 This note will be short and is rather more about asking the
IESG to be sure that any possible issues are addressed than to
try to do a detailed review of the issues.

AFAICT, the focus of the I-D is to be sure that applications and
elaborations of any URI scheme be firmly under the control and
management of the owner of that scheme and that possible
deviations from that principle are well-controlled.
http://www.w3.org/TR/2004/REC-webarch-20041215, Se= ction 2.2.2.1,
cited in the draft as [webarch] is clear that the ownership of a
URN is delegated to the owners of URN Namespaces rather than
being bound to the "urn" URI scheme itself.=C2=A0 I believe it is=
possible to read this document in a way that has no impact on
URNs and URN namespaces.=C2=A0 =C2=A0However, it appears to me that, if
read without appropriate care, some of the restrictions imposed
on queries and fragments may be inconsistent with mechanisms and
syntax for use in particular URN Namespaces or URNs generally
that were contemplated and extensively discussed during the
development of RFC 8141.=C2=A0 Those ideas were deferred by the WG
for future work but the mechanisms may well be in use in
important URN namespaces.=C2=A0 Because the last paragraph of Section
1.1 of this I-D essentially declares any existing specification,
even a standards-track one or one adopted by other bodies, that
does not comply with the recommendations of the I-D to be
incorrect and in need of correction, the effects of a reading
that retroactively restricts URN Namespace practices that are
under the control of the Namespace owners could be quite serious.

My preference would be that someone who has been more active
with URN work and Namespace registrations in the last couple of
years do a careful review of the document to determine whether
my concerns justify some tuning of the text.=C2=A0 However, given how
late it is in the review process (again, my apologies for not
catching the issue until now), a reasonable alternative would be
to simply insert a sentence early in the I-D that says that it
applies primarily to locator-type URIs although name-type ones
may find it useful as general guidance _or_ to explicitly call
out the difference in ownership between URNs and other URI
schemes.

=C2=A0thanks,
=C2=A0 =C2=A0john

p.s. It would be, IMO, helpful if the IESG and the community
would think about the implications of BCP (or IETF-stream
Informational) documents that effectively obsolete or deprecate
existing standards without identifying them or explicitly
updating them and whose responsibility it is to find the
discrepancies.

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--000000000000a22c17059b8d11e6-- From nobody Tue Jan 7 08:16:54 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5712011B; Tue, 7 Jan 2020 08:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 awvczxoQv_1e; Tue, 7 Jan 2020 08:16:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E27512025D; Tue, 7 Jan 2020 08:15:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B32B3897A; Tue, 7 Jan 2020 11:15:22 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9864060A; Tue, 7 Jan 2020 11:15:42 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker cc: John C Klensin , "General Area Review Team \(gen-art\@ietf.org\)" , urn@ietf.org, The IESG , IETF Discussion Mailing List Subject: Re: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice In-Reply-To: References: <87E116C31DAF1434C3C3937F@PSB> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:16:42 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > I remain of the view that the URN/URL distinction is unhelpful because it is > meaningless. There are no sharp boundaries between categories of identifier > as the distinction supposes. > Before making this argument in more detail, I will make a plea for respect. I > find that the biggest obstacle to getting clarity on naming is that when > faced with an analysis that contradicts deeply held beliefs, the usual > response is to tell people to 'do some research' or 'understand the issues'. > The URN/URI distinction does not in fact represent an essential distinction > between types identifiers as claimed. It describes a difference in source of > authority at best, not an essential property. I agree with you. I think that we might have found new ways in which they are meaningfully distinct had to a uquitious way to resolve the more abstract URNs. That didn't happen, and I don't imagine that it is coming in the way envisioned. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4Urq4ACgkQgItw+93Q 3WWONgf8DeSN6pqvnrPmk6JBkccxZSOJo0qaGFxfwTLm37ssBZi2B0/wJTlqsLam DHobBseXAa9QIczNhhIraUBZ3o/cxlLj75MkyRiutga8olIFSdavmK8VOC7AcXY5 Q9j2DesWlYGW4rWABOmm3jyGFo9jGjmM4Q6cvrtveXCDcUGtg3WFaLJqjeHHBWVY nIwqBZSCgfy0Rg/XB/WpzDWB8QIm1g88HKCGvt8eSw6bQHLD/8vp1DImWe61ZrEt rjNRm8GpJ2xJt2552IUAz4GJyKkJ3FVUaG1cNGmyRCYGzpdnHmKPSkIi+FiQx2Jo +khrc3dQLwSYBsZ5Z0NDjIEb5NO7+g== =2Q2o -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 7 08:35:42 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96375120855; Tue, 7 Jan 2020 08:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 d05P0sxs3B5X; Tue, 7 Jan 2020 08:35:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DFD120851; Tue, 7 Jan 2020 08:35:18 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 007GZEEY063997 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 7 Jan 2020 10:35:16 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578414917; bh=kh6+P4K8azbFqbi6ACYIBh3BOFCHbZc1rccEKnmGM0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TDf+0KU4w5wgOd6b0WPrKO0xIbU/DD0d7eEr+PG1cQXNYXNtUdCcFNV0jDgAL4De3 6KkWoZf38deb3FsVYydMxXdm3v4P/L1sUvue8E/836iG8eWgUW5TomcufbkQbPwzf0 2wHAQJpFo5KSt5gVTnAnXSOk5rPdChZKWXxRHE9I= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: John C Klensin , iesg@ietf.org Cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> From: Adam Roach Message-ID: Date: Tue, 7 Jan 2020 10:35:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:35:28 -0000 To help with framing this conversation, the changes from RFC 7320 are highlighted here: https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-03 I have some rather extensive thoughts on the process of creating bis documents [1]. While I'm not going to reiterate all of them here, I want to highlight a specific passage that seems to bear on John's comments: >    One major concern that drives these incremental document updates is >    that an attempt to republish an RFC as originally described in RFC >    2026 can result in such an effort being bogged down by issues that >    exist in text unrelated to the desired changes.  Such issues can >    arise from a change in the consensus of the IETF around best current >    practices, such as in the areas of security, privacy, or >    architectural design of an underlying protocol.  This complication >    arises from the fact that processing of an updated full version of an >    RFC is procedurally identical to processing of a green-field >    definition of a new protocol: review by the IETF at large, and review >    by the IESG, are performed on the entire document, leaving legacy >    text open to comments that will delay - and occasionally block - >    publication of such documents. /a ____ [1] https://tools.ietf.org/html/draft-roach-bis-documents-00 On 1/7/20 12:57 AM, John C Klensin wrote: > Hi. > > My apologies for the extreme lateness of this note. I have > tried to pass URN work on to others since RFCs 8141 and 8254 and > had assumed that someone else would check through this document > to be sure that it appropriately covered both locator-type and > name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3). > I had assumed that reviews within the ART area and/or a specific > ART Area Review would address that topic but, AFAICT, they may > not have done so. > > I've had occasion to look through the document and I'm actually > not sure about the name-locator distinction as it may apply to > it. This note will be short and is rather more about asking the > IESG to be sure that any possible issues are addressed than to > try to do a detailed review of the issues. > > AFAICT, the focus of the I-D is to be sure that applications and > elaborations of any URI scheme be firmly under the control and > management of the owner of that scheme and that possible > deviations from that principle are well-controlled. > http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1, > cited in the draft as [webarch] is clear that the ownership of a > URN is delegated to the owners of URN Namespaces rather than > being bound to the "urn" URI scheme itself. I believe it is > possible to read this document in a way that has no impact on > URNs and URN namespaces. However, it appears to me that, if > read without appropriate care, some of the restrictions imposed > on queries and fragments may be inconsistent with mechanisms and > syntax for use in particular URN Namespaces or URNs generally > that were contemplated and extensively discussed during the > development of RFC 8141. Those ideas were deferred by the WG > for future work but the mechanisms may well be in use in > important URN namespaces. Because the last paragraph of Section > 1.1 of this I-D essentially declares any existing specification, > even a standards-track one or one adopted by other bodies, that > does not comply with the recommendations of the I-D to be > incorrect and in need of correction, the effects of a reading > that retroactively restricts URN Namespace practices that are > under the control of the Namespace owners could be quite serious. > > My preference would be that someone who has been more active > with URN work and Namespace registrations in the last couple of > years do a careful review of the document to determine whether > my concerns justify some tuning of the text. However, given how > late it is in the review process (again, my apologies for not > catching the issue until now), a reasonable alternative would be > to simply insert a sentence early in the I-D that says that it > applies primarily to locator-type URIs although name-type ones > may find it useful as general guidance _or_ to explicitly call > out the difference in ownership between URNs and other URI > schemes. > > thanks, > john > > p.s. It would be, IMO, helpful if the IESG and the community > would think about the implications of BCP (or IETF-stream > Informational) documents that effectively obsolete or deprecate > existing standards without identifying them or explicitly > updating them and whose responsibility it is to find the > discrepancies. > From nobody Tue Jan 7 09:48:28 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A14A1200E9; Tue, 7 Jan 2020 09:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj02Aq8RDiIK; Tue, 7 Jan 2020 09:48:14 -0800 (PST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 B48E31200CC; Tue, 7 Jan 2020 09:48:14 -0800 (PST) Received: by mail-io1-f47.google.com with SMTP id h8so243535iob.2; Tue, 07 Jan 2020 09:48:14 -0800 (PST) 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=IuOpvnuUwP/KQ++zdKH6O9Dn1kirFI26FmD411J8kFo=; b=Mfw4ZjImsvORLT7oJY47TinaeoBE4xmWTTXxw9Ynel8EI0ijKfg2ZxlLgUC/HxaDW6 5FyPFryWTmLfQKP2szTM1OsSnaRv6csegUGgVzxg/tg0j6OySZndVf7DZG6xQrSecxjH ZeNDkNMAvSRlTbGZBjRpNdzfRzZpxJ8dOIetbxoO4NB0m7xw62+lArmJD5Q62YRUO+B8 F7rcmFmhDjE49xG7DzEPKwpQps++qVIuT0dvfzMTapLVpmABUnYDGEwftm/InEJZRGmt DkFDlZ2JSXlVVG5bwEkjenKYRI12UW/1voi5PLOy/bDDq9trr8CxE9EjE9nU2bVfuNoO bFTQ== X-Gm-Message-State: APjAAAXKyZ6zs5BAfpV/zXgWalNcry127VVhsoSq1Fa0Ep/kEbe/RYrJ c4wFvbGSnpqAchvsaTJysA3Y2M8QHzahKIjePaMEuA== X-Google-Smtp-Source: APXvYqz+iMHKRZ6cE/ZPkUmY/G7J7oTUieATdjzbRNz0GeAS2qd7qpmAN1yC/IUyviKzZwXXAF4nw+lZLuprGt/73V8= X-Received: by 2002:a5e:8417:: with SMTP id h23mr84197ioj.17.1578419293573; Tue, 07 Jan 2020 09:48:13 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> From: Barry Leiba Date: Tue, 7 Jan 2020 12:48:02 -0500 Message-ID: Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: John C Klensin Cc: IESG , art@ietf.org, Mark Nottingham , urn@ietf.org, IETF discussion list Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 17:48:16 -0000 I think we need to tease apart two things in John's note: the URN scheme, and the concept of URNs as opposed to URLs, the two together forming what we call URIs. It's clear to me that BCP 190 has no actual effect on "urn:", because the things it talks about simply don't apply there, or are taken care of by the fact that URN namespaces are completely controlled by the owners of the namespaces. There is no internal hierarchy within URN namespaces unless the specification of the namespace creates one and defines how that hierarchy works and is managed. For the other part of the issue, I'm not fully in agreement with Phillip and Michael, in that I do think there's a useful distinction between a URI that names something without specifying how to locate it... and one that is a locator. There is, for example, a fundamental difference between, say, "http:" and "ni:" (see RFC 6920). That said, I also think that existing URI schemes that define *names* lack hierarchies, and are similarly not really affected by BCP 190. As I read through 7320bis and placed my "Yes" ballot, I didn't see anything, neither in the original text nor in the changed text, that made me question this, and as I look back through it now I still don't. So I don't have any concerns here. If anyone has something specific to raise, please raise it now, while the document is still in IESG Evaluation and we can more easily discuss it and make changes. Barry On Tue, Jan 7, 2020 at 1:58 AM John C Klensin wrote: > > Hi. > > My apologies for the extreme lateness of this note. I have > tried to pass URN work on to others since RFCs 8141 and 8254 and > had assumed that someone else would check through this document > to be sure that it appropriately covered both locator-type and > name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3). > I had assumed that reviews within the ART area and/or a specific > ART Area Review would address that topic but, AFAICT, they may > not have done so. > > I've had occasion to look through the document and I'm actually > not sure about the name-locator distinction as it may apply to > it. This note will be short and is rather more about asking the > IESG to be sure that any possible issues are addressed than to > try to do a detailed review of the issues. > > AFAICT, the focus of the I-D is to be sure that applications and > elaborations of any URI scheme be firmly under the control and > management of the owner of that scheme and that possible > deviations from that principle are well-controlled. > http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1, > cited in the draft as [webarch] is clear that the ownership of a > URN is delegated to the owners of URN Namespaces rather than > being bound to the "urn" URI scheme itself. I believe it is > possible to read this document in a way that has no impact on > URNs and URN namespaces. However, it appears to me that, if > read without appropriate care, some of the restrictions imposed > on queries and fragments may be inconsistent with mechanisms and > syntax for use in particular URN Namespaces or URNs generally > that were contemplated and extensively discussed during the > development of RFC 8141. Those ideas were deferred by the WG > for future work but the mechanisms may well be in use in > important URN namespaces. Because the last paragraph of Section > 1.1 of this I-D essentially declares any existing specification, > even a standards-track one or one adopted by other bodies, that > does not comply with the recommendations of the I-D to be > incorrect and in need of correction, the effects of a reading > that retroactively restricts URN Namespace practices that are > under the control of the Namespace owners could be quite serious. > > My preference would be that someone who has been more active > with URN work and Namespace registrations in the last couple of > years do a careful review of the document to determine whether > my concerns justify some tuning of the text. However, given how > late it is in the review process (again, my apologies for not > catching the issue until now), a reasonable alternative would be > to simply insert a sentence early in the I-D that says that it > applies primarily to locator-type URIs although name-type ones > may find it useful as general guidance _or_ to explicitly call > out the difference in ownership between URNs and other URI > schemes. > > thanks, > john > > p.s. It would be, IMO, helpful if the IESG and the community > would think about the implications of BCP (or IETF-stream > Informational) documents that effectively obsolete or deprecate > existing standards without identifying them or explicitly > updating them and whose responsibility it is to find the > discrepancies. > From nobody Tue Jan 7 11:12:05 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40C61200FB; Tue, 7 Jan 2020 11:11:54 -0800 (PST) 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, 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 z84cV2DVfgNG; Tue, 7 Jan 2020 11:11:52 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADFF1200FD; Tue, 7 Jan 2020 11:11:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1iouGZ-0008r3-9f; Tue, 07 Jan 2020 14:11:47 -0500 Date: Tue, 07 Jan 2020 14:11:40 -0500 From: John C Klensin To: Adam Roach , iesg@ietf.org cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice Message-ID: <444B2465A9B73F3D0DE59FFF@PSB> In-Reply-To: References: <87E116C31DAF1434C3C3937F@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:11:55 -0000 --On Tuesday, January 7, 2020 10:35 -0600 Adam Roach wrote: > To help with framing this conversation, the changes from RFC > 7320 are highlighted here: >=20 > = https://www.ietf.org/rfcdiff?url1=3Drfc7320&url2=3Ddraft-nottingh= a > m-rfc7320bis-03 >=20 > I have some rather extensive thoughts on the process of > creating bis documents [1]. While I'm not going to reiterate > all of them here, I want to highlight a specific passage that > seems to bear on John's comments: >=20 >> =C2=A0=C2=A0 One major concern that drives these incremental = document >> updates is =C2=A0=C2=A0 that an attempt to republish an RFC = as >> originally described in RFC =C2=A0=C2=A0 2026 can result in = such an >> effort being bogged down by issues that =C2=A0=C2=A0 exist in = text >> unrelated to the desired changes.=C2=A0 Such issues can = =C2=A0=C2=A0 >> arise from a change in the consensus of the IETF around best >... Adam, I studied those comments when you first posted them. I believe that I sent comments at that time, but to summarize and highlight them in a shorter note, I see a key problem (and several others that may be less important and that were addressed in my earlier comments) with an replacement document that does not address all open issues in its predecessor: It leaves the reader with the understanding that the new document represents the IETF's best understanding of the topic covered (not merely a view of the most urgent problems to be fixed). Put differently, it implies that any issues not address are unimportant. That can be mitigated somewhat by including a section identifying known outstanding issues, but draft-nottingham-rfc7320bis-03 does not appear to contain such a section.=20 In addition, as your quoted comment above implies, an incremental document that nonetheless replaces an earlier one is a change to what 2026 specifies. I do not believe it is appropriate to change the procedures of 2026 by ignoring it, nor do I believe that examples of its being ignored in the past constitute justification for ignoring it in the future. Just as we tried to do with NEWTRK and ISDs (arguably a different approach to at least part of the problem you are trying to address), a change to how we handle replacement documents that ignores (if nothing else) 2026's "no known defects" rule requires an update or other change to 2026 before the desired approach is appealed to in order to justify a particular document. That, and my p.s., aside, I had hoped my note would rather carefully avoid dragging us back into either this issue or the ones raised by Phillip and Barry (like Barry, I don't fully agree with the former). It seems to me that both that comment and part of Barry's raise fundamental questions about how RFC3986 is defined and what it specifies. Those issues are probably best addressed at another time. =20 Instead, I was trying to raise a far more narrow question: Given that RFC 3986 separates names and locators and that we have already had confusion about what is appropriate in URNs based on the language there, does this document make things worse? I think it may. Even a statement fragment (from the first paragraph of Section 3 and inherited from 7320) like "...as links that are exchanged as part of the protocol, rather than statically specified syntax" are inconsistent with the use of keyword values in some URN namespaces as static indicators. If you want to ask the slightly different question of whether, if RFC 7320 made things worse, does this I-D make things even worse than that, I don't have an easy answer except to note at least one example: The last paragraph of Section 2.3, which appears to be new, says > Extensions MUST NOT define a structure within individual URI > components (e.g., a prefix or suffix), again to avoid > collisions and erroneous client assumptions. But, as I understand that rule, it is precisely what some rules, and provisions for namespace-specific rules, in RFC 8141, do. Again, the solution at this point appears to be either to be much more careful about binding the statements in the I-D to the concept of ownership or to indication that this specification does not apply to URNs (or, if preferred, to what 3986 describes as "name" URIs) at all. best, john From nobody Tue Jan 7 11:23:21 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02584120220 for ; Tue, 7 Jan 2020 11:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 09hEK4v7HK9g for ; Tue, 7 Jan 2020 11:23:18 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BF8120169 for ; Tue, 7 Jan 2020 11:23:18 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8DFE421FBC; Tue, 7 Jan 2020 14:23:17 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 07 Jan 2020 14:23:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=eJRzvx UMr9x91gJ4wfqjUBXBKJT+HJZ9XqO8FYV20Vk=; b=WKYrMMR5DQkVreh1nIGH4H mZ45Iynd0XEaj8GVoTyMy6EH+47zG0YjgqmNSu3L2swXhenr/0aybGgI4ckWsa6y 7EYqO47hBRA6zsVfIZri/MAWXmJaUD9gUM5k8Y7fcJrVQUEwhSyBW5B/LAR9Ltut a+XPNBS5JVk8YUs10xqC0jLpFEIaSlPRhy9DATGgbyio6gzfS9Swny8SJgXeIZtC p+pq6qhY3u5UjdcG2wQMXzaPWmshG79qS67Vso3GbY+1cMIf083p0uZc2ZEMMQhn QH96+RRH1ErU8zAAmaTmTUfmqUAmM/aqhsgcr9nccTwu6s8EmOoYNqHi/OuQ/vGQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehiedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecukfhppedutdekrddvvddurddukedtrdduhe enucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgv thhitghsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B6F6330602DE; Tue, 7 Jan 2020 14:23:16 -0500 (EST) Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> From: Keith Moore Message-ID: Date: Tue, 7 Jan 2020 14:23:16 -0500 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: Content-Type: multipart/alternative; boundary="------------F53B2517F0B16AFDE0773835" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:23:20 -0000 This is a multi-part message in MIME format. --------------F53B2517F0B16AFDE0773835 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/7/20 12:48 PM, Barry Leiba wrote: > For the other part of the issue, I'm not fully in agreement with > Phillip and Michael, in that I do think there's a useful distinction > between a URI that names something without specifying how to locate > it... and one that is a locator. I emphatically disagree.  URNs have /defined/ properties that URIs in general do not.   The constant efforts by those politically opposed to URNs because of Not Invented Here syndrome, to degrade the utility of URNs, have been obvious for a long time now, and can only be understood as deliberate efforts to cause harm. Keith --------------F53B2517F0B16AFDE0773835 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/7/20 12:48 PM, Barry Leiba wrote:

For the other part of the issue, I'm not fully in agreement with
Phillip and Michael, in that I do think there's a useful distinction
between a URI that names something without specifying how to locate
it... and one that is a locator.

I emphatically disagree.  URNs have defined properties that URIs in general do not.   The constant efforts by those politically opposed to URNs because of Not Invented Here syndrome, to degrade the utility of URNs, have been obvious for a long time now, and can only be understood as deliberate efforts to cause harm.

Keith


--------------F53B2517F0B16AFDE0773835-- From nobody Tue Jan 7 11:54:14 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA81200FD; Tue, 7 Jan 2020 11:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxQRab6X6ZKR; Tue, 7 Jan 2020 11:53:53 -0800 (PST) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 2E27D1200B3; Tue, 7 Jan 2020 11:53:53 -0800 (PST) Received: by mail-oi1-f179.google.com with SMTP id p67so498786oib.13; Tue, 07 Jan 2020 11:53:53 -0800 (PST) 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=ibvo7OmV9+zNwjb1AHdIT1vKqOZQ/LoeRVExlz19n8A=; b=m1eKD0DimMFXqj4PPYNigVO2KLLhsOBcW3N5+HschzBt+d9XjpTKCZ/Pinkv2KhwI6 /729Vyj9Ypp8nKx39lxkkD7U/6zh2JzQMBRHfbhi1lQotksNohLdUoc7K88OuYM1pfV0 i/PcO0X9FqdyPGze2jdPj9SbTRie5igCxN5dikPihXBTVFxhXQXdkgTY9SW7cUZQeqs6 5VLE2ipuU/9W/b3KGvHBNje5cb4P27TSO7e0iXGJ32U8HsMcv73sgPPcgc+vGKgVclc6 lPDRz9EhRrdsL+2vGi21eDGUIlye82PLhiQi45GD/+YzRhhz2IUb5Vw8yWrGrD5nvXAg qz7Q== X-Gm-Message-State: APjAAAVLkUtD/oWlIfGNatz89g9iIJD+2cQYUSWADx6ep60Oae18a7w9 1phCnNwm4cpfsmYDFX9ioIKNriKUYWtF/vQFNKzbQ38td/U= X-Google-Smtp-Source: APXvYqxvdqhMzuAeUM4BwZOAH1pf43T/A6RUak2okFVC3rLZ+5z6tKjB5FKIzUkgspI3SuwGkc7UO64MnMwpg2rrT1s= X-Received: by 2002:a54:4f04:: with SMTP id e4mr48512oiy.111.1578426832209; Tue, 07 Jan 2020 11:53:52 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> <29803.1578413742@localhost> In-Reply-To: <29803.1578413742@localhost> From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 14:53:43 -0500 Message-ID: Subject: Re: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: Michael Richardson Cc: John C Klensin , "General Area Review Team (gen-art@ietf.org)" , urn@ietf.org, The IESG , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="000000000000a3494a059b922212" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:53:55 -0000 --000000000000a3494a059b922212 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 12:48 PM Barry Leiba wrote: > For the other part of the issue, I'm not fully in agreement with > Phillip and Michael, in that I do think there's a useful distinction > between a URI that names something without specifying how to locate > it... and one that is a locator. There is, for example, a fundamental > difference between, say, "http:" and "ni:" (see RFC 6920). That is precisely what I was talking about when I said that ni: is indexical. But that is no longer an essential distinction either. We can distinguish names that are under IANA authority (DNS, IP) from those that are not. But that is the limit of it. Given that it was announced today that SHA-1 was broken, lets take another look at a SIN: alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com That is a valid email address. It can be routed on the Internet (not the best privacy choice but possible). But it is a name that can be bound to a security policy. So if mb2gk-6duf5-ygyyl-jny5e-rwshz is the UDF (SHA-2-512) of Alice's OpenPGP encryption key. We have an implicit semantic here: Encrypt all mail sent to this address with the key that has fingerprint mb2gk-6duf5-ygyyl-jny5e-rwshz The reason that I have hammered on the fact that the name/locator distinction being bogus is precisely because the obsession with defining a distinction where there is NO difference has caused the neglect of a situation where there is a very real and important one. https://www.ietf.org/id/draft-hallambaker-mesh-udf-08.html#name-secure-internet-names A Strong Internet Name allows ANY URI with a DNS component to be turned On Tue, Jan 7, 2020 at 11:15 AM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > I remain of the view that the URN/URL distinction is unhelpful > because it is > > meaningless. There are no sharp boundaries between categories of > identifier > > as the distinction supposes. > > > Before making this argument in more detail, I will make a plea for > respect. I > > find that the biggest obstacle to getting clarity on naming is that > when > > faced with an analysis that contradicts deeply held beliefs, the > usual > > response is to tell people to 'do some research' or 'understand the > issues'. > > > The URN/URI distinction does not in fact represent an essential > distinction > > between types identifiers as claimed. It describes a difference in > source of > > authority at best, not an essential property. > > I agree with you. > > I think that we might have found new ways in which they are meaningfully > distinct had to a uquitious way to resolve the more abstract URNs. > That didn't happen, and I don't imagine that it is coming in the way > envisioned. > HTTPs are names but they are a name that embodies a (fairly) unambiguous means of location. Having had the misfortune to engage in discussion with acolytes of a prominent opponent of post-modernism, I have been writing a defense of postmodernism today. One of the chief arguments made by the postmodernists is that perfect knowledge is an illusion. And I think that is a profound observation that is essential to understanding why the original concept of URNs and for that matter most registration schemes are doomed to fail. The Web succeeded because of 404 Not Found. The links are scruffy. And that is fine if you are OK with the idea that knowledge can be scruffy, that it will never be perfect. And that is why the Web came out of CERN because (good) scientists understand that there is no absolute knowledge and that what we are arriving at is a better approximation to the truth, not the truth itself. There have been plenty of people making that type of argument since ancient times. But until the mid 80s, most scientists had a very rigid epistemology that was essentially Victorian in its outlook. Scientists were serious people who were finding out profound and universal truths and we had all be very very careful not to make mistakes because that 'would be bad'. I would encourage people to take a look at what research scientists in their 20s and 30s are saying about their approach to science. They are utterly rejecting that view. What politicians now call 'Western values' and demand other countries observe is a modern construct that is fifty years (racial tolerance) old at most. In some areas, what is now the fixed consensus is less than a decade old (evolve already). The reason we have the nonsense of .com, .org, .net etc is because DNS was designed by people who had an essentially Victorian view of epistemology in which taxonomy represents essential qualities. (Whether the same is true of the extension TLDs I will leave aside) The reason I and others received (and continue to receive from some) the patronizing responses we do (do some research you ignorant baboon! you don't understand) is that we have profoundly different and fundamentally incompatible epistemologies and some people regard mine as heresy. Both are capable of self examination. But mine is capable of examining theirs, they can only reject mine. So its like me trying to explain complex numbers to someone who insists that you can't take the square root of a negative number and can't get past that. The route out of formal methods to PoMo is that to solve the problems we faced in the 1980s in formal methods, it was necessary to apply meta-mathematics and understand the limitations of logic. And once you do that you are in Post Modernism. So the URN notion that we must carefully decide how to resolve before we defined schemes was wrong. It was and is much more important to have a catalog that is as *complete *as possible than for the entries to be *correct*. Resolution of many types of name is inherently ambiguous because the context varies. We cannot resolve a barcode on a physical object like a can of beans. But we can ask for information on the can of beans and we can order an instance of the can of beans for delivery. And both forms of 'location' are going to be subjective and depend on the context in which they are attempted. --000000000000a3494a059b922212 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 7, 2020 at 12:48 PM Barry Leiba= <barryleiba@computer.org= > wrote:=C2=A0=C2=A0
For the other part of th= e issue, I'm not fully in agreement with
Phillip and Michael, in tha= t I do think there's a useful distinction
between a URI that names s= omething without specifying how to locate
it... and one that is a locato= r.=C2=A0 There is, for example, a fundamental
difference between, say, "http:" and "ni:" (see RFC 692= 0).=C2=A0=C2=A0

Tha= t is precisely what I was talking about when I said that ni: is indexical. = But that is no longer an essential distinction either.

We can distinguish nam= es that are under IANA authority (DNS, IP) from those that are not. But tha= t is the limit of it.


Given that it wa= s announced today that SHA-1 was broken, lets take another look at a SIN:

That is a valid email address. It = can be routed on the Internet (not the best privacy choice but possible). B= ut it is a name that can be bound to a security policy.

So if=C2=A0 mb2gk-6duf5-ygyyl-jny5e-rwshz is the UDF (SHA-2-512) of Alice's OpenPGP= encryption key. We have an implicit semantic here: Encrypt all mail sent t= o this address with the key that has fingerprint mb2gk-6duf5-ygyyl-jny5e-rw= shz

The reason that I have hammered on the fact that the name/locator distinct= ion being bogus is precisely because the obsession with defining a distinct= ion where there is NO difference has caused the neglect of a situation wher= e there is a very real and important one.


A Strong Internet Name allows ANY URI with a DNS component = to be turned



=
On Tue, Jan 7, 2020 at 11:15 AM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Phillip Hallam-Baker <ietf@hallambaker.com> wrote:
=C2=A0 =C2=A0 > I remain of the view that the URN/URL distinction is unh= elpful because it is
=C2=A0 =C2=A0 > meaningless. There are no sharp boundaries between categ= ories of identifier
=C2=A0 =C2=A0 > as the distinction supposes.

=C2=A0 =C2=A0 > Before making this argument in more detail, I will make = a plea for respect. I
=C2=A0 =C2=A0 > find that the biggest obstacle to getting clarity on nam= ing is that when
=C2=A0 =C2=A0 > faced with an analysis that contradicts deeply held beli= efs, the usual
=C2=A0 =C2=A0 > response is to tell people to 'do some research'= or 'understand the issues'.

=C2=A0 =C2=A0 > The URN/URI distinction does not in fact represent an es= sential distinction
=C2=A0 =C2=A0 > between types identifiers as claimed. It describes a dif= ference in source of
=C2=A0 =C2=A0 > authority at best, not an essential property.

I agree with you.

I think that we might have found new ways in which they are meaningfully distinct had to a uquitious way to resolve the more abstract URNs.
That didn't happen, and I don't imagine that it is coming in the wa= y envisioned.

HTTPs are names but they are a name that embo= dies a (fairly) unambiguous means of location.

Having had the misfortune to engage in discussion wit= h acolytes of a prominent opponent of post-modernism, I have been writing a= defense of postmodernism today. One of the chief arguments made by the pos= tmodernists is that perfect knowledge is an illusion. And I think that is a= profound observation that is essential to understanding why the original c= oncept of URNs and for that matter most registration schemes are doomed to = fail.

The Web succeeded b= ecause of 404 Not Found. The links are scruffy. And that is fine if you are= OK with the idea that knowledge can be scruffy, that it will never be perf= ect. And that is why the Web came out of CERN because (good) scientists und= erstand that there is no absolute knowledge and that what we are arriving a= t is a better approximation to the truth, not the truth itself.=C2=A0
=

There have been plenty of peop= le making that type of argument since ancient times. But until the mid 80s,= most scientists had a very rigid epistemology that was essentially Victori= an in its outlook. Scientists were serious people who were finding out prof= ound and universal truths and we had all be very very careful not to make m= istakes because that 'would be bad'.

I would encourage people to take a look at what resear= ch scientists in their 20s and 30s are saying about their approach to scien= ce. They are utterly rejecting that view.

What politicians now call 'Western values' and= demand other countries observe is a modern construct that is fifty years (= racial tolerance) old at most. In some areas, what is now the fixed consens= us is less than a decade old (evolve already). The reason we have the nonse= nse of .com, .org, .net etc is because DNS was designed by people who had a= n essentially Victorian view of epistemology in which taxonomy represents e= ssential qualities. (Whether the same is true of the extension TLDs I will = leave aside)
The reason I= and others received (and continue to receive from some) the patronizing re= sponses we do (do some research you ignorant baboon! you don't understa= nd) is that we have profoundly different and fundamentally incompatible epi= stemologies and some people regard mine as heresy. Both are capable of self= examination. But mine is capable of examining theirs, they can only reject= mine. So its like me trying to explain complex numbers to someone who insi= sts that you can't take the square root of a negative number and can= 9;t get past that.

The ro= ute out of formal methods to PoMo is that to solve the problems we faced in= the 1980s in formal methods, it was necessary to apply meta-mathematics an= d understand the limitations of logic. And once you do that you are in Post= Modernism.


So the URN notion that we must carefully decide how to resolve befo= re we defined schemes was wrong. It was and is much more important to have = a catalog that is as complete as possible than for the entries to be= correct.

Resoluti= on of many types of name is inherently ambiguous because the context varies= . We cannot resolve a barcode on a physical object like a can of beans. But= we can ask for information on the can of beans and we can order an instanc= e of the can of beans for delivery. And both forms of 'location' ar= e going to be subjective and depend on the context in which they are attemp= ted.
--000000000000a3494a059b922212-- From nobody Tue Jan 7 13:33:36 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5645A12013C for ; Tue, 7 Jan 2020 13:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JldIbt4oQRsm for ; Tue, 7 Jan 2020 13:33:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4803D1200E7 for ; Tue, 7 Jan 2020 13:33:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ED60D3897D; Tue, 7 Jan 2020 16:33:10 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4200260A; Tue, 7 Jan 2020 16:33:31 -0500 (EST) From: Michael Richardson To: Keith Moore cc: ietf@ietf.org Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice In-Reply-To: References: <87E116C31DAF1434C3C3937F@PSB> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 21:33:35 -0000 --=-=-= Content-Type: text/plain Keith Moore wrote: > I emphatically disagree. URNs have defined properties that URIs in general do > not. The constant efforts by those politically opposed to URNs because of Not > Invented Here syndrome, to degrade the utility of URNs, have been obvious for > a long time now, and can only be understood as deliberate efforts to cause > harm. I really wanted URNs to succeed. I have not seen this occur. Either that's because they are too hard to use, or there isn't any compelling reason to use them. I don't know which. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4U+SsACgkQgItw+93Q 3WV+HwgAsTlnjeb6CJu4/x7g/KOVrh04/R+EWR2cwjdFoxU+uVfuBNayf0Bg22Uy +ftyMrG+A34p3pzNx4F8TbSBTF0eM/ftfqwTwp6yVbslE6X2VRD2HkL2CM283JlP 41Nzz207TnqpUkK6nB1ZEyWGFVHNxUfvp5881/HrzzIAZL8VrQelwXRTPDN/4aZB LcCifXHMf74KDmDCQIZLieTOap9Xys0901JtvYlSOwXAqyWqfAqzOiuszXj0Xcax XfbRQ+8MLMTW4AUaim3yN3YMlj3tG/R9GqrqelVw1n/erg4G8foIzj+YCA5a8zeZ 7UEY+fQHQ0O0uU60PJvpuaY5HrrvSQ== =fw3e -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 7 13:36:29 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5631712080C for ; Tue, 7 Jan 2020 13:36:28 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trWsIK_bPeC4 for ; Tue, 7 Jan 2020 13:36:26 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 39E231200E7 for ; Tue, 7 Jan 2020 13:36:26 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id t8so892276iln.4 for ; Tue, 07 Jan 2020 13:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=lfgIXuQMUwK4cF/Son95vPxgsJHsjiizWziXdc0o43k=; b=WUJKRHbAcaOJim5dqg4ONYKRpNJWW+oKmxSAlbZSoEFFs/wz/2EtapnyejLp8ulKHz r0KpprwenE1ElTQ9qtONBq17ORzJsGmV6klmZBQ7b/CtmG7Gjb6sdBGNdG7cZAaQaYdn /IEEOZ45TS5lOW9ekfGWqXFQ8e4r7CvldPoRw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=lfgIXuQMUwK4cF/Son95vPxgsJHsjiizWziXdc0o43k=; b=AgbosEGSdSyMdHg7TlMpE7BIMBsXKURd3yVV9FVc3Ibz2jaI4utTdNL0oiWU9ufCvG mc3i1/P1ha4BzI2fgT8++6FJ2qt26Nn6wo7ELmBAtZmEl5FouiVzHhYvP2xgG88cE6Wy 8pDCKH5OE7SfS0nxSLzAoJWOG4pEoeRJH9/PgKZdvA9wPucm+ewuUDZAcZilSCkOQIz1 maGYxCqEcOXeUF/tLLz43Kt2bX5J7xXCNml2nTGDMXBVy9YabfWWqsce2LRbUGeq2mEv /OKNlN7kznCjGct1GCDe8HZj1En2Hxm7yaTqpGB5wlWZiQCmfZ1PuE7Ehnbe9HF6Rq1T xGkw== X-Gm-Message-State: APjAAAVnoS5jrdYteNhY0ZI9IrkILqqIMCFgadxSolCZKunToHOIGsSp X6DNSPsISOS0SrPP8Y1Xg+vFdg== X-Google-Smtp-Source: APXvYqxi+lr6MNGVVvqBjGi1p8x6KJi9efQosRbScvQfaUCoy3OdLjEoS+Q0oUT3uAN/fe3s49Vnyg== X-Received: by 2002:a92:3b98:: with SMTP id n24mr1190988ilh.108.1578432985385; Tue, 07 Jan 2020 13:36:25 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id f125sm241292ilh.88.2020.01.07.13.36.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 13:36:24 -0800 (PST) Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: Michael Richardson , Keith Moore Cc: ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Tue, 7 Jan 2020 14:36:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <16161.1578432811@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eGXgmDgVVzMrSZqsqUtCm7xA7EOskwD8k" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 21:36:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eGXgmDgVVzMrSZqsqUtCm7xA7EOskwD8k Content-Type: multipart/mixed; boundary="2dpPzoiGchtbGO1Oq5WxBlLSBUkzjpoWc"; protected-headers="v1" From: Peter Saint-Andre To: Michael Richardson , Keith Moore Cc: ietf@ietf.org Message-ID: Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> In-Reply-To: <16161.1578432811@localhost> --2dpPzoiGchtbGO1Oq5WxBlLSBUkzjpoWc Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/7/20 2:33 PM, Michael Richardson wrote: >=20 > Keith Moore wrote: > > I emphatically disagree. URNs have defined properties that URIs i= n general do > > not. The constant efforts by those politically opposed to URNs be= cause of Not > > Invented Here syndrome, to degrade the utility of URNs, have been= obvious for > > a long time now, and can only be understood as deliberate efforts= to cause > > harm. >=20 > I really wanted URNs to succeed. >=20 > I have not seen this occur.=20 Definitions of success vary. URNs are widely used in the information sciences (e.g., national libraries), but that isn't as visible as the web= =2E Peter --2dpPzoiGchtbGO1Oq5WxBlLSBUkzjpoWc-- --eGXgmDgVVzMrSZqsqUtCm7xA7EOskwD8k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAl4U+dcACgkQZWGMGH9o FKnnKBAAtgnLq8qbcvCMdLLQBgk9sGeO+TTBUqntZTSZL4vCDuNdzQWvhjIlCvXt za1K7TIphu9IHv9k/lf1Ck6N6qN1uuHdF8pscdhLm3eS5eXmxqrJicuHjP0LHIEP Vd+OPTDVWIZG6YdMVoKlpd6jNgpgT/qxdX2+WErcJgGoOT3Nd0XUQe7bdFNVFvZl w92eqjqoiSGFQLFM1j9FiyerTQLviS4FxRo+lzVIBbm3HE8/TD4VhMYjEdbIO61h k/eJGVxT00LVV+lBtke9IUv04qCoduGevN6WDkITQx16FpmsAhsBj8stTzCeZDfx tHGmC7lQQdtq0oIzoDZVg2W8uKDTvrwwtTUBtt1YT+p/68d1wxHjHZAGiCYDKdyQ Eya4CmUZceOQDe+S3Lmnv4Cl7abrjT3fk8gsJqkTNLGK5gavXl5Dhst7zV49GSW/ nu7vyEoaYYB/5VLlzF7IsFfyCA+u0OACoEBpy2roXtXhveFjzf5Lj4YP49cs+yfm jIXnRwuyzBQjTSIv3y5IpnczyOVToHk4dXVkiQ+AvPuaL+Cg9IinR1jPzvWTQ4qz TVMIYzWHSJDbUCqX4ENrqUGYBGJB8WfBuz5NzLzJKMxFbcUmyW+Ktv9dIg9tLWe2 B5WF9wKE6C+zIMUjNtlS69P1Y07aX5R6bUlUfcq34RkaVJanqkE= =vsHm -----END PGP SIGNATURE----- --eGXgmDgVVzMrSZqsqUtCm7xA7EOskwD8k-- From nobody Tue Jan 7 13:47:40 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F11207FE for ; Tue, 7 Jan 2020 13:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 YlXMU4QqsovT for ; Tue, 7 Jan 2020 13:47:36 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1CF120147 for ; Tue, 7 Jan 2020 13:47:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C070521EB2; Tue, 7 Jan 2020 16:47:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 07 Jan 2020 16:47:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=xNcAoysSjwcDXAbfvLd8v1GGUJQ+hHgZ4jRF2FS99 cM=; b=U1l4Y8KzwNechknqoykhgzdk4uMb3QCHe1BSRxscsZdEVMbIkXpqAeEON lMaRTjv0sD8Vde27TY3MuegJurECz9j2eeBjdCRLcZw4SEFndQRsRgYmFhVyYvpX MideXqoby05W3dbV2GjHO7xsDpx8SaVVMFmM1BXagMxAJfDCU1p+WS/4uB1jsD87 80TrKFXKnSBoQeZEAbZdBU6HuBtkCzhqc5WHnRqmOFep8fOw5fSEWxGoFL9br874 nNKnx/cQlAFPY0JIG+d1S+I22sLiDeoQNslHtsv1IzX+/RHFl7Yrz3xOUy1/MCoJ YiyU9B6j6jIlVGdKrA8HpgWKveoFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehiedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucfkphepuddtkedrvddvuddrudektddrud ehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghr vghtihgtshdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B51678005C; Tue, 7 Jan 2020 16:47:34 -0500 (EST) Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: Michael Richardson Cc: ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> From: Keith Moore Message-ID: Date: Tue, 7 Jan 2020 16:47:33 -0500 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: <16161.1578432811@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 21:47:39 -0000 On 1/7/20 4:33 PM, Michael Richardson wrote: > Keith Moore wrote: > > I emphatically disagree. URNs have defined properties that URIs in general do > > not. The constant efforts by those politically opposed to URNs because of Not > > Invented Here syndrome, to degrade the utility of URNs, have been obvious for > > a long time now, and can only be understood as deliberate efforts to cause > > harm. > > I really wanted URNs to succeed. > > I have not seen this occur. Either that's because they are too hard to use, > or there isn't any compelling reason to use them. I don't know which. There have also been efforts to sabotage them.  URNs were always seen as competing with handles and later DoIs, and some people didn't like that.   And the very idea that IETF would create a new namespace distinct from URLs, also rankled some who saw it an intrusion on their own architecture. But I suspect that the biggest problem that URNs have had is that they aren't well understood, even within IETF. Keith From nobody Tue Jan 7 14:49:45 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAC512085F; Tue, 7 Jan 2020 14:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=firsthand.net 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 Dc9Y9WfyBA1W; Tue, 7 Jan 2020 14:49:34 -0800 (PST) Received: from tranquility.default.cdelarrinaga.uk0.bigv.io (tranquility.default.cdelarrinaga.uk0.bigv.io [IPv6:2001:41c8:51:8b8::184]) (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 23A66120843; Tue, 7 Jan 2020 14:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=firsthand.net; s=tranquility; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=l3BqeZDh4QF5H1jBkVTSzGJNkwQgCM6w9+2U9m8feTo=; b=S0/Ei+GGCl87tWLGc61z8D2CKw/PSFmcPDm2dKkUND1gfQVpSq+zjDZwVO/1dZ6dDvKZ407YoMeUV21tKIaS+gIgJqPOu5tTn/39h6cvVVqIDv2MzgfH9rn6KbDvfEKQjN7MItMPCXz81ohxFZRoSe+p4jpvRm0hZGm/s1V3X00=; Received: from 188.29.164.240.threembb.co.uk ([188.29.164.240] helo=[192.168.43.165]) by tranquility.default.cdelarrinaga.uk0.bigv.io with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ioxfH-0007Uo-B5; Tue, 07 Jan 2020 22:49:31 +0000 Subject: Re: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: Phillip Hallam-Baker Cc: "General Area Review Team (gen-art@ietf.org)" , urn@ietf.org, The IESG , IETF Discussion Mailing List References: <87E116C31DAF1434C3C3937F@PSB> <29803.1578413742@localhost> From: Christian Message-ID: <86e1f21b-b594-b390-fe67-c5f495cffa64@firsthand.net> Date: Tue, 7 Jan 2020 22:49:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------279B353DDDBD3A4C1F8B6BB7" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 22:49:39 -0000 This is a multi-part message in MIME format. --------------279B353DDDBD3A4C1F8B6BB7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit picking up as a post modern fag end... On 07/01/2020 19:53, Phillip Hallam-Baker wrote: > Resolution of many types of name is inherently ambiguous because the > context varies.. We cannot resolve a barcode on a physical object like > a can of beans. But we can ask for information on the can of beans and > we can order an instance of the can of beans for delivery. And both > forms of 'location' are going to be subjective and depend on the > context in which they are attempted. I suppose the question is can a schema capture both identifier and locator contexts (my plural) unambiguously in all cases? Should I take your post modernist interpretation as saying the answer is no - we have to live with ambiguity, even to the extent of the failure to resolve one or other or possibly both and do so without breaking wind? But given this interpretation what language is needed if URI and URN linguistically don't meet the need? Or is the other interpretation to offer a list of contexts that work and exclude application for the others? In which case which is the more useful approach for building real world apps and their networks? It rather kills the idea of hard coded registries for all eventualities I think. That I like. As I really like the import of post modernist sensibility. This argument is worth something. best Christian --------------279B353DDDBD3A4C1F8B6BB7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

picking up as a post modern fag end...

On 07/01/2020 19:53, Phillip Hallam-Baker wrote:
Resolution of many types of name is inherently ambiguous because the context varies.. We cannot resolve a barcode on a physical object like a can of beans. But we can ask for information on the can of beans and we can order an instance of the can of beans for delivery. And both forms of 'location' are going to be subjective and depend on the context in which they are attempted.

I suppose the question is can a schema capture both identifier and locator contexts (my plural) unambiguously in all cases?

Should I take your post modernist interpretation as saying the answer is no - we have to live with ambiguity, even to the extent of the failure to resolve one or other or possibly both and do so without breaking wind?

But given this interpretation what language is needed if URI and URN linguistically don't meet the need? 

Or is the other interpretation to offer a list of contexts that work and exclude application for the others?

In which case which is the more useful approach for building real world apps and their networks? 

It rather kills the idea of hard coded registries for all eventualities I think. That I like. As I really like the import of post modernist sensibility. This argument is worth something.

best Christian

--------------279B353DDDBD3A4C1F8B6BB7-- From nobody Tue Jan 7 15:51:05 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F530120220; Tue, 7 Jan 2020 15:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-p5R1erC1Db; Tue, 7 Jan 2020 15:50:46 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 C9DDF12013C; Tue, 7 Jan 2020 15:50:46 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id n59so264243pjb.1; Tue, 07 Jan 2020 15:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=DiIo7NMrRDey82VslgS7RqWDOXU/ANdYEskZ4LE+xj0=; b=WgdE6q9IrMy8uh5DxP9/FsDDSoq/T72KU4is7umg1DViJ31ObwQPtpRVPskknNEF7Y NZcaXMRty5Tc8T1Ot5G8ze6il1LJtW68qvCY3c8Md38yME+iuw/TZ8XSQcJabHAcG8Xy MgHeB3axrUwdfvTu7QauiJ/+S3sdlmka/wi1cRpiXFYsQ29541XhGSY29kYZbEOTKyLF d6mhywywHHhPc9muIAbOGuDbxP0SFjvQtH62+7H005uephMYlWm9ySk3QjDWh2ST8Pg2 odzMWZto7nWDRxPILzhIZ+rUlq5uLg1ZDVBISGrNE21YFPGyKDO643BijwRs6ldLrilX zH5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=DiIo7NMrRDey82VslgS7RqWDOXU/ANdYEskZ4LE+xj0=; b=Updw1r5zGrR87yCXikt6KL9LAr68IQttyM1BxfHCblrbgIj5Rmc3MB3B/xOnAmvNVs IvdZ9V0bApTkrv6dRL9F77I4rx3HAHU6LSDcDPB1nkXJXvijpzW7BcBrXOEPMFxh5CXd GOz1lFwFZze5J4VuKHFSQgsa7rq8EsUdI/QsP+2ZgYlsZf9gTERl9U8v+xHc/SHVfqQU 6gRFSKf+3WA1cSqmlMjxT4sh7PEvke0ZvGET1ROh61AarN1XpFoCi+em9jrEHTk7N50z mj6OdVLYJmb7a+Kvd7C2+QspFOYVLqZsmwSvbObrW1bBxaQFzMGykCsk0ScM2kogoC9Y treQ== X-Gm-Message-State: APjAAAV30FDSf/EXqJ0c8UFCnT1RfbKkJM/hE55ErjB8nq687E6xT0hr uqMdKx1wRlLKqRCo/7SjN/DnDt1HOUc= X-Google-Smtp-Source: APXvYqwrP37wxzxYz1LLUlfLGi4QxfZPqL6XKJy/rpg9P9VJKkljSnwBKAxlfws0HiZpqMe89qMBgQ== X-Received: by 2002:a17:902:b691:: with SMTP id c17mr2370243pls.254.1578441046082; Tue, 07 Jan 2020 15:50:46 -0800 (PST) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id n2sm832253pgn.71.2020.01.07.15.50.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 15:50:45 -0800 (PST) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'John C Klensin'" , "'Adam Roach'" , Cc: , , , References: <87E116C31DAF1434C3C3937F@PSB> <444B2465A9B73F3D0DE59FFF@PSB> In-Reply-To: <444B2465A9B73F3D0DE59FFF@PSB> Subject: RE: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice Date: Tue, 7 Jan 2020 15:50:43 -0800 Message-ID: <002b01d5c5b5$47227290$d56757b0$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHlIqFVvsYjY3mX8ZSjZXIfuJ5VFQIu5gyCAc3WKQanoPwSoA== Content-Language: en-us Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 23:50:48 -0000 FWIW, while I agree with the "spirit of making this BCP guidance, rather than rules", I don't see how changing "MAY" to "can" or a "SHOULD NOT... but instead" to "are encouraged to" is helpful (substituting terms that are well-defined with words that seem to be similar in meaning but less well-defined. The keywords MAY, SHOULD, SHOULD NOT seem to me to be sufficient "guidance" in a BCP-status document. Perhaps it would be helpful to add a kind of applicability statement at the beginning that these guidelines are intended to apply to "http:" and "https:" URIs and those with similar patterns and SHOULD be considered for others, although they don't seem to be relevant for URI-schemes that don't use the generic syntax with hierarchical paths (such as "urn:" or "data:" or "mailto") There is no need to consider the philosophic difference between a name and a locator. It's a matter of choosing a syntax for serialization of a data structure and the implication of ownership and origin that comes with some syntactic arrangements for some implementations. Larry -- https://LarryMasinter.net From nobody Tue Jan 7 16:18:47 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018CF120020; Tue, 7 Jan 2020 16:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eprzhI2QcRT4; Tue, 7 Jan 2020 16:18:43 -0800 (PST) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (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 A0D21120018; Tue, 7 Jan 2020 16:18:43 -0800 (PST) Received: by mail-ot1-f45.google.com with SMTP id w21so1872110otj.7; Tue, 07 Jan 2020 16:18:43 -0800 (PST) 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=KsVsYPYLQE+I76X+hyia3u6/V4SaimYB4tgvgMkBFIg=; b=s+TzLfuLp7ERgKo6bxXmImLC7XCUPicw5hMjoYj8QqSj3WtSmruBY0PuyFd5aPFG3x tB7agE5NCN9yIWMcjYOcRbcq01khCR24F0ugOun+qsJmbbTgOKb2Qe6mPUHqFVI/2vkt RH+rivCqR3v78mTyE+lUWqXPxLhyk3b8i681vXQgxqxFMATGBcbaOyTyFUBlaDmbUNGM w+BjKyhzzogLCuyfkjVnTbsgbomqD9HM3x8Bt7qzagRna8F+7EbOTBaS/ArWXN4TbKTX zhlL7TyAUzdRNq6lO4faGFk8GCizKbGf5WTuLqpZRBXleSIj+PPMM5RjNOzPPLn4JYvv kamw== X-Gm-Message-State: APjAAAWozV0ABXK6gVh5QPJOv806qUiYx66ZqvSnLLh/oh4470TRVloF hSeaCxjnntP4n9dQ5vOqzPwJdTMQ95MlL1jL256H/D+K X-Google-Smtp-Source: APXvYqzK9pkdVgjhJ5NhspvQeo4oZHQcUrAy9DpjYmbl15A2HT0wXtwWMS5yCwjuu/1SBh5Cw0i07RRxjOsm67x+oNc= X-Received: by 2002:a05:6830:1481:: with SMTP id s1mr2229466otq.66.1578442722735; Tue, 07 Jan 2020 16:18:42 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> <29803.1578413742@localhost> <86e1f21b-b594-b390-fe67-c5f495cffa64@firsthand.net> In-Reply-To: <86e1f21b-b594-b390-fe67-c5f495cffa64@firsthand.net> From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 19:18:31 -0500 Message-ID: Subject: Re: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: Christian Cc: "General Area Review Team (gen-art@ietf.org)" , urn@ietf.org, The IESG , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="000000000000c97be0059b95d5ad" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:18:45 -0000 --000000000000c97be0059b95d5ad Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 5:49 PM Christian wrote: > picking up as a post modern fag end... > On 07/01/2020 19:53, Phillip Hallam-Baker wrote: > > Resolution of many types of name is inherently ambiguous because the > context varies.. We cannot resolve a barcode on a physical object like a > can of beans. But we can ask for information on the can of beans and we can > order an instance of the can of beans for delivery. And both forms of > 'location' are going to be subjective and depend on the context in which > they are attempted. > > I suppose the question is can a schema capture both identifier and locator > contexts (my plural) unambiguously in all cases? > Definitely not because the identifier interpretation can change over time. Additional contexts can be added. The identifier may be grandfathered into a new scheme. It may be abandoned. > Should I take your post modernist interpretation as saying the answer is > no - we have to live with ambiguity, even to the extent of the failure to > resolve one or other or possibly both and do so without breaking wind? > We can deny that the ambiguity exists. We can say the earth is flat as well. But it won't change anything. > But given this interpretation what language is needed if URI and URN > linguistically don't meet the need? > > Or is the other interpretation to offer a list of contexts that work and > exclude application for the others? > > In which case which is the more useful approach for building real world > apps and their networks? > I believe that the Internet was founded on the principle of allowing every user to experiment and to extend. It is thus impossible to enumerate all possible uses. It is however possible to identify uses that are useful generally and network effects strongly (unfortunately too strongly) encourage focusing on common uses. > It rather kills the idea of hard coded registries for all eventualities I > think. That I like. As I really like the import of post modernist > sensibility. This argument is worth something. > > best Christian > --000000000000c97be0059b95d5ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 7, 2020 at 5:49 PM Christian <cdel@firsthand.net> wrote:
=
=20 =20 =20

picking up as a post modern fag end...

On 07/01/2020 19:53, Phillip Hallam-Baker wrote:
Resolution of many types of name is inherently ambiguous because the context varies.. We cannot resolve a barcode on a physical object like a can of beans. But we can ask for information on the can of beans and we can order an instance of the can of beans for delivery. And both forms of 'location= 9; are going to be subjective and depend on the context in which they are attempted.

I suppose the question is can a schema capture both identifier and locator contexts (my plural) unambiguously in all cases?

D= efinitely not because the identifier interpretation can change over time. A= dditional contexts can be added. The identifier may be grandfathered into a= new scheme. It may be abandoned.

Should I take your post modernist interpretation as saying the answer is no - we have to live with ambiguity, even to the extent of the failure to resolve one or other or possibly both and do so without breaking wind?

We can deny that the ambiguity exists. = We can say the earth is flat as well. But it won't change anything.=C2= =A0

But given this interpretation what language is needed if URI and URN linguistically don't meet the need?=C2=A0

Or is the other interpretation to offer a list of contexts that work and exclude application for the others?

In which case which is the more useful approach for building real world apps and their networks?=C2=A0

I believe that the Intern= et was founded on the principle of allowing every user to experiment and to= extend. It is thus impossible to enumerate all possible uses. It is howeve= r possible to identify uses that are useful generally and network effects s= trongly (unfortunately too strongly) encourage focusing on common uses.

It rather kills the idea of hard coded registries for all eventualities I think. That I like. As I really like the import of post modernist sensibility. This argument is worth something.

best Christian

--000000000000c97be0059b95d5ad-- From nobody Tue Jan 7 16:31:15 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3480120018 for ; Tue, 7 Jan 2020 16:31:05 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKoIVfujnsHs for ; Tue, 7 Jan 2020 16:31:03 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 3C77912004F for ; Tue, 7 Jan 2020 16:31:03 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id t26so1274986ioi.13 for ; Tue, 07 Jan 2020 16:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GEmqktg5R6YlC/lTNgD0xWDOxoKsEXTtJtguhv3Lphg=; b=M23p7xZoHcSzvfaRoMklcm2lLX0MJFarEppfvTJNEWiOAxazkqK4PGFCS6AgWjzb18 uvI67mwhOxx8dSuq4Waz+6TmMZO7N8U8C5Xbw24hyPoKedu6PuAKeNmRrnhDb3RgZHnK y1lfDuoAsp1IIVESUO64sKovA74fdZKx13630= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GEmqktg5R6YlC/lTNgD0xWDOxoKsEXTtJtguhv3Lphg=; b=NVOEN9J5s36866ot/VjqeYLOk8P0VAa4Td7oHgfcLm5IM1tcBoiaDnkXL23C8YUXIr kw/1+EHc2EnQbXP33xDpy4KFoo+3n3y+YplQ+WBelKyxo9Y8jhMQo9sG23TBHY5Fhkgq hZuBfOUOeoUCaFde8f9AxGyKuUk5d1T9AGqJODSy2W1gm+kfHG0ujQAUrKtVMAx0FagX FOJGMexhSw5AOfVNQTwboHs0AmjlebfyKKCBV/zwDwb7RbiKP4FTy75IUYdcLb3grDVv ZiJ2/zz+FEYeCqb/LvYmK18pm47Hi5QvTIom/PgltuzAJNPt/CZsLe9n3wfSCav5BzcC 7/gQ== X-Gm-Message-State: APjAAAU2xYtyREtjbcrC17r9Pcmn488UXlzHwhahje1yAUbOym5IBO5Y gVE39qhiut7FDfD8akYROoEgvA== X-Google-Smtp-Source: APXvYqzp5quT3VRoz26zX84/B/mFs8sjjqA3VG/HXAi+dXbzPNFii9KHriFxYRUZGvd25w1XJ4DJ+w== X-Received: by 2002:a5d:8901:: with SMTP id b1mr1304834ion.246.1578443462391; Tue, 07 Jan 2020 16:31:02 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id y18sm393992ilm.9.2020.01.07.16.31.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 16:31:01 -0800 (PST) Subject: Re: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: John C Klensin , Adam Roach , iesg@ietf.org Cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> <444B2465A9B73F3D0DE59FFF@PSB> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Tue, 7 Jan 2020 17:31:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <444B2465A9B73F3D0DE59FFF@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:31:06 -0000 On 1/7/20 12:11 PM, John C Klensin wrote: > Instead, I was trying to raise a far more narrow question: Given > that RFC 3986 separates names and locators and that we have > already had confusion about what is appropriate in URNs based on > the language there, does this document make things worse? I > think it may. Even a statement fragment (from the first > paragraph of Section 3 and inherited from 7320) like "...as > links that are exchanged as part of the protocol, rather than > statically specified syntax" are inconsistent with the use of > keyword values in some URN namespaces as static indicators. Indeed, it's not immediately obvious what a "protocol" would be in the case of many URN namespaces, precisely because the URN is a name rather than a locator. > If > you want to ask the slightly different question of whether, if > RFC 7320 made things worse, does this I-D make things even worse > than that, I don't have an easy answer except to note at least > one example: The last paragraph of Section 2.3, which appears to > be new, says > >> Extensions MUST NOT define a structure within individual URI >> components (e.g., a prefix or suffix), again to avoid >> collisions and erroneous client assumptions. > > But, as I understand that rule, it is precisely what some rules, > and provisions for namespace-specific rules, in RFC 8141, do. It's not clear to me whether a URN namespace counts as a 7320bis protocol extension (which can "offer new capabilities that could apply to any identifier, or to a large subset of possible identifiers"); however a definition of, say, URN r-components would probably fit the bill, and such a definition might well define structures that would violate the aforementioned MUST NOT. > Again, the solution at this point appears to be either to be > much more careful about binding the statements in the I-D to the > concept of ownership or to indication that this specification > does not apply to URNs (or, if preferred, to what 3986 describes > as "name" URIs) at all. That might be the best approach. Peter From nobody Tue Jan 7 16:48:17 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22977120025 for ; Tue, 7 Jan 2020 16:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 mbUyHLgsxbNr for ; Tue, 7 Jan 2020 16:48:14 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2B804120018 for ; Tue, 7 Jan 2020 16:48:14 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0080foBZ008592; Wed, 8 Jan 2020 00:48:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9webW+sUkgjhmuXFpPCkB6iZvcrmyvbyKCUg326ziiI=; b=NTZJnjlxn8w0nEGLlbzeq7ElFKdATSKB56KnSSVrIJEQMleFrSy9nnmUAu7khJR93noJ /CAM8Gbm8qm2diVNPcaog+B1A9QkyZtsajEtn/4BIObkr2DUivYRX4TCGIJPZ641Ycsk kS4FMA72V9QiD8EaMRPyorT+9yc6Caw+0Lm35B+Hb7j/dPJOpVpZA+zK9Fo/bel7L8T0 z7QnruPIzRr7lesD8FqfqZe4ffbimKhYBNCZOsEjeo9x27lYC2f9QTRlgbQwEWLqZM4O sSn0BZboMPa83Yf2Gf8cQFArndxG0MSRlR1trrbQyglxlfiRvHRB4hgbeN01625VDmmu jw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2xckbcvr6x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jan 2020 00:48:08 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 0080kgQb007146; Tue, 7 Jan 2020 19:48:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2xapwygaaa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2020 19:48:07 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 19:48:06 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 7 Jan 2020 19:48:06 -0500 From: "Salz, Rich" To: Michael Richardson , Keith Moore CC: "ietf@ietf.org" Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice Thread-Topic: URNs and Last Call: (URI Design and Ownership) to Best Current Practice Thread-Index: AQHVxSfkD9PsghDG8UG8rB9yHiSwm6ffzrgAgAAanACAACRkgP//4owA Date: Wed, 8 Jan 2020 00:48:05 +0000 Message-ID: <7652D096-3DBB-46DF-91A7-CF9A5732B998@akamai.com> References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> In-Reply-To: <16161.1578432811@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.38] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=875 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001080005 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-07_08:2020-01-07, 2020-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 spamscore=0 mlxlogscore=847 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001080004 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:48:15 -0000 PiAgICBJIGhhdmUgbm90IHNlZW4gdGhpcyBvY2N1ci4gIEVpdGhlciB0aGF0J3MgYmVjYXVzZSB0 aGV5IGFyZSB0b28gaGFyZCB0byB1c2UsDQogICAgb3IgdGhlcmUgaXNuJ3QgYW55IGNvbXBlbGxp bmcgcmVhc29uIHRvIHVzZSB0aGVtLiBJIGRvbid0IGtub3cgd2hpY2guDQogIA0KT3IgeW91IGFy ZSBsb29raW5nIGluIHRoZSB3cm9uZyBwbGFjZS4gIExpYnJhcnkvaW5mb3JtYXRpb24gc2NpZW5j ZXM/DQoNCg== From nobody Tue Jan 7 17:41:52 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE2F120086 for ; Tue, 7 Jan 2020 17:41:51 -0800 (PST) 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 BsH4Xa1lJ67U for ; Tue, 7 Jan 2020 17:41:50 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 2DCA912007C for ; Tue, 7 Jan 2020 17:41:50 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id t26so1407377ioi.13 for ; Tue, 07 Jan 2020 17:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2+5kG2iPZ9RV/LZ7UT+8PoDLWLhvfu58sZ2amazGkW0=; b=gnYH4guYty8RXD2L9fa8aeaTgCQDrzUa+nskorm+i7vJtX5jSa7fvtHlOQJo3zg1Vt 2HsqAD3loQ/JKlzJHn6iL4QTnrlHnNo3aWDTQ537YRKSRKOte8cJlb9U65l+MyEm8vue nGuPk29SFZWadEbYpcP+oPQKLEmUlDRm8ZmEZ3u5HyTNGregdAq8laYI5UzOM2sX9FyJ xPylrxBkn4/dutTm7HEhn+5XmqH2vJhI7Br/omGdozsY0FlZt+EN36z7Jh4SuA8znvcm qtevH9tmRJSCJJRAr+1sqz2Lc7cZcg2Xw3eaRkYHINhQihxb5Cla6gzw4Us5U19UBiTL mAYQ== 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=2+5kG2iPZ9RV/LZ7UT+8PoDLWLhvfu58sZ2amazGkW0=; b=KIjCjJytzfnxGNfZ82aSNmni+9UmIbTl0vU7oNFY3FHILgBZCXXRuSW2zZG4JbfOpn bcyqVF0jx5Wv40euvJN7GjjHg0iSEpZ2xW4vvA9T+yunvJbOtQJhrTprZu68eZUrKBsc 4KZ4WKrSjyqeZgeR/oyG1UltjQKo6HhxwV3hqLp8D6ETpUq5amqRIo6kqSrx2WrKJP0K UZ93yA0aTNKUVgk1T6snnvGOCFIho2sIUW9c9BG30eBi60mYxw194hisiLeU0P0Pt17r 9PIuTmBQEVAwm3zD0EwnWeEPEZrq6a4dMYjGVMiPQ9vnxTdHqu0W9FGS73Y3MUuBZ+xw 5NRw== X-Gm-Message-State: APjAAAXmRQDLmo1ROoL6K5op1ZYfCir5es99l5DQguR8AH6BXatqanH0 JGxQp7TSzLK/oqJDO0dqEq54ex7ppEdYcQ+Qx80= X-Google-Smtp-Source: APXvYqwL/xAsqj8g9wvbE0BCVva+t9PzpGpohC3U0CUMBlsuuCyFN5ti8aj/DpaPSBLnDsFuF10xa5ZP6sCdU82WJLk= X-Received: by 2002:a6b:d219:: with SMTP id q25mr1566042iob.49.1578447709274; Tue, 07 Jan 2020 17:41:49 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> In-Reply-To: From: Rob Sayre Date: Tue, 7 Jan 2020 17:41:38 -0800 Message-ID: Subject: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice To: Peter Saint-Andre Cc: Michael Richardson , Keith Moore , IETF discussion list Content-Type: multipart/alternative; boundary="000000000000020735059b96ff42" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 01:41:52 -0000 --000000000000020735059b96ff42 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 1:36 PM Peter Saint-Andre wrote: > On 1/7/20 2:33 PM, Michael Richardson wrote: > > > > I really wanted URNs to succeed. > > > > I have not seen this occur. > > Definitions of success vary. URNs are widely used in the information > sciences (e.g., national libraries), but that isn't as visible as the web. > Definitions of success do indeed vary. Without weighing in on this particular issue, the IETF does seem to be clinging to unsuccessful standards like URNs and DNSSEC. That doesn't mean they're bad, but it does mean those standards missed the mark in ways that would have been difficult to predict at the time they were drafted. This failure to reflect is disappointing. thanks, Rob --000000000000020735059b96ff42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 7, 2020 at 1:36 PM Peter Sain= t-Andre <stpeter@mozilla.com&= gt; wrote:
On 1/7/20 2:33 PM, Michael Richardson wrote:
>
> I really wanted URNs to succeed.
>
> I have not seen this occur.

Definitions of success vary. URNs are widely used in the information
sciences (e.g., national libraries), but that isn't as visible as the w= eb.

Definitions of success do indeed va= ry. Without weighing in on this particular issue, the IETF does seem to be = clinging to unsuccessful standards like URNs and DNSSEC. That doesn't m= ean they're bad, but it does mean those standards missed the mark in wa= ys that would have been difficult to predict at the time they were drafted.= This failure to reflect is disappointing.

thanks,=
Rob
--000000000000020735059b96ff42-- From nobody Tue Jan 7 18:21:43 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C049D1200F5 for ; Tue, 7 Jan 2020 18:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 SAeTuAVf6sHY for ; Tue, 7 Jan 2020 18:21:38 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D661512007C for ; Tue, 7 Jan 2020 18:21:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DEE123BF; Tue, 7 Jan 2020 21:21:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 07 Jan 2020 21:21:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=6p8n4l JqE+6vr0Nrd9y4lSWIEsIWaQiNQ5Cg6y7fd74=; b=OID8rqzR1Z5UqlRSjk8vmI XUXvY3NrLH1O0OVontm9dwjEd+zDIuuMhtMSp5NAE5iY0+sIeAutOcmvy5fwxnbj EMH3SN6DowKeY+zixqAl5wv6DYLilFvKkk/YTrxoIYyEsZgcpuIqY3fz3lZW3MWU DgNi1n0zF+lUOn2yI+OGlS9aWYAonSu3l/Di3Pof2IhxwZFKceZOYDKdpm1mu08P YK+Zi/x6DzCPWdicq7rAroHFPTUy5wDsIJ9KkzFi/zEt6oPxggnZ6tom4uAOeKDj aRw00PGOrxN+INnsN8RSshnEXQltT9SRnpcufI27jdR/Lq/S8GfM+XnhJBMWO9Ww == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehjedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghithhh ucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqe enucfkphepuddtkedrvddvuddrudektddrudehnecurfgrrhgrmhepmhgrihhlfhhrohhm pehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id D3A808005A; Tue, 7 Jan 2020 21:21:35 -0500 (EST) Subject: utility of URNs and DNSSEC (was: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice) To: Rob Sayre Cc: IETF discussion list References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> From: Keith Moore Message-ID: Date: Tue, 7 Jan 2020 21:21:35 -0500 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: Content-Type: multipart/alternative; boundary="------------BF0A6DD421ECBE2F9FD3CD3A" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 02:21:41 -0000 This is a multi-part message in MIME format. --------------BF0A6DD421ECBE2F9FD3CD3A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/7/20 8:41 PM, Rob Sayre wrote: > Definitions of success vary. URNs are widely used in the information > sciences (e.g., national libraries), but that isn't as visible as > the web. > > > Definitions of success do indeed vary. Without weighing in on this > particular issue, the IETF does seem to be clinging to unsuccessful > standards like URNs and DNSSEC. That doesn't mean they're bad, but it > does mean those standards missed the mark in ways that would have been > difficult to predict at the time they were drafted. This failure to > reflect is disappointing. Actually, it means no such thing. For URNs, the average Internet user or even IETF participant simply is not in a position to evaluate their utility.   Granted, the expectation within IETF was that URNs would be more publicly visible than they are now.   But most people don't know what ISBNs are either, and they've been around much longer. (I expect that URNs would be much more visible to us today had URN resolution systems been developed and incorporated into browsers.   But this is still possible.   Meanwhile, URNs remain useful even without URN resolution support in browsers, just not as widely useful and not as visible.) DNSSEC is still quite useful, even though it has had a bit of trouble getting going.   The very nature of DNSSEC was that it would take a long time to deploy.   A similar statement could be made (and has been made) about IPv6. It's very shortsighted to expect that everything that IETF does that is useful, will appear useful to IETF participants within a few years of adoption. I realize that much of the industry has come to expect quick payoff.   Reality is that some good things take time to mature before they're useful.  Fortunately, IETF isn't a VC-funded startup that needs to ship product within two years. Keith --------------BF0A6DD421ECBE2F9FD3CD3A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/7/20 8:41 PM, Rob Sayre wrote:

Definitions of success vary. URNs are widely used in the information
sciences (e.g., national libraries), but that isn't as visible as the web.

Definitions of success do indeed vary. Without weighing in on this particular issue, the IETF does seem to be clinging to unsuccessful standards like URNs and DNSSEC. That doesn't mean they're bad, but it does mean those standards missed the mark in ways that would have been difficult to predict at the time they were drafted. This failure to reflect is disappointing.

Actually, it means no such thing.

For URNs, the average Internet user or even IETF participant simply is not in a position to evaluate their utility.   Granted, the expectation within IETF was that URNs would be more publicly visible than they are now.   But most people don't know what ISBNs are either, and they've been around much longer.

(I expect that URNs would be much more visible to us today had URN resolution systems been developed and incorporated into browsers.   But this is still possible.   Meanwhile, URNs remain useful even without URN resolution support in browsers, just not as widely useful and not as visible.)

DNSSEC is still quite useful, even though it has had a bit of trouble getting going.   The very nature of DNSSEC was that it would take a long time to deploy.   A similar statement could be made (and has been made) about IPv6.

It's very shortsighted to expect that everything that IETF does that is useful, will appear useful to IETF participants within a few years of adoption.  

I realize that much of the industry has come to expect quick payoff.   Reality is that some good things take time to mature before they're useful.  Fortunately, IETF isn't a VC-funded startup that needs to ship product within two years.  

Keith


--------------BF0A6DD421ECBE2F9FD3CD3A-- From nobody Tue Jan 7 18:36:19 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1EF1200EB for ; Tue, 7 Jan 2020 18:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 Y11eMm5nFnlQ for ; Tue, 7 Jan 2020 18:36:13 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C032C12007C for ; Tue, 7 Jan 2020 18:36:13 -0800 (PST) Received: from [10.200.0.108] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 600302AE5DD for ; Tue, 7 Jan 2020 21:36:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: utility of URNs and DNSSEC (was: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice) From: Viktor Dukhovni In-Reply-To: Date: Tue, 7 Jan 2020 21:36:11 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: IETF discussion list Message-Id: References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> To: IETF discussion list X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 02:36:18 -0000 > On Jan 7, 2020, at 9:21 PM, Keith Moore = wrote: >=20 > DNSSEC is still quite useful, even though it has had a bit of trouble = getting going. The very nature of DNSSEC was that it would take a long = time to deploy. A similar statement could be made (and has been made) = about IPv6. >=20 > It's very shortsighted to expect that everything that IETF does that = is useful, will appear useful to IETF participants within a few years of = adoption. Indeed, and 2019 saw a significant uptick in the number of DNSSEC = domains, https://stats.dnssec-tools.org/images/totalds.svg For a few additional data points: = https://lists.dns-oarc.net/pipermail/dns-operations/2020-January/019559.ht= ml - 10.70 million signed delegations, up from ~8.77 million a year ago. + 1.50 million signed .COM delegations, up from ~973 thousand. + 97 TLDs with 1000+ signed delegations, up from 76. - 1.73 million DANE SMTP domains, up from ~775 thousand a year ago. + DANE MX hosts in 5.0 thousand zones, up from ~3.8 thousand. - ECDSA P256 (13) now most common KSK algorithm, ahead of RSASHA256 = (8). + Last year: 4,005,976 alg 8; 1,908,218 alg 13. + This year: 3,798,256 alg 8; 3,937,115 alg 13. Also, for example, the .com and .net zone ZSKs have been upgraded from 1024-bit RSA to 1280-bit RSA. Meaningful progress is being made. --=20 Viktor. From nobody Tue Jan 7 21:08:56 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E20120041; Tue, 7 Jan 2020 21:08:49 -0800 (PST) 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, 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 dwM6zHv61ByI; Tue, 7 Jan 2020 21:08:47 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA8B120025; Tue, 7 Jan 2020 21:08:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ip3aC-000A6x-Tu; Wed, 08 Jan 2020 00:08:40 -0500 Date: Wed, 08 Jan 2020 00:08:34 -0500 From: John C Klensin To: Peter Saint-Andre , Adam Roach , iesg@ietf.org cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org Subject: Re: [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice Message-ID: <83F6216862324B84D43C9280@PSB> In-Reply-To: References: <87E116C31DAF1434C3C3937F@PSB> <444B2465A9B73F3D0DE59FFF@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 05:08:50 -0000 --On Tuesday, January 7, 2020 17:31 -0700 Peter Saint-Andre wrote: >... >> If >> you want to ask the slightly different question of whether, if >> RFC 7320 made things worse, does this I-D make things even >> worse than that, I don't have an easy answer except to note >> at least one example: The last paragraph of Section 2.3, >> which appears to be new, says >> >>> Extensions MUST NOT define a structure within individual URI >>> components (e.g., a prefix or suffix), again to avoid >>> collisions and erroneous client assumptions. >> >> But, as I understand that rule, it is precisely what some >> rules, and provisions for namespace-specific rules, in RFC >> 8141, do. > > It's not clear to me whether a URN namespace counts as a > 7320bis protocol extension (which can "offer new capabilities > that could apply to any identifier, or to a large subset of > possible identifiers"); however a definition of, say, URN > r-components would probably fit the bill, and such a > definition might well define structures that would violate the > aforementioned MUST NOT. I was trying to avoid getting dragged down into details, both in the hope of keeping the message as short as possible and to avoid a distracting side-discussion, but, yes r-components and the issues associated with pass-through information for those URN namespaces that resolve to one or more URLs were examples that crossed my mind. >> Again, the solution at this point appears to be either to be >> much more careful about binding the statements in the I-D to >> the concept of ownership or to indication that this >> specification does not apply to URNs (or, if preferred, to >> what 3986 describes as "name" URIs) at all. > > That might be the best approach. If we don't want both the discussion and the document to drag out, I believe so. best, john From nobody Wed Jan 8 15:15:06 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ADF12022A; Wed, 8 Jan 2020 15:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=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 q7JpPBAEafFy; Wed, 8 Jan 2020 15:14:58 -0800 (PST) Received: from thornhill.mtv.corp.google.com (unknown [IPv6:2620:0:1000:1111:c03e:1e8:50bf:2fe4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id E0D6112022E; Wed, 8 Jan 2020 15:14:57 -0800 (PST) To: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org From: IAB Chair Subject: Draft IAB conflict of interest policy Message-ID: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Date: Wed, 8 Jan 2020 15:14:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BF796EEED930DB9A884FBDF1" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 23:15:00 -0000 This is a multi-part message in MIME format. --------------BF796EEED930DB9A884FBDF1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Colleagues, The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them toiab@iab.org . best regards, Ted Hardie for the IAB INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, “Covered Individuals”). This policy has no impact on any other participants in IAB activities, for instance liaisons to and from the IAB or IAB program members. In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be—or may appear to be—incompatible or in conflict with a Covered Individual’s personal interests (including interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter. The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology. Covered Individuals shall not use the IAB’s resources or decisions as a means for personal or third-party gain. Disclosure of Actual or Potential Conflicts The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates. In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion. The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms: * A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees. * A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. * Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult. Disclosure Transparency A person's recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private. --------------BF796EEED930DB9A884FBDF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, “Covered Individuals”). This policy has no impact on any other participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be—or may appear to be—incompatible or in conflict with a Covered Individual’s personal interests (including interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB’s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.


--------------BF796EEED930DB9A884FBDF1-- From nobody Wed Jan 8 22:31:15 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01451120118 for ; Wed, 8 Jan 2020 22:31:14 -0800 (PST) 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 1SrOwFyLXgm9 for ; Wed, 8 Jan 2020 22:31:12 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 44E21120020 for ; Wed, 8 Jan 2020 22:31:12 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id z8so5949929ioh.0 for ; Wed, 08 Jan 2020 22:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2GupruXwy5P+ymxraA3e5ToPsPCKYI0q/9f+Cu5KRhM=; b=s0x3JdYGjLAXX2tNJ2cjm7y264zmeWCYcnLxqo6zoblwL3anTMJe4HsLY4rSl/Z7VZ OHiNzR+evfZR2PXZ9nLzrJ3UExoUWm15ttRA8+nu1mu9pJelwq/idWJkzVC76762Gof2 sL3V/g3klnPTT9SBMi0CnBCep4mTgsjhWSSm5BC95V86UrRSNugc9ttDjxX1XkcOkHfQ 5YBf955X08owLt/YppYW+j5YBOZ/7lZ2EHpkm6YVg8v89dQCe1tJSsoMNozygoYTV+a6 v3YvYwRtRIdGw49z/mBPHGKpLpZZEdyZrWaX11D7EvBAT0vswoKpXChk1mvjBxxqun6w M8xA== 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=2GupruXwy5P+ymxraA3e5ToPsPCKYI0q/9f+Cu5KRhM=; b=qKJRCONdpn1q+LHJfDgBmUsS+t69Y8IUZFSwzOjkvHCETER/rDiv19zNKUzmdvXOaS MZhZI7+70qjrhplU0lGCTkvd2tbS20MvGSVqfjO95oo0ojTr4iYl17uwYlxVs0aVQ6KN SH0Nd12xIziq8HaI6zvERm7LeXPxPubV1i351LoZiLG2lGv4hxJ9wyAFsJF5TnRCSnkS tbgAjWiJJm10NTQqV9DQ4pJ5A3q+/ahfnqx9FCqKYmJsaRwrrWWw5ohpqcdgZS3VzBM6 Tu0wGsiYW1fT0drY75y7yL9BPiKlJQmOJ/VZQwgEVyRAFWNtYEo/cTHNjJbxnHY7t9Jg a56Q== X-Gm-Message-State: APjAAAVBqKHtOvAzWXuDoGixqo9FHtex4K8eLYoqyJU5CvODsiVJKg+E A8/AjxdRfPNyXw3RJQT7aJtUtzo8LNFwUJcWB1+XCylve6cvSA== X-Google-Smtp-Source: APXvYqyQOiFGeT2ZanzKDHYTf4AKR+oGw/pu2t/K47gqoai/ynR+ehUCVPAbr8VnfpPT2q8W7TdrnSPqecoGttKzP3A= X-Received: by 2002:a6b:731a:: with SMTP id e26mr6313375ioh.254.1578551471461; Wed, 08 Jan 2020 22:31:11 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> In-Reply-To: From: Rob Sayre Date: Wed, 8 Jan 2020 22:31:00 -0800 Message-ID: Subject: Re: utility of URNs and DNSSEC (was: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice) To: Keith Moore Cc: IETF discussion list Content-Type: multipart/alternative; boundary="000000000000b75f0a059baf2770" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 06:31:14 -0000 --000000000000b75f0a059baf2770 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 6:21 PM Keith Moore wrote: > On 1/7/20 8:41 PM, Rob Sayre wrote: > > Definitions of success vary. URNs are widely used in the information >> sciences (e.g., national libraries), but that isn't as visible as the web. >> > > Definitions of success do indeed vary. Without weighing in on this > particular issue, the IETF does seem to be clinging to unsuccessful > standards like URNs and DNSSEC. That doesn't mean they're bad, but it does > mean those standards missed the mark in ways that would have been difficult > to predict at the time they were drafted. This failure to reflect is > disappointing. > > Actually, it means no such thing. > Check out the footnote in https://www.iab.org/documents/correspondence-reports-documents/2019-2/avoiding-unintended-harm-to-internet-infrastructure/ At the very least, one might concede that the usefulness of DNSSEC is a matter of debate. I actually happen to think DNSSEC might be useful once DNS transports are encrypted, which the IETF has screwed up for 30 years. However, the DNSSEC RFC is 15 years old, so I don't think it's generally productive to bring up in new work. thanks, Rob --000000000000b75f0a059baf2770 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 7, 2020 at 6:21 PM Keith = Moore <moore@network-heret= ics.com> wrote:
=20 =20 =20

On 1/7/20 8:41 PM, Rob Sayre wrote:

Definitions of success vary. URNs are widely used in the information
sciences (e.g., national libraries), but that isn't as visible as the web.

Definitions of success do indeed vary. Without weighing in on this particular issue, the IETF does seem to be clinging to unsuccessful standards like URNs and DNSSEC. That doesn't mean they're bad, but it does mean those standards missed the mark i= n ways that would have been difficult to predict at the time they were drafted. This failure to reflect is disappointing.

Actually, it means no such thing.


Check out the footnote in


At the very least, one = might concede that the usefulness of DNSSEC is a matter of debate.

I actually happen to think DNSSEC might be useful once DNS= transports are encrypted, which the IETF has screwed up for 30 years. Howe= ver, the DNSSEC RFC is 15 years old, so I don't think it's generall= y productive to bring up in new work.

thanks,
Rob

--000000000000b75f0a059baf2770-- From nobody Wed Jan 8 23:13:37 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6948120025 for ; Wed, 8 Jan 2020 23:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zzab70nRlvM for ; Wed, 8 Jan 2020 23:13:33 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D676120020 for ; Wed, 8 Jan 2020 23:13:33 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 81D862B0D93; Thu, 9 Jan 2020 02:13:32 -0500 (EST) Date: Thu, 9 Jan 2020 02:13:32 -0500 From: Viktor Dukhovni To: ietf@ietf.org Subject: Re: utility of URNs and DNSSEC (was: Re: URNs and Last Call: (URI Design and Ownership) to Best Current Practice) Message-ID: <20200109071332.GD73491@straasha.imrryr.org> Reply-To: ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> <16161.1578432811@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 07:13:36 -0000 On Wed, Jan 08, 2020 at 10:31:00PM -0800, Rob Sayre wrote: > At the very least, one might concede that the usefulness of DNSSEC is a > matter of debate. There is no debating that some find it useful. Their use-cases (priorities) may be different from yours. That is, there's nothing to debate. > I actually happen to think DNSSEC might be useful once DNS transports are > encrypted, which the IETF has screwed up for 30 years. However, the DNSSEC > RFC is 15 years old, so I don't think it's generally productive to bring up > in new work. The base insecure DNS, SMTP, TCP are older still, and we continue to use them and build on them. There's no meat on this bone of contention, and it is in any case a digression. Let's move on. -- Viktor. From nobody Thu Jan 9 05:14:44 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8941200D7; Thu, 9 Jan 2020 05:14:43 -0800 (PST) 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 WQVVTO7z4wdx; Thu, 9 Jan 2020 05:14:41 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 3C890120048; Thu, 9 Jan 2020 05:14:41 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id q6so7318398wro.9; Thu, 09 Jan 2020 05:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OL2lvxX9Jfz5lPDjP7wequw8QdwPPLwlM5W2+acbuOk=; b=FkEaI01EErQnsl8o+BixuSPyricIIovRKokMSvhC3+ojftSczbXAdXsAu9lYXhfNe5 fo2QdMTSZxottweH7Y/fwQuD6lx3ymKh/+QG1C7uPvuwoTVXvsGxI8Q5t52Krl/CvfTs AeI6Mgw1rd0i4v4TCq4eDgELggDtAedKaxoikjybsGUYRBY/vaRTVsvC2y3Q5ViKxJgG 1AYMUnyZPuUN73tQ3LbcC4njsK5CK2mLKbAT8N+ekGdlnVE+9eBkI15TbAXpAnK4jZJH aqQnWdsPaJiskElXRFicG6sdwd7mJmZKabvT1REi5GMmAAgvYz2ORw7PHy0rHKbVxJIG 4E4g== 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=OL2lvxX9Jfz5lPDjP7wequw8QdwPPLwlM5W2+acbuOk=; b=LuKsz1yc+1wB4xHIVpRG2VHLjO3sjdaUFfyhCxHKgwarSUbeZ5OmEuRJOSzezEXoSo ops4PRp+GpExxOW73I4OiWoP5JE+puHbRfco/ny5BgnRR4xWivhN/MxLcv3ZxPVoCcr/ ncWv6Nlq3lckdl96sL577tihjddAjdT2hMEvtAKycNeVVfVT2okPyYcmb/jpfn4uxszW XZTYYB/73zOliHkSBWVIbj1l0fmtkDpLwoWbPiniV9qZOhFp4SvnzBa9WyV1Ss2mK9KD wZ8HGuRta4gB+6iQ3LCZB+fRtDt6GWSpLxC4OjyjZeB86+84XCzI3tvYhNwjLDuprrOQ b+jg== X-Gm-Message-State: APjAAAURtwMwYJpU5lMkfuRte94xvzfBVRw7FGXOgH0Ea77AHFkG8Twp cKAfburvFvxsKahEwDF+MILTCiGC X-Google-Smtp-Source: APXvYqzAV4CYS8TLkhhMd3RtC+hjSWGDGIBtOfcfGA3Ns0QIKtV6sC3DhQEC9vyIN+p3PQtiGmTbPQ== X-Received: by 2002:a5d:46c7:: with SMTP id g7mr10801923wrs.11.1578575679689; Thu, 09 Jan 2020 05:14:39 -0800 (PST) Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id i5sm8173697wrv.34.2020.01.09.05.14.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 05:14:38 -0800 (PST) From: Stewart Bryant Message-Id: <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Thu, 9 Jan 2020 13:14:37 +0000 In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Cc: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org To: IAB Chair References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:14:43 -0000 --Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 8 Jan 2020, at 23:14, IAB Chair wrote: >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >=20 >=20 Is this to be a public or a private register of interests? Best regards Stewart= --Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 8 Jan 2020, at 23:14, IAB Chair <iab-chair@iab.org> = wrote:

The = IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates.



Is this to be a public or a private register = of interests?

Best regards

Stewart
= --Apple-Mail=_32B9592E-2F59-4C16-9754-0290F38BD087-- From nobody Thu Jan 9 05:44:02 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1641200C1 for ; Thu, 9 Jan 2020 05:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=F/45A4RM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VNicclCC 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 7CQYnJYp57q8 for ; Thu, 9 Jan 2020 05:43:59 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096901200DB for ; Thu, 9 Jan 2020 05:43:59 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3A69121FC5 for ; Thu, 9 Jan 2020 08:43:58 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 09 Jan 2020 08:43:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:content-type:mime-version:subject:message-id:date:to; s= fm2; bh=gtQOVUo26H+XQZpMmfVdYkkIO/n0PlnfKxBeZuyt9Eo=; b=F/45A4RM ziA0vg93OLo4wS4caBQYs3n1HlWAW+niN4Z+7gN5rhWFB7349ghdqbFGYxCQZvPJ BqBW/0YqNs+hdXdE9TBienLIoUUCHCHVKXq1+ZAo0M8Y4pCaBXjtdiyckltdowpx EiK1yXPnZ9CQTh9QMQ0GnzP2t49W/ZLY/zdv1R2FTHtwC2QTuEmiAtKj3buPAcf5 RkzxGxVQ13E1vH6AqHSwCmRohB6lAZbj4Km1m/hum5zICbCjQjb6lYHd2jShNUsi cTYRc1ZP1e4b4TUlwfjB1kUz2y9ahfunowbiSK593FBBhumYIPAQqSwfLkingj6S shvvvSDhetKvEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=gtQOVUo26H+XQZpMmfVdYkkIO/n0P lnfKxBeZuyt9Eo=; b=VNicclCCOsMKUavRSsX0t/oDFq7OGh/bXKBosTA4ltWAD Y+ABdZ+uz4i9lwT3uGIuFS0fQP6Apahp2g4YnPYJ9TxY/QihpnDA06MUDHFFiktO FVYgYTmz9OUQsKk5dA1XEwgw6Yn0aUofL76jssfJZFLJxiMqj9L5xgACxN5hR66f XHttV0SseTwPECetBbTFmZXfyilGWZorhqCCEscLIAYI9YkKGYeWutCe7aSo5jfc rr/kYjAuO5YVSKVXP3dAQkK8yVLnvNrrvzitp4jobn3gTa8w9t5NNpDqx47l7lar rSRShs3KsQYOhdNRQOrQxzCOdd82TDPmq0Tqyqqww== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeiuddgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtggfukfffvffosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhsrgcu vehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrihhnpe hnhihtihhmvghsrdgtohhmpdihohhuthhusggvrdgtohhmnecukfhppedujeefrdefkedr uddujedrkedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvg hrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id A3AFF80059 for ; Thu, 9 Jan 2020 08:43:57 -0500 (EST) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_6E37DB69-BD44-4898-B8D4-58972BE1442C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Peter Kirstein Message-Id: <6D9F0B21-1B10-459A-A969-883612B0D319@cooperw.in> Date: Thu, 9 Jan 2020 08:43:57 -0500 To: IETF discussion list X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:44:01 -0000 --Apple-Mail=_6E37DB69-BD44-4898-B8D4-58972BE1442C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sharing this sad news from Stephen Hailes. > It is with great sadness that I have to have to announce the death = of=20 > Professor Peter Kirstein CBE FREng DFBCS FIET FInstP, an Internet = pioneer=20 > and the founding head of the Department of Computer Science at UCL. = Peter=20 > died yesterday morning (8th January) as a consequence of the brain = cancer=20 > with which he had been diagnosed in the latter part of last year. >=20 > Peter has come to be known as the father of the European Internet, = both=20 > because he was instrumental in establishing the first connection to = the=20 > ARPANET outside the US, and because of the role of Peter and his = research=20 > group in developing TCP/IP. Peter continued throughout his life to = be=20 > important in the development of network security protocols, video=20= > conferencing, multicast, directory services, secure e-mail, = certificate=20 > authorities, and IPv6. He was instrumental in delivering effective = Internet=20 > connectivity to the Caucasus and Central Asia through what was = state-of-the=20 > art satellite technology as project manager of the SILK project. >=20 > Peter won many plaudits throughout his life =E2=80=93 to name but a = few he was a=20 > recipient of the Marconi prize and the SIGCOMM award and was = inducted into=20 > the Internet Hall of Fame as a pioneer as part of its first intake. = Never=20 > one to rest on his laurels, Peter continued to be interested in and = to work=20 > in new areas of networking, developing an interest in IoT and being = an=20 > advocate for the Handle System developed by Bob Kahn as late as = last year.=20 > Peter retired in November 2019, at the age of 86. He lived life to = the full=20 > =E2=80=93 he broke his pelvis skiing, only last year. He was a = gentleman, innately=20 > kind and supportive, and someone to whom all were worthy of equal=20= > consideration, from the most junior of staff to the most senior. He=20= > retained a passionate interest in the Department of Computer = Science at UCL=20 > to the very end of his life, and will be sorely missed by those of = us that=20 > had the good fortune to know him, work with him, and call him = friend. >=20 > Peter is survived by his wife Gwen, daughters Lynn and Claire and = their=20 > children. >=20 > For those that are interested in early Internet developments, there = is an=20 > opportunity to hear Peter speak about these in an interview with = Jim=20 > Boulton filmed last year: = https://www.youtube.com/watch?v=3DCfzbAzGVSyE = .=20 > There is also an obituary in the New York Times=20 > = https://www.nytimes.com/2020/01/08/technology/peter-kirstein-dead.html = . --Apple-Mail=_6E37DB69-BD44-4898-B8D4-58972BE1442C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sharing this sad news from Stephen Hailes.

   It is with great sadness that I have to have to = announce the death of 
   Professor = Peter Kirstein CBE FREng DFBCS FIET FInstP, an Internet pioneer 
   and the founding head of the Department of = Computer Science at UCL. Peter 
   died = yesterday morning (8th January) as a consequence of the brain = cancer 
   with which he had been = diagnosed in the latter part of last year.

   Peter has come to be known as the father of = the European Internet, both 
   because = he was instrumental in establishing the first connection to the 
   ARPANET outside the US, and because of the = role of Peter and his research 
   group= in developing TCP/IP. Peter continued throughout his life to = be 
   important in the development of = network security protocols, video 
   conferencing, multicast, directory = services, secure e-mail, certificate 
   authorities, and IPv6. He was instrumental = in delivering effective Internet 
   connectivity to the Caucasus and Central = Asia through what was state-of-the 
   art satellite technology as project manager = of the SILK project.

   Peter = won many plaudits throughout his life =E2=80=93 to name but a few he was = a 
   recipient of the Marconi prize = and the SIGCOMM award and was inducted into 
   the Internet Hall of Fame as a pioneer as = part of its first intake. Never 
   one = to rest on his laurels, Peter continued to be interested in and to = work 
   in new areas of networking, = developing an interest in IoT and being an 
   advocate for the Handle System developed by = Bob Kahn as late as last year. 
   Peter= retired in November 2019, at the age of 86. He lived life to the = full 
   =E2=80=93 he broke his pelvis = skiing, only last year. He was a gentleman, innately 
   kind and supportive, and someone to whom = all were worthy of equal 
   consideration, from the most junior of = staff to the most senior. He 
   retained a passionate interest in the = Department of Computer Science at UCL 
   to the very end of his life, and will be = sorely missed by those of us that 
   had the good fortune to know him, work with = him, and call him friend.

   Peter is survived by his wife Gwen, = daughters Lynn and Claire and their 
   children.

   For those that are interested in early = Internet developments, there is an 
   opportunity to hear Peter speak about these = in an interview with Jim 
   Boulton = filmed last year: https://www.youtube.com/watch?v=3DCfzbAzGVSyE. 
   There is also an obituary in the New York = Times 
   https://www.nytimes.com/2020/01/08/technology/peter-kirstein-de= ad.html.


= --Apple-Mail=_6E37DB69-BD44-4898-B8D4-58972BE1442C-- From nobody Thu Jan 9 06:29:03 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D77512004E; Thu, 9 Jan 2020 06:28:57 -0800 (PST) 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, 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 QrgWGMwoQcOF; Thu, 9 Jan 2020 06:28:52 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90B0120089; Thu, 9 Jan 2020 06:28:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ipYnq-000F2b-0X; Thu, 09 Jan 2020 09:28:50 -0500 Date: Thu, 09 Jan 2020 09:28:44 -0500 From: John C Klensin To: Stewart Bryant , IAB Chair cc: iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy Message-ID: In-Reply-To: <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:28:57 -0000 --On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant wrote: >> On 8 Jan 2020, at 23:14, IAB Chair wrote: >> >> The IAB requires that all Covered Individuals disclose their >> main employment, sponsorship, consulting customer, or other >> sources of income when joining the IAB or whenever there are >> updates. > Is this to be a public or a private register of interests? Stewart's question is important for what may be an additional reason. There is a fairly long history of IAB members who often show up as "independent" but who are full-time consultants with multiple clients (as distinct from those who serve in consulting, rather than employee, roles but with one principal client). They may have, in the words of the draft, no "main employment, sponsorship, consulting customer, ...". In those situations, it isn't terribly unusual for consulting agreements to contain requirements that the relationship not be disclosed by either party without mutual consent. I've had little trouble getting consent when there is a substantive reason that doesn't threaten the reasons for the confidentiality provision and there are provisions to keep the information from becoming generally known, but completely public disclosures would probably not fly. I'd assume that someone working for, or a principal of, a stealth startup might face similar constraints. While I applaud the IAB's coming to grips with this issue, let's be sure we don't do anything that limits the diversity or range of skills and perspectives of people who can serve on the IAB as an accidental side-effect of a well-intentioned policy. john From nobody Thu Jan 9 06:44:30 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017571200B4 for ; Thu, 9 Jan 2020 06:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C8GOHhqDEgey for ; Thu, 9 Jan 2020 06:44:26 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B501200D8 for ; Thu, 9 Jan 2020 06:44:25 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id u1so7510622ljk.7 for ; Thu, 09 Jan 2020 06:44:25 -0800 (PST) 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=7pEweHIiSZh8B78Wmp8vnjz0ng3w/M96pSNbAnYI3JA=; b=ZQIwSHwlJEvh2ykkde9ST8YEsmwpYzg2E9HZ5uabVmVzXvIMzirTXHSoWVUBoU9C0T StNIBP9xbXc3xR+xuELE6AOIxO7nfieM236Mt/ZMnSsY5k/SX7GQvCfd5MJu+B8sSeZe 6kPns3d/Fe2G8Q4IJAJZ3Vh6Cix+tr24V99Fq94AvutP1NHNuVhNFhmShUhH02FF0ykW rtonL5aHRyLvx5dpstZpK+sgc5InMh7mBbiThR/T2odxPfwFja3bUGIhpR+OdJziwYx1 2o1vsLfDecWG590SzxhubXzn9vS00yePEkJpRC55jgpzZlzQf/SiF18ahEX7Dpb3sxwj l35A== 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=7pEweHIiSZh8B78Wmp8vnjz0ng3w/M96pSNbAnYI3JA=; b=nEnMD3+AVeyrtSlMzFbwkKQFSTkCSRHGwreNiCwwFhRBfq8dTrBmSp2x+IbbrV382m gwGtpaGZb36adFcEgOiecMp/QyeTDkt63KTevdjr5/mWa/3JbFvfjCvsPevB1eNewane aAB9a1eA0aHDv3CJeMPBdK6iisdr/LswtR1zhueQUoIJ8GmfqxdUL5kUk0e4/YHXP46O Ofr73ZISxqnc1CTrpE91GzWVze4m0BVyRXL6tmfoFZ+eXtwZ4Ml6sulzokRf21Lpg/d3 bTtDWfFsUs3Nm1GeujwWbM9pIje6eKkY+2IzVIoF+gy9t983n2L8VAtWdkewpU6MY4Xv YhFA== X-Gm-Message-State: APjAAAXc0YGoQTTeQVqb8gL3boGKdTgvxj/xXzAl7I+KGsNrFvQ+OoDZ TNz4JYcgSfJk3ymPQ0PPobu/u4lgTqwFbCi9XQZURQ== X-Google-Smtp-Source: APXvYqyQltGeoytUWPXkU1Evktqm5VcVesRaOZFlxjaJpRIqmzS2+3ZNKKUCu+YLYsoDwAFUUfMqd3K+Z7xU8SjKPF8= X-Received: by 2002:a2e:88c5:: with SMTP id a5mr6899536ljk.201.1578581063639; Thu, 09 Jan 2020 06:44:23 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> In-Reply-To: From: Eric Rescorla Date: Thu, 9 Jan 2020 06:43:47 -0800 Message-ID: Subject: Re: [arch-d] Draft IAB conflict of interest policy To: John C Klensin Cc: Stewart Bryant , IAB Chair , "iab@iab.org IAB" , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000008c42df059bb60bc0" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:44:29 -0000 --0000000000008c42df059bb60bc0 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 at 6:29 AM John C Klensin wrote: > > > --On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant > wrote: > > >> On 8 Jan 2020, at 23:14, IAB Chair wrote: > >> > >> The IAB requires that all Covered Individuals disclose their > >> main employment, sponsorship, consulting customer, or other > >> sources of income when joining the IAB or whenever there are > >> updates. > > > Is this to be a public or a private register of interests? > > Stewart's question is important for what may be an additional > reason. There is a fairly long history of IAB members who often > show up as "independent" but who are full-time consultants with > multiple clients (as distinct from those who serve in > consulting, rather than employee, roles but with one principal > client). They may have, in the words of the draft, no "main > employment, sponsorship, consulting customer, ...". In those > situations, it isn't terribly unusual for consulting agreements > to contain requirements that the relationship not be disclosed > by either party without mutual consent. I've had little trouble > getting consent when there is a substantive reason that doesn't > threaten the reasons for the confidentiality provision and there > are provisions to keep the information from becoming generally > known, but completely public disclosures would probably not fly. > > I'd assume that someone working for, or a principal of, a > stealth startup might face similar constraints. > > While I applaud the IAB's coming to grips with this issue, let's > be sure we don't do anything that limits the diversity or range > of skills and perspectives of people who can serve on the IAB > as an accidental side-effect of a well-intentioned policy. > This seems like an important point. In addition, it's not clear to me as I read this text how I am supposed to read "main.... or other sources of income". Surely the intention is not that people disclose all other sources of income. -Ekr > john > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000008c42df059bb60bc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 6:29 AM John C= Klensin <john-ietf@jck.com>= wrote:


--On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant
<stewart.b= ryant@gmail.com> wrote:

>> On 8 Jan 2020, at 23:14, IAB Chair <iab-chair@iab.org> wrote:
>>
>> The IAB requires that all Covered Individuals disclose their
>> main employment, sponsorship, consulting customer, or other
>> sources of income when joining the IAB or whenever there are
>> updates.

> Is this to be a public or a private register of interests?

Stewart's question is important for what may be an additional
reason.=C2=A0 There is a fairly long history of IAB members who often
show up as "independent" but who are full-time consultants with multiple clients (as distinct from those who serve in
consulting, rather than employee, roles but with one principal
client).=C2=A0 They may have, in the words of the draft, no "main
employment, sponsorship, consulting customer, ...".=C2=A0 In those
situations, it isn't terribly unusual for consulting agreements
to contain requirements that the relationship not be disclosed
by either party without mutual consent.=C2=A0 I've had little trouble getting consent when there is a substantive reason that doesn't
threaten the reasons for the confidentiality provision and there
are provisions to keep the information from becoming generally
known, but completely public disclosures would probably not fly.

I'd assume that someone working for, or a principal of, a
stealth startup might face similar constraints.

While I applaud the IAB's coming to grips with this issue, let's be sure we don't do anything that limits the diversity or range
of skills and perspectives of people who can serve on=C2=A0 the IAB
as an accidental side-effect of a well-intentioned policy.
=

This seems like an important point. In addition, it'= ;s not clear to me as
I read this text how I am supposed to read = "main.... or other sources
of income". Surely the inten= tion is not that people disclose all other
sources of income.
=

-Ekr


=C2=A0 =C2=A0john


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000008c42df059bb60bc0-- From nobody Thu Jan 9 06:48:30 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0DD120019; Thu, 9 Jan 2020 06:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 ObwnXYwM25Dh; Thu, 9 Jan 2020 06:48:12 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4B2291200B4; Thu, 9 Jan 2020 06:48:12 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id g17so7693390wro.2; Thu, 09 Jan 2020 06:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ec5x6EM612P81UnJ13/N83rOfr3xExnsEptsdWstwQ=; b=RFUnPFPQVSlgfwCqiPyN5PwXqYIE1HweLI7Tmy3UvE+Kgg86LMJweEZEtjlAkK1CmJ ZtNDEED2/fDoauNPP2te/8vky89lYI25XD4VfMoA4/Op4OGTVMIgsimECU/mUxK5YK5K GV/3JIQtjqerd7cpnQasdXGTUlUTEA6v/ac1ZmFRDp1x4kYp5GX1/SANWBXUxkkYHWQY boqnrpQlV8VnvcG5PLIjXx7tRF+jq7lIQXisbro9cSSDEpdQvS/pREMSjb7+BId7Bl+t 5Yc1/32qA6p80btjTbDR9wElC58LXaQmy8+01ZuZaYxIoTfJpAgaHMEHY60253fHFt7d w0rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ec5x6EM612P81UnJ13/N83rOfr3xExnsEptsdWstwQ=; b=Z1UtVktKRF2F5ZZeZ9v9R+2GgHjtv5oAKi9S9o+bD/2WrPxBmJbAOntewHx1qTeLCb vDh2L5/dP2f73BWufdZlbH3TnMdADj9jNvVuFCYGuWByK+9xHbIbIrHBIBokpkCx9LV0 6QMkb0AVd44JBVkOi5O9W2L5Lsc9IbmBU+93fiyDMhxryuN5QcGY/bQMUffNX5bGhdqo pEKIfAOay2PtHbs10Wxp675gbyLA6kGuH/j7oxZENOadBFI3xfd9pCBvuEsehNDwMOuT FkD8+nJ2qyzejrGz6qD7xk/QnMKqU7rPqQg0jAn+P91477tG2tolYMF9W0/YI/MO2T5S 0dVg== X-Gm-Message-State: APjAAAVCnWUuUt8iGW2TxSK8z+ecvzXUKILVs0xvOW/JNd+7VO9xiPwA R0yvqPRvDH2JYxl7GnxbavVXCCHM X-Google-Smtp-Source: APXvYqwUy6csmnqd0kYAUsVWqffNJfwz6rdmflUqTcIPy9jbsVmpEeX7ZtFtSV2G/DMFDrnY+spOOw== X-Received: by 2002:adf:eb89:: with SMTP id t9mr11608315wrn.5.1578581290751; Thu, 09 Jan 2020 06:48:10 -0800 (PST) Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id f17sm3149302wmc.8.2020.01.09.06.48.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 06:48:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: [arch-d] Draft IAB conflict of interest policy From: Stewart Bryant In-Reply-To: Date: Thu, 9 Jan 2020 14:48:09 +0000 Cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> To: John C Klensin X-Mailer: Apple Mail (2.3601.0.10) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:48:15 -0000 > On 9 Jan 2020, at 14:28, John C Klensin wrote: >=20 >=20 >=20 > --On Thursday, January 9, 2020 13:14 +0000 Stewart Bryant > wrote: >=20 >>> On 8 Jan 2020, at 23:14, IAB Chair wrote: >>>=20 >>> The IAB requires that all Covered Individuals disclose their >>> main employment, sponsorship, consulting customer, or other >>> sources of income when joining the IAB or whenever there are >>> updates. >=20 >> Is this to be a public or a private register of interests? >=20 > Stewart's question is important for what may be an additional > reason. There is a fairly long history of IAB members who often > show up as "independent" but who are full-time consultants with > multiple clients (as distinct from those who serve in > consulting, rather than employee, roles but with one principal > client). They may have, in the words of the draft, no "main > employment, sponsorship, consulting customer, ...". In those > situations, it isn't terribly unusual for consulting agreements > to contain requirements that the relationship not be disclosed > by either party without mutual consent. I've had little trouble > getting consent when there is a substantive reason that doesn't > threaten the reasons for the confidentiality provision and there > are provisions to keep the information from becoming generally > known, but completely public disclosures would probably not fly. >=20 > I'd assume that someone working for, or a principal of, a > stealth startup might face similar constraints. >=20 > While I applaud the IAB's coming to grips with this issue, let's > be sure we don't do anything that limits the diversity or range > of skills and perspectives of people who can serve on the IAB > as an accidental side-effect of a well-intentioned policy. >=20 > John >=20 John I think that this is a dilemma we need to explore in more depth. Is taking money from a secret client consistent with holding high office = in an open standards organisation? I for one have always found that = difficult to accept as reasonable. Say it is, we all agree on the potential for abuse. Say it is not, then as you say the candidate pool is reduced. A compromise might be to require confidential disclosure to some trusted = party that monitors recusal, but the even that is potentially subject to = abuse through soft power. I suspect that the only way to ensure that we have a fully trustworthy = system is to require openness and accept that the candidate pool is = reduced. - Stewart >=20 From nobody Thu Jan 9 06:55:04 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84092120944; Thu, 9 Jan 2020 06:54:55 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 2bKpQLlAPyMB; Thu, 9 Jan 2020 06:54:54 -0800 (PST) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 1078F120934; Thu, 9 Jan 2020 06:54:53 -0800 (PST) Received: by mail-ed1-x52c.google.com with SMTP id t17so5839226eds.6; Thu, 09 Jan 2020 06:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :content-transfer-encoding; bh=SgLF/Z9na83qPxU942H2jQv1zQDvCIftCTdUkuLAcv8=; b=e/Abp9dZ4g+a6JtVjveYoeEe8J7lQneXJcgoopLqS9GoCr/QLUK18Uityibv1Ry0dX dT+i1Qzt4hx9bRnULXfHEXOGY/chWBNVSZCNYJODpoTiop0rM07oy/I0439SVYiV13L3 rEobLpnD23y5MUkNxUNygkU6H2fVG/dZj2sJUz/RsC9kN6pPUNsR5QjZo3yccLS1EN1n 8KTYR21vrXgGqJ8vEoAsjGnz69rbdPkzmF2j0unZuXRKzT7soFfMDihpPORdHQiKMFdH zsDukCixvpJOh4713gWCO3jc0yvbhAnubGTp4xx/LnXZzJGXl6Uq6lFS6uSCpTTX/Vgk SbwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:content-transfer-encoding; bh=SgLF/Z9na83qPxU942H2jQv1zQDvCIftCTdUkuLAcv8=; b=QdPmrfLHFsJl31zPXtVzlyXRlheRKkaOuwX8urCPeHutRfWTcNZpHMUcaKhY0+9EOw U+FA4wHiQDJAKQRCBthY7BHDMEQCembJ5Bp7IO3yb93ADBa9mwUf27m0xvpcy3+Kaqfs 10iZfwDFYkceWQbp5X4Fabo1321/eiyWVBF6T9bvT68xjYqW5n28DhM4fLRSQMvVpn/G uQrl/oYXfYjur3AWPRe6WTdv9wOVixEMNnO2zy8JcUujjKwMIWPwQSCihsMOlZV4O6VX +r0+29emdq0rYileZjIJMI0F8bHRpclpqok1e27v/Q3wRq/l7XtUIYa7ZV6r/XdUTMtG ld6A== X-Gm-Message-State: APjAAAUayzLw3BOIOk+ZSzwvHkaNPms2wXk/yFFWnYXaDyJV/NPGGavP GXOaW9hRmW7XUWlyo/ZX3ncIQH+j35uETySp4ZXVkw== X-Google-Smtp-Source: APXvYqwpqaP5n5EDsA8bXpUDVondEU4+5Jtva/Ph7br06QvfBS6zTLHvyHOc4R1A2oYOgNTkBqZFSofCqVnCLdIQeWs= X-Received: by 2002:a05:6402:1777:: with SMTP id da23mr11706125edb.292.1578581691423; Thu, 09 Jan 2020 06:54:51 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 9 Jan 2020 06:54:50 -0800 From: Alvaro Retana In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> MIME-Version: 1.0 Date: Thu, 9 Jan 2020 06:54:50 -0800 Message-ID: Subject: Re: [arch-d] Draft IAB conflict of interest policy To: architecture-discuss@ietf.org, IAB Chair , iab@iab.org, ietf@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 14:54:57 -0000 On January 8, 2020 at 6:15:13 PM, IAB Chair wrote: Hi! > This policy covers the nomcom-selected Internet Architecture Board (IAB) > members and ex-officio members (collectively, =E2=80=9CCovered Individual= s=E2=80=9D). This > policy has no impact on any other participants in IAB activities, for > instance liaisons to and from the IAB or IAB program members. I have two questions: (1) Why are the liaison members of the IAB not included as Covered Individuals? =C2=A0rfc2850 treats both ex-officio and liaison members in about the same way -- the only distinction that I could see is that "an ex-officio position may be held by a full member" (=C2=A71.2). =C2=A0Gi= ven that all the other expectations for both are the same, I would like to understand why the liaison members are not included in the policy if they can participate in the IAB discussions. (2) Liaison managers (to other organizations) represent the interests of the IETF, should they be subject to a similar COI policy? =C2=A0Maybe it is not appropriate to include them in this specific policy, but I didn't find anything in rfc4052 related to this point. Thanks! Alvaro. From nobody Thu Jan 9 07:11:30 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB08120132; Thu, 9 Jan 2020 07:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 csFxy9HFcbRM; Thu, 9 Jan 2020 07:11:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DF8CA120019; Thu, 9 Jan 2020 07:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AxOXb3J5pxM0w2XVlLWES/MOfXkLVRWWjwBm569Mr/k=; b=JHYDkKGuMPKMsvL9Emao4tMA+ mqlmV/cYXHjF4hSwklQZbHMPvHDp1lmsJzAwcJDuqU0dPEWNrKXxysS7WOGJ4ni16qUBAx4weYwBz pbT4E9yZq5XWZVkNNX++l66reqjjPlo6h3/NPEz8yNjmToDsM50WbcKxB4ZZiQzK5b2idN69SX65d 6ea2F8Ou+7K+3FH2qUE2RP/4y4u+IM5sGbDNSJx5qWdDVLOOUOzp4I24xpgR8j9+57YyfVREo2jSy 9p8NEUSiroEMjybbBK896NIv6iFIdxZvn1Kpi/tKYMUIX02WfYzoZwLReEj/xJtkCnOtMXFWmPQsz 4uvAC4B+g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59627 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipZSt-004LDh-Vu; Thu, 09 Jan 2020 10:11:20 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: Draft IAB conflict of interest policy From: Joe Touch In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Date: Thu, 9 Jan 2020 07:11:14 -0800 Cc: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org Message-Id: <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> To: IAB Chair X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 15:11:24 -0000 --Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, Numerous issues typically mentioned in COI policies are missing here: 1) compensation may be pending or in the immediate future 2) Compensation need not be financial (e.g., authorship, appointment to = perceived prestigious non-paying positions, quid-pro-quo, etc.) 3) Conflicts go beyond direct collaborations (i.e., the employers whole = organization) 4) The policy should indicate a time frame=20 Some examples from other COI policies include: - no current student/teacher relationship - no PhD graduate / PhD primary advisor *forever* - no current or recent proposal or paper co-author (whether = granted or not) for 4 years - not in any way associated with a current employer *and its = subsidiaries* - agree to not accept compensation (financial or not) for at = least 1 year *after* participation Joe > On Jan 8, 2020, at 3:14 PM, IAB Chair wrote: >=20 > Dear Colleagues, >=20 > The IAB is considering adoption of the conflict of interest policy = below. If you have comments on this draft policy, please send them to = iab@iab.org . >=20 > best regards, >=20 > Ted Hardie > for the IAB >=20 >=20 >=20 > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >=20 > This policy covers the nomcom-selected Internet Architecture Board = (IAB) members and ex-officio members (collectively, =E2=80=9CCovered = Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the = IAB or IAB program members. >=20 > In carrying out their IAB role, Covered Individuals must act in the = best interest of the Internet community. Occasionally this duty may = be=E2=80=94or may appear to be=E2=80=94incompatible or in conflict with = a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which = the Covered Individual is an employee, director, owner, or otherwise has = business or financial interest. If a Covered Individual has a conflict = of interest for whatever reason, that individual must avoid = participating in the work of the IAB that touches on the related matter. >=20 > The IAB does not directly deal with matters relating to contracts or = finance. The IAB does, however, have a role in personnel decisions, and = its decisions and outputs have a potential to indirectly affect = contracts within the IETF system. IAB's technical decisions and outputs = have also a potential to impact both work elsewhere in the IETF and = businesses that employ or develop Internet technology. >=20 > Covered Individuals shall not use the IAB=E2=80=99s resources or = decisions as a means for personal or third-party gain. >=20 > Disclosure of Actual or Potential Conflicts >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >=20 > In addition, when a topic is discussed at the IAB, the Covered = Individuals are required to promptly disclose if that topic constitutes = a perceived or potential conflict of interest. Once disclosed, Covered = Individuals may recuse from participation in discussions or decisions at = their discretion. >=20 > The specific conflicts that may cause a perceived or potential = conflict of interest are matters for individual and IAB judgment, but = generally come in the following forms: >=20 > A personnel decision relates to the Covered Individual, a colleague = that the Covered Individual's works closely with, or a family member. = For the purposes of this policy, a "person working closely with" is = someone working in the same team or project, or a direct manager or = employee of the Covered Individual. And "family" means a spouse, = domestic partner, child, sibling, parent, stepchild, stepparent, and = mother-, father-, son-, daughter-, brother-, or sister-in-law, and any = other person living in the same household, except tenants and household = employees. >=20 > A decision or output from the IAB impacts a contract that the IETF = enters into with a party, and that party relates to the Covered = Individual, a colleague that the Covered Individual's works closely = with, or a family member. >=20 > Activity on the IAB involves discussion and decisions regarding = technical matters, mainly related to IETF activities. As an activity = adjacent to a standardization process, it is often the case that Covered = Individuals will have some (frequently non-financial) stake in the = outcome of discussions or decisions that relate to technical matters. = This policy does not require that Covered Individuals disclose such = conflicts of interest as they relate to technical matters. However, = Covered Individuals need to exercise their judgment and, in = extraordinary cases be willing to disclose potential or perceived = conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of = entering a new market where there is an ongoing IAB discussion, then = disclosure, or even recusal, might be appropriate, even if difficult. >=20 > Disclosure Transparency >=20 > A person's recusal to participate in the discussion of a topic is = always noted in the public IAB minutes. In addition, the IAB will = maintain a repository of all general disclosures of employment and other = sponsorship. It is expected that much of this repository is public, but = there can be situations where some disclosures (such as customers of = consultants) are private. >=20 >=20 > = >=20 --Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

Numerous issues = typically mentioned in COI policies are missing here:

1) compensation may be = pending or in the immediate future

2) Compensation need not be financial = (e.g., authorship, appointment to perceived prestigious non-paying = positions, quid-pro-quo, etc.)

3) Conflicts go beyond direct = collaborations (i.e., the employers whole organization)

4) The policy should = indicate a time frame 

Some examples from other COI policies include:

- no = current student/teacher relationship
- no PhD = graduate / PhD primary advisor *forever*
- no = current or recent proposal or paper co-author (whether granted or not) = for 4 years
- not in any way associated with = a current employer *and its subsidiaries*
- agree = to not accept compensation (financial or not) for at least 1 year = *after* participation

Joe


On Jan 8, 2020, at 3:14 PM, IAB = Chair <iab-chair@iab.org> wrote:

=20 =20

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please = send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST = POLICY

This policy covers the nomcom-selected Internet = Architecture Board (IAB) members and ex-officio members (collectively, = =E2=80=9CCovered Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB = role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in = conflict with a Covered Individual=E2=80=99s personal interests (including = interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not = directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals = shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their = main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the = Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The = specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the = Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB = impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves = discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's = recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




= --Apple-Mail=_8BCF0222-ACF7-4CF2-8486-BDDCB39DAAA2-- From nobody Thu Jan 9 07:15:35 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30357120019 for ; Thu, 9 Jan 2020 07:15:34 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=kumari-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 wT9sTgCuvgbT for ; Thu, 9 Jan 2020 07:15:32 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 167631200FE for ; Thu, 9 Jan 2020 07:15:32 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id t129so6243524qke.10 for ; Thu, 09 Jan 2020 07:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RzGXWKfcRWH0MysPCL6IRnCr1p4YslyqVTvBasak8bw=; b=G3wl8lKYCLyWXv0wA553WnAhSkqUOKC/7WF10gy2CCXfz1Kwthn4k/S0rEtJKpRVsq IgGF6Hko4ORaR9kjIIRnAtPYXhN0RGxSsSwxOOlh+bpm7+elkFcJHWa/kfHgzowsz4Gw OwEnMkrkXsEX2NGfR/6pmmVYvIZoGCNDMeWUDbW/m2PCteMKwqgOaeVb52AspcN0i3fd xXs+u3ocgRtEusA7ktYQOIzWMRS4GV9XfTPn82S21s734jDqP+X8F0ftPjbhg+hsy7KS nt7e3WzvFcW+BXrJayrX+PhLlTTDJ6JYlzjegG/C4zBBkcraj3rX2f0MvVFseATIymSI l/TQ== 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:content-transfer-encoding; bh=RzGXWKfcRWH0MysPCL6IRnCr1p4YslyqVTvBasak8bw=; b=YICWNIgm+H9FyBekIA+DLGXRWkNBnhDCi3S9DbFNCA/LYf/F8ywD9Cl7pzN0Q6TmDA jLps71P8wuEHC6mlHdVklHWJ/l+NPqWiJpiHDND7E8L0vIbcMaFqTAL0wMvjqJ+ua4LZ sttpqAL2qcAvNMv+VCqpcVAptON2KlCS3Dh4Y7zvVfymSCKOGMpkSTrADrQoUf9NaI+T yG+OrtK/6wzyo92f2H0tL2U7s1j1On1Hb8WRk+PKolmi+t8TeDUETaJgI7hJnJXQRLCp PybbUn3mW/OMBHrsGqbNR6Av1ULR9fDEdtRLiySsz7efyMHOTrpwyWOpvrA3Vn0kJEWc ATbQ== X-Gm-Message-State: APjAAAWGOwGPVxu6lCxQ8qIh6FBOVLNj3+ZFDFV38juYUisney+KFRog ZxiXPjOtyfDzahtZBcCELIwRlzHu+9fI1XGnu6H7zAwK X-Google-Smtp-Source: APXvYqzV+v3IlbD3Oo1gCzDXuI6REJahkGutKdeLZPlrUlTMW9ZgRX+d5BmOfzDFV5mxkD+gEBmlsMEmpULNVub5+/8= X-Received: by 2002:a37:9982:: with SMTP id b124mr9758576qke.245.1578582930870; Thu, 09 Jan 2020 07:15:30 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> From: Warren Kumari Date: Thu, 9 Jan 2020 10:14:54 -0500 Message-ID: Subject: Re: Draft IAB conflict of interest policy To: IAB Chair Cc: IETF Discuss , architecture-discuss@ietf.org, IAB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 15:15:34 -0000 On Wed, Jan 8, 2020 at 6:15 PM IAB Chair wrote: > > Dear Colleagues, > > The IAB is considering adoption of the conflict of interest policy below.= If you have comments on this draft policy, please send them to iab@iab.or= g. > > best regards, > > Ted Hardie > for the IAB > > > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY > > This policy covers the nomcom-selected Internet Architecture Board (IAB) = members and ex-officio members (collectively, =E2=80=9CCovered Individuals= =E2=80=9D). This policy has no impact on any other participants in IAB acti= vities, for instance liaisons to and from the IAB or IAB program members. > > In carrying out their IAB role, Covered Individuals must act in the best = interest of the Internet community. Occasionally this duty may be=E2=80=94o= r may appear to be=E2=80=94incompatible or in conflict with a Covered Indiv= idual=E2=80=99s personal interests (including interests of their family mem= bers), or the interests of an organization of which the Covered Individual = is an employee, director, owner, or otherwise has business or financial int= erest. If a Covered Individual has a conflict of interest for whatever reas= on, that individual must avoid participating in the work of the IAB that to= uches on the related matter. > > The IAB does not directly deal with matters relating to contracts or fina= nce. The IAB does, however, have a role in personnel decisions, and its dec= isions and outputs have a potential to indirectly affect contracts within t= he IETF system. IAB's technical decisions and outputs have also a potential= to impact both work elsewhere in the IETF and businesses that employ or de= velop Internet technology. > > Covered Individuals shall not use the IAB=E2=80=99s resources or decision= s as a means for personal or third-party gain. > > Disclosure of Actual or Potential Conflicts > > The IAB requires that all Covered Individuals disclose their main employm= ent, sponsorship, consulting customer, or other sources of income when join= ing the IAB or whenever there are updates. > > In addition, when a topic is discussed at the IAB, the Covered Individual= s are required to promptly disclose if that topic constitutes a perceived o= r potential conflict of interest. Once disclosed, Covered Individuals may r= ecuse from participation in discussions or decisions at their discretion. > > The specific conflicts that may cause a perceived or potential conflict o= f interest are matters for individual and IAB judgment, but generally come = in the following forms: > > A personnel decision relates to the Covered Individual, a colleague that = the Covered Individual's works closely with, or a family member. For the pu= rposes of this policy, a "person working closely with" is someone working i= n the same team or project, or a direct manager or employee of the Covered = Individual. And "family" means a spouse, domestic partner, child, sibling, = parent, stepchild, stepparent, and mother-, father-, son-, daughter-, broth= er-, or sister-in-law, and any other person living in the same household, e= xcept tenants and household employees. I'm a bit concerned by the specificity of these -- the fact that they are explicitly enumerated implies that everything not listed so just fine - for example, my dear Grandma[0] is a leading ASP.NET developer, and is forming a company - as grandparents are not excluded, *clearly* I could, as an IAB member, recommend she gets the contract for rewriting the DT in some shiny new asp based framework. I'm guessing that this was copied from somewhere else, because I'm assuming most IAB people won't run into the "household employees" issue (which is sad, because my personal valet gives good legal advice, and my butler ties a great Windsor knot, and is also an expert on long term archival solutions for technical documents). I *do* realize that this says "perceived or potential conflict of interest", and so issues like my Grandma should be excluded, but perhaps something more along the lines of Spencer's "Do the right thing" tone would be better? Or a combination, with some specificity but a mention of the list not being wholly inclusive/just a sample or subset? W > > A decision or output from the IAB impacts a contract that the IETF enters= into with a party, and that party relates to the Covered Individual, a col= league that the Covered Individual's works closely with, or a family member= . > > Activity on the IAB involves discussion and decisions regarding technical= matters, mainly related to IETF activities. As an activity adjacent to a s= tandardization process, it is often the case that Covered Individuals will = have some (frequently non-financial) stake in the outcome of discussions or= decisions that relate to technical matters. This policy does not require t= hat Covered Individuals disclose such conflicts of interest as they relate = to technical matters. However, Covered Individuals need to exercise their j= udgment and, in extraordinary cases be willing to disclose potential or per= ceived conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of entering = a new market where there is an ongoing IAB discussion, then disclosure, or = even recusal, might be appropriate, even if difficult. > > Disclosure Transparency > > A person's recusal to participate in the discussion of a topic is always = noted in the public IAB minutes. In addition, the IAB will maintain a repos= itory of all general disclosures of employment and other sponsorship. It is= expected that much of this repository is public, but there can be situatio= ns where some disclosures (such as customers of consultants) are private. > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Jan 9 08:13:50 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D2E12012D; Thu, 9 Jan 2020 08:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 LJwpxWI5Rzzp; Thu, 9 Jan 2020 08:13:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD911200FA; Thu, 9 Jan 2020 08:13:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89BD6BE53; Thu, 9 Jan 2020 16:13:29 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_BBMyQ6lNrT; Thu, 9 Jan 2020 16:13:27 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E4B1ABE51; Thu, 9 Jan 2020 16:13:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578586406; bh=afrDVyJooG78WG6aaVSPBY/eT/xPJTEoqP4/LuMZzuI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vba6xeTPSVhYz+0UFDVr7ZcL/eqTqFwcgRM4qJFCnKNC7U8LyxzBf4HovmX5e9Wdv ICHHl46mOGTNbY+bDfgqDLsVhgbTBPhFcZYEjwXDWiCJXn3ZVFk3jfuDIJo4bsEO+a WT3mVqCrlZMozqNL5cNfngT57Z0FYUnwRmR6GROE= Subject: Re: Draft IAB conflict of interest policy To: IAB Chair , ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <352570ca-1f4b-33e7-3bfe-57cc0e852f1b@cs.tcd.ie> Date: Thu, 9 Jan 2020 16:13:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 16:13:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV Content-Type: multipart/mixed; boundary="BCkoJBa5askY94jk21CMv450JjTXEzZjF"; protected-headers="v1" From: Stephen Farrell To: IAB Chair , ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org Message-ID: <352570ca-1f4b-33e7-3bfe-57cc0e852f1b@cs.tcd.ie> Subject: Re: Draft IAB conflict of interest policy References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> --BCkoJBa5askY94jk21CMv450JjTXEzZjF Content-Type: multipart/mixed; boundary="------------01B0991A504123AE170DEA38" Content-Language: en-US This is a multi-part message in MIME format. --------------01B0991A504123AE170DEA38 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, FYI, this text is also in a github repo [1] so raising issues there is also a possibility that may help us to track things more easily, for folks who prefer to do things that way. Cheers, S. [1] https://github.com/jariarkko/alternate-iab-coi-policy/blob/master/coi-pol= icy.md On 08/01/2020 23:14, IAB Chair wrote: > Dear Colleagues, >=20 > The IAB is considering adoption of the conflict of interest policy > below.=C2=A0 If you have comments on this draft policy, please send the= m > toiab@iab.org . >=20 > best regards, >=20 > Ted Hardie > for the IAB >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 INTERNET ARCHITECTURE BOARD CONFLICT OF INTERE= ST POLICY >=20 > This policy covers the nomcom-selected Internet Architecture Board (IAB= ) > members and ex-officio members (collectively, =E2=80=9CCovered Individu= als=E2=80=9D). > This policy has no impact on any other participants in IAB activities, > for instance liaisons to and from the IAB or IAB program members. >=20 > In carrying out their IAB role, Covered Individuals must act in the bes= t > interest of the Internet community. Occasionally this duty may be=E2=80= =94or may > appear to be=E2=80=94incompatible or in conflict with a Covered Individ= ual=E2=80=99s > personal interests (including interests of their family members), or th= e > interests of an organization of which the Covered Individual is an > employee, director, owner, or otherwise has business or financial > interest. If a Covered Individual has a conflict of interest for > whatever reason, that individual must avoid participating in the work o= f > the IAB that touches on the related matter. >=20 > The IAB does not directly deal with matters relating to contracts or > finance. The IAB does, however, have a role in personnel decisions, and= > its decisions and outputs have a potential to indirectly affect > contracts within the IETF system. IAB's technical decisions and outputs= > have also a potential to impact both work elsewhere in the IETF and > businesses that employ or develop Internet technology. >=20 > Covered Individuals shall not use the IAB=E2=80=99s resources or decisi= ons as a > means for personal or third-party gain. >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 Disclosure of Actual or Potential Conflicts >=20 > The IAB requires that all Covered Individuals disclose their main > employment, sponsorship, consulting customer, or other sources of incom= e > when joining the IAB or whenever there are updates. >=20 > In addition, when a topic is discussed at the IAB, the Covered > Individuals are required to promptly disclose if that topic constitutes= > a perceived or potential conflict of interest. Once disclosed, Covered > Individuals may recuse from participation in discussions or decisions a= t > their discretion. >=20 > The specific conflicts that may cause a perceived or potential conflict= > of interest are matters for individual and IAB judgment, but generally > come in the following forms: >=20 > =C2=A0* >=20 > =C2=A0=C2=A0 A personnel decision relates to the Covered Individual, a = colleague > =C2=A0=C2=A0 that the Covered Individual's works closely with, or a fam= ily > =C2=A0=C2=A0 member. For the purposes of this policy, a "person working= closely > =C2=A0=C2=A0 with" is someone working in the same team or project, or a= direct > =C2=A0=C2=A0 manager or employee of the Covered Individual. And "family= " means a > =C2=A0=C2=A0 spouse, domestic partner, child, sibling, parent, stepchil= d, > =C2=A0=C2=A0 stepparent, and mother-, father-, son-, daughter-, brother= -, or > =C2=A0=C2=A0 sister-in-law, and any other person living in the same hou= sehold, > =C2=A0=C2=A0 except tenants and household employees. >=20 > =C2=A0* >=20 > =C2=A0=C2=A0 A decision or output from the IAB impacts a contract that = the IETF > =C2=A0=C2=A0 enters into with a party, and that party relates to the Co= vered > =C2=A0=C2=A0 Individual, a colleague that the Covered Individual's work= s closely > =C2=A0=C2=A0 with, or a family member. >=20 > =C2=A0* >=20 > =C2=A0=C2=A0 Activity on the IAB involves discussion and decisions rega= rding > =C2=A0=C2=A0 technical matters, mainly related to IETF activities. As a= n activity > =C2=A0=C2=A0 adjacent to a standardization process, it is often the cas= e that > =C2=A0=C2=A0 Covered Individuals will have some (frequently non-financi= al) stake > =C2=A0=C2=A0 in the outcome of discussions or decisions that relate to = technical > =C2=A0=C2=A0 matters. This policy does not require that Covered Individ= uals > =C2=A0=C2=A0 disclose such conflicts of interest as they relate to tech= nical > =C2=A0=C2=A0 matters. However, Covered Individuals need to exercise the= ir > =C2=A0=C2=A0 judgment and, in extraordinary cases be willing to disclos= e > =C2=A0=C2=A0 potential or perceived conflicts of interest even as they = relate to > =C2=A0=C2=A0 technical matters. For example, if a Covered Individual's = sponsor > =C2=A0=C2=A0 were in the process of entering a new market where there i= s an > =C2=A0=C2=A0 ongoing IAB discussion, then disclosure, or even recusal, = might be > =C2=A0=C2=A0 appropriate, even if difficult. >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 Disclosure Transparency >=20 > A person's recusal to participate in the discussion of a topic is alway= s > noted in the public IAB minutes. In addition, the IAB will maintain a > repository of all general disclosures of employment and other > sponsorship. It is expected that much of this repository is public, but= > there can be situations where some disclosures (such as customers of > consultants) are private. >=20 >=20 >=20 > =C2=A0 >=20 >=20 >=20 >=20 --------------01B0991A504123AE170DEA38 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------01B0991A504123AE170DEA38-- --BCkoJBa5askY94jk21CMv450JjTXEzZjF-- --OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4XUSEACgkQWrL68XsX K+oT7BAAnkOXHTc3bzqg8d8h5mhCj7xQXxBDU+/6rAFq3t9Ppt7KABsi7jI3EKQd ZoAjg05kxRCKl0lhXuG7GHSIWGKJYuVfjNKNv2tt8iL9U63URdmNWz3yd4wyC/Mm WZEZUbufp2Mv37MuQxffP2D2ywRRM3oTvMFFhYfvgfnkxcusffW2Ww4GroRoe7kN LDHTtokWz34MpBu12oS85EMJIdcF0NALuJaGRknZA+Z6AIojHQ53eVeUXls2n2io b603bRWQI7Edq0apuf+LFPQjG58Mfq2y/DN02tEICOJL6WwsUsT6BwWCyo/9gVtp SoFld0hZcj6nPSnBA2sO5OziTGfxnllGOU/+QCMZ+oIhTkAYfuHze5prOX+TDYmp +1mXa9VvyY90cLMN9L9CuIG/bFXaAFCe5Vpo9TdoXEyrqyiYv1p6C5bqeQsuS2UL phwRRtnOCldZYZDQbv8xNFqt6icce4xk8P8FWX7d7gmbMIL+33RlnTEVE0FDElDV VAUdJcBpwQj9AYGqClIi1o5wYBUcZJC1Oo2BCGxdE5KIFUy7BHt6Bwg1umCRAF/N DwQ5/BI0Mc1vOVML1vm3nWT4jlZo/aPyIIXScOr8SGxaN7BZzmBHhxCRjaGS/3M9 ja/Zd3t7ZZsxtPRCfF8ozZe9r0Ko3HZyEnCn99HK0D1WHk6nLGA= =dLkh -----END PGP SIGNATURE----- --OwwVpwsyWy4ztjNFtYVMbf6ITe9hlnVZV-- From nobody Thu Jan 9 08:57:58 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FB31200F6 for ; Thu, 9 Jan 2020 08:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 RKnuT4Ll8oGD for ; Thu, 9 Jan 2020 08:57:46 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 323B11200B5 for ; Thu, 9 Jan 2020 08:57:46 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id 5so6443421qtz.1 for ; Thu, 09 Jan 2020 08:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D1/8cfNa3Egi7p+5LKcPs+HsBMhtja7eTewZ/niP68M=; b=Ms3yO9Xlkau3Mys2C1b7Lg3FLJkCbJHU0M6jxvnjtUPw2kcTqR1Nz9ajsiYRvKdvwV X5IM84efeIJEdfoFkWezUm//jMqBcB7K5RAa2UD92XPUb8R0Dkp0cUschz+OArDxVQAs HDOkcCkQ8wHzZ5rHjrZ1WcUASXCyAf6prubTMzuMOmDxQDdd5AJFiREijDGpIOkRJDcB yLdvD/301EV1rW4UTDE6EBGpx/pO0IlY/423kj5QFCagYVH56iGJH7N4WiyurOUGQfKC mPG8oxW5geOkTaGkLC3Wkh+81KCfqun2xCIknPXOE0Eehfa183pIL+WwR/PcZrx1h+gW Ki/w== 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=D1/8cfNa3Egi7p+5LKcPs+HsBMhtja7eTewZ/niP68M=; b=Vwm9M+hMhwlHB29sQM+KLkhK1xZCLvuuSEei6pY3NvqjJkHoOVDfLP2QCXs2ErPV3h qe9+nICob9B72pzI9KvufJX8QbQqbqh+wyaSZe+IJF8POsQhV292Ga9lHM2y4xVGyAr2 62L0rQxgkBUho9tVDalZA8s9cxw2SmhKKvWg+aeZRMRveS0fC0K8iLCEJAo3vuHMjvaQ RSbpFvh2zcoCCvMPT2WsOOXpcHawarckugjlK1DrOLSkht06gnnBn++xLKr+W94QWM18 lXxbNiSTnRwB4XAyphMs+x846uXgBWLROHT7cweh7bzHhkrHnTT+g60AyoB2POGL3GuE RhSA== X-Gm-Message-State: APjAAAUEIedPl817cIGEknVcA8ukctY0elItEw/6adjHRpn0GLlIKbHM lIGqlJYHxbYG0nVlB+1cx8I38eiXl88R//saX02zww== X-Google-Smtp-Source: APXvYqy7tsI6lfDtKMlqSzl0SQXYpjK2Z6bJbHczdRT2k9bFDYi4/K5K/ySIJe+4NmE+wDhAEzwCo+dh5nWYevtHHdE= X-Received: by 2002:ac8:47c1:: with SMTP id d1mr8520563qtr.84.1578589065163; Thu, 09 Jan 2020 08:57:45 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> From: Richard Barnes Date: Thu, 9 Jan 2020 11:57:33 -0500 Message-ID: Subject: Re: Draft IAB conflict of interest policy To: IAB Chair Cc: IETF discussion list , architecture-discuss@ietf.org, IAB IAB Content-Type: multipart/alternative; boundary="00000000000079dab8059bb7e8ad" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 16:57:50 -0000 --00000000000079dab8059bb7e8ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would propose the IAB not adopt this policy, or at least scope it way down. Much of the IAB's work is focused on technical issues, at a high enough strategic level that the impacts to specific people or companies are highly attenuated. In those discussions, the IAB's work benefits from having diverse opinions, including the opinions of those who have skin in the game. Trying to introduce some notion of CoI in this context would be harmful -- because there's no hard conflict, it will inevitably be vague, and thus primarily a tool for IAB members to try to silence one another or a cause for IAB members to self-censor. Where the IAB is directly involved in finance or personnel decisions, there of course should be guards against self dealing. That's where any CoI policy for the IAB should stop. --Richard On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: > Dear Colleagues, > > The IAB is considering adoption of the conflict of interest policy below. > If you have comments on this draft policy, please send them to iab@iab.or= g > . > > best regards, > Ted Hardie > for the IAB > > > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY > > This policy covers the nomcom-selected Internet Architecture Board (IAB) > members and ex-officio members (collectively, =E2=80=9CCovered Individual= s=E2=80=9D). This > policy has no impact on any other participants in IAB activities, for > instance liaisons to and from the IAB or IAB program members. > > In carrying out their IAB role, Covered Individuals must act in the best > interest of the Internet community. Occasionally this duty may be=E2=80= =94or may > appear to be=E2=80=94incompatible or in conflict with a Covered Individua= l=E2=80=99s > personal interests (including interests of their family members), or the > interests of an organization of which the Covered Individual is an > employee, director, owner, or otherwise has business or financial interes= t. > If a Covered Individual has a conflict of interest for whatever reason, > that individual must avoid participating in the work of the IAB that > touches on the related matter. > > The IAB does not directly deal with matters relating to contracts or > finance. The IAB does, however, have a role in personnel decisions, and i= ts > decisions and outputs have a potential to indirectly affect contracts > within the IETF system. IAB's technical decisions and outputs have also a > potential to impact both work elsewhere in the IETF and businesses that > employ or develop Internet technology. > > Covered Individuals shall not use the IAB=E2=80=99s resources or decision= s as a > means for personal or third-party gain. > Disclosure of Actual or Potential Conflicts > > The IAB requires that all Covered Individuals disclose their main > employment, sponsorship, consulting customer, or other sources of income > when joining the IAB or whenever there are updates. > > In addition, when a topic is discussed at the IAB, the Covered Individual= s > are required to promptly disclose if that topic constitutes a perceived o= r > potential conflict of interest. Once disclosed, Covered Individuals may > recuse from participation in discussions or decisions at their discretion= . > > The specific conflicts that may cause a perceived or potential conflict o= f > interest are matters for individual and IAB judgment, but generally come = in > the following forms: > > - > > A personnel decision relates to the Covered Individual, a colleague > that the Covered Individual's works closely with, or a family member. = For > the purposes of this policy, a "person working closely with" is someon= e > working in the same team or project, or a direct manager or employee o= f the > Covered Individual. And "family" means a spouse, domestic partner, chi= ld, > sibling, parent, stepchild, stepparent, and mother-, father-, son-, > daughter-, brother-, or sister-in-law, and any other person living in = the > same household, except tenants and household employees. > - > > A decision or output from the IAB impacts a contract that the IETF > enters into with a party, and that party relates to the Covered Indivi= dual, > a colleague that the Covered Individual's works closely with, or a fam= ily > member. > - > > Activity on the IAB involves discussion and decisions regarding > technical matters, mainly related to IETF activities. As an activity > adjacent to a standardization process, it is often the case that Cover= ed > Individuals will have some (frequently non-financial) stake in the out= come > of discussions or decisions that relate to technical matters. This pol= icy > does not require that Covered Individuals disclose such conflicts of > interest as they relate to technical matters. However, Covered Individ= uals > need to exercise their judgment and, in extraordinary cases be willing= to > disclose potential or perceived conflicts of interest even as they rel= ate > to technical matters. For example, if a Covered Individual's sponsor w= ere > in the process of entering a new market where there is an ongoing IAB > discussion, then disclosure, or even recusal, might be appropriate, ev= en if > difficult. > > Disclosure Transparency > > A person's recusal to participate in the discussion of a topic is always > noted in the public IAB minutes. In addition, the IAB will maintain a > repository of all general disclosures of employment and other sponsorship= . > It is expected that much of this repository is public, but there can be > situations where some disclosures (such as customers of consultants) are > private. > > > > > > --00000000000079dab8059bb7e8ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would propose the IAB not adopt this policy, or at = least scope it way down.

Much of the IAB's wor= k is focused on technical issues, at a high enough strategic level that the= impacts to specific people or companies are highly attenuated.=C2=A0 In th= ose discussions, the IAB's work benefits from having diverse opinions, = including the opinions of those who have skin in the game.=C2=A0 Trying to = introduce some notion of CoI in this context would be harmful -- because th= ere's no hard conflict, it will inevitably be vague, and thus primarily= a tool for IAB members to try to silence one another or a cause for IAB me= mbers to self-censor.

Where the IAB is directl= y involved in finance or personnel decisions, there of course should be gua= rds against self dealing.=C2=A0 That's where any CoI policy for the IAB= should stop.

--Richard

On Wed, Jan 8, 20= 20 at 6:16 PM IAB Chair <iab-chair@= iab.org> wrote:
=20 =20 =20

<= /span>Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.=C2=A0 If you have comments on this draft policy, please send them to=C2=A0iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, =E2=80=9CCo= vered Individuals=E2=80=9D). This policy has no impact on any other partici= pants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in co= nflict with a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, o= r a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partn= er, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic i= s always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.



--00000000000079dab8059bb7e8ad-- From nobody Thu Jan 9 09:36:39 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD712001A; Thu, 9 Jan 2020 09:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 QHoGr6nYK3Vp; Thu, 9 Jan 2020 09:36:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B33C120019; Thu, 9 Jan 2020 09:36:30 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009HaPf2056092 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 11:36:26 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578591389; bh=tntLVFRA+GgpAfj61NhBojH71PktnbsLACjVKDN45gA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=mUZ7DeSIzXcQ8oV6bkXh1ftBFVDdEBpYd+a9g7h8Bbt3Nz3gfQ24zOcL5h5yx811m WfEo3C7jm/CBkmRBYuN3PBAtUc00gi/Mhjc+47WRVeBBG7nTRSVbc5KfB+idYe9QFY kAGll7BKvV+o+J6EmzsziG7wNV53DeG3ywpaI6ec= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: Draft IAB conflict of interest policy Date: Thu, 9 Jan 2020 11:36:17 -0600 In-Reply-To: Cc: IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org To: Richard Barnes References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 17:36:33 -0000 --Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642 Content-Type: multipart/alternative; boundary="Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80" --Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I also wondered why CoI on technical matters is any different for IAB = members than for people participating in protocol design in working = groups. That concern is somewhat mitigated by the fact that the third bullet = (discussing technical CoI) only requires the exercise of judgement. But = I hope we expect IAB members to exercise judgement in all aspects of the = role :-) Ben. > On Jan 9, 2020, at 10:57 AM, Richard Barnes wrote: >=20 > I would propose the IAB not adopt this policy, or at least scope it = way down. >=20 > Much of the IAB's work is focused on technical issues, at a high = enough strategic level that the impacts to specific people or companies = are highly attenuated. In those discussions, the IAB's work benefits = from having diverse opinions, including the opinions of those who have = skin in the game. Trying to introduce some notion of CoI in this = context would be harmful -- because there's no hard conflict, it will = inevitably be vague, and thus primarily a tool for IAB members to try to = silence one another or a cause for IAB members to self-censor. >=20 > Where the IAB is directly involved in finance or personnel decisions, = there of course should be guards against self dealing. That's where any = CoI policy for the IAB should stop. >=20 > --Richard >=20 > On Wed, Jan 8, 2020 at 6:16 PM IAB Chair > wrote: > Dear Colleagues, >=20 > The IAB is considering adoption of the conflict of interest policy = below. If you have comments on this draft policy, please send them to = iab@iab.org . >=20 > best regards, >=20 > Ted Hardie > for the IAB >=20 >=20 >=20 > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >=20 > This policy covers the nomcom-selected Internet Architecture Board = (IAB) members and ex-officio members (collectively, =E2=80=9CCovered = Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the = IAB or IAB program members. >=20 > In carrying out their IAB role, Covered Individuals must act in the = best interest of the Internet community. Occasionally this duty may = be=E2=80=94or may appear to be=E2=80=94incompatible or in conflict with = a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which = the Covered Individual is an employee, director, owner, or otherwise has = business or financial interest. If a Covered Individual has a conflict = of interest for whatever reason, that individual must avoid = participating in the work of the IAB that touches on the related matter. >=20 > The IAB does not directly deal with matters relating to contracts or = finance. The IAB does, however, have a role in personnel decisions, and = its decisions and outputs have a potential to indirectly affect = contracts within the IETF system. IAB's technical decisions and outputs = have also a potential to impact both work elsewhere in the IETF and = businesses that employ or develop Internet technology. >=20 > Covered Individuals shall not use the IAB=E2=80=99s resources or = decisions as a means for personal or third-party gain. >=20 > Disclosure of Actual or Potential Conflicts >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >=20 > In addition, when a topic is discussed at the IAB, the Covered = Individuals are required to promptly disclose if that topic constitutes = a perceived or potential conflict of interest. Once disclosed, Covered = Individuals may recuse from participation in discussions or decisions at = their discretion. >=20 > The specific conflicts that may cause a perceived or potential = conflict of interest are matters for individual and IAB judgment, but = generally come in the following forms: >=20 > A personnel decision relates to the Covered Individual, a colleague = that the Covered Individual's works closely with, or a family member. = For the purposes of this policy, a "person working closely with" is = someone working in the same team or project, or a direct manager or = employee of the Covered Individual. And "family" means a spouse, = domestic partner, child, sibling, parent, stepchild, stepparent, and = mother-, father-, son-, daughter-, brother-, or sister-in-law, and any = other person living in the same household, except tenants and household = employees. >=20 > A decision or output from the IAB impacts a contract that the IETF = enters into with a party, and that party relates to the Covered = Individual, a colleague that the Covered Individual's works closely = with, or a family member. >=20 > Activity on the IAB involves discussion and decisions regarding = technical matters, mainly related to IETF activities. As an activity = adjacent to a standardization process, it is often the case that Covered = Individuals will have some (frequently non-financial) stake in the = outcome of discussions or decisions that relate to technical matters. = This policy does not require that Covered Individuals disclose such = conflicts of interest as they relate to technical matters. However, = Covered Individuals need to exercise their judgment and, in = extraordinary cases be willing to disclose potential or perceived = conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of = entering a new market where there is an ongoing IAB discussion, then = disclosure, or even recusal, might be appropriate, even if difficult. >=20 > Disclosure Transparency >=20 > A person's recusal to participate in the discussion of a topic is = always noted in the public IAB minutes. In addition, the IAB will = maintain a repository of all general disclosures of employment and other = sponsorship. It is expected that much of this repository is public, but = there can be situations where some disclosures (such as customers of = consultants) are private. >=20 >=20 > = >=20 --Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = also wondered why CoI on technical matters is any different for IAB = members than for people participating in protocol design in working = groups. 

That = concern is somewhat mitigated by the fact that the third bullet = (discussing technical CoI) only requires the exercise of judgement. But = I hope we expect IAB members to exercise judgement in all aspects of the = role :-)

Ben.


On = Jan 9, 2020, at 10:57 AM, Richard Barnes <rlb@ipv.sx> wrote:

I would propose the IAB not adopt this = policy, or at least scope it way down.

Much of the IAB's work is focused on = technical issues, at a high enough strategic level that the impacts to = specific people or companies are highly attenuated.  In those = discussions, the IAB's work benefits from having diverse opinions, = including the opinions of those who have skin in the game.  Trying = to introduce some notion of CoI in this context would be harmful -- = because there's no hard conflict, it will inevitably be vague, and thus = primarily a tool for IAB members to try to silence one another or a = cause for IAB members to self-censor.

Where the IAB is = directly involved in finance or personnel decisions, there of course = should be guards against self dealing.  That's where any CoI policy = for the IAB should stop.

--Richard

On Wed, Jan = 8, 2020 at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please = send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST = POLICY

This policy covers the nomcom-selected Internet = Architecture Board (IAB) members and ex-officio members (collectively, = =E2=80=9CCovered Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB = role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in = conflict with a Covered Individual=E2=80=99s personal interests (including = interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not = directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals = shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their = main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the = Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The = specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the = Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB = impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves = discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's = recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




= --Apple-Mail=_EF74CBB8-C91D-443B-93A5-44947A227B80-- --Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl4XZJEACgkQgFZKbJXz 1A0TlRAAmZAmBvD5kK3F5BHL8hQZsofipiWzxgcOA35FL2b5d48aOzn7qw6l+T2N ZdNVZ3ma7AkOo900Pgf1knUEsvwoC1y9E5GoO1BvFoBsH2hjNb0ffmVy4YnDm29y GmYxJCQXDgawnhWOflOPx8nm/Cmln6AhcXhpSrE26FmobZFHj/P0xlZJJ+Vv8k01 hOmlauv/eo71B3hJ4+unKaB847ceonE+FsQiVMvSZ7Rmlf6hx8IUKq2ryPnwuK1a GHvtwkB7RUuZ6HNSO3vfYl0aaLgkYCwxlZf6Z3vCsZPL4h7CCd8naqUHnVARrLQJ Pk2ov86g/R9J3bRPMYHVBdpVEtqWp7D0LdWzJiHr6j3JCLCK40zuNTIyuANzrjMR yoN4tHD6mdPy/+CTYOaY5lfon26E6aQgseZ9eLoNC0XfjeSL3U0/h/g7OrkAXm8J XE4y7yGMbRiHiL40WP39ovI9PQpy4jdxbTJ2Bc03poGI/g2kXVOkDWRWjjVN8vSM HqyXj6JrKWpVoEXoVCnyYzm4/zhzyGah13Q5KRXi/W4tJ0k4HOY3uw+jKJ1UVePo N+RYnGZoM3aToO0IwIFpHOU/Bw5NWbW/J6kLUZPFnbIxOEmwiWnCA5pntUr+Vvii gVD2VsHX9qM8ZS1FFrhCnnl3iPuM/WQCG6KZxqBo+7qUUA+AcSY= =48rJ -----END PGP SIGNATURE----- --Apple-Mail=_7791B92E-E578-4D91-BC5A-B20455E83642-- From nobody Thu Jan 9 09:55:45 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC621200FE; Thu, 9 Jan 2020 09:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 7waRihT_YnZw; Thu, 9 Jan 2020 09:55:35 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 654CA120019; Thu, 9 Jan 2020 09:55:35 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009Hsmbw024522; Thu, 9 Jan 2020 17:55:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NHMwRGPyQDxFea6jd/r+XOLwTkE2oO6A1D7lZf2aX0Q=; b=GIjWVaIKM6R03rGJVqfRSSSB3g26fOW3qkEzwTZU/UBLtyhgrsDaurek74J3QgFrlNIC u5LZyR7Ud7z0dGBxnnkRsLfNyoKFC0HL0d9Ol6n7lHoFPtD4PpTpLxvLlXe5F+i4OgDu lg/EJyDq3KHKupxO9nsl6uCk0uvX+Sz78ItTicupSPrIvg1XYIXTSR74dz8rqt5HV+xR 1Xw/4XVc6pBlQh9+Iw7DhHcOsRvp/K2sIhGaseuNKodmmCi5fkx/uSA3QP9iHBhmUbNp utZnTAQPamkbvwBPXa//RuMwIPVqPBKlwA72Aq8TYuDxTOFypVl7ldFAmxM5U8AcEAnM iQ== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2xdbv7nshg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 17:55:34 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 009HlWVm011773; Thu, 9 Jan 2020 09:55:33 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xasjb4h7w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 09:55:33 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 12:55:32 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 9 Jan 2020 12:55:32 -0500 From: "Salz, Rich" To: Stewart Bryant , John C Klensin CC: IAB Chair , "iab@iab.org" , "ietf@ietf.org" , "architecture-discuss@ietf.org" Subject: Re: [arch-d] Draft IAB conflict of interest policy Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfipFqAgAAUtQCAAAVtgP//4IiA Date: Thu, 9 Jan 2020 17:55:31 +0000 Message-ID: <815C4AB0-9BFB-4073-BA49-1A8F90B2F0B1@akamai.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.52] Content-Type: text/plain; charset="utf-8" Content-ID: <91166063EC3B9641A0084EA8A662910A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-09_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=865 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001090146 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_03:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 impostorscore=0 clxscore=1011 mlxscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=838 adultscore=0 suspectscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090146 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 17:55:37 -0000 PiAgICBJIHN1c3BlY3QgdGhhdCB0aGUgIG9ubHkgd2F5IHRvIGVuc3VyZSB0aGF0IHdlIGhhdmUg YSBmdWxseSB0cnVzdHdvcnRoeSBzeXN0ZW0gaXMgdG8gcmVxdWlyZSBvcGVubmVzcyBhbmQgYWNj ZXB0IHRoYXQgdGhlIGNhbmRpZGF0ZSBwb29sIGlzIHJlZHVjZWQuDQogDQpUaGVyZSBtYXkgYmUg b3RoZXIgd2F5cyB0byBhY2hpZXZlIHRoZSBnb2FsLCBidXQgSSBhZ3JlZSB3aXRoIHRyYW5zcGFy ZW5jeSB0cnVtcHMgYWxsIGFzIHRoZSBkZWZhdWx0Lg0KICAgIA0KICAgIA0KICAgIA0KICAgIA0K ICAgID4gDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Thu Jan 9 10:11:59 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A311200CD; Thu, 9 Jan 2020 10:11:53 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=akamai.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 Q4pLmdCYFA6X; Thu, 9 Jan 2020 10:11:51 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 463C812004C; Thu, 9 Jan 2020 10:11:51 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 009I5KAf001010; Thu, 9 Jan 2020 18:11:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=TqElYi6Uzz27AAS1+gSIRKL9Nuvcooh7XLjEXsF7T+s=; b=fXTTfp9D55Ic2Nwj6FhYRp9So5lOCBI6r4wie3Bb/38WzNuPUtDGr0uc57DaTKP1Kvew AF7CfnzcCWHfXLCxzrmi3acuSD7OzUNA3FzCVZZ2W3ca3crRbmW1NSldNzMmqzAXtqVl O2JeEodRe4xl1itg9gRx9ac7lSzIpYyJnkg/9CiBKR7Vc8VRSTUPEpF0n6K92fB8HXJi yRNRd4EYq+KRIsKYrDTSGFWKaqE/bdXodYDkwvbncajf5npGv+d+thL2/WRLhxz02aEF N0Tg15FwZfOs6QTE+VoiuyCU1m3Rwi9FGeTrY1iRV1WNUxhyRtDwk2k2kwdY/yge+QkW Dg== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2xd9fn6wp0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 18:11:50 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 009I2jhT027036; Thu, 9 Jan 2020 10:11:49 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xasjb4mnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 10:11:49 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 13:11:48 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 9 Jan 2020 13:11:47 -0500 From: "Salz, Rich" To: IAB Chair , "ietf@ietf.org" , "architecture-discuss@ietf.org" , "iab@iab.org" Subject: Re: Draft IAB conflict of interest policy Thread-Topic: Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfio4+A Date: Thu, 9 Jan 2020 18:11:47 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.52] Content-Type: multipart/alternative; boundary="_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-09_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=888 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001090149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_03:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 mlxlogscore=864 spamscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090149 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:11:53 -0000 --_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc3N1bWUgdGhpcyB3YXMgcmV2aWV3ZWQgYnkgdGhlIGFwcHJvcHJpYXRlL3JlbGV2YW50IGxl Z2FsIGNvdW5zZWw/DQoNCg0K --_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <605CAE39CE8B4F4191FEBFAD65E99DD8@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MzA0NzU2NDg7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE3NjU1ODMyMDY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhc3N1bWUgdGhp cyB3YXMgcmV2aWV3ZWQgYnkgdGhlIGFwcHJvcHJpYXRlL3JlbGV2YW50IGxlZ2FsIGNvdW5zZWw/ PG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_C7834943A7AD49D2B748E22A1E82A014akamaicom_-- From nobody Thu Jan 9 10:28:26 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8D120111; Thu, 9 Jan 2020 10:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 3DGretRDW9oO; Thu, 9 Jan 2020 10:28:17 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 DD6BB120115; Thu, 9 Jan 2020 10:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=H3YOVYAYa2EwnfDp/tKJrAI83CK+X0d7I1XZse0PLek=; b=Zz+OHH28Bj8W6FJZHpqsxX75Lb Ol0G+7JnTMKNgUBmMbeWduMRARiOV/ZeMGEtSxZBt+9UUYdQBgiDoKrXHV2svDko14MZcKQ+xdnXi RKx9x+3QUz44KJZfG8eFZbyTj4zz1H0fnovv2QGvfHyAgHdjCVPob4m7KO/Ioko9pAlvU0ZyMHsQS jrIP15b7ZPspNejBIbrOqFN7GBirKFv/A1ciq6ajN+PpssipBUFcnsXA7dvt1PH1pv440PXzMXe+3 iNpZTbs/QorT6MtUI0Otv9HJHcbpfvS5aqnPl/N5D1w7mPvdhCQM/pE0IPtoca6wOJnE9S9MAtN8+ NZSPC+Gw==; Received: from [38.64.80.138] (port=62000 helo=[172.21.15.51]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipcXT-003bGO-CA; Thu, 09 Jan 2020 13:28:16 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [arch-d] Draft IAB conflict of interest policy From: Joe Touch In-Reply-To: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> Date: Thu, 9 Jan 2020 10:28:10 -0800 Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Message-Id: References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> To: Ben Campbell X-Mailer: iPhone Mail (17C54) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:28:19 -0000 --Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable They and IESG members are in positions of decision.=20 Others are not.=20 Joe > On Jan 9, 2020, at 9:37 AM, Ben Campbell wrote: >=20 > =EF=BB=BFI also wondered why CoI on technical matters is any different for= IAB members than for people participating in protocol design in working gro= ups.=20 >=20 > That concern is somewhat mitigated by the fact that the third bullet (disc= ussing technical CoI) only requires the exercise of judgement. But I hope we= expect IAB members to exercise judgement in all aspects of the role :-) >=20 > Ben. >=20 >=20 >> On Jan 9, 2020, at 10:57 AM, Richard Barnes wrote: >>=20 >> I would propose the IAB not adopt this policy, or at least scope it way d= own. >>=20 >> Much of the IAB's work is focused on technical issues, at a high enough s= trategic level that the impacts to specific people or companies are highly a= ttenuated. In those discussions, the IAB's work benefits from having divers= e opinions, including the opinions of those who have skin in the game. Tryi= ng to introduce some notion of CoI in this context would be harmful -- becau= se there's no hard conflict, it will inevitably be vague, and thus primarily= a tool for IAB members to try to silence one another or a cause for IAB mem= bers to self-censor. >>=20 >> Where the IAB is directly involved in finance or personnel decisions, the= re of course should be guards against self dealing. That's where any CoI po= licy for the IAB should stop. >>=20 >> --Richard >>=20 >> On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: >>> Dear Colleagues, >>>=20 >>> The IAB is considering adoption of the conflict of interest policy below= . If you have comments on this draft policy, please send them to iab@iab.or= g. >>>=20 >>> best regards, >>>=20 >>> Ted Hardie >>> for the IAB >>>=20 >>>=20 >>>=20 >>> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >>>=20 >>> This policy covers the nomcom-selected Internet Architecture Board (IAB)= members and ex-officio members (collectively, =E2=80=9CCovered Individuals=E2= =80=9D). This policy has no impact on any other participants in IAB activiti= es, for instance liaisons to and from the IAB or IAB program members. >>>=20 >>> In carrying out their IAB role, Covered Individuals must act in the best= interest of the Internet community. Occasionally this duty may be=E2=80=94o= r may appear to be=E2=80=94incompatible or in conflict with a Covered Indivi= dual=E2=80=99s personal interests (including interests of their family membe= rs), or the interests of an organization of which the Covered Individual is a= n employee, director, owner, or otherwise has business or financial interest= . If a Covered Individual has a conflict of interest for whatever reason, th= at individual must avoid participating in the work of the IAB that touches o= n the related matter. >>>=20 >>> The IAB does not directly deal with matters relating to contracts or fin= ance. The IAB does, however, have a role in personnel decisions, and its dec= isions and outputs have a potential to indirectly affect contracts within th= e IETF system. IAB's technical decisions and outputs have also a potential t= o impact both work elsewhere in the IETF and businesses that employ or devel= op Internet technology. >>>=20 >>> Covered Individuals shall not use the IAB=E2=80=99s resources or decisio= ns as a means for personal or third-party gain. >>>=20 >>> Disclosure of Actual or Potential Conflicts >>>=20 >>> The IAB requires that all Covered Individuals disclose their main employ= ment, sponsorship, consulting customer, or other sources of income when join= ing the IAB or whenever there are updates. >>>=20 >>> In addition, when a topic is discussed at the IAB, the Covered Individua= ls are required to promptly disclose if that topic constitutes a perceived o= r potential conflict of interest. Once disclosed, Covered Individuals may re= cuse from participation in discussions or decisions at their discretion. >>>=20 >>> The specific conflicts that may cause a perceived or potential conflict o= f interest are matters for individual and IAB judgment, but generally come i= n the following forms: >>>=20 >>> A personnel decision relates to the Covered Individual, a colleague that= the Covered Individual's works closely with, or a family member. For the pu= rposes of this policy, a "person working closely with" is someone working in= the same team or project, or a direct manager or employee of the Covered In= dividual. And "family" means a spouse, domestic partner, child, sibling, par= ent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-,= or sister-in-law, and any other person living in the same household, except= tenants and household employees. >>>=20 >>> A decision or output from the IAB impacts a contract that the IETF enter= s into with a party, and that party relates to the Covered Individual, a col= league that the Covered Individual's works closely with, or a family member.= >>>=20 >>> Activity on the IAB involves discussion and decisions regarding technica= l matters, mainly related to IETF activities. As an activity adjacent to a s= tandardization process, it is often the case that Covered Individuals will h= ave some (frequently non-financial) stake in the outcome of discussions or d= ecisions that relate to technical matters. This policy does not require that= Covered Individuals disclose such conflicts of interest as they relate to t= echnical matters. However, Covered Individuals need to exercise their judgme= nt and, in extraordinary cases be willing to disclose potential or perceived= conflicts of interest even as they relate to technical matters. For example= , if a Covered Individual's sponsor were in the process of entering a new ma= rket where there is an ongoing IAB discussion, then disclosure, or even recu= sal, might be appropriate, even if difficult. >>>=20 >>> Disclosure Transparency >>>=20 >>> A person's recusal to participate in the discussion of a topic is always= noted in the public IAB minutes. In addition, the IAB will maintain a repos= itory of all general disclosures of employment and other sponsorship. It is e= xpected that much of this repository is public, but there can be situations w= here some disclosures (such as customers of consultants) are private. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
They and IESG members are i= n positions of decision. 

Others are not. 

J= oe

On Jan 9, 2020, at 9:= 37 AM, Ben Campbell <ben@nostrum.com> wrote:

=EF=BB=BFI also wondered why CoI on= technical matters is any different for IAB members than for people particip= ating in protocol design in working groups. 

That concern is somewhat mitigated by the fact that= the third bullet (discussing technical CoI) only requires the exercise of j= udgement. But I hope we expect IAB members to exercise judgement in all aspe= cts of the role :-)

Ben.

On Ja= n 9, 2020, at 10:57 AM, Richard Barnes <rlb@ipv.sx> wrote:

I would propo= se the IAB not adopt this policy, or at least scope it way down.

Much of the IAB's work is foc= used on technical issues, at a high enough strategic level that the impacts t= o specific people or companies are highly attenuated.  In those discuss= ions, the IAB's work benefits from having diverse opinions, including the op= inions of those who have skin in the game.  Trying to introduce some no= tion of CoI in this context would be harmful -- because there's no hard conf= lict, it will inevitably be vague, and thus primarily a tool for IAB members= to try to silence one another or a cause for IAB members to self-censor.

Where= the IAB is directly involved in finance or personnel decisions, there of co= urse should be guards against self dealing.  That's where any CoI polic= y for the IAB should stop.

--Richard

On Wed, Jan 8, 2020 at 6:16= PM IAB Chair <iab-chair@= iab.org> wrote:
=20 =20 =20
<= /font>

Dear Colleagues,

The I= AB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them to iab@iab.org.<= /font>

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architectur= e Board (IAB) members and ex-officio members (collectively, =E2=80=9CCov= ered Individuals=E2=80=9D). This policy has no impact on any other particip= ants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, C= overed Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in con= flict with a Covered Individual=E2=80=99s personal interests (including interests o= f their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not direc= tly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shal= l not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The spe= cific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Cover= ed Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts= a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion a= nd decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recu= sal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




__________________= _____________________________
Architecture-discuss mailing l= ist
Architecture-discuss@ietf.org
https://ww= w.ietf.org/mailman/listinfo/architecture-discuss
= --Apple-Mail-D0D97742-66D3-4C65-9B32-0F19E44DB96E-- From nobody Thu Jan 9 10:47:45 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F2C12011F for ; Thu, 9 Jan 2020 10:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 CQEcmuBQUZY8 for ; Thu, 9 Jan 2020 10:47:36 -0800 (PST) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC361120118 for ; Thu, 9 Jan 2020 10:47:35 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id z22so8398998ljg.1 for ; Thu, 09 Jan 2020 10:47:35 -0800 (PST) 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=3h2LbRbuwpuCqcAwnux4Xdy2qyxCgxfFwPuqvlhNdnU=; b=RXGr0Iw1sz4gX6B9X9MiiS8HeBzFVfLDBVjA8LE2KG4/HZf0PbFmIdXgDTRCsAR1nN W5akOylu/xT8luRwyjVLw3Tp0pcaT4ENSEILp2iMmIKQaaDWykzxtQBaStaGnDS2+ypc FgK3UtRMC6DYvWkaEJuK94/1RE1T0n1hu80X2i2BFcinLI2NjZAeHxe1XR7Y58VkGiNl i+W7XbvYBM546Ollle4HkBTwMRScHNUMFmR4E00K0m7DpfT4NG3RQmm1ZE4ORataPhyC Oox93pjbrgId2fcsfHqkWgTvbVkejA2g2+PBig3rIpl02/wOlJnmoZ674axHi40dwWWg cDBQ== 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=3h2LbRbuwpuCqcAwnux4Xdy2qyxCgxfFwPuqvlhNdnU=; b=HdGRCBPlwlD0INX5uNmROaU3ebG8kuT4yrZGpy+ZrUw8aPYhqdHAPi1ey04dTFlX1B 1JZy9cACnINdvmqK7ApR5ZfGCP8CLoPW8M4xmI9KGHuBMlh3t+8wCUUcwPWOoTThQXfE 3eQNsXN6dXVxp/W2XfwBGiMlrNZ+jo3pz7hSD1qDc24UA72gis4LDACKUO4hr6ZLTqHd QxmXpWJzDoKBtCV4EcEsRX49n6q8z7dVXcszTT4ItUumfOyuRR87hVhENXR3Ux/RPle2 81PS1SwqmC1/VzbyN6bkYbBd2TGtKgt6R8/tUT14QPQbBH9DwOZ6+XTDKXZQTwdTDP2X Bvvg== X-Gm-Message-State: APjAAAVqYxcIjCvA6VZgv2n7LdT/WQaWoSdSfehDMZaW0Jl3cvLMfhB8 1cUbHFeAUQyzbAE0OgOjWpc8JROAuuVWJh0/0I4+rw== X-Google-Smtp-Source: APXvYqxf7j5LS+gwOxVATwTAK/JU1EGzFDDzA/m2XzBgdClA8jZahyQE/q1NQwARCO+I8+7nrfs3OTq3g4wISc51piI= X-Received: by 2002:a05:651c:239:: with SMTP id z25mr7735646ljn.48.1578595653970; Thu, 09 Jan 2020 10:47:33 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: From: Eric Rescorla Date: Thu, 9 Jan 2020 10:46:57 -0800 Message-ID: Subject: Re: [arch-d] Draft IAB conflict of interest policy To: Richard Barnes Cc: IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000330b34059bb9719e" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:47:39 -0000 --000000000000330b34059bb9719e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I concur with Richard here. The IETF is most successful when we get input from people who are directly involved in the technologies that we are standardizing, but of course that very often means that they are working on those technologies for their employer. And indeed one of the criteria we often use to ask whether someone is a good fit for leadership is whether they have this kind of non-standards "day job" expertise. Treating this as the same kind of fianancial or personnel CoI that we properly should discourage seems backwards. -Ekr On Thu, Jan 9, 2020 at 8:58 AM Richard Barnes wrote: > I would propose the IAB not adopt this policy, or at least scope it way > down. > > Much of the IAB's work is focused on technical issues, at a high enough > strategic level that the impacts to specific people or companies are high= ly > attenuated. In those discussions, the IAB's work benefits from having > diverse opinions, including the opinions of those who have skin in the > game. Trying to introduce some notion of CoI in this context would be > harmful -- because there's no hard conflict, it will inevitably be vague, > and thus primarily a tool for IAB members to try to silence one another o= r > a cause for IAB members to self-censor. > > Where the IAB is directly involved in finance or personnel decisions, > there of course should be guards against self dealing. That's where any > CoI policy for the IAB should stop. > > --Richard > > On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: > >> Dear Colleagues, >> >> The IAB is considering adoption of the conflict of interest policy >> below. If you have comments on this draft policy, please send them to >> iab@iab.org. >> >> best regards, >> Ted Hardie >> for the IAB >> >> >> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >> >> This policy covers the nomcom-selected Internet Architecture Board (IAB) >> members and ex-officio members (collectively, =E2=80=9CCovered Individua= ls=E2=80=9D). This >> policy has no impact on any other participants in IAB activities, for >> instance liaisons to and from the IAB or IAB program members. >> >> In carrying out their IAB role, Covered Individuals must act in the best >> interest of the Internet community. Occasionally this duty may be=E2=80= =94or may >> appear to be=E2=80=94incompatible or in conflict with a Covered Individu= al=E2=80=99s >> personal interests (including interests of their family members), or the >> interests of an organization of which the Covered Individual is an >> employee, director, owner, or otherwise has business or financial intere= st. >> If a Covered Individual has a conflict of interest for whatever reason, >> that individual must avoid participating in the work of the IAB that >> touches on the related matter. >> >> The IAB does not directly deal with matters relating to contracts or >> finance. The IAB does, however, have a role in personnel decisions, and = its >> decisions and outputs have a potential to indirectly affect contracts >> within the IETF system. IAB's technical decisions and outputs have also = a >> potential to impact both work elsewhere in the IETF and businesses that >> employ or develop Internet technology. >> >> Covered Individuals shall not use the IAB=E2=80=99s resources or decisio= ns as a >> means for personal or third-party gain. >> Disclosure of Actual or Potential Conflicts >> >> The IAB requires that all Covered Individuals disclose their main >> employment, sponsorship, consulting customer, or other sources of income >> when joining the IAB or whenever there are updates. >> >> In addition, when a topic is discussed at the IAB, the Covered >> Individuals are required to promptly disclose if that topic constitutes = a >> perceived or potential conflict of interest. Once disclosed, Covered >> Individuals may recuse from participation in discussions or decisions at >> their discretion. >> >> The specific conflicts that may cause a perceived or potential conflict >> of interest are matters for individual and IAB judgment, but generally c= ome >> in the following forms: >> >> - >> >> A personnel decision relates to the Covered Individual, a colleague >> that the Covered Individual's works closely with, or a family member.= For >> the purposes of this policy, a "person working closely with" is someo= ne >> working in the same team or project, or a direct manager or employee = of the >> Covered Individual. And "family" means a spouse, domestic partner, ch= ild, >> sibling, parent, stepchild, stepparent, and mother-, father-, son-, >> daughter-, brother-, or sister-in-law, and any other person living in= the >> same household, except tenants and household employees. >> - >> >> A decision or output from the IAB impacts a contract that the IETF >> enters into with a party, and that party relates to the Covered Indiv= idual, >> a colleague that the Covered Individual's works closely with, or a fa= mily >> member. >> - >> >> Activity on the IAB involves discussion and decisions regarding >> technical matters, mainly related to IETF activities. As an activity >> adjacent to a standardization process, it is often the case that Cove= red >> Individuals will have some (frequently non-financial) stake in the ou= tcome >> of discussions or decisions that relate to technical matters. This po= licy >> does not require that Covered Individuals disclose such conflicts of >> interest as they relate to technical matters. However, Covered Indivi= duals >> need to exercise their judgment and, in extraordinary cases be willin= g to >> disclose potential or perceived conflicts of interest even as they re= late >> to technical matters. For example, if a Covered Individual's sponsor = were >> in the process of entering a new market where there is an ongoing IAB >> discussion, then disclosure, or even recusal, might be appropriate, e= ven if >> difficult. >> >> Disclosure Transparency >> >> A person's recusal to participate in the discussion of a topic is always >> noted in the public IAB minutes. In addition, the IAB will maintain a >> repository of all general disclosures of employment and other sponsorshi= p. >> It is expected that much of this repository is public, but there can be >> situations where some disclosures (such as customers of consultants) are >> private. >> >> >> >> >> >> _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000330b34059bb9719e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I concur with Richard here. The IETF is most successful wh= en we get
input from people who are directly involved in the technologie= s that
we are standardizing, but of course that very often means that th= ey
are working on those technologies for their employer. And indeed=
one of the criteria we often use to ask whether someone is a goo= d
fit for leadership is whether they have this kind of non-standa= rds
"day job" expertise.

Treating this as = the same kind of fianancial or personnel CoI that we
properly should dis= courage seems backwards.

-Ekr

On Thu, Jan 9, 2020 at 8:58 AM Rich= ard Barnes <rlb@ipv.sx> wrote:
I would propose the IAB not adop= t this policy, or at least scope it way down.

Much= of the IAB's work is focused on technical issues, at a high enough str= ategic level that the impacts to specific people or companies are highly at= tenuated.=C2=A0 In those discussions, the IAB's work benefits from havi= ng diverse opinions, including the opinions of those who have skin in the g= ame.=C2=A0 Trying to introduce some notion of CoI in this context would be = harmful -- because there's no hard conflict, it will inevitably be vagu= e, and thus primarily a tool for IAB members to try to silence one another = or a cause for IAB members to self-censor.

Whe= re the IAB is directly involved in finance or personnel decisions, there of= course should be guards against self dealing.=C2=A0 That's where any C= oI policy for the IAB should stop.

--Richard

On Wed, Jan 8, 2020 at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

<= /span>Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.=C2=A0 If you have comments on this draft policy, please send them to=C2=A0iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, =E2=80=9CCo= vered Individuals=E2=80=9D). This policy has no impact on any other partici= pants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in co= nflict with a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, o= r a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partn= er, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic i= s always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.



_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000330b34059bb9719e-- From nobody Thu Jan 9 10:48:01 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ACF120168; Thu, 9 Jan 2020 10:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 vPu_3rcTdIuI; Thu, 9 Jan 2020 10:47:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F7812086A; Thu, 9 Jan 2020 10:47:53 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009IlnHu068001 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 12:47:50 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578595672; bh=lfzm02+PJyRufm4hzjGZ3/iLkgwCRfLXNUxyACsfDRQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=UcYSA/wubZXovfIrv8DWfBA9EHSu4XrzeOA325AXrjpiSdTpiAnu/WAxVLgJYi3oN tIDxLN4NsjkRjTDM8/1pyrf15HoKDPlg6qb3yRcskrq6XnNAKsJXlrGJPJazGQ6HqL 1z4k0gYIXgPMdllP04UicpQdq5skwvio5/pV/5jQ= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Thu, 9 Jan 2020 12:47:40 -0600 In-Reply-To: Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org To: Joe Touch References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 18:48:00 -0000 --Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD Content-Type: multipart/alternative; boundary="Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892" --Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with that for the IESG, but the IAB is not usually in a position = to approve or block specific technical decisions. Yes, it sets = architectural direction, but see Richard=E2=80=99s comment down-thread. Ben. > On Jan 9, 2020, at 12:28 PM, Joe Touch wrote: >=20 > They and IESG members are in positions of decision. >=20 > Others are not. >=20 > Joe >=20 >> On Jan 9, 2020, at 9:37 AM, Ben Campbell wrote: >>=20 >> =EF=BB=BFI also wondered why CoI on technical matters is any = different for IAB members than for people participating in protocol = design in working groups. >>=20 >> That concern is somewhat mitigated by the fact that the third bullet = (discussing technical CoI) only requires the exercise of judgement. But = I hope we expect IAB members to exercise judgement in all aspects of the = role :-) >>=20 >> Ben. >>=20 >>=20 >>> On Jan 9, 2020, at 10:57 AM, Richard Barnes > wrote: >>>=20 >>> I would propose the IAB not adopt this policy, or at least scope it = way down. >>>=20 >>> Much of the IAB's work is focused on technical issues, at a high = enough strategic level that the impacts to specific people or companies = are highly attenuated. In those discussions, the IAB's work benefits = from having diverse opinions, including the opinions of those who have = skin in the game. Trying to introduce some notion of CoI in this = context would be harmful -- because there's no hard conflict, it will = inevitably be vague, and thus primarily a tool for IAB members to try to = silence one another or a cause for IAB members to self-censor. >>>=20 >>> Where the IAB is directly involved in finance or personnel = decisions, there of course should be guards against self dealing. = That's where any CoI policy for the IAB should stop. >>>=20 >>> --Richard >>>=20 >>> On Wed, Jan 8, 2020 at 6:16 PM IAB Chair > wrote: >>> Dear Colleagues, >>>=20 >>> The IAB is considering adoption of the conflict of interest policy = below. If you have comments on this draft policy, please send them to = iab@iab.org . >>>=20 >>> best regards, >>>=20 >>> Ted Hardie >>> for the IAB >>>=20 >>>=20 >>>=20 >>> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >>>=20 >>> This policy covers the nomcom-selected Internet Architecture Board = (IAB) members and ex-officio members (collectively, =E2=80=9CCovered = Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the = IAB or IAB program members. >>>=20 >>> In carrying out their IAB role, Covered Individuals must act in the = best interest of the Internet community. Occasionally this duty may = be=E2=80=94or may appear to be=E2=80=94incompatible or in conflict with = a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which = the Covered Individual is an employee, director, owner, or otherwise has = business or financial interest. If a Covered Individual has a conflict = of interest for whatever reason, that individual must avoid = participating in the work of the IAB that touches on the related matter. >>>=20 >>> The IAB does not directly deal with matters relating to contracts or = finance. The IAB does, however, have a role in personnel decisions, and = its decisions and outputs have a potential to indirectly affect = contracts within the IETF system. IAB's technical decisions and outputs = have also a potential to impact both work elsewhere in the IETF and = businesses that employ or develop Internet technology. >>>=20 >>> Covered Individuals shall not use the IAB=E2=80=99s resources or = decisions as a means for personal or third-party gain. >>>=20 >>> Disclosure of Actual or Potential Conflicts >>>=20 >>> The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. >>>=20 >>> In addition, when a topic is discussed at the IAB, the Covered = Individuals are required to promptly disclose if that topic constitutes = a perceived or potential conflict of interest. Once disclosed, Covered = Individuals may recuse from participation in discussions or decisions at = their discretion. >>>=20 >>> The specific conflicts that may cause a perceived or potential = conflict of interest are matters for individual and IAB judgment, but = generally come in the following forms: >>>=20 >>> A personnel decision relates to the Covered Individual, a colleague = that the Covered Individual's works closely with, or a family member. = For the purposes of this policy, a "person working closely with" is = someone working in the same team or project, or a direct manager or = employee of the Covered Individual. And "family" means a spouse, = domestic partner, child, sibling, parent, stepchild, stepparent, and = mother-, father-, son-, daughter-, brother-, or sister-in-law, and any = other person living in the same household, except tenants and household = employees. >>>=20 >>> A decision or output from the IAB impacts a contract that the IETF = enters into with a party, and that party relates to the Covered = Individual, a colleague that the Covered Individual's works closely = with, or a family member. >>>=20 >>> Activity on the IAB involves discussion and decisions regarding = technical matters, mainly related to IETF activities. As an activity = adjacent to a standardization process, it is often the case that Covered = Individuals will have some (frequently non-financial) stake in the = outcome of discussions or decisions that relate to technical matters. = This policy does not require that Covered Individuals disclose such = conflicts of interest as they relate to technical matters. However, = Covered Individuals need to exercise their judgment and, in = extraordinary cases be willing to disclose potential or perceived = conflicts of interest even as they relate to technical matters. For = example, if a Covered Individual's sponsor were in the process of = entering a new market where there is an ongoing IAB discussion, then = disclosure, or even recusal, might be appropriate, even if difficult. >>>=20 >>> Disclosure Transparency >>>=20 >>> A person's recusal to participate in the discussion of a topic is = always noted in the public IAB minutes. In addition, the IAB will = maintain a repository of all general disclosures of employment and other = sponsorship. It is expected that much of this repository is public, but = there can be situations where some disclosures (such as customers of = consultants) are private. >>>=20 >>>=20 >>> = >>>=20 >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with that for the IESG, but the IAB is not usually in a position = to approve or block specific technical decisions. Yes, it sets = architectural direction, but see Richard=E2=80=99s comment = down-thread.

Ben.


On Jan 9, 2020, at 12:28 PM, = Joe Touch <touch@strayalpha.com> wrote:

They = and IESG members are in positions of decision. 

Others are = not. 

Joe

On Jan 9, 2020, at 9:37 = AM, Ben Campbell <ben@nostrum.com> wrote:

=EF=BB=BFI also wondered why = CoI on technical matters is any different for IAB members than for = people participating in protocol design in working groups. 

That concern is somewhat = mitigated by the fact that the third bullet (discussing technical CoI) = only requires the exercise of judgement. But I hope we expect IAB = members to exercise judgement in all aspects of the role :-)

Ben.


On Jan = 9, 2020, at 10:57 AM, Richard Barnes <rlb@ipv.sx> wrote:

I would propose the IAB not adopt this = policy, or at least scope it way down.

Much of the IAB's work is focused on = technical issues, at a high enough strategic level that the impacts to = specific people or companies are highly attenuated.  In those = discussions, the IAB's work benefits from having diverse opinions, = including the opinions of those who have skin in the game.  Trying = to introduce some notion of CoI in this context would be harmful -- = because there's no hard conflict, it will inevitably be vague, and thus = primarily a tool for IAB members to try to silence one another or a = cause for IAB members to self-censor.

Where the IAB is = directly involved in finance or personnel decisions, there of course = should be guards against self dealing.  That's where any CoI policy = for the IAB should stop.

--Richard

On Wed, Jan = 8, 2020 at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please = send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB



INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST = POLICY

This policy covers the nomcom-selected Internet = Architecture Board (IAB) members and ex-officio members (collectively, = =E2=80=9CCovered Individuals=E2=80=9D). This policy has no impact on any other = participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB = role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in = conflict with a Covered Individual=E2=80=99s personal interests (including = interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not = directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals = shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their = main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the = Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The = specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the = Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB = impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves = discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's = recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /span>
= --Apple-Mail=_F31E6990-7C65-4089-B844-E7FC2A6FD892-- --Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl4XdUwACgkQgFZKbJXz 1A2MYQ/9FKq5RO7oha++N0i8RXvs+RQE+sWR0RSI2T+cgGAsHbzZTVovVyC8WMwz VnvPtEPIo8ECPghng+ew0rSyxnoNHDRkBAI3BB2vlFqfXEaodQOhZOYNN/bbaf/H R2IwDV4wezUX+ZfCohp23OhlFXlGunOooFlggdaSXcVs//1JO+7xlzowM577Rk8+ B+6PbFZcT4Yl31fQwGanYUq8gZ4YcWGqiHcYM73z8IzVmNTmJEzxZG5ok5aWobhp vCPIHwZiCmCivgoNF1KmSxwjyPvj5ByDBLqmH9AhztI0KoyY92VQjB7X/LhydpYp diKOSVDTr923yMqDiq1DSbDoNFI4S9UQe8FynwpXB3SgNhHaMkYAYGfotBBF90qF 6UhUS/Qif4AHVTxC6bjBZp9WhDL62MHIPTRj/iliXGkLS8k7bTJvl+2K4MJ5jlP0 xDlrT218FA7UChqKpGl09+DzTMQR2IdOrpgmVeRx+i9WrElqCdt/kW8ul6edcCRq PK22KTJwYZ/jDuBDN8E+R3so3luZXmGKGfwlihfZVWgGAJmkmzbJgpb+MgSUQ6lq pqyDRV7oPJcWJsZQBT8gLbwi08UaTZywx3EjQuXD/ipRxYLr/01u8yDA5e6D0AWY qj1P0Bu6DeHLNAySZqCqtsTSjsaErENNMOFaoASzZIJZHJXhCJw= =62SZ -----END PGP SIGNATURE----- --Apple-Mail=_C9590659-21AB-4409-80F8-E5FBD76B42AD-- From nobody Thu Jan 9 11:49:39 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B322B120047 for ; Thu, 9 Jan 2020 11:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=1WWShTR+; dkim=pass (2048-bit key) header.d=comcast.com header.b=kTZUB32r; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=hzrz3WCw 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 OG6SKYRmX0Cc for ; Thu, 9 Jan 2020 11:49:30 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 96D301207FB for ; Thu, 9 Jan 2020 11:49:30 -0800 (PST) Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009Ja9t2007036 for ; Thu, 9 Jan 2020 14:49:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=CQxV8SudkM6Dl/NFwobAgikHGrh4fb2vWOnfVx8u3Fc=; b=1WWShTR+8s+xhMhTqazY8X+Z+r7zuQVzCXXTzoH2liNHexhS3jmj67HaIALPsU2aySeD zpGQ4i/rw4unwpRQnCPH458/GntFbvmqEckBERIi3rFl1N5yaaaPAZbRI1iQTwXlWzhu LN9CJJ///hmf4XUvhAm7lFOJH35lvrbJKvR296gRx5XwQEBXW8I8V2lzxRRL2BX+azIV o8KOABSJPdLil1qW/lJD0X49BCdGkzAZTgzVen6LX4HSEwjkZsys5CwPFM4DS9IBYSqe NedieUZqnI3fyA4WlwEQ/W658w4BLphaYcF+QrV+ye1A5tkYYCBYUvo0VUgFqzu23+hP dQ== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2xcyjkeydx-17 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 14:49:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578599370; x=2442512970; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CQxV8SudkM6Dl/NFwobAgikHGrh4fb2vWOnfVx8u3Fc=; b=kTZUB32rZTML6tM3Oh362fJ787QcfsY2OSZCBdTh55hoVdowPhLu6FihegCSBMa4 2feWvSiedyBDsk0Gf22MgC7/NAzwCBIlKTI8DGDveLpaAQOv6MUwxlhVjQ4TyT/n YYRXgWo10pUwXP7n0Lf0cSXmRXhi/2+3oUuF9Dz49NNwNjm20mtZeWeYQkqwVEVr vtz92dvv+YhmS8a0NaMbKY7j8xOcaunA3WAGIbD1cI5goDgeBc8AmBqQqkGZDgqp Q6dAOoAznq9QlyMkRTTaBQXQ7NVbvlAr3329gQw1uBYm7Glu1NsQHaC/TClf+sX8 jOJZa+tUU9PJFKYkeMcw3A==; X-AuditID: 60729ed4-237ff7000000bc72-5b-5e1783c947e3 Received: from COPDCEX13.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 5B.37.48242.AC3871E5; Thu, 9 Jan 2020 12:49:30 -0700 (MST) Received: from COPDCEX50.cable.comcast.com (147.191.125.149) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 12:49:29 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX50.cable.comcast.com (147.191.125.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 12:49:29 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 14:49:18 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2211.namprd11.prod.outlook.com (10.174.112.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Thu, 9 Jan 2020 19:49:17 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 19:49:17 +0000 From: "Livingood, Jason" To: Stewart Bryant , John C Klensin CC: IAB Chair , "iab@iab.org" , "ietf@ietf.org" , "architecture-discuss@ietf.org" Subject: Re: [arch-d] Draft IAB conflict of interest policy Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmqPjy+NwtyX0e9LVb75savKafiUIiAgAAUtQCAAAVtgIAAAFAA Date: Thu, 9 Jan 2020 19:49:17 +0000 Message-ID: <5C0D54E4-08E7-4151-8235-D03BAC0546E9@cable.comcast.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <1E62D045-4171-41D6-858A-C277C947AD05@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:cf9:e038:159a:bd7b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: deb9f544-b98c-4137-10e9-08d7953d035f x-ms-traffictypediagnostic: BN6PR1101MB2211: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(396003)(376002)(346002)(189003)(199004)(33656002)(316002)(2616005)(53546011)(54906003)(4326008)(6486002)(6512007)(110136005)(6506007)(4744005)(2906002)(64756008)(66476007)(66556008)(76116006)(91956017)(66446008)(8936002)(186003)(81156014)(5660300002)(478600001)(66946007)(71200400001)(86362001)(81166006)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2211; H:BN6PR1101MB2195.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZtOq0SIul/eoPuL4lWPd2+zNsWKNSQHBaV0nXMR+DfPsBQH2u3VKZTar1Uu0+4J7oSrL+eNLcH3luj99zHzbE6tJlj1yzqQgFKTdx0VjE2Zs5eKEnyYkcG8JqMRRZYNSP7yWX/yb/8HISNLkYbjja2VSwKDt7lkPq+Pb2sk+/hIgY4g37gC9JMpvK1iVc9sOxk1IZsd6haC/eFf+P6Qu7Dbsrrfj26ysQoh/uulXONPKse/xGJKpKC5neh45kGwCmEVXijZXanzpFMhuu7Iv1aCpf/GU4RNHuOM81GROxCpj5yiba8VKG5udhnjLUDnsb33KXVi/94KYxqL5WD5Lafl9HqGGgCSTznq6JPzlCcanlVXYHE/XuzJKBzB+uBPLfz9CnebCVOCD1NCZiJLz6mXu59JGxY9cx/oNpN5KJsVGEbxznMf8aGEc4N1MDY2U x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JawGo13xCZs7owmwZkFyIWeFqBxrnCYhG0aImFl7uQL40f4n5h/vCNkMPSPMGFttT9kIS7XBQpVPvxDaUFrRHm8vI6eS0Gdm2fiWIB/+oAqnAd/w2uKoSOjixAztZIGJVBPirNsPTx6hJzEmOYKYVMOfSDf4/OSd3lx3iwnCW5y+z7JNkuTZme+0ueaxL9ByhF64E4vWmJ8y2J1R6cl6n/6JffLNi4wmsbIRGEerhydvzqenkT23JzbbsUF0T0XTDa1GM0+1x0LcZQpMuiJDKdPYtLhQadgrpHVvUhQnY2oL75qmhDqxS7zJMyjtUmCiY40CkhAMf2Nl41RgotMxAw== 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=izGEaD+HdIOE11JBo+tpQRpQOdNiK3eAG2rNq8rSiGU=; b=QYicx6xP5E894rw9FUznaiZuSw0fdEvksEMGzeAXVX0nZWkrwVtLydAjKKXElMAhAAVpc6K+73hB6Ew1LeJBZChFh+F642AD96oxJVPKJ1XMvU5fKVDLyoYnMVtl649PVzb5xFHR0v490DyoJZLHwxQXR4yVtrUODywRBFUVoQYinPVZ5OB0AbBI3VAJniHAfeoWJaOZwgkzWC5Z6anP7eCcrZK/HVLODuKByiOqvq85G6K5AEIIt/i1KQq4F3iscfdjnNzXqXoGXNPVIQtIS8c1MPPT7mynz+uqZHw674+bJF5x9I7ZWQSAD53MlR0LTMoC2RNQc6bLjMXiomLofg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=izGEaD+HdIOE11JBo+tpQRpQOdNiK3eAG2rNq8rSiGU=; b=hzrz3WCwSKGlEPxkbQ4mjp69FqQIYsHDiKps0kIOuBeECw4CsWQ687TfjTRrfouLlV1ECxAfSImRR+g8hjvAeHvDpMqRJc8kE4iQft6tCP8/lupu+qyALKf7tAtuZfI5Qa8ml2XNtRMTqo7gdPZBMTWvwNILv/92bL8a/9U2N7o= x-ms-exchange-crosstenant-network-message-id: deb9f544-b98c-4137-10e9-08d7953d035f x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 19:49:17.4281 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: ehOPw7qVCL7z/Y3BPVT5YTMjl0AsBMkjvYZCfoM8/WC0FMYWU/YMkxW4QmYJhcaA+kkPU6FiUD6TRrrfXU9xpfX9rX2liOf/SzjJ2E8Qt5E= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2211 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <7E673C845D93C740A559F6C4BCBA274A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22Se0hTURzHOffe3d2Ji9My98Me1KjQKNfMxyoTBav1R1BGEVHqjR2zWmp3 U7IoLDVwEzIsRrNa6iZZWiaVVgZlRbWSairlqwetkUnRg95SbfdaBHn++vx+53O+58HhaFUV G8FtyrEQIYc3adgQJlM4UjnbU6xOn1NSJNM39ZfJ9B3dR1l9zbCP0vvPOhl9qXeY1Xue8cms 4aJjQG7o7R6kDS7XN8rQWT9EL2fWFqFES7ZAeEsqySI5ZpIUMuW/kbiBZOUKZBEvmArTiInw o2tB00hMmwqIoB01RjtqTqaVyj7Re4PO87DbX/dkFqFzrBUpOMCx8LSpTmQVvk7BkFdhRSEB vobAee8KKxV9CAZ8rSPFbQT1bptcKuwUPOxvlEnFcwRvyrvlwTAWx8NAdRcd5DC8Eto/fBcl GrsCknVAlMbhBVDyySuTpERwl/oZiRdD7z0HFWQGT4OW4r1ikBKnwq3KOvrvCT19blFS4IXQ 9P6CGIpwOHzxNIh9Gquh1+ekpKticLXdpyUeD4Mvfoobj8da8Pe0MtJaI9Raa0b8BPj0tnbk mSaB12lDViQP8DJoUUndWWAv/RpYyQU4F+oqVkvtGVDbdZmReCLcdf4Qrw74EAMfmvfJg74K b4Y33UkVKM7xzzkdgRkaR8GZS1qpbYAnlVWMxFPhoO253CG+w1i4c9jHHEeyk2jMvPhonS42 Whenj47RxTQj8cse62pFnXZDO8Ic0oQqK7ap01UyvsBcuLUdAUdrwpQ3H4enq5RGvnAHEXIz hHwTMbejCRyjUSvZhd/Xq/BG3kK2EJJHhD+zFKeIKEINHxMah9ep+7sOjA3zXl9TbLCkDLJp T28dS5AVdH777O9IsU/eRsnOR8791SEsfVBaZp+/c1dS6A9vftSGg4fajNOXcC5FQ9XVxlOh 5XFqtMqyZ8XE+j373ZFpQ0cf2WJibC2vspdzdf7k0y8z4nd7zKu0u1dQrsg035IX71DntGoN Y87mdTNpwcz/BqkTWbmuAwAA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 19:49:33 -0000 T24gMS85LzIwLCA5OjQ5IEFNLCAiaWV0ZiBvbiBiZWhhbGYgb2YgU3Rld2FydCBCcnlhbnQiIDxp ZXRmLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bT4gd3JvdGU6DQoNCg0KPiBBIGNvbXByb21pc2UgbWlnaHQgYmUgdG8gcmVxdWlyZSBjb25maWRl bnRpYWwgZGlzY2xvc3VyZSB0byBzb21lIHRydXN0ZWQgcGFydHkgdGhhdCBtb25pdG9ycyByZWN1 c2FsLCBidXQgdGhlIGV2ZW4gdGhhdCBpcyBwb3RlbnRpYWxseSBzdWJqZWN0IHRvIGFidXNlIHRo cm91Z2ggc29mdCBwb3dlci4NCg0KW0pMXSBUaGUgYXBwcm9hY2ggdGhlIElFVEYgTExDIHRvb2sg d2FzIHRvIGhhdmUgZGlzY2xvc3VyZSB0byB0aGUgYm9hcmQgYW5kIHRoZW4gdGhlIGJvYXJkIGRl Y2lkZXMgd2hldGhlciBhbnkgaW5mbyBzaG91bGQgYmUgcmVkYWN0ZWQgYmVmb3JlIHB1Ymxpc2hp bmcgKGlmIHRoZSBkaXNjbG9zZXIgaGFzIGFza2VkIGZvciBpdCkuIEluIHRoZSBJQUIgZXhhbXBs ZSwgdGhlIHBhcmFsbGVsIHdvdWxkIGJlIGNvbmZpZGVudGlhbCBkaXNjbG9zdXJlIHRvIHRoZSBJ QUIgaXRzZWxmIChyYXRoZXIgdGhhbiB0byBhIDNyZCBwYXJ0eSkuDQoNCg0K From nobody Thu Jan 9 11:53:49 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B23120047 for ; Thu, 9 Jan 2020 11:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=xM4sY4VO; dkim=pass (2048-bit key) header.d=comcast.com header.b=RoVNjRPZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=Hk1U6mvs 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 RbX-KuU4CWhG for ; Thu, 9 Jan 2020 11:53:40 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 DB3B61200B8 for ; Thu, 9 Jan 2020 11:53:39 -0800 (PST) Received: from pps.filterd (m0156896.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009Jgwim007980 for ; Thu, 9 Jan 2020 14:53:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=CYW56m/G07GMdunMPtfJ+wAxK9630IQHQ3YV1C5H1D8=; b=xM4sY4VOms1T/GBUye7nTwS3bCoz7iXxHlanH30bCdOs1H40KhVjjnocRP1E+tV92pE+ CY7NybELFvLHqxnPOPBfLQs4w0gsT/msmzhhyL3Fx9LzDHWFwGm/Z4ciLrkkiQkORd2g cLSBkw5XVSAyjDjxDKjAU8cdbKqjMeEKSKZQtFUWy2qIP5JMSw8XPr8EdjoEdkdh5/ph iHed3vUPgxZZxRP8r5117QfiiL7Ei1bIz1cFDmNdt7pG/845svW+D4mmY4i4kdAoZbgp /nTEmq8CiU/Zoz9vFqAUBjjPGlLnYKJXA6nueGB3eAJvOjTrHQE4swcSjO9+ykay7e4t dg== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0b-00143702.pphosted.com with ESMTP id 2xeajx02ck-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 14:53:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578599617; x=2442513217; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CYW56m/G07GMdunMPtfJ+wAxK9630IQHQ3YV1C5H1D8=; b=RoVNjRPZdr8764PdYg8FSZ2WFZfeaQiMpIp/1ySI/TO416qKGf7N9kMedD3UgAEg vU7c4Q2XGA/Hb2Sv5j2JIsC0MGFObc0QBLy+0JohcYEM9k/yITwHtsq6NeFR5E1D ytK0nZi7eH0cxy8HcCQm7Kzy2OXPlr88OCHE7dqeuxD7NWp1w3axNI2VbulMG4A8 ajuobpiTkzL9zG9fIiSQ93lGRAC9w8JKLRK5wQ8TUMUBLeJHUjnTNnQ8m6ZYHSeA /BRngPv9giXNUbZ+GKgdSInSilHuLA+Jmu4OWOMUfRuWJoruazc1sG0adecTPmhy kD6aYDbYnaI5buCAuWqVig==; X-AuditID: 60729ed4-237ff7000000bc72-5d-5e1784c1c150 Received: from COPDCEX12.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 27.97.48242.1C4871E5; Thu, 9 Jan 2020 12:53:37 -0700 (MST) Received: from COPDCEX19.cable.comcast.com (147.191.124.150) by COPDCEX12.cable.comcast.com (147.191.124.143) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 12:53:37 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX19.cable.comcast.com (147.191.124.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 12:53:37 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.55) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 14:53:27 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2242.namprd11.prod.outlook.com (10.174.116.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Thu, 9 Jan 2020 19:53:26 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 19:53:26 +0000 From: "Livingood, Jason" To: Joe Touch , IAB Chair CC: "iab@iab.org" , "ietf@ietf.org" , "architecture-discuss@ietf.org" Subject: Re: Draft IAB conflict of interest policy Thread-Topic: Draft IAB conflict of interest policy Thread-Index: AQHVxnmqPjy+NwtyX0e9LVb75savKaficR0A///7BwA= Date: Thu, 9 Jan 2020 19:53:26 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> In-Reply-To: <7433C1A1-E071-417C-B7B8-CB4C12E7FEDC@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:cf9:e038:159a:bd7b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a4011d9-75fe-47ca-02ef-08d7953d97cf x-ms-traffictypediagnostic: BN6PR1101MB2242: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(366004)(39860400002)(199004)(189003)(478600001)(33656002)(8936002)(71200400001)(66446008)(91956017)(66556008)(66946007)(76116006)(64756008)(66476007)(186003)(5660300002)(2906002)(2616005)(86362001)(6486002)(6506007)(6512007)(54906003)(110136005)(81166006)(4744005)(316002)(81156014)(4326008)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2242; H:BN6PR1101MB2195.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ek5cQyEyfu4fjC2zR/XZWvCci7FYu9qLX8cPIE0IUoyD/IC7j3i45lXxC9C9ASEEHaPCN8UEaGXLh62+Hri8ROu/34lSOqysFaeyspZy8q2K9cYVZ1v8MK+WArblbsayG8qbcVUUrd5tW/llm/E0r5uISK4mk8vyPRrld1AzptYseYXM1RSl3rkJMjxSM1X/8Bk/nvjaQXg04heYwW70UUKAupWr7um6+djv8MlaYIUqgXKhOuxvihdHpFqBH4HEMe1rD55NNWSF3zIZaRjyY1q9uG+SzN8CLc5Z5y1ZVl7pbJM4GKwW56kUbFZO2W7DLnfKBSiAMI7pSaY3E9QXpvSuZrRp4WFhag0hScjpiqjuB/6JCl7J5+XZY4uIFBpMKb4lG9ZhIdwLQx4Tr+1vuicVdmREFbM9pdp4fW0QA+RGXWZwkEdheda+NEVG5vbR x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d6w/rOpDgUxM8f6u9X6DueTAzNL+FKZomDzjScdCDMntnKtcW8V3nyax4Ziq1qRys50lxC/qrE5VI6KhYHG1Pj3m+yNKQHH9M/3nxQvHX/AAfA98QESlWVgkeg7MrCQG/t71vxjiz/xNA+XD46w8DOv72MiqBSqYZNW8E6VFQ3ry6eMAI3ZOtix7ppiWgWlOG+t3IBK5eYJJew2RjY50wIxgyXXMYeo88KXVPhf4YEi/yFg0NOb5mMl8kxiFYs/qXgocEI9Svc5qUXEWfWabSGe7g2eqDCV15R4sAtjVf6ITiOAYOFhSaTmj/2em0olhuMkuLVz1Gs7Pt/nFe+c1qw== 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=UQRXOQp1g70eeZiNuITjeCuBJbCfjM5pts2VDWtc6tU=; b=M5uxlIW6GXTjNqfZiPP+YKnku5DkOkiAWmIx/a9iDc89MlrBPJWQQxOH6AwRBROnays6PBT2Kd0Vtd6Kt1MG6RV6hNGK2PL87TIAgZiMdXNJ/6HDbqqclNcCE7Iynb7SF3UZlPwwM4YSTgJDmofyJg7dTGA3y/5wkhyiM0SdLFc6B39Yqd6n0xebPhg9fogLr+k78iAk2QIxVsy08TJzJhbwiB5fK97EiTB9PU2QlgE5pd7a+P+A/ANQ/k13Orj2Q63QxX953jkWpQ3lPJbq0ueCSm33v2OQ0vKcTbb0bjsOyxMT32cZrguhRJdwy3NGVP2lrnWhYftfcy96TahJ6g== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UQRXOQp1g70eeZiNuITjeCuBJbCfjM5pts2VDWtc6tU=; b=Hk1U6mvsri3S6oto7A9KDGD2k6aEcPA+qU+kRMS96YpFcrak5QmwmeC4TEbQk7F6w7oObWaczgTvWYQvX28VJkuNjRLPi1Ae6DtjzE1izBZmeJleqeYPSa5593FjVWmHiFidTH4XfgG0R4RRjv5ZnWt8oHEOGxweoL3+POQi6X0= x-ms-exchange-crosstenant-network-message-id: 1a4011d9-75fe-47ca-02ef-08d7953d97cf x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 19:53:26.7345 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 5M8nW2PgEYFFiTYicNEZq2s2ipa8FF69n4LpP9bVxlcqz7KzuerprKT3HUgWgbQHX6ihRGQsllRtfrwiZuxSLQ4Z7QwdFnhAq/2qfiYAgQ0= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2242 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <829DEC4C00AA8E409515FFB87A024E3D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22SeUhUURTGu28Zn9LEdVLntEg5SYuYNmo1idli0hAEGf0lZD6ba2qT2huV DDI128aIQnGZFmuUDK3UIDVNSbPMpJTScg9XENukZaykct6bIMj71+/c853v3vtxOVqRLVvI RccmECGW16tkDky4cDlrdUOGMmzN0z5/TXnfWVbzvPOKTGOeHqE0YxUFjKZkYoTZzGp7Osdp bVHRd0rbfbKd3UWHpqKAhCiB8AnbSCSJNZBAh6X/rYAIEhknkGBe0CfvJnrCzy6zKnVEH51E BO9Zbbxn9Qk3UlHVLeUovoY9Yr6TQ6eim6wR2XOA/eDbdAUyIgdOgR9RUHbuEi0VDQimTtXY SUUvgvuFTaxUNCPommikrfMKnENBX3qI1BhEUJoxKBrL8Drov94xI+I4JxwEtQ8drRoan0Bg MZ2ys2rmYx8wtr8R2Qn7Qn3abySxPxQ9mBR9GOwOufeyZFaW422QNvnJdrAA5tYzot4eb4Xe Ww2UlRF2AcuzWyLTWAk9IwWU9FA849lGS+wM48O/RH9n7A1j3dWMNKuDQqPZpl8PXz8UyiR2 hZcFmUjinXD+WpMtPE9Iyx+y7cdBVW26bXY5VL1us/FiaC34KSYHOJOB4R/5lDUUBY6B952B F9Ba0z9XNc10aLwKymq8pW0t5Fy00BK7QXbmoJ1JTMIRWvJHmGuILUHzNqzzUqv9vNRrNV4+ ap+7SPyrVzuq0atcbSPCHFLNlV84rAxTsHySIflQIwKOVjnJH3e5hCnkOj75KBHi9gmJemJo RIs4RqWUyzb+2KvAB/gEcpCQeCL87VKc/cJUtGVJdkjwZ9dR80B2qWfdiqk5k33t7SXbLSjx U9WLYt/JHQP33t7VhbbFT+fojrv1+ChC8z5OZToGMZXKvIzNK317nvTWjpOtt2v6N305Ptx8 J6vi2Lvo4shEv5h0reXGI9Z9KCUlZd7FOvfO/ctKT+fX5bmpK/0jUkYfe+y50bQgoF7FGKJ4 tQctGPg/urfg06cDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 19:53:42 -0000 RnJvbTogaWV0ZiA8aWV0Zi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSm9lIFRvdWNo IDx0b3VjaEBzdHJheWFscGhhLmNvbT4NCg0KPiAxKSBjb21wZW5zYXRpb24gbWF5IGJlIHBlbmRp bmcgb3IgaW4gdGhlIGltbWVkaWF0ZSBmdXR1cmUNCj4gNCkgVGhlIHBvbGljeSBzaG91bGQgaW5k aWNhdGUgYSB0aW1lIGZyYW1lDQoNCltKTF0gVGhlIHdheSB0aGUgSUVURiBMTEMgc29sdmVkIHRo ZXNlIGlzc3VlcyB3YXMgdG8gc2F5IHRoYXQgdGhlIGRpc2Nsb3N1cmVzIHNob3VsZCBiZSBhbm51 YWwgYXQgYSBtaW5pbXVtICYgc2hvdWxkIGJlIHVwZGF0ZWQgYXMgc29tZW9uZSdzIHNpdHVhdGlv biBjaGFuZ2VzLiBTbyBhbiBJQUIgbWVtYmVyIGluIHRoaXMgZXhhbXBsZSBtaWdodCBmaWxlIGEg Q29JIGZvcm0gaW4gSmFudWFyeSBidXQgdGhlbiB0aGV5IGNoYW5nZSBvcmdhbml6YXRpb25zIGlu IEp1bmUsIHNvIHBvc3QgYW4gdXBkYXRlZCBvbmUgYXQgdGhhdCB0aW1lLg0KDQoNCg0KDQo= From nobody Thu Jan 9 12:19:49 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E611207FB; Thu, 9 Jan 2020 12:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.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 YmAPbFHCOA0R; Thu, 9 Jan 2020 12:19:43 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 8B242120047; Thu, 9 Jan 2020 12:19:43 -0800 (PST) Received: from pps.filterd (m0048276.ppops.net [127.0.0.1]) by m0048276.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 009KI1cj021440; Thu, 9 Jan 2020 15:19:43 -0500 Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0048276.ppops.net-00176a04. with ESMTP id 2xamh1wfy1-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Thu, 09 Jan 2020 15:19:43 -0500 Received: from unknown (HELO ashemwp00047.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 09 Jan 2020 12:19:41 -0800 Received: from ashemwp00012.mail.tfayd.com (100.126.24.36) by ashemwp00048.mail.tfayd.com (100.126.24.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 15:19:40 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00012.mail.tfayd.com (100.126.24.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 15:19:39 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 9 Jan 2020 15:19:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WEwqFS1UrJ2Z43eQ6R0NUcIJSS2xZ1Ivp4v0Q6FctoO5F73GcDJKu+wc1T8J0rmUUGT66EkaEnwG9rLDnMsehlBo2Dymp3QHIvUab8s27e+lLStV7nwHFcQR2K+Gnhxl++h8N+Ydd97JNTCCoxYmZoFDlG1L2pv3RlxNcnbF2+f9iDdx/zH2bkMgMJJC5AwHKuLxhJOn4eF7sogpyEIWqAQ28zcuCXDFF3MwiWuy/RIwdIcMsy8NssXkXHdG8IYdG0BiZ4EG+19aAyVo1y++lQ9I0C3xzzprqN52T6ZVTzmiagtPaCdNcJ7eeu6g5OVfOcAENwaB7DrqcuRhjexuDw== 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=2AIwWNIiBjOoTXg/pORE9wZ5pC2clVjIh937XVno5hY=; b=iszzaZNQ+vr5xgocbbI6ASk+/TUWBgVPxdFhp+vyD8Dqbz4Y4J0Qq8IJSGIZ+GbJmnQY1+dqOrCwxCCur+gtN/r5gdEd+oq5qhgCiOYfeqr0Kx+/gjYbaUopfUlWRqegAUrbmD9S4wkxH3mzVFz4dsq7+qQ0DnPaluNt5v9HQHj28yaTOMx9FqZosJfH1lMV6Kx/8BaAJO3DiJx8QTyIL9B2TFMz6N7k2i+drRvNkOXI5GQvfmcgTWQUK0SyuXR1KXsbWs+gFmEVdQeEmjEM51pSI2hwm9FuSGh5lEcCSKqTLOAnTkD4CF8tV29LWu8XLC7OV8L2HrIzndj0fdx/Jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2AIwWNIiBjOoTXg/pORE9wZ5pC2clVjIh937XVno5hY=; b=lLkjWUhMeEW5VmTK2g9fp/6qYD/9K5datUxKOccomHbwIn0xs7vNipnJUh1lAlp6eMdpE9BD/YV7rQsHBaGLTmPajMbw95FpowiGxb1vmHncusSAvvOvLCcJYaw0JCFyoySfUuafgSDjHbY8tA3LxB9Qvdpy3D5Bkb/8f0aHybM= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB2138.namprd14.prod.outlook.com (20.176.89.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 20:19:38 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2623.010; Thu, 9 Jan 2020 20:19:38 +0000 From: "Deen, Glenn (NBCUniversal)" To: "Livingood, Jason" , Ben Campbell , Joe Touch CC: IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" , "Deen, Glenn (NBCUniversal)" Subject: Re: [EXTERNAL] Re: [arch-d] Draft IAB conflict of interest policy Thread-Topic: [EXTERNAL] Re: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxyoembeUp/4Pp02qBY4US3O0UA== Date: Thu, 9 Jan 2020 20:19:38 +0000 Message-ID: <52B13773-88C3-490D-8003-475F845F1ACB@nbcuni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [108.185.101.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 63d4707b-f632-4bc0-c7b0-08d7954140a8 x-ms-traffictypediagnostic: DM6PR14MB2138: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(39860400002)(396003)(346002)(189003)(199004)(71200400001)(107886003)(4326008)(66446008)(8676002)(81156014)(36756003)(966005)(6486002)(6506007)(478600001)(64756008)(2616005)(81166006)(186003)(66556008)(91956017)(316002)(2906002)(33656002)(76116006)(66476007)(86362001)(26005)(66946007)(6512007)(5660300002)(110136005)(54906003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB2138; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yMlThIaN3FICTmA2kVvpjNs3YicjObgcRD/GSQJwzGFnbedsbxO8SaMw8zwjeVbBVjgcGcOX9E4fGPqrOAgtUHYAz8dl1Vfgsk9hT+W7FBNwe8JtLSux5MgnnJESfkntn9LPjYHcklISRsXxT1n+MKYAqXh5usz01B79XkDgUfYfbqU0xRkeD6cAFq0mM3hoimF9o97yUJqTxZ9YCf30vu/MFJapzTZ+aDw8XyjxljBgAXNX7qZZiJPEF4EMswzkpjdXO8fRz6VExl17IkOMRsAkEDpotRD3w67LUDkEVDU4MfMArlIMcGcY66+WVAZXbA8GSeQyz4WO871k+IWa9LLwK3oICN96Gn88V+Ey/8cDjU47hF1JDVsDsLsER9JQ1R9swlypM00GXCstTleq6kceOo5YUbONbvgCid7o/xm49cIxJruFknrKJZ1UtbeFIIJgu+rRWWcNSmsqVS3n7+FjVHBgesADkxYU9qrvHpnVkUXUTLi9SIrBQho3/UDvEORa5S/f914euJbxN/rNEw== Content-Type: text/plain; charset="utf-8" Content-ID: <5256406D18E5F04F88209FE4E3CF51E7@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 63d4707b-f632-4bc0-c7b0-08d7954140a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 20:19:38.5295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BPwjPrHo1OFG1ToX8mJHTYvcijiUhLjMH2soGFGSy2hVBe2BbRBM5QaBqOWTGdnun/DLMETpEmg/f/KXzCZSKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB2138 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 spamscore=0 bulkscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 phishscore=0 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090166 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:19:48 -0000 DQoNCu+7v09uIDEvOS8yMCwgMTI6MDggUE0sICJBcmNoaXRlY3R1cmUtZGlzY3VzcyBvbiBiZWhh bGYgb2YgTGl2aW5nb29kLCBKYXNvbiIgPGFyY2hpdGVjdHVyZS1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIEphc29uX0xpdmluZ29vZEBjb21jYXN0LmNvbT4gd3JvdGU6DQoN CiAgICBGcm9tOiBpZXRmIDxpZXRmLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBCZW4g Q2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4NCiAgICA+IEkgYWdyZWUgd2l0aCB0aGF0IGZvciB0 aGUgSUVTRywgYnV0IHRoZSBJQUIgaXMgbm90IHVzdWFsbHkgaW4gYSBwb3NpdGlvbiB0byBhcHBy b3ZlIG9yIGJsb2NrIHNwZWNpZmljIHRlY2huaWNhbCBkZWNpc2lvbnMuIFllcywgaXQgc2V0cyBh cmNoaXRlY3R1cmFsIGRpcmVjdGlvbiwgYnV0IHNlZSBSaWNoYXJk4oCZcyBjb21tZW50IGRvd24t dGhyZWFkLg0KICAgIA0KICAgIFtKTF0gUGVyaGFwcyB3ZSBhcmUgdGhpbmtpbmcgdG9vIG5hcnJv d2x5IGFib3V0IHdoYXQgdGhlIElBQiBkb2VzPyBIZXJlIGFyZSBzb21lIGFyZWFzIGZvciBwb3Rl bnRpYWwgY29uZmxpY3QgdGhhdCBhcmUgdW5yZWxhdGVkIHRvIGFyY2hpdGVjdHVyYWwgZGlyZWN0 aW9uOg0KICAgIDEgLSBDb25maXJtaW5nIHRoZSBJRVRGIENoYWlyIGFuZCBBcmVhIERpcmVjdG9y cw0KICAgIDIgLSBTdGFuZGFyZHMgYXBwZWFscw0KICAgIDMgLSBSRkMgU2VyaWVzDQogICAgNCAt IExpYWlzb24gcm9sZXMNCiAgICA1IC0gQWR2aWNlIHRvIElTT0MNCg0KW0dEXSArIDYgLSBBcHBv aW50IGFuIElTT0MgVHJ1c3RlZSANCiAgICANCiAgICBbSkxdIEV2ZW4gaW4gYXJjaGl0ZWN0dXJh bCBvdmVyc2lnaHQsIHdoYXQgaWYgdGhlcmUgd2FzIGEgc3Ryb25nIHB1c2ggZm9yIGEgcGFydGlj dWxhciBhcHByb2FjaCBhZ2FpbnN0IGEgcGFydGljdWxhciBwcm90b2NvbCBvciBjb2RlYyBhbmQg c29tZW9uZSBvbiB0aGUgSUFCIGhhZCBhbiB1bmRpc2Nsb3NlZCBmaW5hbmNpYWwgc3Rha2UgaW4g YSBwYXRlbnQgcG9vbCB0aGF0IHdvdWxkIGRpcmVjdGx5IGJlbmVmaXQgZnJvbSBhIGNlcnRhaW4g ZGVjaXNpb24/IE9yIGlmIHRoZXkgIndvcmtlZCIgZm9yIGEgdW5pdmVyc2l0eSBidXQgd2VyZSAx MDAlIGZ1bmRlZCBieSBhIGdyYW50IGZyb20gYSBnb3Zlcm5tZW50IHRoYXQgd2FzIHVuZGVyd3Jp dGluZyB0aGVpciB0aW1lIHNwZWNpZmljYWxseSB0byB3b3JrIGFnYWluc3QgYSBzcGVjaWZpYyB1 cGdyYWRlIHRvIGVuY3J5cHRpb24/IE9yIHdoYXRldmVyIG90aGVyIGNhc2VzIHlvdSBtaWdodCBp bWFnaW5lLg0KICAgIA0KICAgIFtKTF0gU28gSU1PIGl0IHNlZW1zIGxpa2Ugc29tZSBDb0kgcG9s aWN5IGZvciB0aGUgSUFCIGlzIGJldHRlciB0aGFuIG5vIENvSSBwb2xpY3kuDQogICAgDQogICAg DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBBcmNoaXRlY3R1cmUtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCiAgICBBcmNoaXRlY3R1cmUtZGlz Y3Vzc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FyY2hpdGVjdHVyZS1kaXNjdXNzX187ISFQSVpl ZVc1d3NjeW5SUSE4TzJpQ3pnZVNsSTViQVBhb0xnby04MEs4SUdYYXA4c0lEenlNeWZIY3lUYVZq eE1HX3pVeFZEWExxajNOaWQxJCANCiAgICANCg0K From nobody Thu Jan 9 12:21:07 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92701202A0; Thu, 9 Jan 2020 12:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 5rL2k6dgv6hp; Thu, 9 Jan 2020 12:21:04 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6A91207FB; Thu, 9 Jan 2020 12:21:04 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009KKxBS083665 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 14:21:00 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578601261; bh=AYngZb7tiZbxHzxKuE5CNWyrK8ezrccy59R5HlsI2RU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=fs1xqOuufkcefuDNk7cx+4Ct0X3YhuhNG1P/N8/S30qsDn5BBkZ3tUycpLi1DYnK9 cenmR4EAPis0gRLilsfzRPoW9dc5YNoXTjlUB7SSBol++52p+DDb4vMo8KVLEWY40I xVz/X+J5Hi++T5XzN8ei0zgg43jh9qvDYoNi1JUU= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: <87973F7E-A12D-4DEC-A490-475B7C3BFF34@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Thu, 9 Jan 2020 14:20:50 -0600 In-Reply-To: <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> Cc: Joe Touch , IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" To: "Livingood, Jason" References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:21:06 -0000 --Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 9, 2020, at 2:07 PM, Livingood, Jason = wrote: >=20 > From: ietf on behalf of Ben Campbell = >> I agree with that for the IESG, but the IAB is not usually in a = position to approve or block specific technical decisions. Yes, it sets = architectural direction, but see Richard=E2=80=99s comment down-thread. >=20 > [JL] Perhaps we are thinking too narrowly about what the IAB does? = Here are some areas for potential conflict that are unrelated to = architectural direction: > 1 - Confirming the IETF Chair and Area Directors > 2 - Standards appeals > 3 - RFC Series > 4 - Liaison roles > 5 - Advice to ISOC I think a good part of those categories are covered by the sections on = personnel and contract CoIs. I agree with those sections in principle. >=20 > [JL] Even in architectural oversight, what if there was a strong push = for a particular approach against a particular protocol or codec and = someone on the IAB had an undisclosed financial stake in a patent pool = that would directly benefit from a certain decision? Or if they "worked" = for a university but were 100% funded by a grant from a government that = was underwriting their time specifically to work against a specific = upgrade to encryption? Or whatever other cases you might imagine. I think the IPR pool example is already covered by the IETF IPR = policies. I assume those will continue to apply. (And I suppose a = reminder of them in any such CoI policy would not be a bad thing.) In the govt grant example: Is the issue not also true for someone = pushing similar views in, say, the TLS wg? It seems to me that an effort = to undermine a specific upgrade would be done more effectively at the wg = level than in the IAB. That all being said, I=E2=80=99m almost okay with the proposed text that = effectively says =E2=80=9CIAB members should use their judgement to = decide if they have a problem=E2=80=9D, but that doesn=E2=80=99t seem to = need to be said in a written policy (unless it=E2=80=99s purpose is to = explain why we don=E2=80=99t say more.) >=20 > [JL] So IMO it seems like some CoI policy for the IAB is better than = no CoI policy. >=20 I am not arguing for no policy. I agree in principle with the other two = bullets. Ben. --Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAl4XiyIACgkQgFZKbJXz 1A2kfBAAojoUZBIe3uumuaVWtONX2NkoTVDxNSxOfEV7jvHl1E4lJqTSUBx/iN0V JpW3QEVvI+DBh7iaBeMExCiIfMQZyJmHd0zMzU2xS5cj6U17Ufjz93vV5LHTIpbl KFLHweWB7DdZKw7kbehsHq05WQ4svmetF4KCU0xCcp8gVsv4g09B0CAG912OtF3z /OhOoxiUL+GBBH5Bk9YSvWjkOEeN5eiZeK4bSkJgV+e8mAhJgjGHSaLYU/bKsPqz RpnKTBUMq+dTctx3Qm2TtI1JxdRoiRvgwHnIKT9A0VQFUl8XE1b0uvUrytrmerGS NV0Lf2Rd5X1CkW1+HDC+HlrgpaeaQzVt5NiH681v9JhCXPd/k217677qq0S4YhBz YulOpkBhO/O7uK0mv5Y+nwewp5g0UxYx6f49Bpod8Ca0uxp/dJNtJwthemAku8/X XN//5iEimtTgEdC+74ecLyvgrwQNnEgFyvYfZGa6yDPzSWyl08PUpWmmAICglWv6 HnGP5F9Sof4xbsuInG7rZdpGqxDwgVB0kXICnOF1pl8HK2m/yCEikhEzLZCJAsyv yg25xxo9NDUJs9zpQIhX3HbB07q5RzHHONbElFOOe/pMmgaoZ+EEwbYo6rrG+roZ wGCf8vC6Kl1SX+3LTwKn0QN4cNuucNlaffKt0tG5AfLvukUCA0o= =nEa6 -----END PGP SIGNATURE----- --Apple-Mail=_287540C7-2546-498F-9E77-720FC12B4308-- From nobody Thu Jan 9 13:00:53 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213312013B; Thu, 9 Jan 2020 13:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA-Mm_CE0SMH; Thu, 9 Jan 2020 13:00:49 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id B6BAB120288; Thu, 9 Jan 2020 13:00:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 03FD5299945B; Thu, 9 Jan 2020 16:00:47 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhVFViIoN9bd; Thu, 9 Jan 2020 16:00:40 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 49750299944A; Thu, 9 Jan 2020 16:00:39 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [arch-d] Draft IAB conflict of interest policy From: "Scott O. Bradner" In-Reply-To: <87973F7E-A12D-4DEC-A490-475B7C3BFF34@nostrum.com> Date: Thu, 9 Jan 2020 16:00:38 -0500 Cc: Jason Livingood , IAB Chair , IETF discussion list , IAB IAB , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2B5FED59-A77B-405F-9895-FDA920623D7B@sobco.com> References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> <87973F7E-A12D-4DEC-A490-475B7C3BFF34@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:00:51 -0000 > On Jan 9, 2020, at 3:20 PM, Ben Campbell wrote: >=20 =20 > I think the IPR pool example is already covered by the IETF IPR = policies. I assume those will continue to apply. (And I suppose a = reminder of them in any such CoI policy would not be a bad thing.) a big question in the BOFs developing what is now RFC 8179 was =E2=80=98wh= o is a Participant=E2=80=9D and one sub issue in that topic involved participation by means of role - see RFC 8179 Section 1.m = - consensus in the BOF & mailing list was that WG Chairs & ADs were participants in a working group even if = they never posted to the mailing list or spoke in a meeting because of their role - the result being that they = were required to disclose any IPR they knew about that related to the WG work items there was no discussion participating by role for IAB members so having = something in an IAB CoI policy that=20 says, one way or the other, what IPR disclosure obligations arise from = the role of an IAB member - it might be as=20 simple as saying =E2=80=9CIAB members are treated as normal IETF = participants when it comes to their IPR disclosure=20 obligations under BCP 79.=E2=80=9D or saying =E2=80=9CIAB members are = categorized as participants in all IETF working groups=20 when it comes to their IPR disclosure obligations under BCP 79=E2=80=9D but I suggest saying something so as to not leave the question open for = review by plaintiffs lawyers in the future. Scott From nobody Thu Jan 9 13:01:12 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B57712088F for ; Thu, 9 Jan 2020 13:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=PEEK5BJ3; dkim=pass (2048-bit key) header.d=comcast.com header.b=0nybhGXW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=EO5TeXSp 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 82o1lI-I0mIw for ; Thu, 9 Jan 2020 13:01:03 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 05B8212084C for ; Thu, 9 Jan 2020 13:01:02 -0800 (PST) Received: from pps.filterd (m0156892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009K1EqC010916 for ; Thu, 9 Jan 2020 15:07:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=wgaC909p/eAzK2qiA8YSjPc3BIFklm+MG+3MbQmUOk0=; b=PEEK5BJ3wWrfdM/AoJUIX0UmxXRgQxzeSdeloMqqJVLvbpnwrvj4q0vKXirpT7gyicCC +YMFhE8F7pJHydId4lvfqWVp+spo3i+lueXWKF3n7P+O+z19WHbDvZUzgXUXt0ED1ygf fLeT8/lpz+Wrm0SCQrkF3hJU3fvyjDJyFZ1Euv9cYNJ2ouzRwXzsnlNK1/8firJ8KYaO tuJPeWjJguw2vMePofBkAQBmDhS7HU61JjdJpkHH+xHIcpkC4KrsF5KD0pg+o2yf0eru GoQ7880N8ZpKefLZzzvh0laQTAA3oGUpm7exv+F9D912pE1jOYaAPciuMHGlYz/zosah 5Q== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2xe54wjsh6-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 15:07:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578600468; x=2442514068; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wgaC909p/eAzK2qiA8YSjPc3BIFklm+MG+3MbQmUOk0=; b=0nybhGXWjfzckn90vQyNLUf+2UVsxmvZ0IVPocpsRYlhu+Pn865Qi627kjAyx8hS 05HTMCeDUzllkcqs0yvZHyiec4JL08/COI+nIEdupqYrS7GNTj5Ro9OgtafKKHOx 7MX/y+N6eGPKuBQZ/YT6zBmL1u50F97q9pMmwwp6YJNzg+cx2sTnm6VX3IVxASNf k9bqj4GHsh2Io0N80cv5Eqz1iOxDYi4WjHUC3Ndl+Lh2QsKisp2BxCGQ0BKzPskC xFgTuJzOWBiIOGF9kQul8RLwX33TNWaGETF0rtLbrLzLpLYEeY3IPDWPKtFf/1Ad 6IX6kdxXDaQoDuXstd9m0Q==; X-AuditID: 60729ed4-24fff7000000bc72-fc-5e17881405db Received: from COPDCEX12.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id A8.19.48242.418871E5; Thu, 9 Jan 2020 13:07:48 -0700 (MST) Received: from COPDCEX13.cable.comcast.com (147.191.124.144) by COPDCEX12.cable.comcast.com (147.191.124.143) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 13:07:47 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 13:07:47 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.53) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 15:07:32 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2209.namprd11.prod.outlook.com (10.174.112.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Thu, 9 Jan 2020 20:07:32 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 20:07:31 +0000 From: "Livingood, Jason" To: Ben Campbell , Joe Touch CC: IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" Subject: Re: [arch-d] Draft IAB conflict of interest policy Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmqPjy+NwtyX0e9LVb75savKafijtKAgAAK0oCAAA5/AIAABXMA///CfAA= Date: Thu, 9 Jan 2020 20:07:31 +0000 Message-ID: <73739D2E-EE15-4D49-8E99-0BAA79838548@cable.comcast.com> References: <32C49B6D-8F72-4B6C-B23C-E5E22ACAA198@nostrum.com> <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> In-Reply-To: <79623A46-F585-4DD1-B4CA-C12967E7EE1B@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:155f:33bf:4c1a:6884] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 00c82093-9a97-4a62-888d-08d7953f8f86 x-ms-traffictypediagnostic: BN6PR1101MB2209: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(376002)(396003)(136003)(189003)(199004)(33656002)(86362001)(2906002)(66946007)(66446008)(66476007)(66556008)(64756008)(186003)(76116006)(91956017)(2616005)(4326008)(6506007)(71200400001)(316002)(478600001)(110136005)(8676002)(81156014)(81166006)(54906003)(8936002)(6486002)(6512007)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2209; H:BN6PR1101MB2195.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bq9sIjfzL9hGAtuqKiAU2l9fQ9qZnkSO1osrnaVaGgIJU4wM5CfWAVV52RW5+m8CDGFvKSYxfJJos1zLpMrtjEnIa6lLf5pBsFcw3ei9dzPV6grombO3uIMkJPqBauZyMSFrrCdkpkGMqiH3imgitOYln4hrpYr9o8r7x0j3ZqWTffvtvUGA/X5UyUxtpQKqlCYX+QT0mnJukHrMS1YFr0cWosg4CPeHhtr5YhxvWhJ1SbmphFRa5h1Y8ytSH0GSn876fcgOD+QeYqc1jNqSTRsoyfjObJX1j4ADsPsd66j+cGs/UegvY6CV7RHfA9duIVfogEjBqxQQMraq+oLBfPyA/tXkbEDEZ+e9V3E0V6Yjw4cfnO/xpcVL0oeJsABtxFz0Rq4B9222/I05gnUpWOOOTrcqbeIh/9xTcO2ysYunWEuh7FbI97HHsfwT0mzN x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=boJakw4JenLmp8QWVjox8wzEO3e54HUH6cd4h7VzdbMwXBradNbw74cqd5yeyXkhAwn9DWJPZExCPoJKqCRnAsYzsib1NlKi8LiXdsDnSvt9/K6bTaZHtVZOHhD683Ulefz6c1sjn/1HMSFRd3mYP8h4IuTxLMVNlh+PMX1msPJOe9xBJs02XHHp9Mg7OnX8RHIgYfy27yf0CNXgwxv71WOejg7D9pC4UaSa/ySK5st+Fe6v+jBpVwldxtrgVcCchqxJj6fYDKJBh/XCLBWAEx5ZCm6Cr1tMt1yY1/45UR0E6MA/2ToSLl1NwSF4dShKrrriS7KOTVCLXnjZ6SKpBA== 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=u3AXdO1VXACGn7cbLkTTsVzCnv1rYybQt66wvQNdvE0=; b=KF+csxdK8ZK7w51ZffKMIleACTGWr7+M0W/t61+l6V7SSG3qvezR1fDzt6dmtDH08nddbhbERpQAhI0UGq2yWKGIWgdxBL1hr127tIloL26FEfEMA10mSKdGED8Zg0vrACLJOGE9Gx9rO3E7mpb6I4lB/Z3wXgVcUHoZf6R53PAvZpxuABVmavZHrN+AwSIzS4hEU6U2TBLMBeuzYEtKsGxGUEmvB0MN9DPn+nLrdIP6EnxDBI+iLyAbHB87/HZm65mG1r21tFRr2uFywXf+WvKplOIMi4IQZUm9BB6SdtojMrWlUk9CW1LYI0xbbU0Lbca1mXw3/ykyruzMLyPH2Q== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u3AXdO1VXACGn7cbLkTTsVzCnv1rYybQt66wvQNdvE0=; b=EO5TeXSpen8vjodF+pkmIMNPt1h0gzGlxZmeH9tdnc4gfI9g8GlrGQ0+8zo3jy0qRCEGJy1qtoXupLn+j8GDqLCY6v3M5JwrNKuRKfj7i7BbfE/xc/oB88L1NACbKo5Zg1R4aa2xW79KwHcE7hOYIiIPevOYbH/HwJhIkmUnWx4= x-ms-exchange-crosstenant-network-message-id: 00c82093-9a97-4a62-888d-08d7953f8f86 x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 20:07:31.7952 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: FoYQA4L7yockBN78vVQpNgKEWBk8v7pffT/h3IXrN54l7Um80U7eGrR64NqHCut8npWXULIKv5ELk2tc3K5sxTEvFzSXjwws9Y7BTpq3Wvs= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2209 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <762EA41C6D4FE04BB767AFEE32806649@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHJsWRmVeSWpSXmKPExsWSUDRnsq5Ih3icwZxWSYsNdzpZLeZ3nma3 OHt1LpvFoj9PmCyebZzPYrHq9RMWBzaPW1dfMnssWfKTyWPWzicsHjdbL7AGsEQ1MNqUZBSl Jpa4pKal5hWn2nEpYACbpNS0/KJU18SinMqg1JzUROzKQCpTUnMyy1KL9LEao4/VnIQupox5 Mw0LNvFUfNx5l62BsYOni5GTQ0LARGLPvE6WLkYuDiGBw0wSm3qfskI4Bxklbnf+YINwbjNK 7F6+kAnCOc4o8WPCOWYIZyqTxLcHjVBlDxklHi++xggymU3ATOLuwivMILaIgIvEvBVH2EGK mAUWM0rcbb/ACpIQFrCWaPl6iRWiyEZiaeszFgjbD2jQB3YQm0VAReLys+NsIDYv0KDVDd+h 7ljNKPFizTqwDZwC9hKHe1+DNTMKiEl8P7WGCcRmFhCXuPVkPhPErwISS/acZ4awRSVePv4H tlhUQF/i2c0dUL0pEou7FkHVW0hMWnKFFcKWlbg0v5sRwvaVONB0iA3C1pFYdPkS1Mx8ieuz 5kHZahI33nRA2TISp+f/hprTxCLxr72qi5ED6IEsibdX7SYwms5CcuksoAyzgKbE+l36EKaH xJ8zhhAVihJTuh+yzwIHhKDEyZlPWBYwsq5i5LM00zM0NNEzNLXQMzI02sQITrXzruxgvDzd 4xCjAAejEg/vhELxOCHWxLLiytxDjBIczEoivEdviMUJ8aYkVlalFuXHF5XmpBYfYpTmYFES 52Wz/RUrJJCeWJKanZpakFoEk2Xi4JRqYBT8sHO2/ebt552mf3hbZtt7/d254CKnSY81fZen 7L0pe+uuYIeb5pycZaV/fRumb6qTFNz1Ocfn+tnVl08XBbrf5Vvw3OfBrf1MGfXSq/NN3/JP bsiw31Vq7dWtvK69a7tonWL1nb4XP5iqOYSXTa/5pTVL56t9F7Phl05N7zP9vfKRJ3XmMyqx FGckGmoxFxUnAgB2zhmRsQMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:01:10 -0000 RnJvbTogaWV0ZiA8aWV0Zi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQmVuIENhbXBi ZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQo+IEkgYWdyZWUgd2l0aCB0aGF0IGZvciB0aGUgSUVTRywg YnV0IHRoZSBJQUIgaXMgbm90IHVzdWFsbHkgaW4gYSBwb3NpdGlvbiB0byBhcHByb3ZlIG9yIGJs b2NrIHNwZWNpZmljIHRlY2huaWNhbCBkZWNpc2lvbnMuIFllcywgaXQgc2V0cyBhcmNoaXRlY3R1 cmFsIGRpcmVjdGlvbiwgYnV0IHNlZSBSaWNoYXJk4oCZcyBjb21tZW50IGRvd24tdGhyZWFkLg0K DQpbSkxdIFBlcmhhcHMgd2UgYXJlIHRoaW5raW5nIHRvbyBuYXJyb3dseSBhYm91dCB3aGF0IHRo ZSBJQUIgZG9lcz8gSGVyZSBhcmUgc29tZSBhcmVhcyBmb3IgcG90ZW50aWFsIGNvbmZsaWN0IHRo YXQgYXJlIHVucmVsYXRlZCB0byBhcmNoaXRlY3R1cmFsIGRpcmVjdGlvbjoNCjEgLSBDb25maXJt aW5nIHRoZSBJRVRGIENoYWlyIGFuZCBBcmVhIERpcmVjdG9ycw0KMiAtIFN0YW5kYXJkcyBhcHBl YWxzDQozIC0gUkZDIFNlcmllcw0KNCAtIExpYWlzb24gcm9sZXMNCjUgLSBBZHZpY2UgdG8gSVNP Qw0KDQpbSkxdIEV2ZW4gaW4gYXJjaGl0ZWN0dXJhbCBvdmVyc2lnaHQsIHdoYXQgaWYgdGhlcmUg d2FzIGEgc3Ryb25nIHB1c2ggZm9yIGEgcGFydGljdWxhciBhcHByb2FjaCBhZ2FpbnN0IGEgcGFy dGljdWxhciBwcm90b2NvbCBvciBjb2RlYyBhbmQgc29tZW9uZSBvbiB0aGUgSUFCIGhhZCBhbiB1 bmRpc2Nsb3NlZCBmaW5hbmNpYWwgc3Rha2UgaW4gYSBwYXRlbnQgcG9vbCB0aGF0IHdvdWxkIGRp cmVjdGx5IGJlbmVmaXQgZnJvbSBhIGNlcnRhaW4gZGVjaXNpb24/IE9yIGlmIHRoZXkgIndvcmtl ZCIgZm9yIGEgdW5pdmVyc2l0eSBidXQgd2VyZSAxMDAlIGZ1bmRlZCBieSBhIGdyYW50IGZyb20g YSBnb3Zlcm5tZW50IHRoYXQgd2FzIHVuZGVyd3JpdGluZyB0aGVpciB0aW1lIHNwZWNpZmljYWxs eSB0byB3b3JrIGFnYWluc3QgYSBzcGVjaWZpYyB1cGdyYWRlIHRvIGVuY3J5cHRpb24/IE9yIHdo YXRldmVyIG90aGVyIGNhc2VzIHlvdSBtaWdodCBpbWFnaW5lLg0KDQpbSkxdIFNvIElNTyBpdCBz ZWVtcyBsaWtlIHNvbWUgQ29JIHBvbGljeSBmb3IgdGhlIElBQiBpcyBiZXR0ZXIgdGhhbiBubyBD b0kgcG9saWN5Lg0KDQoNCg== From nobody Thu Jan 9 13:10:42 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF64120807; Thu, 9 Jan 2020 13:10:36 -0800 (PST) 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 Z3yTiWvg9z6Q; Thu, 9 Jan 2020 13:10:34 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 32FFF120801; Thu, 9 Jan 2020 13:10:34 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id s21so3035679plr.7; Thu, 09 Jan 2020 13:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t9V/P/+iz5ZLe/dsdX0cZxNQp3KncbxZn+jwBHBXGRI=; b=aPy0/+wQ61rgTsItQs5YWaZHNa7cW/8CK6zpVS0WPdZKx3saaPCQHhQicO/ziS42qa EvIF9ZnpmA/4dTnBbrPpZEJFvjcpAGgMMJxqAmgxGl6MhwzC8RRkF08lSSCNSoE8LPZl DbQil1J233pCrc/1JM23Vk3/Gea84VPrrdXmOsqDz6x7lZhe1maXCupOJyN5aKZ6mNwR CAWw8Rf9p7YHliTQ6sM/pg4y9ChXXDd4VKV74lFay/CJUn89fO6fjhW2CpAmjqGReIfA qyjrOqWAoDq9tw5B/lsMTdM3vDt4cAcfC2Mz5zQmHrIQT7RKjQJGGvzvF5I+FRPeTAsN K9EQ== 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=t9V/P/+iz5ZLe/dsdX0cZxNQp3KncbxZn+jwBHBXGRI=; b=hNevHEDMlwFz7lCYcqQlnNXBfbjbg2imzx/ErBmO2q3y2/db/e8t9qJWJnn8JsWxjh c4ztBnsa03Y5A4ZKJfoDxhw74E8Tnj8/BQyQiJpO0Vn2rrkHLABvruDl0WAeFUfYDbYR I8lH9Ja8ULg5E8DaOAAnQ1N68Y012vl4NV4F930G41aSwJnXltsBGNWiyHt5Fzuu0eoB mLTx/ZqCvyMQ6/Avgk/U9XhKE+Ns4zuXSEZeP41r6Zf+TcBQoCMds3i7fSaqR9WBXdZt fa1yYEOQQdY+f6yvgH/iwL8sxrqQw500QmUNiAFHD7kHanLKCUEPLm+BuCsfTk55Luio gQDA== X-Gm-Message-State: APjAAAW4jVBlUf23gWLIFeUxJP2LvRwGdtjFdmZTqlV/8DF44Noz3RTm eHJ2rJiWyFP7mWfiEboNCc+mcBTI47vLgprPRLI= X-Google-Smtp-Source: APXvYqx0HW5KMOfhsNZEGucyEIgnQVnUrfsRvBIrk2KeJtgOLtwFSJy4l5ywnQ18g+eim7NanEF06Xr5dKblS088NFE= X-Received: by 2002:a17:90a:bb0c:: with SMTP id u12mr79548pjr.100.1578604233629; Thu, 09 Jan 2020 13:10:33 -0800 (PST) MIME-Version: 1.0 References: <52B13773-88C3-490D-8003-475F845F1ACB@nbcuni.com> In-Reply-To: <52B13773-88C3-490D-8003-475F845F1ACB@nbcuni.com> From: Mary Barnes Date: Thu, 9 Jan 2020 15:10:22 -0600 Message-ID: Subject: Re: [arch-d] [EXTERNAL] Re: Draft IAB conflict of interest policy To: "Deen, Glenn (NBCUniversal)" Cc: "Livingood, Jason" , Ben Campbell , Joe Touch , IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009626fa059bbb70ef" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:10:36 -0000 --0000000000009626fa059bbb70ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Jason. The notion that much of the IAB's work is focused on technical issues is a mis-conception. And, beyond Glenn's point about ISOC Trustee appointment, here's a complete list of all the appointments and confirmations for which the IAB is responsible: https://www.iab.org/activities/iab-appointments-and-confirmations/ And, you can look at many of the IAB correspondence, reports, etc and see that many of the topics are not particularly technical: https://www.iab.org/documents/correspondence-reports-documents/ I think some sort of COI policy is helpful, although as others have suggested, I think we have to put a certain level of trust in the individuals to do the right thing. Regards, Mary. On Thu, Jan 9, 2020 at 2:20 PM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > > > =EF=BB=BFOn 1/9/20, 12:08 PM, "Architecture-discuss on behalf of Livingoo= d, Jason" > Jason_Livingood@comcast.com> wrote: > > From: ietf on behalf of Ben Campbell < > ben@nostrum.com> > > I agree with that for the IESG, but the IAB is not usually in a > position to approve or block specific technical decisions. Yes, it sets > architectural direction, but see Richard=E2=80=99s comment down-thread. > > [JL] Perhaps we are thinking too narrowly about what the IAB does? > Here are some areas for potential conflict that are unrelated to > architectural direction: > 1 - Confirming the IETF Chair and Area Directors > 2 - Standards appeals > 3 - RFC Series > 4 - Liaison roles > 5 - Advice to ISOC > > [GD] + 6 - Appoint an ISOC Trustee > > [JL] Even in architectural oversight, what if there was a strong push > for a particular approach against a particular protocol or codec and > someone on the IAB had an undisclosed financial stake in a patent pool th= at > would directly benefit from a certain decision? Or if they "worked" for a > university but were 100% funded by a grant from a government that was > underwriting their time specifically to work against a specific upgrade t= o > encryption? Or whatever other cases you might imagine. > > [JL] So IMO it seems like some CoI policy for the IAB is better than > no CoI policy. > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/archite= cture-discuss__;!!PIZeeW5wscynRQ!8O2iCzgeSlI5bAPaoLgo-80K8IGXap8sIDzyMyfHcy= TaVjxMG_zUxVDXLqj3Nid1$ > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000009626fa059bbb70ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Jason.=C2=A0 The notion=C2=A0that much of the= IAB's work is focused on technical issues is a mis-conception.=C2=A0 A= nd, beyond Glenn's point about ISOC Trustee appointment, here's a c= omplete list of all the appointments and confirmations for which the IAB is= responsible:=C2=A0=C2=A0https://www.iab.org/activities/iab-appointment= s-and-confirmations/

And, you can look at many of th= e IAB correspondence, reports, etc and see that many of the topics are not = particularly technical:=C2=A0=C2=A0

I thin= k some sort of COI policy is helpful, although as others have suggested, I = think we have to put a certain level of trust in the individuals to do the = right thing.

Regards,
Mary.

On Thu, Jan 9, 2020 at 2:20 PM Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:


=EF=BB=BFOn 1/9/20, 12:08 PM, "Architecture-discuss on behalf of Livin= good, Jason" <architecture-discuss-bounces@ietf.org on behalf o= f Jason_Li= vingood@comcast.com> wrote:

=C2=A0 =C2=A0 From: ietf <ietf-bounces@ietf.org> on behalf of Ben Campbell <ben@nostrum.com><= br> =C2=A0 =C2=A0 > I agree with that for the IESG, but the IAB is not usual= ly in a position to approve or block specific technical decisions. Yes, it = sets architectural direction, but see Richard=E2=80=99s comment down-thread= .

=C2=A0 =C2=A0 [JL] Perhaps we are thinking too narrowly about what the IAB = does? Here are some areas for potential conflict that are unrelated to arch= itectural direction:
=C2=A0 =C2=A0 1 - Confirming the IETF Chair and Area Directors
=C2=A0 =C2=A0 2 - Standards appeals
=C2=A0 =C2=A0 3 - RFC Series
=C2=A0 =C2=A0 4 - Liaison roles
=C2=A0 =C2=A0 5 - Advice to ISOC

[GD] + 6 - Appoint an ISOC Trustee

=C2=A0 =C2=A0 [JL] Even in architectural oversight, what if there was a str= ong push for a particular approach against a particular protocol or codec a= nd someone on the IAB had an undisclosed financial stake in a patent pool t= hat would directly benefit from a certain decision? Or if they "worked= " for a university but were 100% funded by a grant from a government t= hat was underwriting their time specifically to work against a specific upg= rade to encryption? Or whatever other cases you might imagine.

=C2=A0 =C2=A0 [JL] So IMO it seems like some CoI policy for the IAB is bett= er than no CoI policy.


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Architecture-discuss mailing list
=C2=A0 =C2=A0 Architecture-discuss@ietf.org
=C2=A0 =C2=A0 https://urldefense.com/v3/__https://www.ietf.org/mailman/listin= fo/architecture-discuss__;!!PIZeeW5wscynRQ!8O2iCzgeSlI5bAPaoLgo-80K8IGXap8s= IDzyMyfHcyTaVjxMG_zUxVDXLqj3Nid1$


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000009626fa059bbb70ef-- From nobody Thu Jan 9 14:40:30 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0621612086F; Thu, 9 Jan 2020 14:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 LZ2z5zQSHwld; Thu, 9 Jan 2020 14:40:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E438C12087D; Thu, 9 Jan 2020 14:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FcT+6QbkbpF1NVGT71n2yxDar1a3YHDMnpGN5RC7gdA=; b=jL6Ge6oveVfDaq95x4t1WS2+J D7srEKgjolSFKJ+ioYYQI2kEaNKI/WqPGWUaU17R8zDZC8oULobcvMFahFJrvkYLlVjnMd2ONFE0R 8vtbU3flWQAyuu4w3oN7+X2pmvbTZtzNdzQAgNFN3+aKLw9IOlYShalyqZqbEseOFAbmpOGKQOJ/m HerLLNWOA39d1W+6N8E6BvYarKezfoV3X2WuXduCluvuUXTg4pIrsO42LQ1m0mYaZoVXvYEjCm8Ij cyqyLgU1I9LlnGuSGWkoDkS+JjpsomIWywaFScdIrbutNJgQRezcd9EKjWwIgHAIvgahxZPgzlnSt 66tox6Czw==; Received: from [::1] (port=44532 helo=server217.web-hosting.com) by server217.web-hosting.com with esmtpa (Exim 4.92) (envelope-from ) id 1ipgTS-003OGU-A9; Thu, 09 Jan 2020 17:40:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a4da178f75e2759888d63513768d5f9a" Date: Thu, 09 Jan 2020 14:40:18 -0800 From: Joe Touch To: Eric Rescorla Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Message-ID: <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.3.7 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 22:40:28 -0000 --=_a4da178f75e2759888d63513768d5f9a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2020-01-09 10:46, Eric Rescorla wrote: > I concur with Richard here. The IETF is most successful when we get > input from people who are directly involved in the technologies that > we are standardizing, but of course that very often means that they > are working on those technologies for their employer. And indeed > one of the criteria we often use to ask whether someone is a good > fit for leadership is whether they have this kind of non-standards > "day job" expertise. That, IMO, is why we encourage their participation in WG discussions and on lists. But it is dangerous to have those parties directly involved in decision making. The actual and potential COI (esp. perceived potential COI) undermine the decisions made - even when those decisions are otherwise reasonable. I.e., think of this as protecting the value of IAB decisions (and, as Ben noted, there are many, esp. during appeals, that are of a substantive nature that COI benefits). Joe --=_a4da178f75e2759888d63513768d5f9a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most successful wh= en we get
input from people who are directly involved in the technolog= ies that
we are standardizing, but of course that very often means tha= t they
are working on those technologies for their employer. And indeed
one of the criteria we often use to ask whether someone is a good
fit for leadership is whether they have this kind of non-standards
"day job" expertise.
 
 
That, IMO, is why we encourage their participation in WG discussions a= nd on lists.
 
But it is dangerous to have those parties directly involved in decisio= n making. The actual and potential COI (esp. perceived potential COI) under= mine the decisions made - even when those decisions are otherwise reasonabl= e.
 
I.e., think of this as protecting the value of IAB decisions (and, as = Ben noted, there are many, esp. during appeals, that are of a substantive n= ature that COI benefits).
 
Joe


--=_a4da178f75e2759888d63513768d5f9a-- From nobody Thu Jan 9 14:59:32 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382C4120807; Thu, 9 Jan 2020 14:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_FONT_SIZE_LARGE=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 MWqZqeuO5UcU; Thu, 9 Jan 2020 14:59:20 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 699FF120241; Thu, 9 Jan 2020 14:59:20 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id g23so101441vsr.7; Thu, 09 Jan 2020 14:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F/3ay+sYg9MxcVh2s8h2Y7whzO+xaAJxl4xQwrQydMI=; b=ce/H9IqkdvDowfhvtgPRN8a9l+PjICUTaynAHCJ2Cg5caky7ui2Hpifk2zQY3akGbO 7JazuD1J53Wkww4EVCZMAlW/f4KsWHCUFgChnjxCb2JSWEzxhMHCuHBRiSHnukIZCGIP xytc+d2azYRnhGq1wQLciEtpluPUucOo79svtM33bEfE7uYQU7LDcv7HRXtbLHSYRHx0 ezAsjdR8MheCSbWaKPKUPT9F8acyZOZjI6op+WbsoTG7m438QRX4asBCcbGRSd2/pLoV 4nqxQuWC5NnSFONFfvmwsE8Nc8WPAfB1WILkXyOKEAVveiAEYSO2P421/TlvceofiLeS rx3A== 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=F/3ay+sYg9MxcVh2s8h2Y7whzO+xaAJxl4xQwrQydMI=; b=IivECdbJuZIy+cz1p1yW2dJA5JTxShDPSily9t5M+5TB7f1WvBWdVFuin2EhYR+uJp sJ6YLWc3MeSuqJndAo7zOhYs88l00xAqVQtAX0RoeuKyWqTKLSMIvLgrybtHRBzoBO5T 5xBQCOgKP0QweeOHITfJTHGRm78gZmN1fhG/J+jZmOWJzWtzB91MqijFldKqzTb3b3ox U7tClMc1WVjvnZUQB7qKGFy1vAaLXXvSFsbFtuFuxtyMVrBJ6ufpapwGV3NqTQjBXG1W XHgU8j/Te7+Us1FGrWG2kGd6FMw1sNuuICyUA23WP/NUFYVOymGFI1mV1OKrNyGMrQ+m sQTw== X-Gm-Message-State: APjAAAVd0kA6NpgtibYo7dmnVkZPlyGTwKfdQ9gj6XkGEDbjVnyqLTjV XAUQRAewW9pYafQ2X5shqnJt34qwSodDMPSU7CBRTA== X-Google-Smtp-Source: APXvYqw2wjOtcBzHIifJpZ8/JKEmZeeHKMML6R7INONcr2uIqEUS5YOjH+MHjPSjwSDI1AikZwbXrg+h6XnPEvh9hTU= X-Received: by 2002:a05:6102:20c:: with SMTP id z12mr69978vsp.32.1578610759083; Thu, 09 Jan 2020 14:59:19 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: From: Bernard Aboba Date: Thu, 9 Jan 2020 14:59:08 -0800 Message-ID: Subject: Re: [arch-d] Draft IAB conflict of interest policy To: Richard Barnes Cc: IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000088abbd059bbcf588" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 22:59:24 -0000 --00000000000088abbd059bbcf588 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree with Richard here. Much of the IAB work is technical in nature. The IAB should therefore not need a conflict-of-interest policy as heavy weight as that required to assume a senior role within government, a legislature or a governmental advisory committee. Having served on a governmental advisory committee covered by FACA, it would appear to me that the proposed IAB COI policy is potentially more stringent. As an example, under FACA I was not required to provide a complete financial disclosure. The guidance was that a disclosure need only be made in the event of a potential conflict, should one arise. On Thu, Jan 9, 2020 at 8:58 AM Richard Barnes wrote: > I would propose the IAB not adopt this policy, or at least scope it way > down. > > Much of the IAB's work is focused on technical issues, at a high enough > strategic level that the impacts to specific people or companies are high= ly > attenuated. In those discussions, the IAB's work benefits from having > diverse opinions, including the opinions of those who have skin in the > game. Trying to introduce some notion of CoI in this context would be > harmful -- because there's no hard conflict, it will inevitably be vague, > and thus primarily a tool for IAB members to try to silence one another o= r > a cause for IAB members to self-censor. > > Where the IAB is directly involved in finance or personnel decisions, > there of course should be guards against self dealing. That's where any > CoI policy for the IAB should stop. > > --Richard > > On Wed, Jan 8, 2020 at 6:16 PM IAB Chair wrote: > >> Dear Colleagues, >> >> The IAB is considering adoption of the conflict of interest policy >> below. If you have comments on this draft policy, please send them to >> iab@iab.org. >> >> best regards, >> Ted Hardie >> for the IAB >> >> >> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >> >> This policy covers the nomcom-selected Internet Architecture Board (IAB) >> members and ex-officio members (collectively, =E2=80=9CCovered Individua= ls=E2=80=9D). This >> policy has no impact on any other participants in IAB activities, for >> instance liaisons to and from the IAB or IAB program members. >> >> In carrying out their IAB role, Covered Individuals must act in the best >> interest of the Internet community. Occasionally this duty may be=E2=80= =94or may >> appear to be=E2=80=94incompatible or in conflict with a Covered Individu= al=E2=80=99s >> personal interests (including interests of their family members), or the >> interests of an organization of which the Covered Individual is an >> employee, director, owner, or otherwise has business or financial intere= st. >> If a Covered Individual has a conflict of interest for whatever reason, >> that individual must avoid participating in the work of the IAB that >> touches on the related matter. >> >> The IAB does not directly deal with matters relating to contracts or >> finance. The IAB does, however, have a role in personnel decisions, and = its >> decisions and outputs have a potential to indirectly affect contracts >> within the IETF system. IAB's technical decisions and outputs have also = a >> potential to impact both work elsewhere in the IETF and businesses that >> employ or develop Internet technology. >> >> Covered Individuals shall not use the IAB=E2=80=99s resources or decisio= ns as a >> means for personal or third-party gain. >> Disclosure of Actual or Potential Conflicts >> >> The IAB requires that all Covered Individuals disclose their main >> employment, sponsorship, consulting customer, or other sources of income >> when joining the IAB or whenever there are updates. >> >> In addition, when a topic is discussed at the IAB, the Covered >> Individuals are required to promptly disclose if that topic constitutes = a >> perceived or potential conflict of interest. Once disclosed, Covered >> Individuals may recuse from participation in discussions or decisions at >> their discretion. >> >> The specific conflicts that may cause a perceived or potential conflict >> of interest are matters for individual and IAB judgment, but generally c= ome >> in the following forms: >> >> - >> >> A personnel decision relates to the Covered Individual, a colleague >> that the Covered Individual's works closely with, or a family member.= For >> the purposes of this policy, a "person working closely with" is someo= ne >> working in the same team or project, or a direct manager or employee = of the >> Covered Individual. And "family" means a spouse, domestic partner, ch= ild, >> sibling, parent, stepchild, stepparent, and mother-, father-, son-, >> daughter-, brother-, or sister-in-law, and any other person living in= the >> same household, except tenants and household employees. >> - >> >> A decision or output from the IAB impacts a contract that the IETF >> enters into with a party, and that party relates to the Covered Indiv= idual, >> a colleague that the Covered Individual's works closely with, or a fa= mily >> member. >> - >> >> Activity on the IAB involves discussion and decisions regarding >> technical matters, mainly related to IETF activities. As an activity >> adjacent to a standardization process, it is often the case that Cove= red >> Individuals will have some (frequently non-financial) stake in the ou= tcome >> of discussions or decisions that relate to technical matters. This po= licy >> does not require that Covered Individuals disclose such conflicts of >> interest as they relate to technical matters. However, Covered Indivi= duals >> need to exercise their judgment and, in extraordinary cases be willin= g to >> disclose potential or perceived conflicts of interest even as they re= late >> to technical matters. For example, if a Covered Individual's sponsor = were >> in the process of entering a new market where there is an ongoing IAB >> discussion, then disclosure, or even recusal, might be appropriate, e= ven if >> difficult. >> >> Disclosure Transparency >> >> A person's recusal to participate in the discussion of a topic is always >> noted in the public IAB minutes. In addition, the IAB will maintain a >> repository of all general disclosures of employment and other sponsorshi= p. >> It is expected that much of this repository is public, but there can be >> situations where some disclosures (such as customers of consultants) are >> private. >> >> >> >> >> >> _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000088abbd059bbcf588 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree with Richard here.=C2=A0 Much of the IAB work is tec= hnical in nature.=C2=A0 The IAB should therefore not need a conflict-of-int= erest policy as heavy weight as that required to assume a senior role withi= n government, a legislature or a governmental advisory committee.=C2=A0
Having served on a governmental advisory committee covered= by FACA, it would appear to me that the proposed IAB COI policy is potenti= ally more stringent.=C2=A0 As an example, under FACA I was not required to = provide a complete financial disclosure.=C2=A0 The guidance was that a disc= losure need only be made in the event of a potential conflict, should one a= rise.=C2=A0

On Thu, Jan 9, 2020 at 8:58 AM Richard Barnes <rlb@ipv.= sx> wrote:
I would propose the IAB not adopt this policy, or at le= ast scope it way down.

Much of the IAB's work = is focused on technical issues, at a high enough strategic level that the i= mpacts to specific people or companies are highly attenuated.=C2=A0 In thos= e discussions, the IAB's work benefits from having diverse opinions, in= cluding the opinions of those who have skin in the game.=C2=A0 Trying to in= troduce some notion of CoI in this context would be harmful -- because ther= e's no hard conflict, it will inevitably be vague, and thus primarily a= tool for IAB members to try to silence one another or a cause for IAB memb= ers to self-censor.

Where the IAB is directly = involved in finance or personnel decisions, there of course should be guard= s against self dealing.=C2=A0 That's where any CoI policy for the IAB s= hould stop.

--Richard

On Wed, Jan 8, 2020= at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:
=20 =20 =20

<= /span>Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.=C2=A0 If you have comments on this draft policy, please send them to=C2=A0iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, =E2=80=9CCo= vered Individuals=E2=80=9D). This policy has no impact on any other partici= pants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be=E2=80=94or may appear to be=E2=80=94incompatible or in co= nflict with a Covered Individual=E2=80=99s personal interests (including interests = of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB=E2=80=99s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, o= r a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partn= er, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic i= s always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.



_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--00000000000088abbd059bbcf588-- From nobody Thu Jan 9 15:59:44 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB46120816 for ; Thu, 9 Jan 2020 15:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable 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 wF-74tp7Ioo0 for ; Thu, 9 Jan 2020 15:59:39 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DD7120828 for ; Thu, 9 Jan 2020 15:59:39 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id w1so208814ljh.5 for ; Thu, 09 Jan 2020 15:59:39 -0800 (PST) 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=xZGMtq1nQFigj2Qe0Xq8HQFRTkeUZiXDIAnAHHwehPw=; b=1aBqPZUxztwSjRwwta+r30p9Shnd5GoazkA1jZ/PsWPgXjUI3RanGYwXgUBsJR+F2t /VscAKpZZa0fIyphyd1qz7CDPm0XP1SJLluB/tgGJgh1/yW8t9PSJA+eGQ3soe34YpE9 cgdqybqiUYcMkHkDrwiGqK65K8aIDugz6k54ONRRhk3lwadIVGMty4Z15AbvVjtfGakR N7W4gtQ4AwgepqsKvfHIST9JANBd9kjv1kK8pRn+89qtN4I3fKSwExs8vtab8tEi2Z/5 OogOKf13GAMSpsjGC2XdpFnks2/4KElXor468hIqmXbXyqMV9mhuIlEX3ylNy4HIjDFh hw/w== 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=xZGMtq1nQFigj2Qe0Xq8HQFRTkeUZiXDIAnAHHwehPw=; b=HPEVoGqdEq8V43YngCrY0ZRiY4uy8c/Wvc+MTielbTApEkOuAUt+esdX/G0hSANbnU hIpFtpkAj/P/Dh07fC5YawXoY3PX2WZB3xSET5/+cX5DITLTD0ptqRc8Z7Fx/S3EFlMs +0XOtujWUhfnCBEvxyGoani4GdN2DvzrFjL/N0EAbDdvyPWYoOc9xZU0xcgXhfNkkB2/ /ghzYw3GJ05KE1paaJ8qfngKZ1GkuhwK5dqPdGMR/Dq0ed7pKTKz9bE+iiBE6DX9Hzhn TwrzeDUS3/PBQZTUlziG98jPsnIU+Q/YFVHGV0xLD03gDf3wbeREtfvzUCmYOX5W2q5v Zwcw== X-Gm-Message-State: APjAAAXyHs8McO+xPDlYUfV8IBU7g+czBoKBxcBPAATqmcXxtqFJhCzN oRHshFBx9LRX7LckuhqKNurymikVFaPDNIV5t4is4XhVU4w= X-Google-Smtp-Source: APXvYqxON2zPyochOOZTblm8CMpQD58MOQ1IMqIzAKWjfkdRCUDVJZnmnye91JEik21L5GqhGE8jX95C9Lb2GQ/AzcI= X-Received: by 2002:a2e:9008:: with SMTP id h8mr388738ljg.217.1578614377503; Thu, 09 Jan 2020 15:59:37 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> In-Reply-To: <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> From: Eric Rescorla Date: Thu, 9 Jan 2020 15:59:01 -0800 Message-ID: Subject: Re: [arch-d] Draft IAB conflict of interest policy To: Joe Touch Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000356e07059bbdcdbd" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 23:59:42 -0000 --000000000000356e07059bbdcdbd Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: > On 2020-01-09 10:46, Eric Rescorla wrote: > > I concur with Richard here. The IETF is most successful when we get > input from people who are directly involved in the technologies that > we are standardizing, but of course that very often means that they > are working on those technologies for their employer. And indeed > one of the criteria we often use to ask whether someone is a good > fit for leadership is whether they have this kind of non-standards > "day job" expertise. > > > > That, IMO, is why we encourage their participation in WG discussions and > on lists. > > But it is dangerous to have those parties directly involved in decision > making. The actual and potential COI (esp. perceived potential COI) > undermine the decisions made - even when those decisions are otherwise > reasonable. > > I.e., think of this as protecting the value of IAB decisions (and, as Ben > noted, there are many, esp. during appeals, that are of a substantive > nature that COI benefits). > And yet we routinely allow have WG chairs and ADs who are deeply involved (and whose employers are deeply involved) in the technologies that are being standardized. -Ekr > Joe > > > --000000000000356e07059bbdcdbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 2:40 PM Joe To= uch <touch@strayalpha.com>= ; wrote:

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most successful wh= en we get
input from people who are directly involved in the technologie= s that
we are standardizing, but of course that very often means that th= ey
are working on those technologies for their employer. And indeed
one of the criteria we often use to ask whether someone is a good
fit for leadership is whether they have this kind of non-standards
"day job" expertise.
=C2=A0
=C2=A0
That, IMO, is why we encourage their participation in WG discussions a= nd on lists.
=C2=A0
But it is dangerous to have those parties directly involved in decisio= n making. The actual and potential COI (esp. perceived potential COI) under= mine the decisions made - even when those decisions are otherwise reasonabl= e.
=C2=A0
I.e., think of this as protecting the value of IAB decisions (and, as = Ben noted, there are many, esp. during appeals, that are of a substantive n= ature that COI benefits).

And yet we routinely allow have WG chairs and ADs who are deeply involved = (and whose employers are deeply involved) in the technologies that are bein= g standardized.

-Ekr

=C2=A0
Joe


--000000000000356e07059bbdcdbd-- From nobody Thu Jan 9 17:33:20 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866D3120131; Thu, 9 Jan 2020 17:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 hsEKHjHPNLKG; Thu, 9 Jan 2020 17:33:10 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 0C0D2120288; Thu, 9 Jan 2020 17:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wIU3yYqsr66mRzy6RdJQad6Ex8uxKgKu30EpExjdPaM=; b=D6UZJs9vpLoDzSTPXv+IRX/Z/h oQucsYAR7iLjeRy47vNlEh00sq//W6a8w+JweuvVcYUxUVzswNjpqo74EJIn1bWwOwaQdx0mBxOi/ JN7tksFhITvrc2QN02xsV99GgJ12N9z0EiYKn1wbiQ1InhofdgJKyhXX020xUqzshT7r/YWcvwTf8 T2b3hU9JFn+1TIeuxUPEYnVM3BAh34UvDRLya6q8MMJzO+niz4rUS6uBaneCjIrCURPg6cdbOnwQf zlQyb7TcoybbuINAW4m+6OhIV1XjbVKPuGaCcAa3xG1MSFDFMJd9Af+BS5xvMTfoRflydtpCmjwRc Q8t2XElg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:54648 helo=[192.168.1.2]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipjAe-001v1m-S5; Thu, 09 Jan 2020 20:33:09 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [arch-d] Draft IAB conflict of interest policy From: Joe Touch In-Reply-To: Date: Thu, 9 Jan 2020 17:33:02 -0800 Cc: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org Message-Id: References: To: Eric Rescorla X-Mailer: iPad Mail (17C54) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 01:33:12 -0000 --Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. And it at times has been an issue. Joe > On Jan 9, 2020, at 3:59 PM, Eric Rescorla wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: >>> On 2020-01-09 10:46, Eric Rescorla wrote: >>>=20 >>> I concur with Richard here. The IETF is most successful when we get >>> input from people who are directly involved in the technologies that >>> we are standardizing, but of course that very often means that they >>> are working on those technologies for their employer. And indeed >>> one of the criteria we often use to ask whether someone is a good >>> fit for leadership is whether they have this kind of non-standards >>> "day job" expertise. >> =20 >> =20 >> That, IMO, is why we encourage their participation in WG discussions and o= n lists. >> =20 >> But it is dangerous to have those parties directly involved in decision m= aking. The actual and potential COI (esp. perceived potential COI) undermine= the decisions made - even when those decisions are otherwise reasonable. >> =20 >> I.e., think of this as protecting the value of IAB decisions (and, as Ben= noted, there are many, esp. during appeals, that are of a substantive natur= e that COI benefits). >=20 > And yet we routinely allow have WG chairs and ADs who are deeply involved (= and whose employers are deeply involved) in the technologies that are being s= tandardized. >=20 > -Ekr >=20 >> =20 >> Joe >>=20 --Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes.  And it at times= has been an issue.

Joe

On Jan 9, 2020, at 3:59 PM,= Eric Rescorla <ekr@rtfm.com> wrote:

=EF=BB=BF


On Thu, Jan 9, 2020 at 2:40 PM Joe Touch <touch@strayalpha.com> wrote:

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most successful whe= n we get
input from people who are directly involved in the technologies t= hat
we are standardizing, but of course that very often means that they
are working on those technologies for their employer. And indeed
one of the criteria we often use to ask whether someone is a good
=
fit for leadership is whether they have this kind of non-standards
"day job" expertise.
 
 
That, IMO, is why we encourage their participation in WG discussions an= d on lists.
 
But it is dangerous to have those parties directly involved in decision= making. The actual and potential COI (esp. perceived potential COI) undermi= ne the decisions made - even when those decisions are otherwise reasonable.<= /div>
 
I.e., think of this as protecting the value of IAB decisions (and, as B= en noted, there are many, esp. during appeals, that are of a substantive nat= ure that COI benefits).

An= d yet we routinely allow have WG chairs and ADs who are deeply involved (and= whose employers are deeply involved) in the technologies that are being sta= ndardized.

-Ekr

 
Joe


= --Apple-Mail-1DABDE5E-3ECF-4D58-B95A-026E399AA6AE-- From nobody Thu Jan 9 17:40:43 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D212812080B for ; Thu, 9 Jan 2020 17:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viagenie-ca.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 jucYmOWYDooi for ; Thu, 9 Jan 2020 17:40:38 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 87DE4120808 for ; Thu, 9 Jan 2020 17:40:38 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id d71so538183qkc.0 for ; Thu, 09 Jan 2020 17:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=yHMwuAvLK9gUw6iIFm/sm9hze3x1TscAYm1qCihsuYo=; b=CVYDrDaMpRJVVvPJq0uTiMCgf01VkIupNu/vOMj3Xy8lVy9FvtDFhJQsyJkV6l3R87 Hj/Hwc6wiJrVulwz9U6RS/m9jLier4HePapTVnMbZohQYaxgm3dTdFHM0V5crbh2FWe7 +/uloS2/e7Fa4TqRgBcFHEEKD1j+woHVTlle2xfT3krZwShLHoVmVwr9XNerV/7Ehgh/ g6eCUzLqmBdbFbduj+Gj9WkiNEOHsoFfWPqdo74hIrtlfs6afueN8SEhqHrVs250ptvQ u5ufzsF4C38cdMm0Ya3PwNxHrqbvlRZwz9KuymXXOPr/wux3u3qQtdlBfoYappKssOo9 AUiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=yHMwuAvLK9gUw6iIFm/sm9hze3x1TscAYm1qCihsuYo=; b=mYftAcK3Dp6nm2a6HJipn9lAGMLFl3sk0Ak3jX5pSJhKqLvLnkguZA4cJFp1sewcet jnub4WcmrbX1lc65Phedv/tqzAUQq2HFVmxp1lW7/Qwj6vFxzlSMMo5ojq8I6Z82Usml 4wRBjNfHeJFkcRRwGWwNFcX40yTfyIWn5BKgMoww9uWy/da4DwiRnOlCdyCLWItI8Sqh zVpLsqJQE3Y7pmaU+UCr62+kInhiH9JovF0QCM732tpUxcIDSnww+ra6binNeMM2zRIu ZKryx5iLW19MkjZLY6Ct8zsPAcr6C4wAZy6aOjcyismDiZuS3mL5UflJ2kguwHxkb1yE JilA== X-Gm-Message-State: APjAAAWVyNZU9Onfxp73RSB3voSPq5PrN+63F1/Nk55kMjcuZMh2amUs qBeTlyvrTUtMbXfDlkiPgLTozg== X-Google-Smtp-Source: APXvYqx1lCbGi7tDLy1XHPfdM9iY977TYAUmK8ZRMJpJykOApdeZpw6qguYXhBwBVEHjSN6UYUskUw== X-Received: by 2002:a37:63d2:: with SMTP id x201mr896299qkb.30.1578620437475; Thu, 09 Jan 2020 17:40:37 -0800 (PST) Received: from [169.254.100.189] (modemcable016.82-162-184.mc.videotron.ca. [184.162.82.16]) by smtp.gmail.com with ESMTPSA id h34sm236186qtc.62.2020.01.09.17.40.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 17:40:36 -0800 (PST) From: "Marc Blanchet" To: "Eric Rescorla" Cc: "Joe Touch" , "Richard Barnes" , "IAB Chair" , "IAB IAB" , "IETF discussion list" , architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Thu, 09 Jan 2020 20:40:35 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 01:40:41 -0000 On 9 Jan 2020, at 18:59, Eric Rescorla wrote: > On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: > >> On 2020-01-09 10:46, Eric Rescorla wrote: >> >> I concur with Richard here. The IETF is most successful when we get >> input from people who are directly involved in the technologies that >> we are standardizing, but of course that very often means that they >> are working on those technologies for their employer. And indeed >> one of the criteria we often use to ask whether someone is a good >> fit for leadership is whether they have this kind of non-standards >> "day job" expertise. >> >> >> >> That, IMO, is why we encourage their participation in WG discussions and >> on lists. >> >> But it is dangerous to have those parties directly involved in decision >> making. The actual and potential COI (esp. perceived potential COI) >> undermine the decisions made - even when those decisions are otherwise >> reasonable. >> >> I.e., think of this as protecting the value of IAB decisions (and, as Ben >> noted, there are many, esp. during appeals, that are of a substantive >> nature that COI benefits). >> > > And yet we routinely allow have WG chairs and ADs who are deeply involved > (and whose employers are deeply involved) in the technologies that are > being standardized. pretty relevant point, and very common. Marc. > > -Ekr > > >> Joe >> >> >> > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Thu Jan 9 21:53:13 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894C61200B3 for ; Thu, 9 Jan 2020 21:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 qSiRsS-4p70e for ; Thu, 9 Jan 2020 21:53:09 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 5FD13120077 for ; Thu, 9 Jan 2020 21:53:09 -0800 (PST) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00A5qgxb138920 for ; Fri, 10 Jan 2020 00:53:09 -0500 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xe7m34992-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 10 Jan 2020 00:53:08 -0500 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 00A5qqJY025672 for ; Fri, 10 Jan 2020 05:53:07 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma05wdc.us.ibm.com with ESMTP id 2xajb6v4nr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 10 Jan 2020 05:53:07 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 00A5r6s510945040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 10 Jan 2020 05:53:06 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 465D7AE064 for ; Fri, 10 Jan 2020 05:53:06 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 32B61AE062 for ; Fri, 10 Jan 2020 05:53:06 +0000 (GMT) Received: from rotala.raleigh.ibm.com (unknown [9.27.200.19]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTPS for ; Fri, 10 Jan 2020 05:53:06 +0000 (GMT) Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.15.2/8.15.2) with ESMTP id 00A5r4Ol018653 for ; Fri, 10 Jan 2020 00:53:04 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.15.2/8.15.2/Submit) id 00A5r4pH018592 for ietf@ietf.org; Fri, 10 Jan 2020 00:53:04 -0500 From: narten@us.ibm.com Message-Id: <202001100553.00A5r4pH018592@rotala.raleigh.ibm.com> Date: Fri, 10 Jan 2020 00:53:04 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-10_01:2020-01-10, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=75 impostorscore=0 mlxscore=0 clxscore=1015 phishscore=0 mlxlogscore=910 lowpriorityscore=0 bulkscore=0 priorityscore=1501 adultscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001100049 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 05:53:12 -0000 Total of 52 messages in the last 7 days. script run at: Fri 10 Jan 2020 12:53:04 AM EST Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.69% | 4 | 9.98% | 83961 | touch@strayalpha.com 5.77% | 3 | 8.46% | 71211 | ben@nostrum.com 5.77% | 3 | 8.10% | 68141 | ietf@hallambaker.com 5.77% | 3 | 6.98% | 58702 | ekr@rtfm.com 7.69% | 4 | 4.98% | 41915 | john-ietf@jck.com 5.77% | 3 | 6.34% | 53387 | jason_livingood@comcast.com 5.77% | 3 | 4.51% | 37968 | rsalz@akamai.com 5.77% | 3 | 4.39% | 36979 | moore@network-heretics.com 3.85% | 2 | 3.60% | 30297 | stpeter@mozilla.com 3.85% | 2 | 3.06% | 25777 | sayrer@gmail.com 3.85% | 2 | 2.79% | 23481 | stewart.bryant@gmail.com 3.85% | 2 | 2.25% | 18944 | mcr+ietf@sandelman.ca 3.85% | 2 | 2.22% | 18710 | ietf-dane@dukhovni.org 1.92% | 1 | 3.62% | 30502 | stephen.farrell@cs.tcd.ie 1.92% | 1 | 3.49% | 29337 | bernard.aboba@gmail.com 1.92% | 1 | 3.11% | 26174 | rlb@ipv.sx 1.92% | 1 | 2.86% | 24040 | iab-chair@iab.org 1.92% | 1 | 2.29% | 19264 | alissa@cooperw.in 1.92% | 1 | 2.24% | 18891 | mary.ietf.barnes@gmail.com 1.92% | 1 | 1.89% | 15943 | glenn.deen@nbcuni.com 1.92% | 1 | 1.80% | 15164 | warren@kumari.net 1.92% | 1 | 1.67% | 14077 | adam@nostrum.com 1.92% | 1 | 1.63% | 13692 | barryleiba@computer.org 1.92% | 1 | 1.47% | 12340 | cdel@firsthand.net 1.92% | 1 | 1.40% | 11803 | marc.blanchet@viagenie.ca 1.92% | 1 | 1.33% | 11227 | lmm@acm.org 1.92% | 1 | 1.23% | 10384 | aretana.ietf@gmail.com 1.92% | 1 | 1.17% | 9811 | narten@us.ibm.com 1.92% | 1 | 1.11% | 9363 | sob@sobco.com --------+------+--------+----------+------------------------ 100.00% | 52 |100.00% | 841485 | Total From nobody Thu Jan 9 23:04:26 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6A120142; Thu, 9 Jan 2020 23:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=OJMraudM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W0b1mCcT 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 LTQ2kwUcq589; Thu, 9 Jan 2020 23:04:11 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2EC120112; Thu, 9 Jan 2020 23:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27189; q=dns/txt; s=iport; t=1578639851; x=1579849451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UbYYqBK1B0TJLbvx9O0GFMFKDvltgMmhBc+fJXLefK4=; b=OJMraudMx0H9rE0VQXuY0jRAvtU0rhMHv3hSdaPfGKnZMH+znv41QHbH 7Mp8ihT6AtMDcj11KfFjEhlAjnv9Gz/B7DPgFhOPwl/4duOViYra2BiOD Jo1jPaSeBndeQJob8YAbOusdHN0zlWdTEtquKHG/XHbonM2ysAIYQl6MB 4=; IronPort-PHdr: =?us-ascii?q?9a23=3A1ntIyBY88LKJvWVxX1C6OHf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20Q+bRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavnayEzBuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8CACNIRhe/4YNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYF7gVQpJwVsD0kgBAsqhAmDRgOLAow/iUuEYoFCgRADVAkBAQEMAQEYAQw?= =?us-ascii?q?IAgEBg3tFAheBWSQ4EwIDDQEBBAEBAQIBBQRthTcMhV8CAQMBARARHQEBKgI?= =?us-ascii?q?DBQMBDwIBCBItAwICAh8GCxQDDgIEDgUUDoI5SwGBfU0DLgEOoBgCgTiIYXW?= =?us-ascii?q?BMoJ+AQEFhRUNC4IMAwaBNowZGoFBP4ERJyCBTlAuPoIbSQEBAoEpHEmCYzK?= =?us-ascii?q?CLI00UYINOYVXmCMxRAqCN4c7ikyEJhQHgkeHf5AilzKCIIwJg3ACBAIEBQI?= =?us-ascii?q?OAQEFgWkigVhwFTsqAYJBUBgNkk8MF4NQhRSFP3SBKJAsAQE?= X-IronPort-AV: E=Sophos;i="5.69,415,1571702400"; d="scan'208,217";a="401204104" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jan 2020 07:03:46 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00A73kdS009639 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Jan 2020 07:03:46 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 01:03:45 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 01:03:45 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 10 Jan 2020 01:03:45 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hzjdG6y8YEIQq/CZbg0hUxnhfYuwyshXlCTf6ZrGUmi7caGhVfboFhkd32f+EK6LCrpPCQCo5FrlGNr4wwGXN6H+XTKRvrmz7VzuVnElnEJ3dw3zrFSKzV4z+xnh4GqiCpzQHQD/6VkE7L4UaMCQTGA64DqeTkeOeJ27j8+4meiVTkJn2zQfqK2U3VGrJB1ALGePICEs6ka1lnNM4QLIv37JJlWlZ2tEYFJfCUHU7r0stdvrr6ulozsRsq8Zlo93C8P4qPmNNr48sVe47r8zLCTsd+UNeTKGq7DV0FyW1l2CGWEv2tlDW0aYgQkKUDwRrGkIKPkaCW+R45QEZPaflw== 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=UbYYqBK1B0TJLbvx9O0GFMFKDvltgMmhBc+fJXLefK4=; b=G7DAXaTzrtVyFzyiymnbbsQgydWdaRS43swmNe/s/DqF9+8gwkRvGn/MF6mgzuszYGhGIhXzr5PaexN0dNPF7KjIbUjrrhhHKZnBefxvmkBplBH3g4rCoL5UQMLW+Yjo16wxGBZziksh+E4jUHpdJH5mSBP9CsB6AlLbZIs5F4rSatkeEz4VQGJb77BsUC5WQU+T1MXpElINmZFcbW9pZR+5LlQfv0a8kX9JtNVtgDC8vZDcLD56oflcZRCx1kQUO2DJ4RXMatt39ivL6ZOhJo0rpHdoOi+KV3QCprJJPdU6nO5hKLOVt+miVSWgsoQG/m6/1tq62tqMvWUvX9Al8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UbYYqBK1B0TJLbvx9O0GFMFKDvltgMmhBc+fJXLefK4=; b=W0b1mCcTC9W74qImY0m4DJ19YA4FGBZjzE95195gQWCm4Z7gmhyEcm7kdrSUJqGZ6R7OPaPA2f1T10sUDS9/h3KbH1BqDb00lrdQa+td6fEpliNKEazcEcQlhGgOugszLnAKQgpAn3JHmHw7+wIkfwrOje91G7nc9N9KX3uXlEg= Received: from DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) by DM6PR11MB4041.namprd11.prod.outlook.com (20.176.125.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 10 Jan 2020 07:03:44 +0000 Received: from DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5]) by DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5%7]) with mapi id 15.20.2623.010; Fri, 10 Jan 2020 07:03:44 +0000 From: "Eliot Lear (elear)" To: Bernard Aboba CC: Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , "architecture-discuss@ietf.org" Subject: Re: [arch-d] Draft IAB conflict of interest policy Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmHmJFkBEFdAU6GRM36N32yCafijtKAgABlBgCAAIdkgA== Date: Fri, 10 Jan 2020 07:03:44 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> 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=elear@cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:e841:a75e:18e1:8e4c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef708c5e-7028-444c-dc74-08d7959b3b54 x-ms-traffictypediagnostic: DM6PR11MB4041: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(136003)(39860400002)(366004)(199004)(189003)(52314003)(8676002)(186003)(33656002)(6486002)(6512007)(5660300002)(71200400001)(6506007)(53546011)(2616005)(2906002)(478600001)(4326008)(66556008)(6916009)(64756008)(66574012)(66476007)(66946007)(66446008)(76116006)(8936002)(91956017)(81166006)(54906003)(966005)(81156014)(36756003)(316002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4041; H:DM6PR11MB3995.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iWfIXmMZRSMPHo1cRSEmCfzX1rkUt7pZ8O1onHZLW2Fzsem+EnNAX1JRTPYFRt2YdHxIhQa4QPUsVQxA1suTJilRlLh7Y7FM8CIeRpVABxEQN1OhCb5GZw9vhgOytv1p1r8pr515tZRU8J4tGibfJHl4T8xZu5DCYwCxEoMtNCJ388pWMQT2C1TgHwxWmSGdpsbrzrYRXzaL4ZVNSRj2DbAbv3sDPsTyb8dXQIJPOWNWn00igw2f2wTPQFhlLBqA7qwJn/8fyTjIsAqHVRqaoalHIswDFeaVEbZrnCyF0aRojpfLDTelE/K01uQZWS70ZS8ksar2VXP39pGpbjovo/NljEWbJIJKHq0nk+zj5XbDPXE20nmSYP0xPvq+pxSI5p9A5wIoa2FskSItbtAyUXkQbE0WqNM00jaSfRJksrQZel/VAqoIii7KfNO3v0RVUVjORUzJ71b2kLeWkyR/0xW6c+4X1Qeeoq1X2lY9Lp/MryZAO5/Pq+o/Z3zo5luoHyivuO6zVEODiZdkUvqxwVV55qLjr7hrC2Vx8bhi/To= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ef708c5e-7028-444c-dc74-08d7959b3b54 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 07:03:44.3011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Qb/k6wqAU8NMcJaPMYOCr6WavfA98OP0ZwiIoa7hajzJVmT0Fl/dGsWYzWludqXt X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4041 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 07:04:17 -0000 --_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFJpY2hhcmQsIEJlcm5hcmQsIGFuZCBFS1IuICBXaGVyZSBpbmRpdmlkdWFs cyBvbiB0aGUgSUVTRyBoYXZlIGdyZWF0IHBvd2VyLCB0aGlzIGdlbmVyYWxseSBjYW5ub3QgYmUg c2FpZCBhYm91dCBJQUIgbWVtYmVycywgIHdobyBsYXJnZWx5IG1ha2UgZGVjaXNpb25zIG9uIHJv dWdoIGNvbnNlbnN1cy4gICBUaGUgYXBwcm9wcmlhdGUgc2FmZWd1YXJkIGFnYWluc3QgQ09JIGlu IHRoZSBJQUIgaXMgdG8gaGF2ZSBhIGRpdmVyc2UgSUFCLCBhbmQgdGhlIE5PTUNPTSBhbmQgdGhl IElTT0MgQm9UIHNob3VsZCBzZWUgdG8gaXQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlIGFueXdheSwg c28gYXMgdG8gaGVscCB0aGUgY29tbXVuaXR5IGJlIHByZXBhcmVkIGZvciBUaGUgTmV4dCAodW5m b3Jlc2VlbikgUHJvYmxlbS4NCg0KRWxpb3QNCg0KT24gOSBKYW4gMjAyMCwgYXQgMjM6NTksIEJl cm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpBZ3JlZSB3aXRoIFJpY2hhcmQgaGVyZS4gIE11Y2ggb2Yg dGhlIElBQiB3b3JrIGlzIHRlY2huaWNhbCBpbiBuYXR1cmUuICBUaGUgSUFCIHNob3VsZCB0aGVy ZWZvcmUgbm90IG5lZWQgYSBjb25mbGljdC1vZi1pbnRlcmVzdCBwb2xpY3kgYXMgaGVhdnkgd2Vp Z2h0IGFzIHRoYXQgcmVxdWlyZWQgdG8gYXNzdW1lIGEgc2VuaW9yIHJvbGUgd2l0aGluIGdvdmVy bm1lbnQsIGEgbGVnaXNsYXR1cmUgb3IgYSBnb3Zlcm5tZW50YWwgYWR2aXNvcnkgY29tbWl0dGVl Lg0KDQpIYXZpbmcgc2VydmVkIG9uIGEgZ292ZXJubWVudGFsIGFkdmlzb3J5IGNvbW1pdHRlZSBj b3ZlcmVkIGJ5IEZBQ0EsIGl0IHdvdWxkIGFwcGVhciB0byBtZSB0aGF0IHRoZSBwcm9wb3NlZCBJ QUIgQ09JIHBvbGljeSBpcyBwb3RlbnRpYWxseSBtb3JlIHN0cmluZ2VudC4gIEFzIGFuIGV4YW1w bGUsIHVuZGVyIEZBQ0EgSSB3YXMgbm90IHJlcXVpcmVkIHRvIHByb3ZpZGUgYSBjb21wbGV0ZSBm aW5hbmNpYWwgZGlzY2xvc3VyZS4gIFRoZSBndWlkYW5jZSB3YXMgdGhhdCBhIGRpc2Nsb3N1cmUg bmVlZCBvbmx5IGJlIG1hZGUgaW4gdGhlIGV2ZW50IG9mIGEgcG90ZW50aWFsIGNvbmZsaWN0LCBz aG91bGQgb25lIGFyaXNlLg0KDQpPbiBUaHUsIEphbiA5LCAyMDIwIGF0IDg6NTggQU0gUmljaGFy ZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCkkgd291bGQg cHJvcG9zZSB0aGUgSUFCIG5vdCBhZG9wdCB0aGlzIHBvbGljeSwgb3IgYXQgbGVhc3Qgc2NvcGUg aXQgd2F5IGRvd24uDQoNCk11Y2ggb2YgdGhlIElBQidzIHdvcmsgaXMgZm9jdXNlZCBvbiB0ZWNo bmljYWwgaXNzdWVzLCBhdCBhIGhpZ2ggZW5vdWdoIHN0cmF0ZWdpYyBsZXZlbCB0aGF0IHRoZSBp bXBhY3RzIHRvIHNwZWNpZmljIHBlb3BsZSBvciBjb21wYW5pZXMgYXJlIGhpZ2hseSBhdHRlbnVh dGVkLiAgSW4gdGhvc2UgZGlzY3Vzc2lvbnMsIHRoZSBJQUIncyB3b3JrIGJlbmVmaXRzIGZyb20g aGF2aW5nIGRpdmVyc2Ugb3BpbmlvbnMsIGluY2x1ZGluZyB0aGUgb3BpbmlvbnMgb2YgdGhvc2Ug d2hvIGhhdmUgc2tpbiBpbiB0aGUgZ2FtZS4gIFRyeWluZyB0byBpbnRyb2R1Y2Ugc29tZSBub3Rp b24gb2YgQ29JIGluIHRoaXMgY29udGV4dCB3b3VsZCBiZSBoYXJtZnVsIC0tIGJlY2F1c2UgdGhl cmUncyBubyBoYXJkIGNvbmZsaWN0LCBpdCB3aWxsIGluZXZpdGFibHkgYmUgdmFndWUsIGFuZCB0 aHVzIHByaW1hcmlseSBhIHRvb2wgZm9yIElBQiBtZW1iZXJzIHRvIHRyeSB0byBzaWxlbmNlIG9u ZSBhbm90aGVyIG9yIGEgY2F1c2UgZm9yIElBQiBtZW1iZXJzIHRvIHNlbGYtY2Vuc29yLg0KDQpX aGVyZSB0aGUgSUFCIGlzIGRpcmVjdGx5IGludm9sdmVkIGluIGZpbmFuY2Ugb3IgcGVyc29ubmVs IGRlY2lzaW9ucywgdGhlcmUgb2YgY291cnNlIHNob3VsZCBiZSBndWFyZHMgYWdhaW5zdCBzZWxm IGRlYWxpbmcuICBUaGF0J3Mgd2hlcmUgYW55IENvSSBwb2xpY3kgZm9yIHRoZSBJQUIgc2hvdWxk IHN0b3AuDQoNCi0tUmljaGFyZA0KDQpPbiBXZWQsIEphbiA4LCAyMDIwIGF0IDY6MTYgUE0gSUFC IENoYWlyIDxpYWItY2hhaXJAaWFiLm9yZzxtYWlsdG86aWFiLWNoYWlyQGlhYi5vcmc+PiB3cm90 ZToNCg0KRGVhciBDb2xsZWFndWVzLA0KDQpUaGUgSUFCIGlzIGNvbnNpZGVyaW5nIGFkb3B0aW9u IG9mIHRoZSBjb25mbGljdCBvZiBpbnRlcmVzdCBwb2xpY3kgYmVsb3cuICBJZiB5b3UgaGF2ZSBj b21tZW50cyBvbiB0aGlzIGRyYWZ0IHBvbGljeSwgcGxlYXNlIHNlbmQgdGhlbSB0byBpYWJAaWFi Lm9yZzxtYWlsdG86aWFiQGlhYi5vcmc+Lg0KDQpiZXN0IHJlZ2FyZHMsDQoNClRlZCBIYXJkaWUN CmZvciB0aGUgSUFCDQoNCg0KDQpJTlRFUk5FVCBBUkNISVRFQ1RVUkUgQk9BUkQgQ09ORkxJQ1Qg T0YgSU5URVJFU1QgUE9MSUNZDQoNClRoaXMgcG9saWN5IGNvdmVycyB0aGUgbm9tY29tLXNlbGVj dGVkIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBtZW1iZXJzIGFuZCBleC1vZmZp Y2lvIG1lbWJlcnMgKGNvbGxlY3RpdmVseSwg4oCcQ292ZXJlZCBJbmRpdmlkdWFsc+KAnSkuIFRo aXMgcG9saWN5IGhhcyBubyBpbXBhY3Qgb24gYW55IG90aGVyIHBhcnRpY2lwYW50cyBpbiBJQUIg YWN0aXZpdGllcywgZm9yIGluc3RhbmNlIGxpYWlzb25zIHRvIGFuZCBmcm9tIHRoZSBJQUIgb3Ig SUFCIHByb2dyYW0gbWVtYmVycy4NCg0KSW4gY2Fycnlpbmcgb3V0IHRoZWlyIElBQiByb2xlLCBD b3ZlcmVkIEluZGl2aWR1YWxzIG11c3QgYWN0IGluIHRoZSBiZXN0IGludGVyZXN0IG9mIHRoZSBJ bnRlcm5ldCBjb21tdW5pdHkuIE9jY2FzaW9uYWxseSB0aGlzIGR1dHkgbWF5IGJl4oCUb3IgbWF5 IGFwcGVhciB0byBiZeKAlGluY29tcGF0aWJsZSBvciBpbiBjb25mbGljdCB3aXRoIGEgQ292ZXJl ZCBJbmRpdmlkdWFs4oCZcyBwZXJzb25hbCBpbnRlcmVzdHMgKGluY2x1ZGluZyBpbnRlcmVzdHMg b2YgdGhlaXIgZmFtaWx5IG1lbWJlcnMpLCBvciB0aGUgaW50ZXJlc3RzIG9mIGFuIG9yZ2FuaXph dGlvbiBvZiB3aGljaCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsIGlzIGFuIGVtcGxveWVlLCBkaXJl Y3Rvciwgb3duZXIsIG9yIG90aGVyd2lzZSBoYXMgYnVzaW5lc3Mgb3IgZmluYW5jaWFsIGludGVy ZXN0LiBJZiBhIENvdmVyZWQgSW5kaXZpZHVhbCBoYXMgYSBjb25mbGljdCBvZiBpbnRlcmVzdCBm b3Igd2hhdGV2ZXIgcmVhc29uLCB0aGF0IGluZGl2aWR1YWwgbXVzdCBhdm9pZCBwYXJ0aWNpcGF0 aW5nIGluIHRoZSB3b3JrIG9mIHRoZSBJQUIgdGhhdCB0b3VjaGVzIG9uIHRoZSByZWxhdGVkIG1h dHRlci4NCg0KVGhlIElBQiBkb2VzIG5vdCBkaXJlY3RseSBkZWFsIHdpdGggbWF0dGVycyByZWxh dGluZyB0byBjb250cmFjdHMgb3IgZmluYW5jZS4gVGhlIElBQiBkb2VzLCBob3dldmVyLCBoYXZl IGEgcm9sZSBpbiBwZXJzb25uZWwgZGVjaXNpb25zLCBhbmQgaXRzIGRlY2lzaW9ucyBhbmQgb3V0 cHV0cyBoYXZlIGEgcG90ZW50aWFsIHRvIGluZGlyZWN0bHkgYWZmZWN0IGNvbnRyYWN0cyB3aXRo aW4gdGhlIElFVEYgc3lzdGVtLiBJQUIncyB0ZWNobmljYWwgZGVjaXNpb25zIGFuZCBvdXRwdXRz IGhhdmUgYWxzbyBhIHBvdGVudGlhbCB0byBpbXBhY3QgYm90aCB3b3JrIGVsc2V3aGVyZSBpbiB0 aGUgSUVURiBhbmQgYnVzaW5lc3NlcyB0aGF0IGVtcGxveSBvciBkZXZlbG9wIEludGVybmV0IHRl Y2hub2xvZ3kuDQoNCkNvdmVyZWQgSW5kaXZpZHVhbHMgc2hhbGwgbm90IHVzZSB0aGUgSUFC4oCZ cyByZXNvdXJjZXMgb3IgZGVjaXNpb25zIGFzIGEgbWVhbnMgZm9yIHBlcnNvbmFsIG9yIHRoaXJk LXBhcnR5IGdhaW4uDQoNCkRpc2Nsb3N1cmUgb2YgQWN0dWFsIG9yIFBvdGVudGlhbCBDb25mbGlj dHMNCg0KVGhlIElBQiByZXF1aXJlcyB0aGF0IGFsbCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Ns b3NlIHRoZWlyIG1haW4gZW1wbG95bWVudCwgc3BvbnNvcnNoaXAsIGNvbnN1bHRpbmcgY3VzdG9t ZXIsIG9yIG90aGVyIHNvdXJjZXMgb2YgaW5jb21lIHdoZW4gam9pbmluZyB0aGUgSUFCIG9yIHdo ZW5ldmVyIHRoZXJlIGFyZSB1cGRhdGVzLg0KDQpJbiBhZGRpdGlvbiwgd2hlbiBhIHRvcGljIGlz IGRpc2N1c3NlZCBhdCB0aGUgSUFCLCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFscyBhcmUgcmVxdWly ZWQgdG8gcHJvbXB0bHkgZGlzY2xvc2UgaWYgdGhhdCB0b3BpYyBjb25zdGl0dXRlcyBhIHBlcmNl aXZlZCBvciBwb3RlbnRpYWwgY29uZmxpY3Qgb2YgaW50ZXJlc3QuIE9uY2UgZGlzY2xvc2VkLCBD b3ZlcmVkIEluZGl2aWR1YWxzIG1heSByZWN1c2UgZnJvbSBwYXJ0aWNpcGF0aW9uIGluIGRpc2N1 c3Npb25zIG9yIGRlY2lzaW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLg0KDQpUaGUgc3BlY2lmaWMg Y29uZmxpY3RzIHRoYXQgbWF5IGNhdXNlIGEgcGVyY2VpdmVkIG9yIHBvdGVudGlhbCBjb25mbGlj dCBvZiBpbnRlcmVzdCBhcmUgbWF0dGVycyBmb3IgaW5kaXZpZHVhbCBhbmQgSUFCIGp1ZGdtZW50 LCBidXQgZ2VuZXJhbGx5IGNvbWUgaW4gdGhlIGZvbGxvd2luZyBmb3JtczoNCg0KICAqICAgQSBw ZXJzb25uZWwgZGVjaXNpb24gcmVsYXRlcyB0byB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsLCBhIGNv bGxlYWd1ZSB0aGF0IHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwncyB3b3JrcyBjbG9zZWx5IHdpdGgs IG9yIGEgZmFtaWx5IG1lbWJlci4gRm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIHBvbGljeSwgYSAi cGVyc29uIHdvcmtpbmcgY2xvc2VseSB3aXRoIiBpcyBzb21lb25lIHdvcmtpbmcgaW4gdGhlIHNh bWUgdGVhbSBvciBwcm9qZWN0LCBvciBhIGRpcmVjdCBtYW5hZ2VyIG9yIGVtcGxveWVlIG9mIHRo ZSBDb3ZlcmVkIEluZGl2aWR1YWwuIEFuZCAiZmFtaWx5IiBtZWFucyBhIHNwb3VzZSwgZG9tZXN0 aWMgcGFydG5lciwgY2hpbGQsIHNpYmxpbmcsIHBhcmVudCwgc3RlcGNoaWxkLCBzdGVwcGFyZW50 LCBhbmQgbW90aGVyLSwgZmF0aGVyLSwgc29uLSwgZGF1Z2h0ZXItLCBicm90aGVyLSwgb3Igc2lz dGVyLWluLWxhdywgYW5kIGFueSBvdGhlciBwZXJzb24gbGl2aW5nIGluIHRoZSBzYW1lIGhvdXNl aG9sZCwgZXhjZXB0IHRlbmFudHMgYW5kIGhvdXNlaG9sZCBlbXBsb3llZXMuDQoNCiAgKiAgIEEg ZGVjaXNpb24gb3Igb3V0cHV0IGZyb20gdGhlIElBQiBpbXBhY3RzIGEgY29udHJhY3QgdGhhdCB0 aGUgSUVURiBlbnRlcnMgaW50byB3aXRoIGEgcGFydHksIGFuZCB0aGF0IHBhcnR5IHJlbGF0ZXMg dG8gdGhlIENvdmVyZWQgSW5kaXZpZHVhbCwgYSBjb2xsZWFndWUgdGhhdCB0aGUgQ292ZXJlZCBJ bmRpdmlkdWFsJ3Mgd29ya3MgY2xvc2VseSB3aXRoLCBvciBhIGZhbWlseSBtZW1iZXIuDQoNCiAg KiAgIEFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMgZGlzY3Vzc2lvbiBhbmQgZGVjaXNpb25z IHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFpbmx5IHJlbGF0ZWQgdG8gSUVURiBhY3Rp dml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0byBhIHN0YW5kYXJkaXphdGlvbiBwcm9j ZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENvdmVyZWQgSW5kaXZpZHVhbHMgd2lsbCBo YXZlIHNvbWUgKGZyZXF1ZW50bHkgbm9uLWZpbmFuY2lhbCkgc3Rha2UgaW4gdGhlIG91dGNvbWUg b2YgZGlzY3Vzc2lvbnMgb3IgZGVjaXNpb25zIHRoYXQgcmVsYXRlIHRvIHRlY2huaWNhbCBtYXR0 ZXJzLiBUaGlzIHBvbGljeSBkb2VzIG5vdCByZXF1aXJlIHRoYXQgQ292ZXJlZCBJbmRpdmlkdWFs cyBkaXNjbG9zZSBzdWNoIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBhcyB0aGV5IHJlbGF0ZSB0byB0 ZWNobmljYWwgbWF0dGVycy4gSG93ZXZlciwgQ292ZXJlZCBJbmRpdmlkdWFscyBuZWVkIHRvIGV4 ZXJjaXNlIHRoZWlyIGp1ZGdtZW50IGFuZCwgaW4gZXh0cmFvcmRpbmFyeSBjYXNlcyBiZSB3aWxs aW5nIHRvIGRpc2Nsb3NlIHBvdGVudGlhbCBvciBwZXJjZWl2ZWQgY29uZmxpY3RzIG9mIGludGVy ZXN0IGV2ZW4gYXMgdGhleSByZWxhdGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIEZvciBleGFtcGxl LCBpZiBhIENvdmVyZWQgSW5kaXZpZHVhbCdzIHNwb25zb3Igd2VyZSBpbiB0aGUgcHJvY2VzcyBv ZiBlbnRlcmluZyBhIG5ldyBtYXJrZXQgd2hlcmUgdGhlcmUgaXMgYW4gb25nb2luZyBJQUIgZGlz Y3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBvciBldmVuIHJlY3VzYWwsIG1pZ2h0IGJlIGFwcHJv cHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC4NCg0KRGlzY2xvc3VyZSBUcmFuc3BhcmVuY3kNCg0K QSBwZXJzb24ncyByZWN1c2FsIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNzaW9uIG9mIGEg dG9waWMgaXMgYWx3YXlzIG5vdGVkIGluIHRoZSBwdWJsaWMgSUFCIG1pbnV0ZXMuIEluIGFkZGl0 aW9uLCB0aGUgSUFCIHdpbGwgbWFpbnRhaW4gYSByZXBvc2l0b3J5IG9mIGFsbCBnZW5lcmFsIGRp c2Nsb3N1cmVzIG9mIGVtcGxveW1lbnQgYW5kIG90aGVyIHNwb25zb3JzaGlwLiBJdCBpcyBleHBl Y3RlZCB0aGF0IG11Y2ggb2YgdGhpcyByZXBvc2l0b3J5IGlzIHB1YmxpYywgYnV0IHRoZXJlIGNh biBiZSBzaXR1YXRpb25zIHdoZXJlIHNvbWUgZGlzY2xvc3VyZXMgKHN1Y2ggYXMgY3VzdG9tZXJz IG9mIGNvbnN1bHRhbnRzKSBhcmUgcHJpdmF0ZS4NCg0KDQo8aHR0cHM6Ly9naXRodWIuY29tL2ph cmlhcmtrby9hbHRlcm5hdGUtaWFiLWNvaS1wb2xpY3kvYmxvYi9tYXN0ZXIvY29pLXBvbGljeS4u bWQjc3RhdHVzPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpBcmNoaXRlY3R1cmUtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCkFyY2hpdGVjdHVyZS1k aXNjdXNzQGlldGYub3JnPG1haWx0bzpBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBcmNoaXRl Y3R1cmUtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCkFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3Jn PG1haWx0bzpBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MNCg0K --_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C00E35C69C96646B5902F8838170874@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWdyZWUgd2l0aCBSaWNoYXJkLCBCZXJuYXJk LCBhbmQgRUtSLiAmbmJzcDtXaGVyZSBpbmRpdmlkdWFscyBvbiB0aGUgSUVTRyBoYXZlIGdyZWF0 IHBvd2VyLCB0aGlzIGdlbmVyYWxseSBjYW5ub3QgYmUgc2FpZCBhYm91dCBJQUIgbWVtYmVycywg Jm5ic3A7d2hvIGxhcmdlbHkgbWFrZSBkZWNpc2lvbnMgb24gcm91Z2ggY29uc2Vuc3VzLiAmbmJz cDsgVGhlIGFwcHJvcHJpYXRlIHNhZmVndWFyZCBhZ2FpbnN0IENPSSBpbiB0aGUgSUFCIGlzIHRv IGhhdmUgYSBkaXZlcnNlDQogSUFCLCBhbmQgdGhlIE5PTUNPTSBhbmQgdGhlIElTT0MgQm9UIHNo b3VsZCBzZWUgdG8gaXQgdGhhdCB0aGlzIGlzIHRoZSBjYXNlIGFueXdheSwgc28gYXMgdG8gaGVs cCB0aGUgY29tbXVuaXR5IGJlIHByZXBhcmVkIGZvciBUaGUgTmV4dCAodW5mb3Jlc2VlbikgUHJv YmxlbS4mbmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkVsaW90PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA5IEphbiAyMDIwLCBhdCAyMzo1OSwgQmVybmFyZCBB Ym9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiBjbGFzcz0i Ij5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj5BZ3JlZSB3aXRoIFJpY2hhcmQgaGVyZS4mbmJzcDsgTXVjaCBvZiB0aGUg SUFCIHdvcmsgaXMgdGVjaG5pY2FsIGluIG5hdHVyZS4mbmJzcDsgVGhlIElBQiBzaG91bGQgdGhl cmVmb3JlIG5vdCBuZWVkIGEgY29uZmxpY3Qtb2YtaW50ZXJlc3QgcG9saWN5IGFzIGhlYXZ5IHdl aWdodCBhcyB0aGF0IHJlcXVpcmVkIHRvIGFzc3VtZSBhIHNlbmlvciByb2xlIHdpdGhpbiBnb3Zl cm5tZW50LCBhIGxlZ2lzbGF0dXJlIG9yIGEgZ292ZXJubWVudGFsDQogYWR2aXNvcnkgY29tbWl0 dGVlLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SGF2aW5nIHNlcnZlZCBvbiBhIGdvdmVybm1lbnRhbCBhZHZpc29yeSBjb21taXR0ZWUg Y292ZXJlZCBieSBGQUNBLCBpdCB3b3VsZCBhcHBlYXIgdG8gbWUgdGhhdCB0aGUgcHJvcG9zZWQg SUFCIENPSSBwb2xpY3kgaXMgcG90ZW50aWFsbHkgbW9yZSBzdHJpbmdlbnQuJm5ic3A7IEFzIGFu IGV4YW1wbGUsIHVuZGVyIEZBQ0EgSSB3YXMgbm90IHJlcXVpcmVkIHRvIHByb3ZpZGUgYSBjb21w bGV0ZSBmaW5hbmNpYWwgZGlzY2xvc3VyZS4mbmJzcDsNCiBUaGUgZ3VpZGFuY2Ugd2FzIHRoYXQg YSBkaXNjbG9zdXJlIG5lZWQgb25seSBiZSBtYWRlIGluIHRoZSBldmVudCBvZiBhIHBvdGVudGlh bCBjb25mbGljdCwgc2hvdWxkIG9uZSBhcmlzZS4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 ImdtYWlsX2F0dHIiPk9uIFRodSwgSmFuIDksIDIwMjAgYXQgODo1OCBBTSBSaWNoYXJkIEJhcm5l cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIGNsYXNzPSIiPnJsYkBpcHYuc3g8L2E+ Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIHdvdWxkIHByb3Bvc2UgdGhlIElBQiBub3QgYWRv cHQgdGhpcyBwb2xpY3ksIG9yIGF0IGxlYXN0IHNjb3BlIGl0IHdheSBkb3duLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TXVjaCBvZiB0 aGUgSUFCJ3Mgd29yayBpcyBmb2N1c2VkIG9uIHRlY2huaWNhbCBpc3N1ZXMsIGF0IGEgaGlnaCBl bm91Z2ggc3RyYXRlZ2ljIGxldmVsIHRoYXQgdGhlIGltcGFjdHMgdG8gc3BlY2lmaWMgcGVvcGxl IG9yIGNvbXBhbmllcyBhcmUgaGlnaGx5IGF0dGVudWF0ZWQuJm5ic3A7IEluIHRob3NlIGRpc2N1 c3Npb25zLCB0aGUgSUFCJ3Mgd29yayBiZW5lZml0cyBmcm9tIGhhdmluZyBkaXZlcnNlIG9waW5p b25zLCBpbmNsdWRpbmcNCiB0aGUgb3BpbmlvbnMgb2YgdGhvc2Ugd2hvIGhhdmUgc2tpbiBpbiB0 aGUgZ2FtZS4mbmJzcDsgVHJ5aW5nIHRvIGludHJvZHVjZSBzb21lIG5vdGlvbiBvZiBDb0kgaW4g dGhpcyBjb250ZXh0IHdvdWxkIGJlIGhhcm1mdWwgLS0gYmVjYXVzZSB0aGVyZSdzIG5vIGhhcmQg Y29uZmxpY3QsIGl0IHdpbGwgaW5ldml0YWJseSBiZSB2YWd1ZSwgYW5kIHRodXMgcHJpbWFyaWx5 IGEgdG9vbCBmb3IgSUFCIG1lbWJlcnMgdG8gdHJ5IHRvIHNpbGVuY2Ugb25lIGFub3RoZXINCiBv ciBhIGNhdXNlIGZvciBJQUIgbWVtYmVycyB0byBzZWxmLWNlbnNvci48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PldoZXJlIHRoZSBJQUIgaXMgZGlyZWN0bHkgaW52b2x2ZWQgaW4gZmluYW5jZSBvciBwZXJzb25u ZWwgZGVjaXNpb25zLCB0aGVyZSBvZiBjb3Vyc2Ugc2hvdWxkIGJlIGd1YXJkcyBhZ2FpbnN0IHNl bGYgZGVhbGluZy4mbmJzcDsgVGhhdCdzIHdoZXJlIGFueSBDb0kgcG9saWN5IGZvciB0aGUgSUFC IHNob3VsZCBzdG9wLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+LS1SaWNoYXJkPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJnbWFpbF9hdHRyIj5PbiBXZWQsIEphbiA4LCAyMDIwIGF0IDY6MTYgUE0gSUFCIENoYWly ICZsdDs8YSBocmVmPSJtYWlsdG86aWFiLWNoYWlyQGlhYi5vcmciIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5pYWItY2hhaXJAaWFiLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJBcmlhbCIgY2xhc3M9IiI+ PGZvbnQgc2l6ZT0iJiM0MzszIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0 LDM0KTtmb250LXNpemU6c21hbGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0 dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0 ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10 cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3Jv dW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7 dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7ZGlzcGxheTppbmxpbmU7ZmxvYXQ6bm9uZSIg Y2xhc3M9IiI+PC9zcGFuPjwvZm9udD48L2ZvbnQ+DQo8cCBzdHlsZT0iY29sb3I6cmdiKDM0LDM0 LDM0KTtmb250LWZhbWlseTpBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21h bGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12 YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0 ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUs MjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNv bG9yOmluaXRpYWwiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PHNwYW4gZGlyPSJsdHIiIG5h bWU9ImFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3JnIiBjbGFzcz0iIj48L3NwYW4+PC9zcGFu Pjxmb250IHNpemU9IiYjNDM7MSIgY2xhc3M9IiI+RGVhciBDb2xsZWFndWVzLDwvZm9udD48L3A+ DQo8cCBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZhbWlseTpBcmlhbCxIZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJp YW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0 OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDow cHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBw eDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxl OmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwiIGNsYXNzPSIiPg0KPGZvbnQg c2l6ZT0iJiM0MzsxIiBjbGFzcz0iIj5UaGUgSUFCIGlzIGNvbnNpZGVyaW5nIGFkb3B0aW9uIG9m IHRoZSBjb25mbGljdCBvZiBpbnRlcmVzdCBwb2xpY3kgYmVsb3cuJm5ic3A7IElmIHlvdSBoYXZl IGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQgcG9saWN5LCBwbGVhc2Ugc2VuZCB0aGVtIHRvPHNwYW4g Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppYWJAaWFiLm9yZyIgc3R5bGU9 ImNvbG9yOnJnYigxNyw4NSwyMDQpIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aWFiQGlhYi5v cmc8L2E+LjwvZm9udD48L3A+DQo8cCBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KTtmb250LWZh bWlseTpBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGw7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpz dGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3Jt YWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7dGV4 dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWwi IGNsYXNzPSIiPg0KPGZvbnQgc2l6ZT0iJiM0MzsxIiBjbGFzcz0iIj5iZXN0IHJlZ2FyZHMsPC9m b250PjwvcD4NCjxmb250IHNpemU9IiYjNDM7MSIgY2xhc3M9IiI+VGVkIEhhcmRpZTwvZm9udD48 YnIgY2xhc3M9IiI+DQo8Zm9udCBzaXplPSImIzQzOzEiIGNsYXNzPSIiPmZvciB0aGUgSUFCPGJy IGNsYXNzPSIiPg0KPC9mb250PjxiciBjbGFzcz0iIj4NCjxmb250IHNpemU9IiYjNDM7MiIgY2xh c3M9IiI+PGZvbnQgc2l6ZT0iJiM0MzszIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6cmdi KDM0LDM0LDM0KTtmb250LWZhbWlseTpBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGw7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7 Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDtsZXR0ZXItc3BhY2luZzpu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9u ZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJn YigyNTUsMjU1LDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0 aW9uLWNvbG9yOmluaXRpYWw7ZGlzcGxheTppbmxpbmU7ZmxvYXQ6bm9uZSIgY2xhc3M9IiI+PC9z cGFuPjwvZm9udD48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNs YXNzPSIiPjxzcGFuIGRpcj0ibHRyIiBuYW1lPSJhcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9y ZyIgY2xhc3M9IiI+PC9zcGFuPjwvc3Bhbj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhv bGRlciI+DQo8L2Rpdj4NCjxoMyBjbGFzcz0iIj5JTlRFUk5FVCBBUkNISVRFQ1RVUkUgQk9BUkQg Q09ORkxJQ1QgT0YgSU5URVJFU1QgUE9MSUNZPC9oMz4NCjxwIGNsYXNzPSIiPlRoaXMgcG9saWN5 IGNvdmVycyB0aGUgbm9tY29tLXNlbGVjdGVkIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAo SUFCKSBtZW1iZXJzIGFuZCBleC1vZmZpY2lvIG1lbWJlcnMgKGNvbGxlY3RpdmVseSwg4oCcQ292 ZXJlZCBJbmRpdmlkdWFsc+KAnSkuIFRoaXMgcG9saWN5IGhhcyBubyBpbXBhY3Qgb24gYW55IG90 aGVyIHBhcnRpY2lwYW50cyBpbiBJQUIgYWN0aXZpdGllcywgZm9yIGluc3RhbmNlIGxpYWlzb25z IHRvIGFuZCBmcm9tDQogdGhlIElBQiBvciBJQUIgcHJvZ3JhbSBtZW1iZXJzLjwvcD4NCjxwIGNs YXNzPSIiPkluIGNhcnJ5aW5nIG91dCB0aGVpciBJQUIgcm9sZSwgQ292ZXJlZCBJbmRpdmlkdWFs cyBtdXN0IGFjdCBpbiB0aGUgYmVzdCBpbnRlcmVzdCBvZiB0aGUgSW50ZXJuZXQgY29tbXVuaXR5 LiBPY2Nhc2lvbmFsbHkgdGhpcyBkdXR5IG1heSBiZeKAlG9yIG1heSBhcHBlYXIgdG8gYmXigJRp bmNvbXBhdGlibGUgb3IgaW4gY29uZmxpY3Qgd2l0aCBhIENvdmVyZWQgSW5kaXZpZHVhbOKAmXMg cGVyc29uYWwgaW50ZXJlc3RzIChpbmNsdWRpbmcNCiBpbnRlcmVzdHMgb2YgdGhlaXIgZmFtaWx5 IG1lbWJlcnMpLCBvciB0aGUgaW50ZXJlc3RzIG9mIGFuIG9yZ2FuaXphdGlvbiBvZiB3aGljaCB0 aGUgQ292ZXJlZCBJbmRpdmlkdWFsIGlzIGFuIGVtcGxveWVlLCBkaXJlY3Rvciwgb3duZXIsIG9y IG90aGVyd2lzZSBoYXMgYnVzaW5lc3Mgb3IgZmluYW5jaWFsIGludGVyZXN0LiBJZiBhIENvdmVy ZWQgSW5kaXZpZHVhbCBoYXMgYSBjb25mbGljdCBvZiBpbnRlcmVzdCBmb3Igd2hhdGV2ZXIgcmVh c29uLA0KIHRoYXQgaW5kaXZpZHVhbCBtdXN0IGF2b2lkIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHdv cmsgb2YgdGhlIElBQiB0aGF0IHRvdWNoZXMgb24gdGhlIHJlbGF0ZWQgbWF0dGVyLjwvcD4NCjxw IGNsYXNzPSIiPlRoZSBJQUIgZG9lcyBub3QgZGlyZWN0bHkgZGVhbCB3aXRoIG1hdHRlcnMgcmVs YXRpbmcgdG8gY29udHJhY3RzIG9yIGZpbmFuY2UuIFRoZSBJQUIgZG9lcywgaG93ZXZlciwgaGF2 ZSBhIHJvbGUgaW4gcGVyc29ubmVsIGRlY2lzaW9ucywgYW5kIGl0cyBkZWNpc2lvbnMgYW5kIG91 dHB1dHMgaGF2ZSBhIHBvdGVudGlhbCB0byBpbmRpcmVjdGx5IGFmZmVjdCBjb250cmFjdHMgd2l0 aGluIHRoZSBJRVRGIHN5c3RlbS4gSUFCJ3MNCiB0ZWNobmljYWwgZGVjaXNpb25zIGFuZCBvdXRw dXRzIGhhdmUgYWxzbyBhIHBvdGVudGlhbCB0byBpbXBhY3QgYm90aCB3b3JrIGVsc2V3aGVyZSBp biB0aGUgSUVURiBhbmQgYnVzaW5lc3NlcyB0aGF0IGVtcGxveSBvciBkZXZlbG9wIEludGVybmV0 IHRlY2hub2xvZ3kuPC9wPg0KPHAgY2xhc3M9IiI+Q292ZXJlZCBJbmRpdmlkdWFscyBzaGFsbCBu b3QgdXNlIHRoZSBJQULigJlzIHJlc291cmNlcyBvciBkZWNpc2lvbnMgYXMgYSBtZWFucyBmb3Ig cGVyc29uYWwgb3IgdGhpcmQtcGFydHkgZ2Fpbi48L3A+DQo8aDMgY2xhc3M9IiI+RGlzY2xvc3Vy ZSBvZiBBY3R1YWwgb3IgUG90ZW50aWFsIENvbmZsaWN0czwvaDM+DQo8cCBjbGFzcz0iIj5UaGUg SUFCIHJlcXVpcmVzIHRoYXQgYWxsIENvdmVyZWQgSW5kaXZpZHVhbHMgZGlzY2xvc2UgdGhlaXIg bWFpbiBlbXBsb3ltZW50LCBzcG9uc29yc2hpcCwgY29uc3VsdGluZyBjdXN0b21lciwgb3Igb3Ro ZXIgc291cmNlcyBvZiBpbmNvbWUgd2hlbiBqb2luaW5nIHRoZSBJQUIgb3Igd2hlbmV2ZXIgdGhl cmUgYXJlIHVwZGF0ZXMuPC9wPg0KPHAgY2xhc3M9IiI+SW4gYWRkaXRpb24sIHdoZW4gYSB0b3Bp YyBpcyBkaXNjdXNzZWQgYXQgdGhlIElBQiwgdGhlIENvdmVyZWQgSW5kaXZpZHVhbHMgYXJlIHJl cXVpcmVkIHRvIHByb21wdGx5IGRpc2Nsb3NlIGlmIHRoYXQgdG9waWMgY29uc3RpdHV0ZXMgYSBw ZXJjZWl2ZWQgb3IgcG90ZW50aWFsIGNvbmZsaWN0IG9mIGludGVyZXN0LiBPbmNlIGRpc2Nsb3Nl ZCwgQ292ZXJlZCBJbmRpdmlkdWFscyBtYXkgcmVjdXNlIGZyb20gcGFydGljaXBhdGlvbg0KIGlu IGRpc2N1c3Npb25zIG9yIGRlY2lzaW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLjwvcD4NCjxwIGNs YXNzPSIiPlRoZSBzcGVjaWZpYyBjb25mbGljdHMgdGhhdCBtYXkgY2F1c2UgYSBwZXJjZWl2ZWQg b3IgcG90ZW50aWFsIGNvbmZsaWN0IG9mIGludGVyZXN0IGFyZSBtYXR0ZXJzIGZvciBpbmRpdmlk dWFsIGFuZCBJQUIganVkZ21lbnQsIGJ1dCBnZW5lcmFsbHkgY29tZSBpbiB0aGUgZm9sbG93aW5n IGZvcm1zOjwvcD4NCjx1bCBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPkEg cGVyc29ubmVsIGRlY2lzaW9uIHJlbGF0ZXMgdG8gdGhlIENvdmVyZWQgSW5kaXZpZHVhbCwgYSBj b2xsZWFndWUgdGhhdCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsJ3Mgd29ya3MgY2xvc2VseSB3aXRo LCBvciBhIGZhbWlseSBtZW1iZXIuIEZvciB0aGUgcHVycG9zZXMgb2YgdGhpcyBwb2xpY3ksIGEg JnF1b3Q7cGVyc29uIHdvcmtpbmcgY2xvc2VseSB3aXRoJnF1b3Q7IGlzIHNvbWVvbmUgd29ya2lu ZyBpbiB0aGUgc2FtZSB0ZWFtIG9yIHByb2plY3QsDQogb3IgYSBkaXJlY3QgbWFuYWdlciBvciBl bXBsb3llZSBvZiB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsLiBBbmQgJnF1b3Q7ZmFtaWx5JnF1b3Q7 IG1lYW5zIGEgc3BvdXNlLCBkb21lc3RpYyBwYXJ0bmVyLCBjaGlsZCwgc2libGluZywgcGFyZW50 LCBzdGVwY2hpbGQsIHN0ZXBwYXJlbnQsIGFuZCBtb3RoZXItLCBmYXRoZXItLCBzb24tLCBkYXVn aHRlci0sIGJyb3RoZXItLCBvciBzaXN0ZXItaW4tbGF3LCBhbmQgYW55IG90aGVyIHBlcnNvbiBs aXZpbmcgaW4gdGhlIHNhbWUNCiBob3VzZWhvbGQsIGV4Y2VwdCB0ZW5hbnRzIGFuZCBob3VzZWhv bGQgZW1wbG95ZWVzLjwvcD4NCjwvbGk+PGxpIGNsYXNzPSIiPg0KPHAgY2xhc3M9IiI+QSBkZWNp c2lvbiBvciBvdXRwdXQgZnJvbSB0aGUgSUFCIGltcGFjdHMgYSBjb250cmFjdCB0aGF0IHRoZSBJ RVRGIGVudGVycyBpbnRvIHdpdGggYSBwYXJ0eSwgYW5kIHRoYXQgcGFydHkgcmVsYXRlcyB0byB0 aGUgQ292ZXJlZCBJbmRpdmlkdWFsLCBhIGNvbGxlYWd1ZSB0aGF0IHRoZSBDb3ZlcmVkIEluZGl2 aWR1YWwncyB3b3JrcyBjbG9zZWx5IHdpdGgsIG9yIGEgZmFtaWx5IG1lbWJlci48L3A+DQo8L2xp PjxsaSBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPkFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMg ZGlzY3Vzc2lvbiBhbmQgZGVjaXNpb25zIHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFp bmx5IHJlbGF0ZWQgdG8gSUVURiBhY3Rpdml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0 byBhIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENv dmVyZWQgSW5kaXZpZHVhbHMgd2lsbCBoYXZlIHNvbWUgKGZyZXF1ZW50bHkNCiBub24tZmluYW5j aWFsKSBzdGFrZSBpbiB0aGUgb3V0Y29tZSBvZiBkaXNjdXNzaW9ucyBvciBkZWNpc2lvbnMgdGhh dCByZWxhdGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIFRoaXMgcG9saWN5IGRvZXMgbm90IHJlcXVp cmUgdGhhdCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Nsb3NlIHN1Y2ggY29uZmxpY3RzIG9mIGlu dGVyZXN0IGFzIHRoZXkgcmVsYXRlIHRvIHRlY2huaWNhbCBtYXR0ZXJzLiBIb3dldmVyLCBDb3Zl cmVkIEluZGl2aWR1YWxzIG5lZWQNCiB0byBleGVyY2lzZSB0aGVpciBqdWRnbWVudCBhbmQsIGlu IGV4dHJhb3JkaW5hcnkgY2FzZXMgYmUgd2lsbGluZyB0byBkaXNjbG9zZSBwb3RlbnRpYWwgb3Ig cGVyY2VpdmVkIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBldmVuIGFzIHRoZXkgcmVsYXRlIHRvIHRl Y2huaWNhbCBtYXR0ZXJzLiBGb3IgZXhhbXBsZSwgaWYgYSBDb3ZlcmVkIEluZGl2aWR1YWwncyBz cG9uc29yIHdlcmUgaW4gdGhlIHByb2Nlc3Mgb2YgZW50ZXJpbmcgYSBuZXcgbWFya2V0DQogd2hl cmUgdGhlcmUgaXMgYW4gb25nb2luZyBJQUIgZGlzY3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBv ciBldmVuIHJlY3VzYWwsIG1pZ2h0IGJlIGFwcHJvcHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC48 L3A+DQo8L2xpPjwvdWw+DQo8aDMgY2xhc3M9IiI+RGlzY2xvc3VyZSBUcmFuc3BhcmVuY3k8L2gz Pg0KPHAgY2xhc3M9IiI+QSBwZXJzb24ncyByZWN1c2FsIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBk aXNjdXNzaW9uIG9mIGEgdG9waWMgaXMgYWx3YXlzIG5vdGVkIGluIHRoZSBwdWJsaWMgSUFCIG1p bnV0ZXMuIEluIGFkZGl0aW9uLCB0aGUgSUFCIHdpbGwgbWFpbnRhaW4gYSByZXBvc2l0b3J5IG9m IGFsbCBnZW5lcmFsIGRpc2Nsb3N1cmVzIG9mIGVtcGxveW1lbnQgYW5kIG90aGVyIHNwb25zb3Jz aGlwLiBJdCBpcyBleHBlY3RlZCB0aGF0IG11Y2ggb2YNCiB0aGlzIHJlcG9zaXRvcnkgaXMgcHVi bGljLCBidXQgdGhlcmUgY2FuIGJlIHNpdHVhdGlvbnMgd2hlcmUgc29tZSBkaXNjbG9zdXJlcyAo c3VjaCBhcyBjdXN0b21lcnMgb2YgY29uc3VsdGFudHMpIGFyZSBwcml2YXRlLjwvcD4NCjxoMSBj bGFzcz0iIj48YSBpZD0iZ21haWwtbV82NjU4NTkxOTc1MTQ0OTAzMDE1Z21haWwtbV8tMzg2NDM1 Mjc2MjYwNDkxNDQ1M3VzZXItY29udGVudC1zdGF0dXMiIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9qYXJpYXJra28vYWx0ZXJuYXRlLWlhYi1jb2ktcG9saWN5L2Jsb2IvbWFzdGVyL2NvaS1wb2xp Y3kuLm1kI3N0YXR1cyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjx1IGNsYXNzPSIiPjwvdT48 YnIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+PC9hPjwvaDE+DQo8cCBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48c3BhbiBkaXI9Imx0ciIgbmFtZT0iYXJjaGl0ZWN0 dXJlLWRpc2N1c3NAaWV0Zi5vcmciIGNsYXNzPSIiPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOkFyY2hpdGVjdHVyZS1kaXNjdXNz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+QXJjaGl0ZWN0dXJlLWRpc2N1c3NA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcmNoaXRlY3R1cmUtZGlzY3VzcyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcmNoaXRlY3R1cmUtZGlzY3VzczwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0KQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOkFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3JnIiBjbGFz cz0iIj5BcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FyY2hpdGVjdHVyZS1kaXNjdXNzPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E56C960BEFF447EAAB62C441B4FD3354ciscocom_-- From nobody Fri Jan 10 10:42:14 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7576F120AC4; Fri, 10 Jan 2020 10:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mCIHi-1gyBvK; Fri, 10 Jan 2020 10:42:09 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09ED61208F5; Fri, 10 Jan 2020 10:42:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 656CB9AE102D; Fri, 10 Jan 2020 12:42:05 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFbuNK0yJB4D; Fri, 10 Jan 2020 12:42:02 -0600 (CST) Received: from [172.16.1.18] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 6FC2F9AE1023; Fri, 10 Jan 2020 12:42:02 -0600 (CST) From: "Pete Resnick" To: "Eric Rescorla" Cc: "Joe Touch" , "Richard Barnes" , "IAB Chair" , IAB , "IETF discussion list" , architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Fri, 10 Jan 2020 12:42:02 -0600 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <2377bee131af6f5a6f5a1104bc25e056@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 18:42:14 -0000 On 9 Jan 2020, at 17:59, Eric Rescorla wrote: > On Thu, Jan 9, 2020 at 2:40 PM Joe Touch wrote: > >> On 2020-01-09 10:46, Eric Rescorla wrote: >> >> The IETF is most successful when we get >> input from people who are directly involved in the technologies that >> we are standardizing, but of course that very often means that they >> are working on those technologies for their employer. >> >> But it is dangerous to have those parties directly involved in >> decision >> making. The actual and potential COI (esp. perceived potential COI) >> undermine the decisions made - even when those decisions are >> otherwise >> reasonable. >> >> I.e., think of this as protecting the value of IAB decisions (and, as >> Ben >> noted, there are many, esp. during appeals, that are of a substantive >> nature that COI benefits). > > And yet we routinely allow have WG chairs and ADs who are deeply > involved > (and whose employers are deeply involved) in the technologies that are > being standardized. One important difference with chairs (and even ADs) is that their technical/standardization decisions can be appealed, where potential conflicts of interest can presumably be removed from the equation. That's not true of the IAB. So while I agree with Richard that it's the mainly the personnel and finance decisions that need a CoI policy, it's probably also useful to have it apply in those relatively few discussions of the IAB that result in an actual *decision* (handling appeals, perhaps some odd liaison activities). So it's really the third bullet in the proposal that needs to be reduced. That said, for all of this I think transparency is the most important bit, not the recusal. So long as everyone is open about their possible biases, the others in the discussion can take those into account and adjust. The NomCom processes can be used for people who do not appropriately disclose. And on that note: It's not just recusal that should be minuted; if someone discloses a perceived or potential CoI, whether or not they recuse, that should be noted (appropriately redacted if necessary). pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Fri Jan 10 10:58:48 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A608E120804; Fri, 10 Jan 2020 10:58:46 -0800 (PST) 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, HTML_MESSAGE=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 0SjNl1mNrME4; Fri, 10 Jan 2020 10:58:44 -0800 (PST) Received: from rtp-alcoop-nitro2.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 583591200FA; Fri, 10 Jan 2020 10:58:44 -0800 (PST) From: IETF Chair Content-Type: multipart/alternative; boundary="Apple-Mail=_5E52C7B7-F6A9-476D-BD58-DF76122ABCFB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: IETF 107 Birds of a Feather (BOF) proposals due in 4 weeks Message-Id: Date: Fri, 10 Jan 2020 13:58:41 -0500 To: IETF-Announce , IETF discussion list X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 18:58:47 -0000 --Apple-Mail=_5E52C7B7-F6A9-476D-BD58-DF76122ABCFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wanted to remind everyone that proposals for "Birds of a Feather=E2=80=9D= (BOF) sessions at IETF 107 are due no later than Friday, 7 February at = 23:59 UTC.=20 Instructions for submitting your proposal are available at: = https://www.ietf.org/how/bofs/bof-procedures/ = =20 Please also read RFC 5434 (https://tools.ietf.org/html/rfc5434 = ), Considerations for Having a = Successful Birds-of-a-Feather Session, if you are not familiar with it.=20= If you are working on a BOF request but you=E2=80=99re not quite ready = to submit it, please tell the IESG now by sending an email to = iesg@ietf.org to get advance help with the = request. We have a number of ways of bringing new work into the IETF and = BOFs are just one of them, so please talk to the IESG or an individual = Area Director (https://www.ietf.org/about/groups/iesg/members/ = ) about your idea if = you=E2=80=99re thinking about proposing a BOF. IETF 107 will take place March 21-27, Vancouver. More information is = available at: https://www.ietf.org/how/meetings/107/ = Best, Alissa Cooper IETF Chair= --Apple-Mail=_5E52C7B7-F6A9-476D-BD58-DF76122ABCFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = wanted to remind everyone that proposals for "Birds of a Feather=E2=80=9D = (BOF) sessions at IETF 107 are due no later than Friday, 7 February at = 23:59 UTC. 

Instructions for = submitting your proposal are available at: https://www.ietf.org/how/bofs/bof-procedures/ 

Please also read RFC 5434 (https://tools.ietf.org/html/rfc5434), Considerations for = Having a Successful Birds-of-a-Feather Session, if you are not familiar = with it. 

If you are working on a BOF = request but you=E2=80=99re not quite ready to submit it, please tell the = IESG now by sending an email to iesg@ietf.org to get advance help with the request. = We have a number of ways of bringing new work into the IETF and BOFs are = just one of them, so please talk to the IESG or an individual Area = Director (https://www.ietf.org/about/groups/iesg/members/) about = your idea if you=E2=80=99re thinking about proposing a BOF.

IETF 107 will take place March 21-27, = Vancouver. More information is available at: https://www.ietf.org/how/meetings/107/

Best,
Alissa Cooper
IETF = Chair= --Apple-Mail=_5E52C7B7-F6A9-476D-BD58-DF76122ABCFB-- From nobody Sat Jan 11 00:57:11 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84F120033; Sat, 11 Jan 2020 00:57:02 -0800 (PST) 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=unavailable 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 mA2_q_jZyBaw; Sat, 11 Jan 2020 00:56:58 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 293D012004A; Sat, 11 Jan 2020 00:56:58 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id t2so3981597wrr.1; Sat, 11 Jan 2020 00:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3jgeuovyseLNj4znrOaGYf8ASCW8Au2GVt9izeT5qXw=; b=KCUmk3Pc5kv8hn2AdghOtZ9ucEhOizBPZYPzqUIAWdKDayZOI4QVgJQ5eo+27CZFTD vYBa+iKaehVvtRaxv3EdMfDTbg7mPMQT68wQrb44+gpJOxU+n+VxrLLxji6X8RsMwFn8 7glugXsgLa6DcvGlyscb9gNrGATKFfCF/wAQLur8aYIYZ87Dz1EqW1+oZ/FR/tbVQ2nx 4xtjYoDUq4BvI5FqElgAPE9AhFhtJ6pD+UZGNoJzJs9SrOjyBCiC94+l92qwd3+5ejkm Tq004R0RwfO2gkywT6w57pmS6T+tFL/8UrM3B9Ehksm7p+huyXq4BkFpecqe5ynoDPkM mutA== 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=3jgeuovyseLNj4znrOaGYf8ASCW8Au2GVt9izeT5qXw=; b=cwulcp0KBdHrO03cZP9aLVrmzGyqcESVRUJWWKg/Xj1JwDZ12i+WKKbp/O2xlUcec1 GCWXIoYh9Owus5ikrl4xjgn3ka5yRpxnrfTwPZ/rT4Mto3MxMSHS/+DMsRxGge3/Y8rO sW4yKsasTTMgWNQ/xoa0uFyGjyNokzdAdpkpPV3+/jg3pKyxWlgEEp6p2V5PnQrYhbAI orC3imSkm64ffQZCIfqKBndVR4jeLzHa6vQ2xSLCRXeBJLr/glrccU5DC7et6Gg+M8b7 qqNp3GfIqHsvrij+jQkpubys1EFrMi1PxQofji8in+7TbSJZDcQz/ZZWgWn3FoSA+A97 QI3g== X-Gm-Message-State: APjAAAUjl5itOLd1n2CPA5z1sM0aqXNW5EUcXSkKAEw5pxbVN52KrX1T d0Ob64NwyAvDUodlyGeQ3OA= X-Google-Smtp-Source: APXvYqyltk5WrhtQ02coNyWQywGS5daKRGoQ5vIUYQf4Y8fsI2oAVH18imgR48yfAcLM24InMeBkhw== X-Received: by 2002:adf:ef10:: with SMTP id e16mr7579534wro.336.1578733015496; Sat, 11 Jan 2020 00:56:55 -0800 (PST) Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id u14sm5507503wrm.51.2020.01.11.00.56.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jan 2020 00:56:54 -0800 (PST) From: Stewart Bryant Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Sat, 11 Jan 2020 08:56:23 +0000 In-Reply-To: Cc: Eric Rescorla , Richard Barnes , IAB Chair , IAB IAB , IETF discussion list , architecture-discuss@ietf.org To: Joe Touch References: X-Mailer: Apple Mail (2.3601.0.10) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 08:57:03 -0000 --Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 .. and that is why we run two-in-a-box in most roles so that the = conflicted person can step aside. Stewart > On 10 Jan 2020, at 01:33, Joe Touch wrote: >=20 > Yes. And it at times has been an issue. >=20 > Joe >=20 >> On Jan 9, 2020, at 3:59 PM, Eric Rescorla wrote: >>=20 >> =EF=BB=BF >>=20 >>=20 >> On Thu, Jan 9, 2020 at 2:40 PM Joe Touch > wrote: >> On 2020-01-09 10:46, Eric Rescorla wrote: >>=20 >>> I concur with Richard here. The IETF is most successful when we get >>> input from people who are directly involved in the technologies that >>> we are standardizing, but of course that very often means that they >>> are working on those technologies for their employer. And indeed >>> one of the criteria we often use to ask whether someone is a good >>> fit for leadership is whether they have this kind of non-standards >>> "day job" expertise. >> =20 >> =20 >> That, IMO, is why we encourage their participation in WG discussions = and on lists. >> =20 >> But it is dangerous to have those parties directly involved in = decision making. The actual and potential COI (esp. perceived potential = COI) undermine the decisions made - even when those decisions are = otherwise reasonable. >> =20 >> I.e., think of this as protecting the value of IAB decisions (and, as = Ben noted, there are many, esp. during appeals, that are of a = substantive nature that COI benefits). >>=20 >> And yet we routinely allow have WG chairs and ADs who are deeply = involved (and whose employers are deeply involved) in the technologies = that are being standardized. >>=20 >> -Ekr >>=20 >> =20 >> Joe >>=20 >>=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 .. = and that is why we run two-in-a-box in most roles so that the conflicted = person can step aside.

Stewart

On 10 Jan 2020, at 01:33, Joe = Touch <touch@strayalpha.com> wrote:

Yes. =  And it at times has been an issue.

Joe

On Jan 9, 2020, at 3:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:

=EF=BB=BF


On Thu, Jan 9, 2020 at 2:40 PM Joe Touch <touch@strayalpha.com> wrote:

On 2020-01-09 10:46, Eric Rescorla wrote:

I concur with Richard here. The IETF is most = successful when we get
input from people who are directly = involved in the technologies that
we are standardizing, = but of course that very often means that they
are working on those technologies for their employer. = And indeed
one of the criteria we often use to ask whether someone = is a good
fit for leadership is whether they have this kind of = non-standards
"day job" expertise.
 
 
That, IMO, is why we encourage their participation in WG = discussions and on lists.
 
But it is dangerous to have those parties directly = involved in decision making. The actual and potential COI (esp. = perceived potential COI) undermine the decisions made - even when those = decisions are otherwise reasonable.
 
I.e., think of this as protecting the value of IAB = decisions (and, as Ben noted, there are many, esp. during appeals, that = are of a substantive nature that COI = benefits).

And yet we routinely allow have WG = chairs and ADs who are deeply involved (and whose employers are deeply = involved) in the technologies that are being standardized.

-Ekr

 
Joe


=
_______________________________________________Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss

= --Apple-Mail=_0D99ABA9-A960-406B-A8AD-AED44064A0CD-- From nobody Sun Jan 12 09:37:36 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8737712006D for ; Sun, 12 Jan 2020 09:37:34 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 CHOeFyx_cCb3 for ; Sun, 12 Jan 2020 09:37:33 -0800 (PST) Received: from smtp107.ord1c.emailsrvr.com (smtp107.ord1c.emailsrvr.com [108.166.43.107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F18D120059 for ; Sun, 12 Jan 2020 09:37:33 -0800 (PST) X-Auth-ID: fluffy@iii.ca Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0443AA00F9; Sun, 12 Jan 2020 12:37:31 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (d75-159-246-1.abhsia.telus.net [75.159.246.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sun, 12 Jan 2020 12:37:32 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Draft IAB conflict of interest policy From: Cullen Jennings In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Date: Sun, 12 Jan 2020 10:37:31 -0700 Cc: IETF Crazy , architecture-discuss@ietf.org, iab@iab.org Message-Id: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> To: IAB Chair X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 17:37:35 -0000 --Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 8, 2020, at 4:14 PM, IAB Chair wrote: >=20 > The IAB requires that all Covered Individuals disclose their main = employment, sponsorship, consulting customer, or other sources of income = when joining the IAB or whenever there are updates. Say one of my sources of income involved dead fish and does not have any = COI with work of IETF. I don=E2=80=99t think it is reasonable to expect = disclosure of that. If at some point a COI did arise from this, then I = think it would be reasonable to disclose at that time. This may just be = a bit confusing on how to I should read =E2=80=9Cmain=E2=80=9D and = =E2=80=9Cother sources of incoming=E2=80=9D=20 --Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 8, 2020, at 4:14 PM, IAB Chair <iab-chair@iab.org> = wrote:

The IAB requires that all = Covered Individuals disclose their main employment, sponsorship, = consulting customer, or other sources of income when joining the IAB or = whenever there are updates.

Say one of my sources of income involved dead = fish and does not have any COI with work of IETF. I don=E2=80=99t think = it is reasonable to expect disclosure of that. If at some point a COI = did arise from this, then I think it would be reasonable to disclose at = that time. This may just be a bit confusing on how to I should read =  =E2=80=9Cmain=E2=80=9D and =E2=80=9Cother sources of = incoming=E2=80=9D 




= --Apple-Mail=_A54FF262-997F-4750-A0E4-9AEEC6C0DC27-- From nobody Sun Jan 12 10:31:40 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCDD120046; Sun, 12 Jan 2020 10:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA2lOp3A80HE; Sun, 12 Jan 2020 10:31:33 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 E828E12001B; Sun, 12 Jan 2020 10:31:32 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id u63so2847857pjb.0; Sun, 12 Jan 2020 10:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=TM0tBlsxPcgI/1jVtS+Q/TDf6a32j6PGEDxjzYHVQOw=; b=mEGRwFJq02foFUOZ6EnYUx54iK0GSP0x5Qvc6mV/nJJ9dXn4XMnTcHWgB86y8ROlY7 /C47xJGq16glp4JCDAu5/S/JdDOUq2myUgj64ILtnK7kdUOE6LkQA5dpUvCxwsUWwIEv Culf/oL2p1zAyGJwYhWWfeWhgqJfdbA7ekXI66Hfd4YgBX47lCAmGtUgDYz3YcsR9B8H AC3N1XrAIN/LESLEKOjdFknrrXUWWtkzo1Gd3wGrwGMIJFwzvsRV2hli1eLV126uab1u NBBc6rMJuBd2yHHKHreeqH2P44aroLB9Fj+YJF8+CfyJEKnE4Db6+mrw2mGy/zfJuR+K W/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=TM0tBlsxPcgI/1jVtS+Q/TDf6a32j6PGEDxjzYHVQOw=; b=coHUisl2JZGQh7szaS+VxJCm+LErBoXaIXiMiHjIj2cfgOT9YYmk6P2YXAbIvEHK7S 6CwUEMqdE0+9bldfmJMpkHZV7TiTvB8yPUIl38gzn9hNy2invV6ms++S5XIGFPRLHMuK T0T9yGPMnx+FuNcgvmoMQEeBEchMf+ZPkRY4phwX245UpTWEO9oMA5HidAROeiZoL4M2 i/3vb7q/3Cm4VCNZsMo/BOlPZe8Op4SS3n0Bx8/DRqfXvqb5crX9EeTvxPNiIPRmtiDZ sJTq2671JPimo9u/tC8FVdRDhqPMkiwwze7s0OCg1gIrzJl9WffGPpMvKsgP+2E8rMsC 6g7w== X-Gm-Message-State: APjAAAV5Uw8FWLxE5pvZn7/HiE3X28JsnALy3xUyK4JOeV8lDKB5rzQE 3B4UVwcYqiXQE1FpPZAgAS1ZuJyP X-Google-Smtp-Source: APXvYqxiD8cAZkNT4fs3O5zK53MBPiOKrTsARqae8pXyWvlBzVylsHD66+3N9AMVIsfg+8CClMm2Vw== X-Received: by 2002:a17:902:788d:: with SMTP id q13mr10550037pll.210.1578853892257; Sun, 12 Jan 2020 10:31:32 -0800 (PST) Received: from ?IPv6:2600:380:7047:e822:4d0e:6173:5c4e:a9ab? ([2600:380:7047:e822:4d0e:6173:5c4e:a9ab]) by smtp.gmail.com with ESMTPSA id d14sm11657852pfq.117.2020.01.12.10.31.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Jan 2020 10:31:31 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082 Content-Transfer-Encoding: 7bit From: Bernard Aboba Mime-Version: 1.0 (1.0) Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Sun, 12 Jan 2020 10:31:30 -0800 Message-Id: References: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> Cc: IAB Chair , iab@iab.org, IETF Crazy , architecture-discuss@ietf.org In-Reply-To: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> To: Cullen Jennings X-Mailer: iPhone Mail (17C54) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 18:31:34 -0000 --Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Under the US Federal Advisory Committee Act (FACA) there is no general requi= rement for financial disclosure, except where it is relevant to Committee bu= siness. So if we were talking about an Internet-related committee (e.g. not f= ish and wildlife) income from =E2=80=9Cfish processing=E2=80=9D would not be= relevant so would not need to be disclosed. > On Jan 12, 2020, at 9:38 AM, Cullen Jennings wrote: >=20 > =EF=BB=BF >=20 >> On Jan 8, 2020, at 4:14 PM, IAB Chair wrote: >>=20 >> The IAB requires that all Covered Individuals disclose their main employm= ent, sponsorship, consulting customer, or other sources of income when joini= ng the IAB or whenever there are updates. >=20 > Say one of my sources of income involved dead fish and does not have any C= OI with work of IETF. I don=E2=80=99t think it is reasonable to expect discl= osure of that. If at some point a COI did arise from this, then I think it w= ould be reasonable to disclose at that time. This may just be a bit confusin= g on how to I should read =E2=80=9Cmain=E2=80=9D and =E2=80=9Cother sources= of incoming=E2=80=9D=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Under the US Federal Advis= ory Committee Act (FACA) there is no general requirement for financial discl= osure, except where it is relevant to Committee business. So if we were talk= ing about an Internet-related committee (e.g. not fish and wildlife) income f= rom =E2=80=9Cfish processing=E2=80=9D would not be relevant so would not nee= d to be disclosed.

On Ja= n 12, 2020, at 9:38 AM, Cullen Jennings <fluffy@iii.ca> wrote:

=
=EF=BB=BF

On Jan 8, 2020, at 4:14 PM, IAB Chair <iab-chair@iab.org> wrote:

The IAB requires that all Covered Indivi= duals disclose their main employment, sponsorship, consulting customer, or o= ther sources of income when joining the IAB or whenever there are updates.

Say one of my s= ources of income involved dead fish and does not have any COI with work of I= ETF. I don=E2=80=99t think it is reasonable to expect disclosure of that. If= at some point a COI did arise from this, then I think it would be reasonabl= e to disclose at that time. This may just be a bit confusing on how to I sho= uld read  =E2=80=9Cmain=E2=80=9D and =E2=80=9Cother sources of incoming= =E2=80=9D 



_______________________________________________=
Architecture-discuss mailing list
Architecture-dis= cuss@ietf.org
https://www.ietf.org/mailman/listinfo/architec= ture-discuss
= --Apple-Mail-36C6C27F-0354-4DFC-B198-2DE446AB9082-- From nobody Sun Jan 12 11:20:31 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C417B120044; Sun, 12 Jan 2020 11:20:24 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 d-WhK9GKJ4up; Sun, 12 Jan 2020 11:20:22 -0800 (PST) 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 C2694120046; Sun, 12 Jan 2020 11:20:22 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id x185so3803760pfc.5; Sun, 12 Jan 2020 11:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PWwVRRPbGPN9ADVD9ua4/rOT+yBkYnq8eo3ZNPOSmGI=; b=GA3Fcf3CraadI5mtTkmdGQqN1SJpbn0xvifs8y4MRSIZFXcUKfXViEfXL1jZ1Mae9c k9S3DJbzHeCfHH4tT4lW2UVsUceNPaTdKaQ9sYdgfS80k3E0qMzs0luci2mdXOsS67BY xNG5dWF4FH/qZg3SlPDXk7Rn3s/OBlBXz7QeNvycnrH+5CQEyJV8KucMw6m2/neExFJw UzCoLxAdTN+NTAHeW60VeqoCx7qakKgA71ygYlVEQw2hJqE2JgV++HVCtwJ9wvjTQuo3 wRh3JgBczXFH6iyMlq/Zpip6inhx8t6J53xuSjkOUYhwWncitgyY+AReiSwRdPfuO2Yq SWug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PWwVRRPbGPN9ADVD9ua4/rOT+yBkYnq8eo3ZNPOSmGI=; b=fMJe1iTJVN5e84CejnhvhP5+SVtNCeM4ofhk69eF5vblmSj9VUYg1AlbYzmw950aXd vziJpIaosFGWKpuVssDsc6WRT2bexHlAf3S/XtH5B128xueD30pOd0uxYOeSj/Q9bpmc i52arxV4dten5oc8aLwBIbzG3qbb6yX3yeQM0jmWwW308cEHQyqSGLOzzlMMdoBk2ZfF vmQoG+OwHxuf/qZu9GPZcryE5x1ygw67DHgz7acwXlJukt3+IJSgu1QMfCTtwoE+7d07 Q/zCMlYOhLy5Eofb3xm7kBcKXCQNuWPyfkAwnTKevz4iz4ERvedhyUeoPb4evixJ6fzz mNZA== X-Gm-Message-State: APjAAAXB3RqwSHiEFjfLZ3HYI3o8Mi+JecO23oTkS50599sO0M2mQ7xl +E+XzkmnV5wKekrmgNYulouwyEXD X-Google-Smtp-Source: APXvYqyJUusl6YuofC9xkcNMTe7/KYoElLoo2yB1uoffrJeuoBV8g6cSw8NxMf8RComs2aU+21lD/A== X-Received: by 2002:a63:6c09:: with SMTP id h9mr16863821pgc.34.1578856821969; Sun, 12 Jan 2020 11:20:21 -0800 (PST) Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id e9sm10655700pgn.49.2020.01.12.11.20.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jan 2020 11:20:21 -0800 (PST) Subject: Re: Draft IAB conflict of interest policy To: Cullen Jennings , IAB Chair Cc: iab@iab.org, IETF Crazy , architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> From: Brian E Carpenter Message-ID: Date: Mon, 13 Jan 2020 08:20:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 19:20:25 -0000 On 13-Jan-20 06:37, Cullen Jennings wrote: >=20 >=20 >> On Jan 8, 2020, at 4:14 PM, IAB Chair > wrote: >> >> The IAB requires that all Covered Individuals disclose their main empl= oyment, sponsorship, consulting customer, or other sources of income when= joining the IAB or whenever there are updates. >=20 > Say one of my sources of income involved dead fish and does not have an= y COI with work of IETF. I don=E2=80=99t think it is reasonable to expect= disclosure of that. If at some point a COI did arise from this, then I t= hink it would be reasonable to disclose at that time. This may just be a = bit confusing on how to I should read =C2=A0=E2=80=9Cmain=E2=80=9D and =E2= =80=9Cother sources of incoming=E2=80=9D=C2=A0 If the IAB signed contracts or employed people, that question might even = be worth discussion. As it is, I think this whole discussion is massive o= verkill and possibly exposes IAB members to new risk. As long as IETF LLC= , which actually executes contracts and pays staff, has an adequate COI p= olicy, I think we are fine as we are. BCP 39 makes it fairly clear that the IAB does not need a separate COI po= licy. This text was inserted on legal advice from Jorge Contreras, as the= IETF's pro bono counsel at the time, who said it was intended to 'protec= t IAB members from personal liability for IAB decisions (particularly in = view of the last paragraph, stating that they serve as "individuals")': > Members of the IAB shall serve as individuals, and not as > representatives of any company, agency, or other organization. > Members of the IAB shall owe no fiduciary duty of loyalty or care to= > IAB, IETF, IRTF or IESG. The last sentence in particular seems to make a formal COI policy unneces= sary and possibly harmful. Wouldn't such a policy nullify that protection= that IAB members have had since May 2000? Can we see the legal advice that led to the current proposal? Regards and IANAL, Brian From nobody Sun Jan 12 12:29:08 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AA812006D for ; Sun, 12 Jan 2020 12:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 U8XmCjYgfkc7 for ; Sun, 12 Jan 2020 12:28:58 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 A9C06120041 for ; Sun, 12 Jan 2020 12:28:56 -0800 (PST) Received: from xse464.mail2web.com ([66.113.197.210] helo=xse.mail2web.com) by mx61.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iqjqf-0007WC-AY for ietf@ietf.org; Sun, 12 Jan 2020 21:28:52 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 47wpFm2Wpsz1kqy for ; Sun, 12 Jan 2020 12:28:28 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iqjqW-00028R-7b for ietf@ietf.org; Sun, 12 Jan 2020 12:28:28 -0800 Received: (qmail 29712 invoked from network); 12 Jan 2020 20:28:27 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Jan 2020 20:28:27 -0000 To: Brian E Carpenter , Cullen Jennings , IAB Chair Cc: iab@iab.org, IETF Crazy , architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Subject: Re: Draft IAB conflict of interest policy Message-ID: <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> Date: Sun, 12 Jan 2020 10:28:25 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------73315C047853C911CC97B2D7" Content-Language: en-US X-Originating-IP: 66.113.197.210 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0c2Pj46HODYmpAMVAv0J1pOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDAzc5Jb/eaE0k3pqeq35lKbgN zB/4Jkrw1eDLcif59fsu27D4AFbZfZhJGL1wYxfyU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5aB4itzNZ07CdqP+KMfGjQTAas0edmB2q/yBRqnQY9Wo6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAmwlRxHgmfsZ4 SVWs68EuDrNRwe9Z0gmTfjU2qv1pSEXwwmQ/9UXYhsZqezGmrNqCVMIxJEbxpSoyA6+TVxKKogZ8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVKe6JvDqaPfQft3 SIG8hrREWDvBhuNO4tpnc980Bg7nrXPV49itKdDfF4pwgkHQJZe7g+fQIzWNRfEiY+WEs+sEXPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3QktcdgjwAlzTOIEmu0/d1WuTqTR1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 20:29:01 -0000 This is a multi-part message in MIME format. --------------73315C047853C911CC97B2D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/12/2020 9:20 AM, Brian E Carpenter wrote: > BCP 39 makes it fairly clear that the IAB does not need a separate COI = policy. This text was inserted on legal advice from Jorge Contreras, as t= he IETF's pro bono counsel at the time, who said it was intended to 'prot= ect IAB members from personal liability for IAB decisions (particularly i= n view of the last paragraph, stating that they serve as "individuals")':= > >> Members of the IAB shall serve as individuals, and not as >> representatives of any company, agency, or other organization. >> Members of the IAB shall owe no fiduciary duty of loyalty or care t= o >> IAB, IETF, IRTF or IESG. > The last sentence in particular seems to make a formal COI policy unnec= essary and possibly harmful. Wouldn't such a policy nullify that protecti= on that IAB members have had since May 2000? Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies that "a formal COI policy is unnecessary and possibly harmful". I understand why you would say that, but it requires some level of reading between the lines. You are implicitly suggesting that the current attempt at writing a COI policy for the IAB be scrapped. That may well be very good advice. After all, we might say that what is expected from members of the IAB is exactly the same as what is expected from participants in the IETF in general. But, however well founded that advice may be, we will need some more explanation. > Can we see the legal advice that led to the current proposal? Similarly, if the text in RFC 2850 comes from past debates in the IAB, can you point us to the minutes of these debates? -- Christian Huitema --------------73315C047853C911CC97B2D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 1/12/2020 9:20 AM, Brian E Carpenter wrote:
BCP 39 makes it fairly clear that the IAB does not need a separate COI policy. This text was inserted on legal advice from Jorge Contreras, as the IETF's pro bono counsel at the time, who said it was intended to 'protect IAB members from personal liability for IAB decisions (particularly in view of the last paragraph, stating that they serve as "individuals")':


   Members of the IAB shall serve as individuals, and not as
   representatives of any company, agency, or other organization.
   Members of the IAB shall owe no fiduciary duty of loyalty or care to
   IAB, IETF, IRTF or IESG.

The last sentence in particular seems to make a formal COI policy unnecessary and possibly harmful. Wouldn't such a policy nullify that protection that IAB members have had since May 2000?

Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies that "a formal COI policy is unnecessary and possibly harmful". I understand why you would say that, but it requires some level of reading between the lines.

You are implicitly suggesting that the current attempt at writing a COI policy for the IAB be scrapped. That may well be very good advice. After all, we might say that what is expected from members of the IAB is exactly the same as what is expected from participants in the IETF in general. But, however well founded that advice may be, we will need some more explanation.

Can we see the legal advice that led to the current proposal?

Similarly, if the text in RFC 2850 comes from past debates in the IAB, can you point us to the minutes of these debates?

-- Christian Huitema

--------------73315C047853C911CC97B2D7-- From nobody Sun Jan 12 14:05:02 2020 Return-Path: X-Original-To: ietf@ietf.org Delivered-To: ietf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E42120020; Sun, 12 Jan 2020 14:05:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: NomCom Chair 2019 To: "IETF Announcement List" Cc: ietf@ietf.org Subject: NomCom 2019 Announcement of IAB selections X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <157886670014.23342.13462159929357250787.idtracker@ietfa.amsl.com> Date: Sun, 12 Jan 2020 14:05:00 -0800 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 22:05:00 -0000 As chair of the 2019-2020 NomCom, it gives me great pleasure to announce the results of the NomCom selection process for the IAB. All the IAB candidates noted below have been confirmed by the ISOC Board of Trustees. The selected candidates for the IAB are: Ben Campbell Cullen Jennings Jared Mauch Jiankang Yao 姚健康 Mirja Kühlewind Tommy Pauly The resulting IAB will consist of: Ben Campbell, Independant Consultant Cullen Jennings, Cisco Systems Jared Mauch, Akamai Technologies Jiankang Yao 姚健康, CNNIC China Internet Network Information Center Mirja Kühlewind, Ericsson Tommy Pauly, Apple Jari Arkko, Ericsson Jeff Tantsura, Apstra Mark Nottingham, Fastly Stephen Farrell, Trinity College Dublin Wes Hardaker, USC/ISI Zhenbin Li, Huawei The members of the NomCom thank all of the members of the community who offered to serve on the IAB. Additionally, our thanks go out to the many members of the community who have supported (and continue to support) the NomCom process. The NomCom process for 2019-2020 is not yet finished. The work continues and the schedule and other information can be found on the Nomcom homepage: https://datatracker.ietf.org/nomcom/2019/ I will send out announcements as the slates are confirmed. Regards, Victor Kuarsingh Victor Kuarsingh 2019-2020 IETF NomCom Chair Victor at jvknet dot com nomcom-chair-2019 at ietf dot org From nobody Sun Jan 12 14:06:20 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8902212081F; Sun, 12 Jan 2020 14:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 z3FgexXnTNLe; Sun, 12 Jan 2020 14:06:15 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 2BA3812082E; Sun, 12 Jan 2020 14:06:11 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id 2so3896459pfg.12; Sun, 12 Jan 2020 14:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BkM0JBNkO7ySPuj7qnClC6Ayp57nfxthGFKscsIRDDU=; b=YNXT4PvaEA6KFR0i5QV297l1k6uVaskdUToAWUdT7unq7aO8ahUssL7SDaR6Uk5fB9 nQiHvNhTOgCA9cO+MXutol6CbIKolW0ptq4+4T9ZCBMgt2bsG7t2oaGwG9aaBj2q9pYN pmBul/eOUnATEWSxvPckcOEqi9VERLNHSgLKjwIYZQBFMOh9h1/FPgg0uXGES9qXRZcK TdVbFfs2mPlXk/NY7NKK+opTwMnWhogUeSdlB/kLXDnG3N+WqnKggkVNlEYRTRKEU2jh QCORt0sNi5Gpk+2dtq9f5dXZ9LGl0xoBy0WB5pIsTB7qOVhhZRczzs9Ftx013KsmDbjG pqCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BkM0JBNkO7ySPuj7qnClC6Ayp57nfxthGFKscsIRDDU=; b=AzH2PlI2lTUryFvXqdkp+bFFVwaTpSLQO8eR652+/S+GUju2jJndf4kAMJsSlgmz9j tN2EnEJ6xtez1RR10iFLziSVcW63UcYn31YLqMiLHpK1BkvnsxRlJAUmEH6Y6WshEwTM Hm9HulNfz/XDjhfhIxK8cIrbsM9x7C3yMye0tiNlOhhhhk3ESTDmLWYvuxiNwloXhx4U wCeBXjxqlcHZzmlG+owxlEi+s3GefrGug1Ii61kYT3SC6mSf0MdZwxnX0AHr7cqNc+aw fgN+9yCjkQ1OgVA+yDQCRWxREokqPm9A55EoMhNpupasEVNoJROPP2mljLNuCWNLRRVQ 7Edg== X-Gm-Message-State: APjAAAV4GXReZcjGJ4uZZuUJHVMlQ1NUDggNyEzPGZq7eTBYiClQfbKx 54usg1UKPm1slKenH0s9WRRzC0c0 X-Google-Smtp-Source: APXvYqwRZR62VuCr4FkRBvRD3EVaTvADaV1og/wUevxh/Ly3w/1phtaDlZp2G2F2x1+CM6rYc864CQ== X-Received: by 2002:a63:211f:: with SMTP id h31mr16900867pgh.299.1578866770171; Sun, 12 Jan 2020 14:06:10 -0800 (PST) Received: from [192.168.220.65] (219-88-101-13.adsl.xtra.co.nz. [219.88.101.13]) by smtp.gmail.com with ESMTPSA id j8sm10998106pfe.182.2020.01.12.14.06.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jan 2020 14:06:09 -0800 (PST) Subject: Re: Draft IAB conflict of interest policy To: Christian Huitema , Cullen Jennings , IAB Chair Cc: iab@iab.org, IETF Crazy , architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> From: Brian E Carpenter Message-ID: Date: Mon, 13 Jan 2020 11:06:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 22:06:18 -0000 On 13-Jan-20 09:28, Christian Huitema wrote: > > On 1/12/2020 9:20 AM, Brian E Carpenter wrote: >> BCP 39 makes it fairly clear that the IAB does not need a separate COI policy. This text was inserted on legal advice from Jorge Contreras, as the IETF's pro bono counsel at the time, who said it was intended to 'protect IAB members from personal liability for IAB decisions (particularly in view of the last paragraph, stating that they serve as "individuals")': >> >>> Members of the IAB shall serve as individuals, and not as >>> representatives of any company, agency, or other organization. >>> Members of the IAB shall owe no fiduciary duty of loyalty or care to >>> IAB, IETF, IRTF or IESG. >> The last sentence in particular seems to make a formal COI policy unnecessary and possibly harmful. Wouldn't such a policy nullify that protection that IAB members have had since May 2000? > > Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies that "a formal COI policy is unnecessary and possibly harmful". I understand why you would say that, but it requires some level of reading between the lines. > > You are implicitly suggesting that the current attempt at writing a COI policy for the IAB be scrapped. That may well be very good advice. After all, we might say that what is expected from members of the IAB is exactly the same as what is expected from participants in the IETF in general. But, however well founded that advice may be, we will need some more explanation. Exactly why I asked about legal advice. The *ethical* aspect is probably not contentious, and is indeed right there in the charter already. > >> Can we see the legal advice that led to the current proposal? > > Similarly, if the text in RFC 2850 comes from past debates in the IAB, can you point us to the minutes of these debates? I'm on travel, so I can't easily search the archives, but it would have been late 1999 or early 2000. I did quote verbatim Jorge's comment from my own email archive, and I doubt if any of us would have gone against his advice in those days. Brian From nobody Mon Jan 13 07:47:43 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6EC12011F; Mon, 13 Jan 2020 07:47:36 -0800 (PST) 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=unavailable 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 eOKT7Vt3kaoJ; Mon, 13 Jan 2020 07:47:32 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4728D12010C; Mon, 13 Jan 2020 07:47:32 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id p125so8625070oif.10; Mon, 13 Jan 2020 07:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iI6HbzmDJ6xVCMyHCx9D6DsV++R1dNYdMgBZPxpg8Ns=; b=HIxVwNvzgGlZa0M+/iDruxymADMqeVgdSVg5vA+Gfl5CbM3T9SReR8k4UXPC5gkjay zF0slP6Z60ybfj41zgjiAxAYq2RReztD8mSmryXC6ywamhIM54D8Yk9srtMqq5dUAFcY SFJeGjh2zMmqoF4VTBMCWdGTHx2BopVhS2e2obQtx/WBw6F2NqRvwQ58qm+/g+miV96n 1FX3f6F+eAb+hSIGRMY2H8V58TOfC91hIUmTvrkaLD/JAlH8lotCYbUoKUtJyLlGbMF4 7yFQELcJL+nTEqoO2UyUTYy9cDY/5FHJdrn3f7a8m1qOFOXXc3ilWn2y/esOBNJ6uGFG KI5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iI6HbzmDJ6xVCMyHCx9D6DsV++R1dNYdMgBZPxpg8Ns=; b=h8HnvPw1d0Frff3NakHwxtTkrqGyDdJBeCS3FopV66sjRZFhTvWpAeDTza26YHkZmg R7oocbWeKA/K1e4Cw265YKl6Zpg6l7l08VTvEDWtQaXI10m3Cz4JQ4qF6rUWnmMU4YgS P4a0M+YG38pJkR7qN5+tJzPxtGQwO9LaMpSe2F4ph5mO3JRNyAmr/J0vz097JgSrFFLB Aj95TbJNb96ueMkaUjNuUpG/KQa3hvvSVvDY0tApJOtEyh4Qbiq9Aru91CvT1Q0u5GtM q1QI3Z6ERs76eWs4cKq+gp0WNYbHuWaJ8rl5fZCtSNtClzgT1+1oaPQXua00qFtfBHAE yt2Q== X-Gm-Message-State: APjAAAV4YrnyqBKMLR7njLfdphvfVzSDMym8eODZqGsLOrNIsPciu7Gg N95isfWkXBA7mgCNzX4C8DrW9uPldzM1fDwByk0= X-Google-Smtp-Source: APXvYqyGIsEQ9OxqFAGR9SNi3TO6HDZsASIE932Dy/7Zq+ezILkhh91TaYmmNsiAJJ3TkB5lLqjrxQMz/inbY4qhgaM= X-Received: by 2002:a54:468b:: with SMTP id k11mr12565033oic.134.1578930451567; Mon, 13 Jan 2020 07:47:31 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Mon, 13 Jan 2020 07:47:30 -0800 (PST) In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <5F0ADD7E-84A2-45E0-B084-F5AA5FE62822@iii.ca> <2f9704f7-60e2-7894-46df-72a26c2f21fd@huitema.net> From: Guntur Wiseno Putra Date: Mon, 13 Jan 2020 22:47:30 +0700 Message-ID: Subject: [arch-d] Draft IAB conflict of interest policy To: Brian E Carpenter Cc: Christian Huitema , Cullen Jennings , IAB Chair , "iab@iab.org" , IETF Crazy , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b0da49059c0764c7" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 15:47:37 -0000 --000000000000b0da49059c0764c7 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, (I am reading on "Architecture in Cyberspace":) Networks of Interests in Cyberspace, in Internet: The conflict of interest policy above attempted by IAB means an attempt for a resources management, that is about managing conflicts of interests in such a way of defining tolerances if there are those conflicts happening among "covered members" of an organizational bodies working on Internet technologies...--an attempt that is exclusive to "covered members" of an organizational body... Yet, as what was mentioned above is about the ethic, architecture comes with aesthetic considerations also: such appreciations for, with considerations on laws and principles of, beauties realized in arts: architecture in cyberscape is spatialized music. There are compositional filters made up by the intentions of the architects and perceptual capacity of the viewers. Together the aesthetic and the ethic set values, interests, of the beholders, for a liquid architecture in cyberspace: it is about places of welcomes and defences of "me"...(1) (1) Novak, Marcos, "Liquid Architecture in Cyberspace" https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf Regard, Guntur Wiseno Putra Pada Senin, 13 Januari 2020, Brian E Carpenter menulis: > On 13-Jan-20 09:28, Christian Huitema wrote: > > > > On 1/12/2020 9:20 AM, Brian E Carpenter wrote: > >> BCP 39 makes it fairly clear that the IAB does not need a separate COI > policy. This text was inserted on legal advice from Jorge Contreras, as the > IETF's pro bono counsel at the time, who said it was intended to 'protect > IAB members from personal liability for IAB decisions (particularly in view > of the last paragraph, stating that they serve as "individuals")': > >> > >>> Members of the IAB shall serve as individuals, and not as > >>> representatives of any company, agency, or other organization. > >>> Members of the IAB shall owe no fiduciary duty of loyalty or care to > >>> IAB, IETF, IRTF or IESG. > >> The last sentence in particular seems to make a formal COI policy > unnecessary and possibly harmful. Wouldn't such a policy nullify that > protection that IAB members have had since May 2000? > > > > Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies > that "a formal COI policy is unnecessary and possibly harmful". I > understand why you would say that, but it requires some level of reading > between the lines. > > > > You are implicitly suggesting that the current attempt at writing a COI > policy for the IAB be scrapped. That may well be very good advice. After > all, we might say that what is expected from members of the IAB is exactly > the same as what is expected from participants in the IETF in general. But, > however well founded that advice may be, we will need some more explanation. > > Exactly why I asked about legal advice. The *ethical* aspect is probably > not contentious, and is indeed right there in the charter already. > > > > >> Can we see the legal advice that led to the current proposal? > > > > Similarly, if the text in RFC 2850 comes from past debates in the IAB, > can you point us to the minutes of these debates? > > I'm on travel, so I can't easily search the archives, but it would have > been late 1999 or early 2000. I did quote verbatim Jorge's comment from my > own email archive, and I doubt if any of us would have gone against his > advice in those days. > > Brian > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000b0da49059c0764c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

(I am reading on "Archit= ecture in Cyberspace":)


Networks of Interests in Cyberspace, in Internet:

The conflict of interest policy above attempted by IAB means an attempt for= a resources management, that is about managing conflicts of interests in s= uch a way of defining tolerances if there are those conflicts happening amo= ng "covered members" of an organizational bodies working on Inter= net technologies...--an attempt that is exclusive to "covered members&= quot; of an organizational body...

Yet, as what was mentioned above is about the ethic, architecture comes wit= h aesthetic considerations also: such appreciations for, with consideration= s on laws and principles of, beauties realized in arts: architecture in cyb= erscape is spatialized music. There are compositional filters made up by th= e intentions of the architects and perceptual capacity of the viewers. Toge= ther the aesthetic and the ethic set values, interests, of the beholders, f= or a liquid architecture in cyberspace: it is about places of welcomes and = defences of "me"...(1)


(1) Novak, Marcos, "Liquid Architecture in Cyberspace"


Regard,
Gun= tur Wiseno Putra

Pada Senin, 13 Januari 2020, Brian E Carpenter <= brian.e.ca= rpenter@gmail.com> menulis:
On 13-= Jan-20 09:28, Christian Huitema wrote:
>
> On 1/12/2020 9:20 AM, Brian E Carpenter wrote:
>> BCP 39 makes it fairly clear that the IAB does not need a separate= COI policy. This text was inserted on legal advice from Jorge Contreras, a= s the IETF's pro bono counsel at the time, who said it was intended to = 'protect IAB members from personal liability for IAB decisions (particu= larly in view of the last paragraph, stating that they serve as "indiv= iduals")':
>>
>>>=C2=A0 =C2=A0 Members of the IAB shall serve as individuals, an= d not as
>>>=C2=A0 =C2=A0 representatives of any company, agency, or other = organization.
>>>=C2=A0 =C2=A0 Members of the IAB shall owe no fiduciary duty of= loyalty or care to
>>>=C2=A0 =C2=A0 IAB, IETF, IRTF or IESG.
>> The last sentence in particular seems to make a formal COI policy = unnecessary and possibly harmful. Wouldn't such a policy nullify that p= rotection that IAB members have had since May 2000?
>
> Brian, it is not obvious that this paragraph in RFC2850/BCP39 implies = that "a formal COI policy is unnecessary and possibly harmful". I= understand why you would say that, but it requires some level of reading b= etween the lines.
>
> You are implicitly suggesting that the current attempt at writing a CO= I policy for the IAB be scrapped. That may well be very good advice. After = all, we might say that what is expected from members of the IAB is exactly = the same as what is expected from participants in the IETF in general. But,= however well founded that advice may be, we will need some more explanatio= n.

Exactly why I asked about legal advice. The *ethical* aspect is probably no= t contentious, and is indeed right there in the charter already.

>
>> Can we see the legal advice that led to the current proposal?
>
> Similarly, if the text in RFC 2850 comes from past debates in the IAB,= can you point us to the minutes of these debates?

I'm on travel, so I can't easily search the archives, but it would = have been late 1999 or early 2000. I did quote verbatim Jorge's comment= from my own email archive, and I doubt if any of us would have gone agains= t his advice in those days.

=C2=A0 =C2=A0Brian


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
--000000000000b0da49059c0764c7-- From nobody Mon Jan 13 11:23:37 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933581209F1 for ; Mon, 13 Jan 2020 11:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_FONT_SIZE_LARGE=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=comcast.net 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 kQ69Qwv4NzWh for ; Mon, 13 Jan 2020 11:23:33 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 6181D12088C for ; Mon, 13 Jan 2020 11:23:33 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-11v.sys.comcast.net with ESMTP id r378iRkBDZ2Z3r5JEi0NkZ; Mon, 13 Jan 2020 19:23:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1578943412; bh=6Ks0Xga1sM0rOe8jv5lOZKKTzmf+42g/HwKrTaTSERk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=dij4goHp3UTyICbOYHO1MdOYhvPFZtrxVR5nQWBHJomMGNiO7m0MyBCfw1I7WeCz0 QpLxkNfMevyeF83xCPd6/53ZiNJMOtYZ5vUJXV9qDgoqcMrbxjp0LrfinkChiY3WF6 pSqmCAtiSKPIAOqznaKTAa/npY5DPLmpQDU7lE4SmxH/Pm9KgIXvbTp+VJdWGeo5un OnAmNiftN+GOTrXqjdJmANJZT+db8yco2t20pSCNQRLOuYJgZbTORPu/gU/1tcQKqK 4mkTUiMem7xRAYkGNpsrrqmuxbrx0WyAYUwBY2/FkvheN0phjsMmvhEB365qce9ZBv LvsG8+Ay/1mCw== Received: from [IPv6:2601:152:4400:437c:2db9:9515:98bf:cec0] ([IPv6:2601:152:4400:437c:2db9:9515:98bf:cec0]) by resomta-po-11v.sys.comcast.net with ESMTPSA id r5JCi6i7plImwr5JDikNpw; Mon, 13 Jan 2020 19:23:31 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Subject: Re: Draft IAB conflict of interest policy To: ietf@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> From: Michael StJohns Message-ID: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> Date: Mon, 13 Jan 2020 14:23:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9B3E5538D5043AEB897B6634" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 19:23:35 -0000 This is a multi-part message in MIME format. --------------9B3E5538D5043AEB897B6634 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Given that IAB is in the appeals chain for protocols standards and other items, and has in the past dabbled with personnel decisions, focusing simply on finance and/or personnel seems short sighted. I'm wondering whether it may be time to add the COI disclosures of any I* candidate to the list of material that has to be provided to the Nomcom and to make questions about those disclosures fair game for the Nomcom in selecting a slate. While I appreciate Brian's pointer to BCP 39, it's become clear to me at least that the aspirational goal of "we participate as individuals" is not universally adhered to by all candidates to the various leadership positions.  I can't read minds to know which are, or aren't going to behave with that goal in mind.  This leads me to believe that a scaled up COI process has become more necessary across the board. With respect to the current proposal - it's probably close to good enough, with the exception that "Covered individuals ... or third party gain" probably needs the dual of this - you can't use your position for your own (you, family, company, employer,funder) gain, or to cause a loss to a competitor.   Also - You get the benefit of the doubt if you've publicly disclosed the conflict even if you take actions that might benefit them (working for X on a protocol that's near and dear to Xs bottom line but not taking place on the IESG voting for example).  If you take any actions related to a redacted disclosee you have to show affirmatively (maybe register a statement with the lawyers) that those actions are not anti-competative or you must recuse. Just some thoughts  - Mike On 1/9/2020 11:57 AM, Richard Barnes wrote: > I would propose the IAB not adopt this policy, or at least scope it > way down. > > Much of the IAB's work is focused on technical issues, at a high > enough strategic level that the impacts to specific people or > companies are highly attenuated.  In those discussions, the IAB's work > benefits from having diverse opinions, including the opinions of those > who have skin in the game.  Trying to introduce some notion of CoI in > this context would be harmful -- because there's no hard conflict, it > will inevitably be vague, and thus primarily a tool for IAB members to > try to silence one another or a cause for IAB members to self-censor. > > Where the IAB is directly involved in finance or personnel decisions, > there of course should be guards against self dealing.  That's where > any CoI policy for the IAB should stop. > > --Richard > > On Wed, Jan 8, 2020 at 6:16 PM IAB Chair > wrote: > > Dear Colleagues, > > The IAB is considering adoption of the conflict of interest policy > below.  If you have comments on this draft policy, please send > them toiab@iab.org . > > best regards, > > Ted Hardie > for the IAB > > > INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY > > This policy covers the nomcom-selected Internet Architecture Board > (IAB) members and ex-officio members (collectively, “Covered > Individuals”). This policy has no impact on any other participants > in IAB activities, for instance liaisons to and from the IAB or > IAB program members. > > In carrying out their IAB role, Covered Individuals must act in > the best interest of the Internet community. Occasionally this > duty may be—or may appear to be—incompatible or in conflict with a > Covered Individual’s personal interests (including interests of > their family members), or the interests of an organization of > which the Covered Individual is an employee, director, owner, or > otherwise has business or financial interest. If a Covered > Individual has a conflict of interest for whatever reason, that > individual must avoid participating in the work of the IAB that > touches on the related matter. > > The IAB does not directly deal with matters relating to contracts > or finance. The IAB does, however, have a role in personnel > decisions, and its decisions and outputs have a potential to > indirectly affect contracts within the IETF system. IAB's > technical decisions and outputs have also a potential to impact > both work elsewhere in the IETF and businesses that employ or > develop Internet technology. > > Covered Individuals shall not use the IAB’s resources or decisions > as a means for personal or third-party gain. > > > Disclosure of Actual or Potential Conflicts > > The IAB requires that all Covered Individuals disclose their main > employment, sponsorship, consulting customer, or other sources of > income when joining the IAB or whenever there are updates. > > In addition, when a topic is discussed at the IAB, the Covered > Individuals are required to promptly disclose if that topic > constitutes a perceived or potential conflict of interest. Once > disclosed, Covered Individuals may recuse from participation in > discussions or decisions at their discretion. > > The specific conflicts that may cause a perceived or potential > conflict of interest are matters for individual and IAB judgment, > but generally come in the following forms: > > * > > A personnel decision relates to the Covered Individual, a > colleague that the Covered Individual's works closely with, or > a family member. For the purposes of this policy, a "person > working closely with" is someone working in the same team or > project, or a direct manager or employee of the Covered > Individual. And "family" means a spouse, domestic partner, > child, sibling, parent, stepchild, stepparent, and mother-, > father-, son-, daughter-, brother-, or sister-in-law, and any > other person living in the same household, except tenants and > household employees. > > * > > A decision or output from the IAB impacts a contract that the > IETF enters into with a party, and that party relates to the > Covered Individual, a colleague that the Covered Individual's > works closely with, or a family member. > > * > > Activity on the IAB involves discussion and decisions > regarding technical matters, mainly related to IETF > activities. As an activity adjacent to a standardization > process, it is often the case that Covered Individuals will > have some (frequently non-financial) stake in the outcome of > discussions or decisions that relate to technical matters. > This policy does not require that Covered Individuals disclose > such conflicts of interest as they relate to technical > matters. However, Covered Individuals need to exercise their > judgment and, in extraordinary cases be willing to disclose > potential or perceived conflicts of interest even as they > relate to technical matters. For example, if a Covered > Individual's sponsor were in the process of entering a new > market where there is an ongoing IAB discussion, then > disclosure, or even recusal, might be appropriate, even if > difficult. > > > Disclosure Transparency > > A person's recusal to participate in the discussion of a topic is > always noted in the public IAB minutes. In addition, the IAB will > maintain a repository of all general disclosures of employment and > other sponsorship. It is expected that much of this repository is > public, but there can be situations where some disclosures (such > as customers of consultants) are private. > > > > > > --------------9B3E5538D5043AEB897B6634 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Given that IAB is in the appeals chain for protocols standards and other items, and has in the past dabbled with personnel decisions, focusing simply on finance and/or personnel seems short sighted. 

I'm wondering whether it may be time to add the COI disclosures of any I* candidate to the list of material that has to be provided to the Nomcom and to make questions about those disclosures fair game for the Nomcom in selecting a slate.

While I appreciate Brian's pointer to BCP 39, it's become clear to me at least that the aspirational goal of "we participate as individuals" is not universally adhered to by all candidates to the various leadership positions.  I can't read minds to know which are, or aren't going to behave with that goal in mind.  This leads me to believe that a scaled up COI process has become more necessary across the board.

With respect to the current proposal - it's probably close to good enough, with the exception that "Covered individuals ... or third party gain" probably needs the dual of this - you can't use your position for your own (you, family, company, employer,funder) gain, or to cause a loss to a competitor.   Also - You get the benefit of the doubt if you've publicly disclosed the conflict even if you take actions that might benefit them (working for X on a protocol that's near and dear to Xs bottom line but not taking place on the IESG voting for example).  If you take any actions related to a redacted disclosee you have to show affirmatively (maybe register a statement with the lawyers) that those actions are not anti-competative or you must recuse.

Just some thoughts  - Mike


On 1/9/2020 11:57 AM, Richard Barnes wrote:
I would propose the IAB not adopt this policy, or at least scope it way down.

Much of the IAB's work is focused on technical issues, at a high enough strategic level that the impacts to specific people or companies are highly attenuated.  In those discussions, the IAB's work benefits from having diverse opinions, including the opinions of those who have skin in the game.  Trying to introduce some notion of CoI in this context would be harmful -- because there's no hard conflict, it will inevitably be vague, and thus primarily a tool for IAB members to try to silence one another or a cause for IAB members to self-censor.

Where the IAB is directly involved in finance or personnel decisions, there of course should be guards against self dealing.  That's where any CoI policy for the IAB should stop.

--Richard

On Wed, Jan 8, 2020 at 6:16 PM IAB Chair <iab-chair@iab.org> wrote:

Dear Colleagues,

The IAB is considering adoption of the conflict of interest policy below.  If you have comments on this draft policy, please send them to iab@iab.org.

best regards,

Ted Hardie
for the IAB

INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY

This policy covers the nomcom-selected Internet Architecture Board (IAB) members and ex-officio members (collectively, “Covered Individuals”). This policy has no impact on any other participants in IAB activities, for instance liaisons to and from the IAB or IAB program members.

In carrying out their IAB role, Covered Individuals must act in the best interest of the Internet community. Occasionally this duty may be—or may appear to be—incompatible or in conflict with a Covered Individual’s personal interests (including interests of their family members), or the interests of an organization of which the Covered Individual is an employee, director, owner, or otherwise has business or financial interest. If a Covered Individual has a conflict of interest for whatever reason, that individual must avoid participating in the work of the IAB that touches on the related matter.

The IAB does not directly deal with matters relating to contracts or finance. The IAB does, however, have a role in personnel decisions, and its decisions and outputs have a potential to indirectly affect contracts within the IETF system. IAB's technical decisions and outputs have also a potential to impact both work elsewhere in the IETF and businesses that employ or develop Internet technology.

Covered Individuals shall not use the IAB’s resources or decisions as a means for personal or third-party gain.

Disclosure of Actual or Potential Conflicts

The IAB requires that all Covered Individuals disclose their main employment, sponsorship, consulting customer, or other sources of income when joining the IAB or whenever there are updates.

In addition, when a topic is discussed at the IAB, the Covered Individuals are required to promptly disclose if that topic constitutes a perceived or potential conflict of interest. Once disclosed, Covered Individuals may recuse from participation in discussions or decisions at their discretion.

The specific conflicts that may cause a perceived or potential conflict of interest are matters for individual and IAB judgment, but generally come in the following forms:

  • A personnel decision relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member. For the purposes of this policy, a "person working closely with" is someone working in the same team or project, or a direct manager or employee of the Covered Individual. And "family" means a spouse, domestic partner, child, sibling, parent, stepchild, stepparent, and mother-, father-, son-, daughter-, brother-, or sister-in-law, and any other person living in the same household, except tenants and household employees.

  • A decision or output from the IAB impacts a contract that the IETF enters into with a party, and that party relates to the Covered Individual, a colleague that the Covered Individual's works closely with, or a family member.

  • Activity on the IAB involves discussion and decisions regarding technical matters, mainly related to IETF activities. As an activity adjacent to a standardization process, it is often the case that Covered Individuals will have some (frequently non-financial) stake in the outcome of discussions or decisions that relate to technical matters. This policy does not require that Covered Individuals disclose such conflicts of interest as they relate to technical matters. However, Covered Individuals need to exercise their judgment and, in extraordinary cases be willing to disclose potential or perceived conflicts of interest even as they relate to technical matters. For example, if a Covered Individual's sponsor were in the process of entering a new market where there is an ongoing IAB discussion, then disclosure, or even recusal, might be appropriate, even if difficult.

Disclosure Transparency

A person's recusal to participate in the discussion of a topic is always noted in the public IAB minutes. In addition, the IAB will maintain a repository of all general disclosures of employment and other sponsorship. It is expected that much of this repository is public, but there can be situations where some disclosures (such as customers of consultants) are private.




--------------9B3E5538D5043AEB897B6634-- From nobody Mon Jan 13 11:43:49 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A134120A0F for ; Mon, 13 Jan 2020 11:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZRCDcM1x2TJ for ; Mon, 13 Jan 2020 11:43:43 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 E1CD3120A05 for ; Mon, 13 Jan 2020 11:43:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 47xPCg6C5Kz1nyqr; Mon, 13 Jan 2020 11:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1578944623; bh=BOYxmmCu5p/OCfYi83as5FVsyhf8O8xC4PCTKRAh0LA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=n+5CGQiMKBK3GeqyutAGti82NE9liivtQSua/+RdvpbuCwwRtEF94R2QyJPaApcwi KNdzYKYD33ZpYx+7+zWqBx+RqmVYDm2ZV34vLPELZSNZzPYyfSb6xOzYBWENBabyd+ WvFyfmCqzLQI0ZKuOczQObHFwsniDVxyxMcAbsBg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 47xPCg2YGlz1nymS; Mon, 13 Jan 2020 11:43:43 -0800 (PST) Subject: Re: Draft IAB conflict of interest policy To: Michael StJohns , ietf@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> From: "Joel M. Halpern" Message-ID: Date: Mon, 13 Jan 2020 14:43:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 19:43:46 -0000 There seems to be an implication in Mike's description that I find troublesome. It may well not be intended by Mike. I apologize if I am over-reacting. If we were to insist that WG chairs or ADs recuse themselves from taking positions on technology that matters to their employer, we would quickly find ourselves in a position where we could not get any work done. Whether vendors or operators, our leaders care about the technology we work on. They (more accurately, we) work on the stuff daily, and work on the stuff at the IETF. All of the routing ADs would probably have to recuse themselves from all of the routing work. That sounds backwards. Yes, We do ask that folks disclose their primary affiliation. I believe we ask that for WG chairs, for ADs, and for IAB members. That gives the community the information about the situation. That is VERY different from asking folks not to participate in leadership decisions about work that may affect their employer. Yours, Joel On 1/13/2020 2:23 PM, Michael StJohns wrote: > Given that IAB is in the appeals chain for protocols standards and other > items, and has in the past dabbled with personnel decisions, focusing > simply on finance and/or personnel seems short sighted. > > I'm wondering whether it may be time to add the COI disclosures of any > I* candidate to the list of material that has to be provided to the > Nomcom and to make questions about those disclosures fair game for the > Nomcom in selecting a slate. > > While I appreciate Brian's pointer to BCP 39, it's become clear to me at > least that the aspirational goal of "we participate as individuals" is > not universally adhered to by all candidates to the various leadership > positions.  I can't read minds to know which are, or aren't going to > behave with that goal in mind.  This leads me to believe that a scaled > up COI process has become more necessary across the board. > > With respect to the current proposal - it's probably close to good > enough, with the exception that "Covered individuals ... or third party > gain" probably needs the dual of this - you can't use your position for > your own (you, family, company, employer,funder) gain, or to cause a > loss to a competitor.   Also - You get the benefit of the doubt if > you've publicly disclosed the conflict even if you take actions that > might benefit them (working for X on a protocol that's near and dear to > Xs bottom line but not taking place on the IESG voting for example).  If > you take any actions related to a redacted disclosee you have to show > affirmatively (maybe register a statement with the lawyers) that those > actions are not anti-competative or you must recuse. > > Just some thoughts  - Mike > > > On 1/9/2020 11:57 AM, Richard Barnes wrote: >> I would propose the IAB not adopt this policy, or at least scope it >> way down. >> >> Much of the IAB's work is focused on technical issues, at a high >> enough strategic level that the impacts to specific people or >> companies are highly attenuated.  In those discussions, the IAB's work >> benefits from having diverse opinions, including the opinions of those >> who have skin in the game.  Trying to introduce some notion of CoI in >> this context would be harmful -- because there's no hard conflict, it >> will inevitably be vague, and thus primarily a tool for IAB members to >> try to silence one another or a cause for IAB members to self-censor. >> >> Where the IAB is directly involved in finance or personnel decisions, >> there of course should be guards against self dealing.  That's where >> any CoI policy for the IAB should stop. >> >> --Richard >> >> On Wed, Jan 8, 2020 at 6:16 PM IAB Chair > > wrote: >> >> Dear Colleagues, >> >> The IAB is considering adoption of the conflict of interest policy >> below.  If you have comments on this draft policy, please send >> them toiab@iab.org . >> >> best regards, >> >> Ted Hardie >> for the IAB >> >> >> INTERNET ARCHITECTURE BOARD CONFLICT OF INTEREST POLICY >> >> This policy covers the nomcom-selected Internet Architecture Board >> (IAB) members and ex-officio members (collectively, “Covered >> Individuals”). This policy has no impact on any other participants >> in IAB activities, for instance liaisons to and from the IAB or >> IAB program members. >> >> In carrying out their IAB role, Covered Individuals must act in >> the best interest of the Internet community. Occasionally this >> duty may be—or may appear to be—incompatible or in conflict with a >> Covered Individual’s personal interests (including interests of >> their family members), or the interests of an organization of >> which the Covered Individual is an employee, director, owner, or >> otherwise has business or financial interest. If a Covered >> Individual has a conflict of interest for whatever reason, that >> individual must avoid participating in the work of the IAB that >> touches on the related matter. >> >> The IAB does not directly deal with matters relating to contracts >> or finance. The IAB does, however, have a role in personnel >> decisions, and its decisions and outputs have a potential to >> indirectly affect contracts within the IETF system. IAB's >> technical decisions and outputs have also a potential to impact >> both work elsewhere in the IETF and businesses that employ or >> develop Internet technology. >> >> Covered Individuals shall not use the IAB’s resources or decisions >> as a means for personal or third-party gain. >> >> >> Disclosure of Actual or Potential Conflicts >> >> The IAB requires that all Covered Individuals disclose their main >> employment, sponsorship, consulting customer, or other sources of >> income when joining the IAB or whenever there are updates. >> >> In addition, when a topic is discussed at the IAB, the Covered >> Individuals are required to promptly disclose if that topic >> constitutes a perceived or potential conflict of interest. Once >> disclosed, Covered Individuals may recuse from participation in >> discussions or decisions at their discretion. >> >> The specific conflicts that may cause a perceived or potential >> conflict of interest are matters for individual and IAB judgment, >> but generally come in the following forms: >> >> * >> >> A personnel decision relates to the Covered Individual, a >> colleague that the Covered Individual's works closely with, or >> a family member. For the purposes of this policy, a "person >> working closely with" is someone working in the same team or >> project, or a direct manager or employee of the Covered >> Individual. And "family" means a spouse, domestic partner, >> child, sibling, parent, stepchild, stepparent, and mother-, >> father-, son-, daughter-, brother-, or sister-in-law, and any >> other person living in the same household, except tenants and >> household employees. >> >> * >> >> A decision or output from the IAB impacts a contract that the >> IETF enters into with a party, and that party relates to the >> Covered Individual, a colleague that the Covered Individual's >> works closely with, or a family member. >> >> * >> >> Activity on the IAB involves discussion and decisions >> regarding technical matters, mainly related to IETF >> activities. As an activity adjacent to a standardization >> process, it is often the case that Covered Individuals will >> have some (frequently non-financial) stake in the outcome of >> discussions or decisions that relate to technical matters. >> This policy does not require that Covered Individuals disclose >> such conflicts of interest as they relate to technical >> matters. However, Covered Individuals need to exercise their >> judgment and, in extraordinary cases be willing to disclose >> potential or perceived conflicts of interest even as they >> relate to technical matters. For example, if a Covered >> Individual's sponsor were in the process of entering a new >> market where there is an ongoing IAB discussion, then >> disclosure, or even recusal, might be appropriate, even if >> difficult. >> >> >> Disclosure Transparency >> >> A person's recusal to participate in the discussion of a topic is >> always noted in the public IAB minutes. In addition, the IAB will >> maintain a repository of all general disclosures of employment and >> other sponsorship. It is expected that much of this repository is >> public, but there can be situations where some disclosures (such >> as customers of consultants) are private. >> >> >> >> >> >> > From nobody Mon Jan 13 12:13:35 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF5C120A5A for ; Mon, 13 Jan 2020 12:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=comcast.net 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 F9RC7JuGIVNy for ; Mon, 13 Jan 2020 12:13:32 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 0BE30120113 for ; Mon, 13 Jan 2020 12:13:31 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id r0oQimU6Kqc4dr65bimzzH; Mon, 13 Jan 2020 20:13:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1578946411; bh=pNvLN+4waZsDyYZ2+FCoRW9byd7VmrTcpssbbkJm5JQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ahA912P+uHJZHutE6I1ZQogplkOGXKS+PHbvKe5DB0GOtHehh43sBRlaq/L+GGh2h vZLdczfwKjhqZRaw/u7pgsE/l/jPgBCnQgxQ3gB+/HRAFY2RvPuU6cs2dhZv242ftH t25qHWQ/jCS17ScWH9FjibKNbysRaDYo3hYi6XnOs+nCBx0NRn6fXtmcj6pPwIzU7R 9nB9r+5w/6h0fDpkEAnVr8XJTYrl8t0CKDCbzL+o7kLi5CR28GmgtRQwUSThgc7bTd Y+DZJaVQpMrj5dY0qAR7epLZVwqxMNpi82Wx2sG9TFDQZQEDpFg4L49pBmO1qn4s3K 7UsBl/CUNO6fA== Received: from [IPv6:2601:152:4400:437c:2db9:9515:98bf:cec0] ([IPv6:2601:152:4400:437c:2db9:9515:98bf:cec0]) by resomta-ch2-10v.sys.comcast.net with ESMTPSA id r65Ui8agC0F7Br65ai1P0L; Mon, 13 Jan 2020 20:13:30 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Subject: Re: Draft IAB conflict of interest policy To: "Joel M. Halpern" , ietf@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> From: Michael StJohns Message-ID: Date: Mon, 13 Jan 2020 15:13:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 20:13:34 -0000 On 1/13/2020 2:43 PM, Joel M. Halpern wrote: > There seems to be an implication in Mike's description that I find > troublesome.  It may well not be intended by Mike.  I apologize if I > am over-reacting. > > If we were to insist that WG chairs or ADs recuse themselves from > taking positions on technology that matters to their employer, we > would quickly find ourselves in a position where we could not get any > work done. Whether vendors or operators, our leaders care about the > technology we work on.  They (more accurately, we) work on the stuff > daily, and work on the stuff at the IETF.  All of the routing ADs > would probably have to recuse themselves from all of the routing > work.  That sounds backwards. > > Yes, We do ask that folks disclose their primary affiliation.  I > believe we ask that for WG chairs, for ADs, and for IAB members. That > gives the community the information about the situation. That is VERY > different from asking folks not to participate in leadership decisions > about work that may affect their employer. > > Yours, > Joel Hi Joel - No apologies necessary  - happy to clarify as needed. Here's what I thought I wrote (between the lines!): 1) If you've publicly disclosed a conflict, feel free to participate in the process of building a standard.   If the standard comes before you on the IESG (e.g. standards vote) or IAB (appeal), best to recuse.  I mostly don't have a problem with being an active advocate for something - but being in the selection process - especially if competing standards - is probably reaching over the line.   Mostly I see this behavior from the various ADs and IAB members already. 2) If you've disclosed the conflict, and aren't participating in a specific standards building process, if the standards comes before you, has competitive benefits for your employer (e.g. mainly contributed by your employer or co-employees or standardizes your employers implementation choices over others), consider whether recusal is necessary and whether you need to put your two cents worth in given a non-conflicted co-AD?   A "maybe recuse" tick box here is one or more of Author is an employee, Editor is an employee, WG chair is an employee. 3) If you done a redacted disclosure, avoid even participating in the process of building a standard as its impossible for the rest of us to understand that there may be more than just your best technical judgement at work.   Having your relationship popup publicly later on would tend to taint the standards process and could give a competitor some basis for various legal actions both against you and against the IETF leadership. 4) If you really must participate, paper the hell out of it and make sure you have your leadership peers are on board - e.g. they have to be able to read past the redactions and be of the opinion that its good technical judgement playing here. As someone else mentioned - this is one of the reasons why most of the AD positions are two deep. I don't think I'm asking for "folks not to participate in leadership decisions about work that may affect their employer", what I am suggesting is that when in the "decider" role, that the person takes a very close look at the optics, and avoids blatant conflicts of interest.   90% of the time these will be "don't care" decisions for both the employer and competitors.  It's that other 10% where we might end up in trouble. Later, Mike From nobody Mon Jan 13 15:38:57 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26FD120020 for ; Mon, 13 Jan 2020 15:38:55 -0800 (PST) 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 ZULyeYYmx8tt for ; Mon, 13 Jan 2020 15:38:52 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 06F1C12001B for ; Mon, 13 Jan 2020 15:38:52 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id i11so11769919ioi.12 for ; Mon, 13 Jan 2020 15:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YEt3B2YhrUh0gJU5LW+clyyyWtARRchApKZvZiMrkgw=; b=OzUwLMjO9vDoWqQzkdtTP7zCq22VFsRu3r1ZQUYyu1jKKI4ZSDyORJpIJhCNjLD0zN ZFr8mzQJsjC9W6RrYhJcSzLS8UFlWdUsGG7i+4ebNf/uIJMbU4Lfdp3fqhfo9hNAUXAO jTXRTm57wTtT83QBWJHi0bwi4i6AoTe3fn9ukgZ7YtatOa6eUalh45NfclHIbNVI6Hk8 mmevkEA4i/Z/6JACphK7PSNPO8q8bgR3nWb5Y7TAFu0If68S4/rZW+ZVq/oooi0EEKT7 3Nix/nGT+NECcyifrSWfpnfXBaMGKzFnxtKTj39eDXXPYjVEU4qPbnPo9rEcafNgcjdJ j4lQ== 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=YEt3B2YhrUh0gJU5LW+clyyyWtARRchApKZvZiMrkgw=; b=sAbklAuoYoPomS4NJn4y2J5/TL3Yf5uOTP3AD2ufYAzkFwqCuok/zNm4m1WVur+tx8 BN6ZBoZInLDG+za0FH6XeLn1pwSPswjK31QruuEKyb2ySOwq9WT9Etgv+Ohp8JMx2Szh qctIriAQ60EIhgnL15xcZn3rKWDkjP7gxACloFbZsHWiIC+0mqgKpY09m2uOsobCw6VG z2Sx3brZixi7cFbfpr211b7HjGGrUWJjw7/x//WBnuvl+uIK9c/BgSWzWs/oiUdQwsSL SCuAZz9vJfanhQca/c8+7n1j0YtfM+HOn19ZI7210eu3uggiFq5NhpghGHY1d8VZu247 YSKw== X-Gm-Message-State: APjAAAVY+hk3Au++wt3+pJL0VXfHGAz/3AgOLwJ/DiGfuRHYqLWjAr43 wXViKJ+0XNCNXlkFTWUaFrORMZkZEueik32+am4= X-Google-Smtp-Source: APXvYqzKHcEYI5ZUfMnJLTCKlNPJRvlZyZ5ZWwDznKUZ8EUrOd2HMPFYGNorEPVkUlNv9keUBzXfaS9zvd1D4O44vLA= X-Received: by 2002:a02:3ece:: with SMTP id s197mr16172184jas.30.1578958730392; Mon, 13 Jan 2020 15:38:50 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> In-Reply-To: From: Rob Sayre Date: Mon, 13 Jan 2020 15:38:37 -0800 Message-ID: Subject: Re: Draft IAB conflict of interest policy To: "Joel M. Halpern" Cc: Michael StJohns , IETF discussion list Content-Type: multipart/alternative; boundary="0000000000003d77eb059c0dfa3b" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 23:38:56 -0000 --0000000000003d77eb059c0dfa3b Content-Type: text/plain; charset="UTF-8" On Mon, Jan 13, 2020 at 11:44 AM Joel M. Halpern wrote: > Yes, We do ask that folks disclose their primary affiliation. I believe > we ask that for WG chairs, for ADs, and for IAB members. That gives the > community the information about the situation. That is VERY different > from asking folks not to participate in leadership decisions about work > that may affect their employer. > That often gives "the community the information about the situation", but not always. The classic case is the "consulting firm" that only gets paid via defense or other government contracts. I'm not sure that's a solvable problem, but I do agree that's different from a non-participation request. thanks, Rob --0000000000003d77eb059c0dfa3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 13, 2020 at 11:44 AM Joel M. = Halpern <jmh@joelhalpern.com&= gt; wrote:
Yes, We do ask that folks disclose their primary affiliation.=C2=A0 I belie= ve
we ask that for WG chairs, for ADs, and for IAB members.=C2=A0 That gives t= he
community the information about the situation.=C2=A0 That is VERY different=
from asking folks not to participate in leadership decisions about work that may affect their employer.

That of= ten gives "the community the information about the situation", bu= t not always.

The classic case is the "consul= ting firm" that only gets paid via defense or other government contrac= ts.

I'm not sure that's a solvable problem= , but I do agree that's different from a non-participation request.

thanks,
Rob

--0000000000003d77eb059c0dfa3b-- From nobody Mon Jan 13 22:48:28 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7689512006E; Mon, 13 Jan 2020 22:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qG-EDZZeKNmt; Mon, 13 Jan 2020 22:48:17 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 30334120052; Mon, 13 Jan 2020 22:48:17 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DCD74E766399E78A8842; Tue, 14 Jan 2020 06:48:13 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 14 Jan 2020 06:48:13 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.174]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Tue, 14 Jan 2020 14:48:06 +0800 From: "Roni Even (A)" To: IAB Chair , "ietf@ietf.org" , "architecture-discuss@ietf.org" , "iab@iab.org" Subject: RE: Draft IAB conflict of interest policy Thread-Topic: Draft IAB conflict of interest policy Thread-Index: AQHVxnmcMA59x5ePZEqHjbTI+oboiafpvZYQ Date: Tue, 14 Jan 2020 06:48:05 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD27D56B76@DGGEMM506-MBX.china.huawei.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.63] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 06:48:21 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpBZnRlciByZWFkaW5nIGNhcmVmdWxseSB0aGlzIHByb3Bvc2FsIGFuZCB0aGUgZGlzY3Vz c2lvbiBteSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgdGhpcyBwcm9wb3NhbCBpcyB2ZXJ5IHJlYXNv bmFibGUuDQpJIGV4cGVjdCBmcm9tIHRoZSAgSUFCIG1lbWJlcnMgYW5kIGFsc28gYW55IHBlcnNv biBpbiBsZWFkZXJzaGlwIHBvc2l0aW9uIGluIHRoZSBJRVRGIHRvIGJlaGF2ZSBiYXNlZCBvbiB0 aGVzZSBndWlkZWxpbmVzLg0KSSBzZWUgdGhpcyBwcm9wb3NhbCBhcyBndWlkZWxpbmVzICwgdGhl cmUgYXJlIG5vIHBlbmFsdGllcyBmb3Igbm90IGZvbGxvd2luZyB0aGVzZSBndWlkZWxpbmVzIGFu ZCAgaXQgaXMgZ29vZC4gSSBleHBlY3QgdGhhdCBwZXJzb25zIGluIGxlYWRlcnNoaXAgcG9zaXRp b24gd2lsbCBmb2xsb3dzIHN1Y2ggQ09JIHBvbGljeSBldmVuIGlmIGl0IGlzIG5vdCB3cml0dGVu Lg0KDQpSb25pIEV2ZW4NCg0KRnJvbTogaWV0ZiBbbWFpbHRvOmlldGYtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIElBQiBDaGFpcg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDksIDIw MjAgMToxNSBBTQ0KVG86IGlldGZAaWV0Zi5vcmc7IGFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYu b3JnOyBpYWJAaWFiLm9yZw0KU3ViamVjdDogRHJhZnQgSUFCIGNvbmZsaWN0IG9mIGludGVyZXN0 IHBvbGljeQ0KDQoNCkRlYXIgQ29sbGVhZ3VlcywNCg0KVGhlIElBQiBpcyBjb25zaWRlcmluZyBh ZG9wdGlvbiBvZiB0aGUgY29uZmxpY3Qgb2YgaW50ZXJlc3QgcG9saWN5IGJlbG93LiAgSWYgeW91 IGhhdmUgY29tbWVudHMgb24gdGhpcyBkcmFmdCBwb2xpY3ksIHBsZWFzZSBzZW5kIHRoZW0gdG8g aWFiQGlhYi5vcmc8bWFpbHRvOmlhYkBpYWIub3JnPi4NCg0KYmVzdCByZWdhcmRzLA0KVGVkIEhh cmRpZQ0KZm9yIHRoZSBJQUINCg0KDQpJTlRFUk5FVCBBUkNISVRFQ1RVUkUgQk9BUkQgQ09ORkxJ Q1QgT0YgSU5URVJFU1QgUE9MSUNZDQoNClRoaXMgcG9saWN5IGNvdmVycyB0aGUgbm9tY29tLXNl bGVjdGVkIEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBtZW1iZXJzIGFuZCBleC1v ZmZpY2lvIG1lbWJlcnMgKGNvbGxlY3RpdmVseSwg4oCcQ292ZXJlZCBJbmRpdmlkdWFsc+KAnSku IFRoaXMgcG9saWN5IGhhcyBubyBpbXBhY3Qgb24gYW55IG90aGVyIHBhcnRpY2lwYW50cyBpbiBJ QUIgYWN0aXZpdGllcywgZm9yIGluc3RhbmNlIGxpYWlzb25zIHRvIGFuZCBmcm9tIHRoZSBJQUIg b3IgSUFCIHByb2dyYW0gbWVtYmVycy4NCg0KSW4gY2Fycnlpbmcgb3V0IHRoZWlyIElBQiByb2xl LCBDb3ZlcmVkIEluZGl2aWR1YWxzIG11c3QgYWN0IGluIHRoZSBiZXN0IGludGVyZXN0IG9mIHRo ZSBJbnRlcm5ldCBjb21tdW5pdHkuIE9jY2FzaW9uYWxseSB0aGlzIGR1dHkgbWF5IGJl4oCUb3Ig bWF5IGFwcGVhciB0byBiZeKAlGluY29tcGF0aWJsZSBvciBpbiBjb25mbGljdCB3aXRoIGEgQ292 ZXJlZCBJbmRpdmlkdWFs4oCZcyBwZXJzb25hbCBpbnRlcmVzdHMgKGluY2x1ZGluZyBpbnRlcmVz dHMgb2YgdGhlaXIgZmFtaWx5IG1lbWJlcnMpLCBvciB0aGUgaW50ZXJlc3RzIG9mIGFuIG9yZ2Fu aXphdGlvbiBvZiB3aGljaCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsIGlzIGFuIGVtcGxveWVlLCBk aXJlY3Rvciwgb3duZXIsIG9yIG90aGVyd2lzZSBoYXMgYnVzaW5lc3Mgb3IgZmluYW5jaWFsIGlu dGVyZXN0LiBJZiBhIENvdmVyZWQgSW5kaXZpZHVhbCBoYXMgYSBjb25mbGljdCBvZiBpbnRlcmVz dCBmb3Igd2hhdGV2ZXIgcmVhc29uLCB0aGF0IGluZGl2aWR1YWwgbXVzdCBhdm9pZCBwYXJ0aWNp cGF0aW5nIGluIHRoZSB3b3JrIG9mIHRoZSBJQUIgdGhhdCB0b3VjaGVzIG9uIHRoZSByZWxhdGVk IG1hdHRlci4NCg0KVGhlIElBQiBkb2VzIG5vdCBkaXJlY3RseSBkZWFsIHdpdGggbWF0dGVycyBy ZWxhdGluZyB0byBjb250cmFjdHMgb3IgZmluYW5jZS4gVGhlIElBQiBkb2VzLCBob3dldmVyLCBo YXZlIGEgcm9sZSBpbiBwZXJzb25uZWwgZGVjaXNpb25zLCBhbmQgaXRzIGRlY2lzaW9ucyBhbmQg b3V0cHV0cyBoYXZlIGEgcG90ZW50aWFsIHRvIGluZGlyZWN0bHkgYWZmZWN0IGNvbnRyYWN0cyB3 aXRoaW4gdGhlIElFVEYgc3lzdGVtLiBJQUIncyB0ZWNobmljYWwgZGVjaXNpb25zIGFuZCBvdXRw dXRzIGhhdmUgYWxzbyBhIHBvdGVudGlhbCB0byBpbXBhY3QgYm90aCB3b3JrIGVsc2V3aGVyZSBp biB0aGUgSUVURiBhbmQgYnVzaW5lc3NlcyB0aGF0IGVtcGxveSBvciBkZXZlbG9wIEludGVybmV0 IHRlY2hub2xvZ3kuDQoNCkNvdmVyZWQgSW5kaXZpZHVhbHMgc2hhbGwgbm90IHVzZSB0aGUgSUFC 4oCZcyByZXNvdXJjZXMgb3IgZGVjaXNpb25zIGFzIGEgbWVhbnMgZm9yIHBlcnNvbmFsIG9yIHRo aXJkLXBhcnR5IGdhaW4uDQoNCkRpc2Nsb3N1cmUgb2YgQWN0dWFsIG9yIFBvdGVudGlhbCBDb25m bGljdHMNCg0KVGhlIElBQiByZXF1aXJlcyB0aGF0IGFsbCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRp c2Nsb3NlIHRoZWlyIG1haW4gZW1wbG95bWVudCwgc3BvbnNvcnNoaXAsIGNvbnN1bHRpbmcgY3Vz dG9tZXIsIG9yIG90aGVyIHNvdXJjZXMgb2YgaW5jb21lIHdoZW4gam9pbmluZyB0aGUgSUFCIG9y IHdoZW5ldmVyIHRoZXJlIGFyZSB1cGRhdGVzLg0KDQpJbiBhZGRpdGlvbiwgd2hlbiBhIHRvcGlj IGlzIGRpc2N1c3NlZCBhdCB0aGUgSUFCLCB0aGUgQ292ZXJlZCBJbmRpdmlkdWFscyBhcmUgcmVx dWlyZWQgdG8gcHJvbXB0bHkgZGlzY2xvc2UgaWYgdGhhdCB0b3BpYyBjb25zdGl0dXRlcyBhIHBl cmNlaXZlZCBvciBwb3RlbnRpYWwgY29uZmxpY3Qgb2YgaW50ZXJlc3QuIE9uY2UgZGlzY2xvc2Vk LCBDb3ZlcmVkIEluZGl2aWR1YWxzIG1heSByZWN1c2UgZnJvbSBwYXJ0aWNpcGF0aW9uIGluIGRp c2N1c3Npb25zIG9yIGRlY2lzaW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLg0KDQpUaGUgc3BlY2lm aWMgY29uZmxpY3RzIHRoYXQgbWF5IGNhdXNlIGEgcGVyY2VpdmVkIG9yIHBvdGVudGlhbCBjb25m bGljdCBvZiBpbnRlcmVzdCBhcmUgbWF0dGVycyBmb3IgaW5kaXZpZHVhbCBhbmQgSUFCIGp1ZGdt ZW50LCBidXQgZ2VuZXJhbGx5IGNvbWUgaW4gdGhlIGZvbGxvd2luZyBmb3JtczoNCg0KwrcgICAg ICBBIHBlcnNvbm5lbCBkZWNpc2lvbiByZWxhdGVzIHRvIHRoZSBDb3ZlcmVkIEluZGl2aWR1YWws IGEgY29sbGVhZ3VlIHRoYXQgdGhlIENvdmVyZWQgSW5kaXZpZHVhbCdzIHdvcmtzIGNsb3NlbHkg d2l0aCwgb3IgYSBmYW1pbHkgbWVtYmVyLiBGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgcG9saWN5 LCBhICJwZXJzb24gd29ya2luZyBjbG9zZWx5IHdpdGgiIGlzIHNvbWVvbmUgd29ya2luZyBpbiB0 aGUgc2FtZSB0ZWFtIG9yIHByb2plY3QsIG9yIGEgZGlyZWN0IG1hbmFnZXIgb3IgZW1wbG95ZWUg b2YgdGhlIENvdmVyZWQgSW5kaXZpZHVhbC4gQW5kICJmYW1pbHkiIG1lYW5zIGEgc3BvdXNlLCBk b21lc3RpYyBwYXJ0bmVyLCBjaGlsZCwgc2libGluZywgcGFyZW50LCBzdGVwY2hpbGQsIHN0ZXBw YXJlbnQsIGFuZCBtb3RoZXItLCBmYXRoZXItLCBzb24tLCBkYXVnaHRlci0sIGJyb3RoZXItLCBv ciBzaXN0ZXItaW4tbGF3LCBhbmQgYW55IG90aGVyIHBlcnNvbiBsaXZpbmcgaW4gdGhlIHNhbWUg aG91c2Vob2xkLCBleGNlcHQgdGVuYW50cyBhbmQgaG91c2Vob2xkIGVtcGxveWVlcy4NCg0Kwrcg ICAgICBBIGRlY2lzaW9uIG9yIG91dHB1dCBmcm9tIHRoZSBJQUIgaW1wYWN0cyBhIGNvbnRyYWN0 IHRoYXQgdGhlIElFVEYgZW50ZXJzIGludG8gd2l0aCBhIHBhcnR5LCBhbmQgdGhhdCBwYXJ0eSBy ZWxhdGVzIHRvIHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwsIGEgY29sbGVhZ3VlIHRoYXQgdGhlIENv dmVyZWQgSW5kaXZpZHVhbCdzIHdvcmtzIGNsb3NlbHkgd2l0aCwgb3IgYSBmYW1pbHkgbWVtYmVy Lg0KDQrCtyAgICAgIEFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMgZGlzY3Vzc2lvbiBhbmQg ZGVjaXNpb25zIHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFpbmx5IHJlbGF0ZWQgdG8g SUVURiBhY3Rpdml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0byBhIHN0YW5kYXJkaXph dGlvbiBwcm9jZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENvdmVyZWQgSW5kaXZpZHVh bHMgd2lsbCBoYXZlIHNvbWUgKGZyZXF1ZW50bHkgbm9uLWZpbmFuY2lhbCkgc3Rha2UgaW4gdGhl IG91dGNvbWUgb2YgZGlzY3Vzc2lvbnMgb3IgZGVjaXNpb25zIHRoYXQgcmVsYXRlIHRvIHRlY2hu aWNhbCBtYXR0ZXJzLiBUaGlzIHBvbGljeSBkb2VzIG5vdCByZXF1aXJlIHRoYXQgQ292ZXJlZCBJ bmRpdmlkdWFscyBkaXNjbG9zZSBzdWNoIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBhcyB0aGV5IHJl bGF0ZSB0byB0ZWNobmljYWwgbWF0dGVycy4gSG93ZXZlciwgQ292ZXJlZCBJbmRpdmlkdWFscyBu ZWVkIHRvIGV4ZXJjaXNlIHRoZWlyIGp1ZGdtZW50IGFuZCwgaW4gZXh0cmFvcmRpbmFyeSBjYXNl cyBiZSB3aWxsaW5nIHRvIGRpc2Nsb3NlIHBvdGVudGlhbCBvciBwZXJjZWl2ZWQgY29uZmxpY3Rz IG9mIGludGVyZXN0IGV2ZW4gYXMgdGhleSByZWxhdGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIEZv ciBleGFtcGxlLCBpZiBhIENvdmVyZWQgSW5kaXZpZHVhbCdzIHNwb25zb3Igd2VyZSBpbiB0aGUg cHJvY2VzcyBvZiBlbnRlcmluZyBhIG5ldyBtYXJrZXQgd2hlcmUgdGhlcmUgaXMgYW4gb25nb2lu ZyBJQUIgZGlzY3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBvciBldmVuIHJlY3VzYWwsIG1pZ2h0 IGJlIGFwcHJvcHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC4NCg0KRGlzY2xvc3VyZSBUcmFuc3Bh cmVuY3kNCg0KQSBwZXJzb24ncyByZWN1c2FsIHRvIHBhcnRpY2lwYXRlIGluIHRoZSBkaXNjdXNz aW9uIG9mIGEgdG9waWMgaXMgYWx3YXlzIG5vdGVkIGluIHRoZSBwdWJsaWMgSUFCIG1pbnV0ZXMu IEluIGFkZGl0aW9uLCB0aGUgSUFCIHdpbGwgbWFpbnRhaW4gYSByZXBvc2l0b3J5IG9mIGFsbCBn ZW5lcmFsIGRpc2Nsb3N1cmVzIG9mIGVtcGxveW1lbnQgYW5kIG90aGVyIHNwb25zb3JzaGlwLiBJ dCBpcyBleHBlY3RlZCB0aGF0IG11Y2ggb2YgdGhpcyByZXBvc2l0b3J5IGlzIHB1YmxpYywgYnV0 IHRoZXJlIGNhbiBiZSBzaXR1YXRpb25zIHdoZXJlIHNvbWUgZGlzY2xvc3VyZXMgKHN1Y2ggYXMg Y3VzdG9tZXJzIG9mIGNvbnN1bHRhbnRzKSBhcmUgcHJpdmF0ZS4NCg0KDQo8aHR0cHM6Ly9naXRo dWIuY29tL2phcmlhcmtrby9hbHRlcm5hdGUtaWFiLWNvaS1wb2xpY3kvYmxvYi9tYXN0ZXIvY29p LXBvbGljeS5tZCNzdGF0dXM+DQoNCg0K --_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1z by1zdHlsZS1saW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjI0LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KaDMNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5oYg0K CXttc28tc3R5bGUtbmFtZTpoYjt9DQpzcGFuLmcyDQoJe21zby1zdHlsZS1uYW1lOmcyO30NCnNw YW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJZm9udC1m YW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpi b2xkO30NCnNwYW4uSGVhZGluZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7 DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzM2NUY5MTsNCglmb250 LXdlaWdodDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxNzQ5MDMzNjA3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTE1 MjUzNzg2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZnRlciByZWFkaW5nIGNh cmVmdWxseSB0aGlzIHByb3Bvc2FsIGFuZCB0aGUgZGlzY3Vzc2lvbiBteSBwZXJzb25hbCB2aWV3 IGlzIHRoYXQgdGhpcyBwcm9wb3NhbCBpcyB2ZXJ5IHJlYXNvbmFibGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgZXhwZWN0IGZyb20gdGhlICZuYnNwO0lBQiBtZW1iZXJzIGFuZCBh bHNvIGFueSBwZXJzb24gaW4gbGVhZGVyc2hpcCBwb3NpdGlvbiBpbiB0aGUgSUVURiB0byBiZWhh dmUgYmFzZWQgb24gdGhlc2UgZ3VpZGVsaW5lcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIHNlZSB0aGlzIHByb3Bvc2FsIGFzIGd1aWRlbGluZXMgLCB0aGVyZSBhcmUgbm8gcGVu YWx0aWVzIGZvciBub3QgZm9sbG93aW5nIHRoZXNlIGd1aWRlbGluZXMgYW5kICZuYnNwO2l0IGlz IGdvb2QuIEkgZXhwZWN0IHRoYXQgcGVyc29ucyBpbiBsZWFkZXJzaGlwIHBvc2l0aW9uDQogd2ls bCBmb2xsb3dzIHN1Y2ggQ09JIHBvbGljeSBldmVuIGlmIGl0IGlzIG5vdCB3cml0dGVuLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Um9uaSBFdmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IGlldGYgW21haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPklBQiBDaGFpcjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAwOSwgMjAy MCAxOjE1IEFNPGJyPg0KPGI+VG86PC9iPiBpZXRmQGlldGYub3JnOyBhcmNoaXRlY3R1cmUtZGlz Y3Vzc0BpZXRmLm9yZzsgaWFiQGlhYi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRHJhZnQgSUFC IGNvbmZsaWN0IG9mIGludGVyZXN0IHBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMyMjIyMjIiPkRlYXIgQ29sbGVhZ3Vlcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12 YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo Og0KICAgICAgMHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZToNCiAgICAgIGluaXRpYWw7dGV4dC1k ZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5UaGUgSUFCIGlzIGNvbnNpZGVyaW5nIGFkb3B0 aW9uIG9mIHRoZSBjb25mbGljdCBvZiBpbnRlcmVzdCBwb2xpY3kgYmVsb3cuJm5ic3A7IElmIHlv dSBoYXZlIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQgcG9saWN5LCBwbGVhc2Ugc2VuZCB0aGVtIHRv Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmlhYkBpYWIub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxMTU1Q0MiPmlhYkBpYWIub3JnPC9zcGFuPjwvYT4uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDoNCiAgICAgIDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6DQog ICAgICBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+YmVzdCByZWdh cmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+VGVk IEhhcmRpZTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Zm9yIHRo ZSBJQUI8YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8aDM+SU5URVJO RVQgQVJDSElURUNUVVJFIEJPQVJEIENPTkZMSUNUIE9GIElOVEVSRVNUIFBPTElDWTxvOnA+PC9v OnA+PC9oMz4NCjxwPlRoaXMgcG9saWN5IGNvdmVycyB0aGUgbm9tY29tLXNlbGVjdGVkIEludGVy bmV0IEFyY2hpdGVjdHVyZSBCb2FyZCAoSUFCKSBtZW1iZXJzIGFuZCBleC1vZmZpY2lvIG1lbWJl cnMgKGNvbGxlY3RpdmVseSwg4oCcQ292ZXJlZCBJbmRpdmlkdWFsc+KAnSkuIFRoaXMgcG9saWN5 IGhhcyBubyBpbXBhY3Qgb24gYW55IG90aGVyIHBhcnRpY2lwYW50cyBpbiBJQUIgYWN0aXZpdGll cywgZm9yIGluc3RhbmNlIGxpYWlzb25zIHRvIGFuZCBmcm9tIHRoZSBJQUINCiBvciBJQUIgcHJv Z3JhbSBtZW1iZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHA+SW4gY2Fycnlpbmcgb3V0IHRoZWlyIElB QiByb2xlLCBDb3ZlcmVkIEluZGl2aWR1YWxzIG11c3QgYWN0IGluIHRoZSBiZXN0IGludGVyZXN0 IG9mIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkuIE9jY2FzaW9uYWxseSB0aGlzIGR1dHkgbWF5IGJl 4oCUb3IgbWF5IGFwcGVhciB0byBiZeKAlGluY29tcGF0aWJsZSBvciBpbiBjb25mbGljdCB3aXRo IGEgQ292ZXJlZCBJbmRpdmlkdWFs4oCZcyBwZXJzb25hbCBpbnRlcmVzdHMgKGluY2x1ZGluZyBp bnRlcmVzdHMNCiBvZiB0aGVpciBmYW1pbHkgbWVtYmVycyksIG9yIHRoZSBpbnRlcmVzdHMgb2Yg YW4gb3JnYW5pemF0aW9uIG9mIHdoaWNoIHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwgaXMgYW4gZW1w bG95ZWUsIGRpcmVjdG9yLCBvd25lciwgb3Igb3RoZXJ3aXNlIGhhcyBidXNpbmVzcyBvciBmaW5h bmNpYWwgaW50ZXJlc3QuIElmIGEgQ292ZXJlZCBJbmRpdmlkdWFsIGhhcyBhIGNvbmZsaWN0IG9m IGludGVyZXN0IGZvciB3aGF0ZXZlciByZWFzb24sIHRoYXQgaW5kaXZpZHVhbA0KIG11c3QgYXZv aWQgcGFydGljaXBhdGluZyBpbiB0aGUgd29yayBvZiB0aGUgSUFCIHRoYXQgdG91Y2hlcyBvbiB0 aGUgcmVsYXRlZCBtYXR0ZXIuPG86cD48L286cD48L3A+DQo8cD5UaGUgSUFCIGRvZXMgbm90IGRp cmVjdGx5IGRlYWwgd2l0aCBtYXR0ZXJzIHJlbGF0aW5nIHRvIGNvbnRyYWN0cyBvciBmaW5hbmNl LiBUaGUgSUFCIGRvZXMsIGhvd2V2ZXIsIGhhdmUgYSByb2xlIGluIHBlcnNvbm5lbCBkZWNpc2lv bnMsIGFuZCBpdHMgZGVjaXNpb25zIGFuZCBvdXRwdXRzIGhhdmUgYSBwb3RlbnRpYWwgdG8gaW5k aXJlY3RseSBhZmZlY3QgY29udHJhY3RzIHdpdGhpbiB0aGUgSUVURiBzeXN0ZW0uIElBQidzIHRl Y2huaWNhbA0KIGRlY2lzaW9ucyBhbmQgb3V0cHV0cyBoYXZlIGFsc28gYSBwb3RlbnRpYWwgdG8g aW1wYWN0IGJvdGggd29yayBlbHNld2hlcmUgaW4gdGhlIElFVEYgYW5kIGJ1c2luZXNzZXMgdGhh dCBlbXBsb3kgb3IgZGV2ZWxvcCBJbnRlcm5ldCB0ZWNobm9sb2d5LjxvOnA+PC9vOnA+PC9wPg0K PHA+Q292ZXJlZCBJbmRpdmlkdWFscyBzaGFsbCBub3QgdXNlIHRoZSBJQULigJlzIHJlc291cmNl cyBvciBkZWNpc2lvbnMgYXMgYSBtZWFucyBmb3IgcGVyc29uYWwgb3IgdGhpcmQtcGFydHkgZ2Fp bi48bzpwPjwvbzpwPjwvcD4NCjxoMz5EaXNjbG9zdXJlIG9mIEFjdHVhbCBvciBQb3RlbnRpYWwg Q29uZmxpY3RzPG86cD48L286cD48L2gzPg0KPHA+VGhlIElBQiByZXF1aXJlcyB0aGF0IGFsbCBD b3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Nsb3NlIHRoZWlyIG1haW4gZW1wbG95bWVudCwgc3BvbnNv cnNoaXAsIGNvbnN1bHRpbmcgY3VzdG9tZXIsIG9yIG90aGVyIHNvdXJjZXMgb2YgaW5jb21lIHdo ZW4gam9pbmluZyB0aGUgSUFCIG9yIHdoZW5ldmVyIHRoZXJlIGFyZSB1cGRhdGVzLjxvOnA+PC9v OnA+PC9wPg0KPHA+SW4gYWRkaXRpb24sIHdoZW4gYSB0b3BpYyBpcyBkaXNjdXNzZWQgYXQgdGhl IElBQiwgdGhlIENvdmVyZWQgSW5kaXZpZHVhbHMgYXJlIHJlcXVpcmVkIHRvIHByb21wdGx5IGRp c2Nsb3NlIGlmIHRoYXQgdG9waWMgY29uc3RpdHV0ZXMgYSBwZXJjZWl2ZWQgb3IgcG90ZW50aWFs IGNvbmZsaWN0IG9mIGludGVyZXN0LiBPbmNlIGRpc2Nsb3NlZCwgQ292ZXJlZCBJbmRpdmlkdWFs cyBtYXkgcmVjdXNlIGZyb20gcGFydGljaXBhdGlvbiBpbiBkaXNjdXNzaW9ucw0KIG9yIGRlY2lz aW9ucyBhdCB0aGVpciBkaXNjcmV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIHNwZWNpZmlj IGNvbmZsaWN0cyB0aGF0IG1heSBjYXVzZSBhIHBlcmNlaXZlZCBvciBwb3RlbnRpYWwgY29uZmxp Y3Qgb2YgaW50ZXJlc3QgYXJlIG1hdHRlcnMgZm9yIGluZGl2aWR1YWwgYW5kIElBQiBqdWRnbWVu dCwgYnV0IGdlbmVyYWxseSBjb21lIGluIHRoZSBmb2xsb3dpbmcgZm9ybXM6PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+QSBwZXJzb25uZWwgZGVjaXNpb24gcmVs YXRlcyB0byB0aGUgQ292ZXJlZCBJbmRpdmlkdWFsLCBhIGNvbGxlYWd1ZSB0aGF0IHRoZSBDb3Zl cmVkIEluZGl2aWR1YWwncyB3b3JrcyBjbG9zZWx5IHdpdGgsIG9yIGEgZmFtaWx5IG1lbWJlci4g Rm9yIHRoZSBwdXJwb3NlcyBvZiB0aGlzIHBvbGljeSwgYSAmcXVvdDtwZXJzb24gd29ya2luZyBj bG9zZWx5IHdpdGgmcXVvdDsNCiBpcyBzb21lb25lIHdvcmtpbmcgaW4gdGhlIHNhbWUgdGVhbSBv ciBwcm9qZWN0LCBvciBhIGRpcmVjdCBtYW5hZ2VyIG9yIGVtcGxveWVlIG9mIHRoZSBDb3ZlcmVk IEluZGl2aWR1YWwuIEFuZCAmcXVvdDtmYW1pbHkmcXVvdDsgbWVhbnMgYSBzcG91c2UsIGRvbWVz dGljIHBhcnRuZXIsIGNoaWxkLCBzaWJsaW5nLCBwYXJlbnQsIHN0ZXBjaGlsZCwgc3RlcHBhcmVu dCwgYW5kIG1vdGhlci0sIGZhdGhlci0sIHNvbi0sIGRhdWdodGVyLSwgYnJvdGhlci0sIG9yIHNp c3Rlci1pbi1sYXcsDQogYW5kIGFueSBvdGhlciBwZXJzb24gbGl2aW5nIGluIHRoZSBzYW1lIGhv dXNlaG9sZCwgZXhjZXB0IHRlbmFudHMgYW5kIGhvdXNlaG9sZCBlbXBsb3llZXMuPG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+QSBkZWNpc2lvbiBvciBvdXRwdXQg ZnJvbSB0aGUgSUFCIGltcGFjdHMgYSBjb250cmFjdCB0aGF0IHRoZSBJRVRGIGVudGVycyBpbnRv IHdpdGggYSBwYXJ0eSwgYW5kIHRoYXQgcGFydHkgcmVsYXRlcyB0byB0aGUgQ292ZXJlZCBJbmRp dmlkdWFsLCBhIGNvbGxlYWd1ZSB0aGF0IHRoZSBDb3ZlcmVkIEluZGl2aWR1YWwncyB3b3JrcyBj bG9zZWx5IHdpdGgsDQogb3IgYSBmYW1pbHkgbWVtYmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPkFjdGl2aXR5IG9uIHRoZSBJQUIgaW52b2x2ZXMgZGlzY3Vz c2lvbiBhbmQgZGVjaXNpb25zIHJlZ2FyZGluZyB0ZWNobmljYWwgbWF0dGVycywgbWFpbmx5IHJl bGF0ZWQgdG8gSUVURiBhY3Rpdml0aWVzLiBBcyBhbiBhY3Rpdml0eSBhZGphY2VudCB0byBhIHN0 YW5kYXJkaXphdGlvbiBwcm9jZXNzLCBpdCBpcyBvZnRlbiB0aGUgY2FzZSB0aGF0IENvdmVyZWQN CiBJbmRpdmlkdWFscyB3aWxsIGhhdmUgc29tZSAoZnJlcXVlbnRseSBub24tZmluYW5jaWFsKSBz dGFrZSBpbiB0aGUgb3V0Y29tZSBvZiBkaXNjdXNzaW9ucyBvciBkZWNpc2lvbnMgdGhhdCByZWxh dGUgdG8gdGVjaG5pY2FsIG1hdHRlcnMuIFRoaXMgcG9saWN5IGRvZXMgbm90IHJlcXVpcmUgdGhh dCBDb3ZlcmVkIEluZGl2aWR1YWxzIGRpc2Nsb3NlIHN1Y2ggY29uZmxpY3RzIG9mIGludGVyZXN0 IGFzIHRoZXkgcmVsYXRlIHRvIHRlY2huaWNhbCBtYXR0ZXJzLg0KIEhvd2V2ZXIsIENvdmVyZWQg SW5kaXZpZHVhbHMgbmVlZCB0byBleGVyY2lzZSB0aGVpciBqdWRnbWVudCBhbmQsIGluIGV4dHJh b3JkaW5hcnkgY2FzZXMgYmUgd2lsbGluZyB0byBkaXNjbG9zZSBwb3RlbnRpYWwgb3IgcGVyY2Vp dmVkIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCBldmVuIGFzIHRoZXkgcmVsYXRlIHRvIHRlY2huaWNh bCBtYXR0ZXJzLiBGb3IgZXhhbXBsZSwgaWYgYSBDb3ZlcmVkIEluZGl2aWR1YWwncyBzcG9uc29y IHdlcmUgaW4gdGhlDQogcHJvY2VzcyBvZiBlbnRlcmluZyBhIG5ldyBtYXJrZXQgd2hlcmUgdGhl cmUgaXMgYW4gb25nb2luZyBJQUIgZGlzY3Vzc2lvbiwgdGhlbiBkaXNjbG9zdXJlLCBvciBldmVu IHJlY3VzYWwsIG1pZ2h0IGJlIGFwcHJvcHJpYXRlLCBldmVuIGlmIGRpZmZpY3VsdC48bzpwPjwv bzpwPjwvcD4NCjxoMz5EaXNjbG9zdXJlIFRyYW5zcGFyZW5jeTxvOnA+PC9vOnA+PC9oMz4NCjxw PkEgcGVyc29uJ3MgcmVjdXNhbCB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGlzY3Vzc2lvbiBvZiBh IHRvcGljIGlzIGFsd2F5cyBub3RlZCBpbiB0aGUgcHVibGljIElBQiBtaW51dGVzLiBJbiBhZGRp dGlvbiwgdGhlIElBQiB3aWxsIG1haW50YWluIGEgcmVwb3NpdG9yeSBvZiBhbGwgZ2VuZXJhbCBk aXNjbG9zdXJlcyBvZiBlbXBsb3ltZW50IGFuZCBvdGhlciBzcG9uc29yc2hpcC4gSXQgaXMgZXhw ZWN0ZWQgdGhhdCBtdWNoIG9mIHRoaXMgcmVwb3NpdG9yeQ0KIGlzIHB1YmxpYywgYnV0IHRoZXJl IGNhbiBiZSBzaXR1YXRpb25zIHdoZXJlIHNvbWUgZGlzY2xvc3VyZXMgKHN1Y2ggYXMgY3VzdG9t ZXJzIG9mIGNvbnN1bHRhbnRzKSBhcmUgcHJpdmF0ZS48bzpwPjwvbzpwPjwvcD4NCjxoMT48YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vamFyaWFya2tvL2FsdGVybmF0ZS1pYWItY29pLXBvbGlj eS9ibG9iL21hc3Rlci9jb2ktcG9saWN5Lm1kI3N0YXR1cyIgaWQ9InVzZXItY29udGVudC1zdGF0 dXMiPjxicj4NCjwvYT48bzpwPjwvbzpwPjwvaDE+DQo8cD48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD27D56B76DGGEMM506MBXchi_-- From nobody Tue Jan 14 00:49:54 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4335A12009E for ; Tue, 14 Jan 2020 00:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 header.b=NFN8CvHD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aN/aiwAN 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 jkdcZDbQKHeT for ; Tue, 14 Jan 2020 00:49:49 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34175120091 for ; Tue, 14 Jan 2020 00:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8633; q=dns/txt; s=iport; t=1578991789; x=1580201389; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QuQIw/ZMx1x0kEPGDY2OrBkJwHr+H9cq1x0VpNbSHIw=; b=NFN8CvHDIuL19dQPhY8I3ZO1NR0doeBRVT0GfzV1Gzce4iSJp2Hao78/ WvChz3P5k9T56EpWxIIPUoJQ8VM9b83fo9dPiMj0Lgw8mDDe3NuC80+dn R63jWFxzzPC4bWPOKViXXk/jD/mbil4UrznVrqL/ZrpcTpqIBToy22d3L 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AWxxIPhz3lwcD/dPXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIDUDyNtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTCQA2gB1e/4kNJK1lHgELHINPJCw?= =?us-ascii?q?FgUQgBAsqhA2DRgOLBZYLhGKCUgNUCQEBAQwBAS0CAQGEQAIXgWIkOBMCAw0?= =?us-ascii?q?BAQQBAQECAQUEbYU3DIVfAgEDEhEdAQEjFAEPAgEIQgICAjAlAgQOJ4MEgX5?= =?us-ascii?q?NAy4Bn1kCgTiIYXWBMoJ+AQEFgkSCXhiCDAmBNowZGoFBP4ERJyCCHi4+h1k?= =?us-ascii?q?ygiyNNYMZhVeZHQqCOJYtG5ptqVICBAIEBQIOAQEFgWkigVhwFWUBgkFQGA2?= =?us-ascii?q?IAQwXg1CKU3SBKItRAQE?= X-IronPort-AV: E=Sophos;i="5.69,432,1571702400"; d="scan'208,217";a="705059289" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jan 2020 08:49:47 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00E8nluf010551 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jan 2020 08:49:47 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 Jan 2020 02:49:46 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 Jan 2020 02:49:45 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 14 Jan 2020 02:49:45 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DSn9Ifw0wB0ik+nLESUCDo9dEd23t6iC9uLcqRMtlfAsbeKzB5LfyLvQnhroifNiXNuYPh0gBrRgN9xmhWOXVIEEo/7rOPLnQ22YP1dPLk1jAH67y3bcjg1KyHBzCPRRMfMuWq8PXFFW31Z+Z9DRMirdOxnUnsGEoppiuqUAWIhMItxvg91GGyt5Wz2+1TgXH5FLUa+G1riC2ELuomBop68ltbyy97bPidT+sEQ8OD7boj1sEJn5KXq2XWq5kEDSVxREyTRSkvgR3o0Bi6SsDpxwd8o65h6ojATu4Es9RrlTMVsNWBGLL8ZnB5MvR62YWcz4edkYudw1+RMAigkRGA== 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=QuQIw/ZMx1x0kEPGDY2OrBkJwHr+H9cq1x0VpNbSHIw=; b=HKMsq8IDDq+OV1CdLEeddJOKnfjqEL6uf05HMPeGW7n71mfIzoxXjnk5+FPCflQw6dL7XlAsLAOA/TybGUfjoUAeOa8b+ZnV6y39jmHYKQBiXf8Yvgfl+zZvf3e3hYPRvCEaIWilujPhImKSY+IrOwlMgFgvD888P1doeLK0wDUqT6+5tMvETvy7aFey83hDiIMTSrzclhJW3tvgEJ6vUceT8F6kcRiKdAheKv6Y4swe26DNNW2Wp/PjiFwyMDAtqKQUNs+7rtWuadGuuxK3jZAJNXzjIisAIMlFECT8GlmlBVouBuq8vnJOq0l8g7bwZ6LSSeiJMPL6Zfyk/61c9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QuQIw/ZMx1x0kEPGDY2OrBkJwHr+H9cq1x0VpNbSHIw=; b=aN/aiwAN5C5vtR3Bt/iX7jAUbKWeLufP23wdO/e2CxLzUN2yngoTNOGDMvWmgFqKvKpLmWrSazA6mx0qBoFglYBZ0LIAvioV1oCn0L1u8A6UL7i+MEgwlUr45WoyJn+QcMnSAXJR9EeKXZeliiJJfbaFirxAA9JuOt7oXUkGjd0= Received: from DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) by DM6PR11MB3244.namprd11.prod.outlook.com (20.176.122.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Tue, 14 Jan 2020 08:49:45 +0000 Received: from DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5]) by DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5%7]) with mapi id 15.20.2623.017; Tue, 14 Jan 2020 08:49:45 +0000 From: "Eliot Lear (elear)" To: Michael StJohns CC: "Joel M. Halpern" , "ietf@ietf.org" Subject: Re: Draft IAB conflict of interest policy Thread-Topic: Draft IAB conflict of interest policy Thread-Index: AQHVykcEyGnKQesxcEaOVUOcjTerhKfo/vCAgAAIT4CAANNUgA== Date: Tue, 14 Jan 2020 08:49:44 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> 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=elear@cisco.com; x-originating-ip: [2001:420:c0c0:1003::1ba] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad7613bc-edf7-418a-cb61-08d798ceb440 x-ms-traffictypediagnostic: DM6PR11MB3244: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(346002)(396003)(366004)(376002)(189003)(199004)(33656002)(66476007)(64756008)(91956017)(6916009)(186003)(8676002)(76116006)(36756003)(5660300002)(86362001)(66556008)(66946007)(4326008)(6486002)(66446008)(54906003)(2906002)(8936002)(6506007)(71200400001)(81156014)(316002)(81166006)(6512007)(2616005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3244; H:DM6PR11MB3995.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VgpG4GCwQ0GHAnkP64rFKYWWgzuprzjweh40zsK5V3+hCe1cFH40r84sipkPx7c3bVJKADp0PjQxzIkOVP4RQxwULDNdyvnP70OybyQOeFHzFMJoWFojef4pHrwLj1kG+dfwS8wPWN55lQD3VVFp/iyfHxXhIqiZ3cSfD1yaTVuW2RJ9QIpixfj876vkpDcmnLfp+lFYtgvrQK0CwVUYEUp24anXz5Z1E4hlc6ssVQsATHvfGLtiy5pQXlgh3PSaAGd+e4xPYW2qdvclfDy4hzo/hauo+NrSfh6X6PDOxBf94v0ewcLBE6mgPInOO7TfDdsqyS/PteqaWt0IBc2LVlGe7hdWpGmkiqvNfzVvn6/cLczIF+hqwn8b1H1iKpRIrP/0kWT9hAC3vfKXZHPzwqIRT+eImlsp/J73/EzCFneVt3udWBZhoN9p6EBo4vhp x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FF6265924B084F7B9FAE4BD9AFEBF408ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ad7613bc-edf7-418a-cb61-08d798ceb440 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 08:49:44.5488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jWDupmaKL7tKfuKNYgFIczDDbmDOK0FmucideVzrxyHpZcLxJfDkn574TY0j2oY2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3244 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 08:49:52 -0000 --_000_FF6265924B084F7B9FAE4BD9AFEBF408ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlrZSwNCg0KSSBkb24ndCB0aGluayBJJ20gYXNraW5nIGZvciAiZm9sa3Mgbm90IHRvIHBh cnRpY2lwYXRlIGluIGxlYWRlcnNoaXAgZGVjaXNpb25zIGFib3V0IHdvcmsgdGhhdCBtYXkgYWZm ZWN0IHRoZWlyIGVtcGxveWVyIiwgd2hhdCBJIGFtIHN1Z2dlc3RpbmcgaXMgdGhhdCB3aGVuIGlu IHRoZSAiZGVjaWRlciIgcm9sZSwgdGhhdCB0aGUgcGVyc29uIHRha2VzIGEgdmVyeSBjbG9zZSBs b29rIGF0IHRoZSBvcHRpY3MsIGFuZCBhdm9pZHMgYmxhdGFudCBjb25mbGljdHMgb2YgaW50ZXJl c3QuICAgOTAlIG9mIHRoZSB0aW1lIHRoZXNlIHdpbGwgYmUgImRvbid0IGNhcmUiIGRlY2lzaW9u cyBmb3IgYm90aCB0aGUgZW1wbG95ZXIgYW5kIGNvbXBldGl0b3JzLiAgSXQncyB0aGF0IG90aGVy IDEwJSB3aGVyZSB3ZSBtaWdodCBlbmQgdXAgaW4gdHJvdWJsZS4NCg0KV2hpbGUgSSByZWFsaXpl IHRoYXQgcGVvcGxlIGhhdmUgYW4gaW50ZXJlc3QgaW4gZXJyaW5nIG9uIHRoZSDigJxkaXNjbG9z ZeKAnSBzaWRlLCB0aGVyZSBhcmUgc29tZSBwb3RlbnRpYWwgcmlza3MgaW4gZG9pbmcgc28gd2hl biB0aGVyZSByZWFsbHkgaXMgbm8gcmVhc29uLCBldmVuIGlmIG5vdCBkb2luZyBzbyB3b3VsZCBs ZW5kIGl0c2VsZiB0byB0aGUgYXBwZWFyYW5jZSBvZiBiYWQgcG9vbCBsYXRlcjogaWYgZWFjaCBh bmQgZXZlcnkgSUFCIGRlY2lzaW9uIGludm9sdmluZyBwZXJzb25uZWwgb3Igc3RhbmRhcmRzIGlu IHBhcnRpY3VsYXIgcmVxdWlyZXMgYSBkaXNjbG9zdXJlIHN0YXRlbWVudCBzaW1wbHkgYmVjYXVz ZSB0aGVyZSBpcyBhIGNvcnBvcmF0ZSBpbnRlcmVzdCwgcGVvcGxlIHdpbGwgYmVjb21lIGhhYml0 dWF0ZWQgdG8gc3VjaCBkaXNjbG9zdXJlcywgYW5kIGlnbm9yZSB0aGUgb25lcyB0aGF0IHJlYWxs eSBtYXR0ZXIuDQoNCldpdGggcmVnYXJkIHRvIHJlY3VzYWxzLCB0aGV5IGNhbiBoYW1zdHJpbmcg dGhlIHdvcmsgb2YgdGhlIElBQiwgcGFydGljdWxhcmx5IHdoZW4gaXQgY29tZXMgdG8gY29uZmly bWluZyBjYW5kaWRhdGVzLiAgQXMgYW4gZW1wbG95ZWUgb2YgQ2lzY28gSSBoYWQgdG8gZGVjaWRl IHdoZXRoZXIgdG8gcmVjdXNlIHRoZSBkZWNpc2lvbiB0byBjb25maXJtIHNvbWVvbmUgd2hvIHdv cmtlZCBhdCBhIGNvbXBldGl0b3IuICBDaXNjbyBpcyBzbyBsYXJnZSB0aGF0IHN1Y2ggYSBzZXQg aXMgaGFyZCB0byBkZWZpbmUsIGFuZCBldmVuIGlmIHdlIHVzZWQgY29tbW9uIG5vdGlvbnMsIEkg c2F3IG5vIHZhbHVlIGluIG15IHJlY3VzYWwsIGFuZCBzb21lIGhhcm0gdG8gdGhlIGluc3RpdHV0 aW9uIHdvdWxkIEkgaGF2ZSBkb25lIHNvIGJlY2F1c2UgaXQgd291bGQgaGF2ZSBzZW50IGEgbWVz c2FnZSBzYXlpbmcgdGhhdCB0aGUgSUFCIGFzIGEgd2hvbGUgY291bGQgYmUgdHJ1c3RlZCB0byBl dmFsdWF0ZSBpbiB0aGUgZmFjZSBvZiBzdWNoIHBvdGVudGlhbCBjb25mbGljdHMuDQoNCkluIGFu b3RoZXIgY2FzZSwgSSBteXNlbGYgcmVjdXNlZCBvbiBhIGRlY2lzaW9uIHJlZ2FyZGluZyBJU09D IEJvYXJkIHNlbGVjdGlvbiwgSSBkaWQgc28gb3V0IG9mIGFuIGFidW5kYW5jZSBvZiBjYXV0aW9u IGJlY2F1c2UgdG8gYXZvaWQgdGhlIGFwcGVhcmFuY2Ugb2YgYSBxdWlkLXByby1xdW8gYmV0d2Vl biBtZSBwZXJzb25hbGx5IGFuZCBzb21lb25lIG9uIHRoZSBOT01DT00gdGhhdCBhcHBvaW50ZWQg bWUuIEJ1dCB0aGVyZSBhcmUgdGVuIHZvdGluZyBtZW1iZXJzIG9mIHRoZSBOT01DT00gYW5kIGFz IG1hbnkgb24gdGhlIElBQiB0byBwcm92aWRlIGEgcHJldHR5IHJlYXNvbmFibGUgbGF5ZXIgb2Yg cHJvdGVjdGlvbiwgZXZlbiBoYWQgSSBub3QuICBBcmd1YWJseSBJIGVycmVkIGluIHJlY3VzaW5n IGluIHRoYXQgaW5zdGFuY2UuDQoNCkkgd291bGQgbXVjaCByYXRoZXIgd2UgYXNzdW1lIHRoYXQg cGVvcGxlIGFyZSBjb25mbGljdGVkLCB0aGF0IHRoZXJlIGlzIG5vIGZpZHVjaWFyeSByZXNwb25z aWJpbGl0eSBvbiB0aGUgcGFydCBvZiB0aGUgSUFCLCBsaWFpc29ucywgYW5kIElFU0cgbWVtYmVy cyB0byB0aGUgSUVURiBvciB0aGUgTExDLCBhbmQgdGhhdCBvdXIgb3JnYW5pemF0aW9uIGRlZmVu ZCBhZ2FpbnN0IHN1Y2ggcG90ZW50aWFsIGNvbmZsaWN0cyB0aHJvdWdoIGRpdmVyc2l0eSBvZiBs ZWFkZXJzaGlwLiAgVGhlIGp1c3QtYW5ub3VuY2VkIElBQiBzZWVtcyB0byBtZSB0byBiZSBwcmV0 dHkgd2VsbCBiYWxhbmNlZCAob3IgYXQgbGVhc3QgbW9yZSBiYWxhbmNlZCksIG5vdCBvbmx5IGlu IHRlcm1zIG9mIGNvcnBvcmF0ZSBwYXJ0aWNpcGF0aW9uLCBidXQgYWxzbyBpbiB0ZXJtcyBvZiBw b2ludHMgb2Ygdmlldy4gIFRoYXQgdG8gbWUgYWRkcmVzc2VzIHRoZSBJQUIgZmFyIGJldHRlciB0 aGFuIGFueSBDb0kgcG9saWN5IGV2ZXIgY291bGQuDQoNCkkgZmVlbCBhIGJpdCBkaWZmZXJlbnRs eSBhYm91dCB0aGUgSUVTRyBhbmQgV0cgY2hhaXJzIGJlY2F1c2Ugb2YgdGhlIHdheSB0aG9zZSBy b2xlcyBhcmUgY29uc3RydWN0ZWQsIGJ1dCB0aGF0IGdyb3VuZCBoYXMgYmVlbiB3ZWxsIGNvdmVy ZWQgZWxzZXdoZXJlIGluIHRoaXMgdGhyZWFkLg0KDQpFbGlvdA0KDQo= --_000_FF6265924B084F7B9FAE4BD9AFEBF408ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <069B1ECF73A6C643B1076C5686AC570A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIE1pa2UsPGJyIGNsYXNzPSIiPg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+SSBkb24ndCB0aGluayBJJ20gYXNraW5nIGZvciAmcXVvdDtmb2xrcyBub3QgdG8gcGFy dGljaXBhdGUgaW4gbGVhZGVyc2hpcCBkZWNpc2lvbnMgYWJvdXQgd29yayB0aGF0IG1heSBhZmZl Y3QgdGhlaXIgZW1wbG95ZXImcXVvdDssIHdoYXQgSSBhbSBzdWdnZXN0aW5nIGlzIHRoYXQgd2hl biBpbiB0aGUgJnF1b3Q7ZGVjaWRlciZxdW90OyByb2xlLCB0aGF0IHRoZSBwZXJzb24gdGFrZXMg YSB2ZXJ5IGNsb3NlIGxvb2sgYXQgdGhlIG9wdGljcywgYW5kIGF2b2lkcw0KIGJsYXRhbnQgY29u ZmxpY3RzIG9mIGludGVyZXN0LiZuYnNwOyZuYnNwOyA5MCUgb2YgdGhlIHRpbWUgdGhlc2Ugd2ls bCBiZSAmcXVvdDtkb24ndCBjYXJlJnF1b3Q7IGRlY2lzaW9ucyBmb3IgYm90aCB0aGUgZW1wbG95 ZXIgYW5kIGNvbXBldGl0b3JzLiZuYnNwOyBJdCdzIHRoYXQgb3RoZXIgMTAlIHdoZXJlIHdlIG1p Z2h0IGVuZCB1cCBpbiB0cm91YmxlLjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPldoaWxlIEkgcmVhbGl6ZSB0aGF0IHBlb3BsZSBoYXZl IGFuIGludGVyZXN0IGluIGVycmluZyBvbiB0aGUg4oCcZGlzY2xvc2XigJ0gc2lkZSwgdGhlcmUg YXJlIHNvbWUgcG90ZW50aWFsIHJpc2tzIGluIGRvaW5nIHNvIHdoZW4gdGhlcmUgcmVhbGx5IGlz IG5vIHJlYXNvbiwgZXZlbiBpZiBub3QgZG9pbmcgc28gd291bGQgbGVuZCBpdHNlbGYgdG8gdGhl IGFwcGVhcmFuY2Ugb2YgYmFkIHBvb2wgbGF0ZXI6IGlmIGVhY2ggYW5kIGV2ZXJ5DQogSUFCIGRl Y2lzaW9uIGludm9sdmluZyBwZXJzb25uZWwgb3Igc3RhbmRhcmRzIGluIHBhcnRpY3VsYXIgcmVx dWlyZXMgYSBkaXNjbG9zdXJlIHN0YXRlbWVudCBzaW1wbHkgYmVjYXVzZSB0aGVyZSBpcyBhIGNv cnBvcmF0ZSBpbnRlcmVzdCwgcGVvcGxlIHdpbGwgYmVjb21lIGhhYml0dWF0ZWQgdG8gc3VjaCBk aXNjbG9zdXJlcywgYW5kIGlnbm9yZSB0aGUgb25lcyB0aGF0IHJlYWxseSBtYXR0ZXIuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaXRo IHJlZ2FyZCB0byByZWN1c2FscywgdGhleSBjYW4gaGFtc3RyaW5nIHRoZSB3b3JrIG9mIHRoZSBJ QUIsIHBhcnRpY3VsYXJseSB3aGVuIGl0IGNvbWVzIHRvIGNvbmZpcm1pbmcgY2FuZGlkYXRlcy4g Jm5ic3A7QXMgYW4gZW1wbG95ZWUgb2YgQ2lzY28gSSBoYWQgdG8gZGVjaWRlIHdoZXRoZXIgdG8g cmVjdXNlIHRoZSBkZWNpc2lvbiB0byBjb25maXJtIHNvbWVvbmUgd2hvIHdvcmtlZCBhdCBhIGNv bXBldGl0b3IuICZuYnNwO0Npc2NvDQogaXMgc28gbGFyZ2UgdGhhdCBzdWNoIGEgc2V0IGlzIGhh cmQgdG8gZGVmaW5lLCBhbmQgZXZlbiBpZiB3ZSB1c2VkIGNvbW1vbiBub3Rpb25zLCBJIHNhdyBu byB2YWx1ZSBpbiBteSByZWN1c2FsLCBhbmQgc29tZSBoYXJtIHRvIHRoZSBpbnN0aXR1dGlvbiB3 b3VsZCBJIGhhdmUgZG9uZSBzbyBiZWNhdXNlIGl0IHdvdWxkIGhhdmUgc2VudCBhIG1lc3NhZ2Ug c2F5aW5nIHRoYXQgdGhlIElBQiBhcyBhIHdob2xlIGNvdWxkIGJlIHRydXN0ZWQgdG8gZXZhbHVh dGUNCiBpbiB0aGUgZmFjZSBvZiBzdWNoIHBvdGVudGlhbCBjb25mbGljdHMuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBhbm90aGVy IGNhc2UsIEkgbXlzZWxmIHJlY3VzZWQgb24gYSBkZWNpc2lvbiByZWdhcmRpbmcgSVNPQyBCb2Fy ZCBzZWxlY3Rpb24sIEkgZGlkIHNvIG91dCBvZiBhbiBhYnVuZGFuY2Ugb2YgY2F1dGlvbiBiZWNh dXNlIHRvIGF2b2lkIHRoZSBhcHBlYXJhbmNlIG9mIGEgcXVpZC1wcm8tcXVvIGJldHdlZW4gbWUN CjxiIGNsYXNzPSIiPnBlcnNvbmFsbHkmbmJzcDs8L2I+YW5kIHNvbWVvbmUgb24gdGhlIE5PTUNP TSB0aGF0IGFwcG9pbnRlZCBtZS4gQnV0IHRoZXJlIGFyZSB0ZW4gdm90aW5nIG1lbWJlcnMgb2Yg dGhlIE5PTUNPTSBhbmQgYXMgbWFueSBvbiB0aGUgSUFCIHRvIHByb3ZpZGUgYSBwcmV0dHkgcmVh c29uYWJsZSBsYXllciBvZiBwcm90ZWN0aW9uLCBldmVuIGhhZCBJIG5vdC4gJm5ic3A7QXJndWFi bHkgSSBlcnJlZCBpbiByZWN1c2luZyBpbiB0aGF0IGluc3RhbmNlLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSB3b3VsZCBtdWNoIHJh dGhlciB3ZSBhc3N1bWUgdGhhdCBwZW9wbGUgPGIgY2xhc3M9IiI+YXJlPC9iPiZuYnNwO2NvbmZs aWN0ZWQsIHRoYXQgdGhlcmUgaXMNCjxiIGNsYXNzPSIiPm5vPC9iPiBmaWR1Y2lhcnkgcmVzcG9u c2liaWxpdHkgb24gdGhlIHBhcnQgb2YgdGhlIElBQiwgbGlhaXNvbnMsIGFuZCBJRVNHIG1lbWJl cnMgdG8gdGhlIElFVEYgb3IgdGhlIExMQywgYW5kIHRoYXQgb3VyIG9yZ2FuaXphdGlvbiBkZWZl bmQgYWdhaW5zdCBzdWNoIHBvdGVudGlhbCBjb25mbGljdHMgdGhyb3VnaCBkaXZlcnNpdHkgb2Yg bGVhZGVyc2hpcC4gJm5ic3A7VGhlIGp1c3QtYW5ub3VuY2VkIElBQiBzZWVtcyB0byBtZSB0bw0K IGJlIHByZXR0eSB3ZWxsIGJhbGFuY2VkIChvciBhdCBsZWFzdCBtb3JlIGJhbGFuY2VkKSwgbm90 IG9ubHkgaW4gdGVybXMgb2YgY29ycG9yYXRlIHBhcnRpY2lwYXRpb24sIGJ1dCBhbHNvIGluIHRl cm1zIG9mIHBvaW50cyBvZiB2aWV3LiAmbmJzcDtUaGF0IHRvIG1lIGFkZHJlc3NlcyB0aGUgSUFC IGZhciBiZXR0ZXIgdGhhbiBhbnkgQ29JIHBvbGljeSBldmVyIGNvdWxkLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBmZWVsIGEgYml0 IGRpZmZlcmVudGx5IGFib3V0IHRoZSBJRVNHIGFuZCBXRyBjaGFpcnMgYmVjYXVzZSBvZiB0aGUg d2F5IHRob3NlIHJvbGVzIGFyZSBjb25zdHJ1Y3RlZCwgYnV0IHRoYXQgZ3JvdW5kIGhhcyBiZWVu IHdlbGwgY292ZXJlZCBlbHNld2hlcmUgaW4gdGhpcyB0aHJlYWQuPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FbGlvdDwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FF6265924B084F7B9FAE4BD9AFEBF408ciscocom_-- From nobody Wed Jan 15 14:16:48 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6A1209F1; Wed, 15 Jan 2020 14:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCvf9s52c9Oe; Wed, 15 Jan 2020 14:16:45 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD631209E3; Wed, 15 Jan 2020 14:16:44 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 79E9154802F; Wed, 15 Jan 2020 23:16:37 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7239E440059; Wed, 15 Jan 2020 23:16:37 +0100 (CET) Date: Wed, 15 Jan 2020 23:16:37 +0100 From: Toerless Eckert To: IAB Chair Cc: ietf@ietf.org, architecture-discuss@ietf.org, iab@iab.org Subject: Re: [arch-d] Draft IAB conflict of interest policy Message-ID: <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 22:16:46 -0000 On Wed, Jan 08, 2020 at 03:14:57PM -0800, IAB Chair wrote: [...] > Covered Individuals shall not use the IAB???s resources or decisions as a > means for personal or third-party gain. I really do not know how to judge this. I am thining about the following question to (candidate) IAB members: "Can the work of the IAB that you contribute to impact future financial results of your employer / sponsor ?" If one would answer YES, does that constitute a COI ? If not, then what would be a good reference example for the most minor COI that one should be concerned about ? Thanks Toerless > > Disclosure of Actual or Potential Conflicts > > The IAB requires that all Covered Individuals disclose their main > employment, sponsorship, consulting customer, or other sources of income > when joining the IAB or whenever there are updates. > > In addition, when a topic is discussed at the IAB, the Covered Individuals > are required to promptly disclose if that topic constitutes a perceived or > potential conflict of interest. Once disclosed, Covered Individuals may > recuse from participation in discussions or decisions at their discretion. > > The specific conflicts that may cause a perceived or potential conflict of > interest are matters for individual and IAB judgment, but generally come in > the following forms: > > * > > A personnel decision relates to the Covered Individual, a colleague > that the Covered Individual's works closely with, or a family > member. For the purposes of this policy, a "person working closely > with" is someone working in the same team or project, or a direct > manager or employee of the Covered Individual. And "family" means a > spouse, domestic partner, child, sibling, parent, stepchild, > stepparent, and mother-, father-, son-, daughter-, brother-, or > sister-in-law, and any other person living in the same household, > except tenants and household employees. > > * > > A decision or output from the IAB impacts a contract that the IETF > enters into with a party, and that party relates to the Covered > Individual, a colleague that the Covered Individual's works closely > with, or a family member. > > * > > Activity on the IAB involves discussion and decisions regarding > technical matters, mainly related to IETF activities. As an activity > adjacent to a standardization process, it is often the case that > Covered Individuals will have some (frequently non-financial) stake > in the outcome of discussions or decisions that relate to technical > matters. This policy does not require that Covered Individuals > disclose such conflicts of interest as they relate to technical > matters. However, Covered Individuals need to exercise their > judgment and, in extraordinary cases be willing to disclose > potential or perceived conflicts of interest even as they relate to > technical matters. For example, if a Covered Individual's sponsor > were in the process of entering a new market where there is an > ongoing IAB discussion, then disclosure, or even recusal, might be > appropriate, even if difficult. > > > Disclosure Transparency > > A person's recusal to participate in the discussion of a topic is always > noted in the public IAB minutes. In addition, the IAB will maintain a > repository of all general disclosures of employment and other sponsorship. > It is expected that much of this repository is public, but there can be > situations where some disclosures (such as customers of consultants) are > private. > > > > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Jan 15 17:15:19 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD92A120891 for ; Wed, 15 Jan 2020 17:15:17 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 V4MpkXIMSGjw for ; Wed, 15 Jan 2020 17:15:15 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 63923120882 for ; Wed, 15 Jan 2020 17:15:15 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id dp13so8334451qvb.7 for ; Wed, 15 Jan 2020 17:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WzgQvDn++ZCcu3rcaOXx7AfjmuYYAmuMiO+RX+PgBTo=; b=JPfY/h0FPr00k2CgJwhgq0BI3WfDUWVMLPlCt16PR8nI6tX+3HagoZp3Gwy6GDpu+Z c0zkwJ0X4SlV7HZ2WZWitgnzjxJ/tV+UDpM90j9L6+ewrEscYhLSntLNCowKXbJn5tFO xB6FsOEIiq7gRBjcRvsQzu+IoNMZzaIzSgtHXOK0Y8VnjDcgKO4A2tBC7BA+eHuUVgTw xD7zxnC+k4duZ/OGALJqn/jEyzbenRk/1uj5UYjp7K77+y3eAMJ7jkQxBEZAAt8vUfQv mXusDHxE8XZuVTXtcru8prub8Q83ySzxRU4HlWU3GxVCYlo97zpg5s17pAkBXl4fhztB MQaw== 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=WzgQvDn++ZCcu3rcaOXx7AfjmuYYAmuMiO+RX+PgBTo=; b=UhpUZawF+15sM0ABlPXsO8PINdHe2MChJy1IlJ+aXZkHJImhRluNvbWLmOfW2m15bF RygzAGWP20Q5Ys4oxU85+xucNDZ4F/7S+fh2jlpqbSRsclN89TpyHFZOtqSxy51CrAUE qdqiD9x5gLmtjbFDpceZ8b6DuH6yBwaiEB6qV0FOftaBFJ4Ih5P5kCwFmdfp+6Sfwejr Y9nNs95W0Zc3t41NM2roYgO88RFeowcyXlQ4Z66GurQ6/SypmNbdKszJsNdK8ClsEAKf QxxoIAuaGWRx7lt6qqcsp4Husc2pwRiuK/ofqA9btbO3gnpqYh1srcNTyK+GvTbp2VHQ D5Yw== X-Gm-Message-State: APjAAAV6kILNVHMzgpvSeBegmikqEC4uqEJbFNeKUneeR1iI7siFtsaR ovXsm9sBHzs1pBBPdWUNAs5BPGsTIm0VDZgUL2IBBg== X-Google-Smtp-Source: APXvYqzLAgRpcBqiVwGJ5j+56RCmNbglXpUj8tyEAQbvIu2STVrkuDXiuwtbIOPnFznINBJGTkic/CbpGb2jvIMb7lc= X-Received: by 2002:ad4:408c:: with SMTP id l12mr227085qvp.164.1579137314409; Wed, 15 Jan 2020 17:15:14 -0800 (PST) MIME-Version: 1.0 References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> From: Robert Raszuk Date: Wed, 15 Jan 2020 20:15:03 -0500 Message-ID: Subject: Re: [arch-d] Draft IAB conflict of interest policy To: Toerless Eckert Cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000ad635d059c378eea" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 01:15:18 -0000 --000000000000ad635d059c378eea Content-Type: text/plain; charset="UTF-8" Toerless, Considering that not that many of us are really good in predicting the future you post a pretty tough question to answer ;) Cheers, R. "Can the work of the IAB that you contribute to impact future > financial results of your employer / sponsor ?" > > If one would answer YES, does that constitute a COI ? > > If not, then what would be a good reference example for the most minor COI > that one should be concerned about ? > > Thanks > Toerless > > > > > Disclosure of Actual or Potential Conflicts > > > > The IAB requires that all Covered Individuals disclose their main > > employment, sponsorship, consulting customer, or other sources of income > > when joining the IAB or whenever there are updates. > > > > In addition, when a topic is discussed at the IAB, the Covered > Individuals > > are required to promptly disclose if that topic constitutes a perceived > or > > potential conflict of interest. Once disclosed, Covered Individuals may > > recuse from participation in discussions or decisions at their > discretion. > > > > The specific conflicts that may cause a perceived or potential conflict > of > > interest are matters for individual and IAB judgment, but generally come > in > > the following forms: > > > > * > > > > A personnel decision relates to the Covered Individual, a colleague > > that the Covered Individual's works closely with, or a family > > member. For the purposes of this policy, a "person working closely > > with" is someone working in the same team or project, or a direct > > manager or employee of the Covered Individual. And "family" means a > > spouse, domestic partner, child, sibling, parent, stepchild, > > stepparent, and mother-, father-, son-, daughter-, brother-, or > > sister-in-law, and any other person living in the same household, > > except tenants and household employees. > > > > * > > > > A decision or output from the IAB impacts a contract that the IETF > > enters into with a party, and that party relates to the Covered > > Individual, a colleague that the Covered Individual's works closely > > with, or a family member. > > > > * > > > > Activity on the IAB involves discussion and decisions regarding > > technical matters, mainly related to IETF activities. As an activity > > adjacent to a standardization process, it is often the case that > > Covered Individuals will have some (frequently non-financial) stake > > in the outcome of discussions or decisions that relate to technical > > matters. This policy does not require that Covered Individuals > > disclose such conflicts of interest as they relate to technical > > matters. However, Covered Individuals need to exercise their > > judgment and, in extraordinary cases be willing to disclose > > potential or perceived conflicts of interest even as they relate to > > technical matters. For example, if a Covered Individual's sponsor > > were in the process of entering a new market where there is an > > ongoing IAB discussion, then disclosure, or even recusal, might be > > appropriate, even if difficult. > > > > > > Disclosure Transparency > > > > A person's recusal to participate in the discussion of a topic is always > > noted in the public IAB minutes. In addition, the IAB will maintain a > > repository of all general disclosures of employment and other > sponsorship. > > It is expected that much of this repository is public, but there can be > > situations where some disclosures (such as customers of consultants) are > > private. > > > > > > > > < > https://github.com/jariarkko/alternate-iab-coi-policy/blob/master/coi-policy.md#status > > > > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > -- > --- > tte@cs.fau.de > > --000000000000ad635d059c378eea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Toerless,
<= br>
Considering that not that ma= ny of us are really good in predicting the future you post a pretty tough q= uestion to answer ;)

<= div dir=3D"ltr" class=3D"gmail_attr">Cheers,
R.

"Can the work of the IAB that you contribute = to impact future
financial results of your employer / sponsor ?"

If one would answer YES, does that constitute a COI ?

If not, then what would be a good reference example for the most minor COI =
that one should be concerned about ?

Thanks
=C2=A0 =C2=A0 Toerless

>
>=C2=A0 =C2=A0 =C2=A0 Disclosure of Actual or Potential Conflicts
>
> The IAB requires that all Covered Individuals disclose their main
> employment, sponsorship, consulting customer, or other sources of inco= me
> when joining the IAB or whenever there are updates.
>
> In addition, when a topic is discussed at the IAB, the Covered Individ= uals
> are required to promptly disclose if that topic constitutes a perceive= d or
> potential conflict of interest. Once disclosed, Covered Individuals ma= y
> recuse from participation in discussions or decisions at their discret= ion.
>
> The specific conflicts that may cause a perceived or potential conflic= t of
> interest are matters for individual and IAB judgment, but generally co= me in
> the following forms:
>
>=C2=A0 *
>
>=C2=A0 =C2=A0 A personnel decision relates to the Covered Individual, a= colleague
>=C2=A0 =C2=A0 that the Covered Individual's works closely with, or = a family
>=C2=A0 =C2=A0 member. For the purposes of this policy, a "person w= orking closely
>=C2=A0 =C2=A0 with" is someone working in the same team or project= , or a direct
>=C2=A0 =C2=A0 manager or employee of the Covered Individual. And "= family" means a
>=C2=A0 =C2=A0 spouse, domestic partner, child, sibling, parent, stepchi= ld,
>=C2=A0 =C2=A0 stepparent, and mother-, father-, son-, daughter-, brothe= r-, or
>=C2=A0 =C2=A0 sister-in-law, and any other person living in the same ho= usehold,
>=C2=A0 =C2=A0 except tenants and household employees.
>
>=C2=A0 *
>
>=C2=A0 =C2=A0 A decision or output from the IAB impacts a contract that= the IETF
>=C2=A0 =C2=A0 enters into with a party, and that party relates to the C= overed
>=C2=A0 =C2=A0 Individual, a colleague that the Covered Individual's= works closely
>=C2=A0 =C2=A0 with, or a family member.
>
>=C2=A0 *
>
>=C2=A0 =C2=A0 Activity on the IAB involves discussion and decisions reg= arding
>=C2=A0 =C2=A0 technical matters, mainly related to IETF activities. As = an activity
>=C2=A0 =C2=A0 adjacent to a standardization process, it is often the ca= se that
>=C2=A0 =C2=A0 Covered Individuals will have some (frequently non-financ= ial) stake
>=C2=A0 =C2=A0 in the outcome of discussions or decisions that relate to= technical
>=C2=A0 =C2=A0 matters. This policy does not require that Covered Indivi= duals
>=C2=A0 =C2=A0 disclose such conflicts of interest as they relate to tec= hnical
>=C2=A0 =C2=A0 matters. However, Covered Individuals need to exercise th= eir
>=C2=A0 =C2=A0 judgment and, in extraordinary cases be willing to disclo= se
>=C2=A0 =C2=A0 potential or perceived conflicts of interest even as they= relate to
>=C2=A0 =C2=A0 technical matters. For example, if a Covered Individual&#= 39;s sponsor
>=C2=A0 =C2=A0 were in the process of entering a new market where there = is an
>=C2=A0 =C2=A0 ongoing IAB discussion, then disclosure, or even recusal,= might be
>=C2=A0 =C2=A0 appropriate, even if difficult.
>
>
>=C2=A0 =C2=A0 =C2=A0 Disclosure Transparency
>
> A person's recusal to participate in the discussion of a topic is = always
> noted in the public IAB minutes. In addition, the IAB will maintain a<= br> > repository of all general disclosures of employment and other sponsors= hip.
> It is expected that much of this repository is public, but there can b= e
> situations where some disclosures (such as customers of consultants) a= re
> private.
>
>
>
>=C2=A0 <https://github.com/jariarkko/alternate-iab-coi-policy/blob/mast= er/coi-policy.md#status>
>
>

> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailm= an/listinfo/architecture-discuss


--
---
tte@c= s.fau.de

--000000000000ad635d059c378eea-- From nobody Wed Jan 15 19:10:34 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB6012002F; Wed, 15 Jan 2020 19:10:27 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dySnMb5Sitn9; Wed, 15 Jan 2020 19:10:24 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 D506F120803; Wed, 15 Jan 2020 19:10:24 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id z16so9505045pfk.0; Wed, 15 Jan 2020 19:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S6IeIDtMvL5kiP94t+YJRN/YO2X9fJWfepShvvLd9+o=; b=SelC3UfyPzDtCJvfC85g99xvJYwoZSVZ6SSb6DZkdKTiniZ2NSs5eajxehdRNOzLKo eLhtBpIAh066YV/ZSEwBqwDjGFD+1i3eR1xCaxVdv/lmOalPuoa/NWM2mybCpaFusjKd 6DrTYlI/B3SYs1Bq34NLI9bGXermDMHg7afJsGPcQguaMZzjSWw1KzyNQmropkoMHcDa o24MgdhTuuYYzxG5upzrWfD3/LZdYRc8DtX3n25kBCbQS6Irog9waoX4mqJUmMI0MgSp C1HzhsaHc+dVVFYleiFr0HhUJ3SWW3MO0BORfHjPffo+9xyK6rXQ0GXAjwH+1kROLHUZ IDXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S6IeIDtMvL5kiP94t+YJRN/YO2X9fJWfepShvvLd9+o=; b=XCvzPKEDK3XW26AyYZDPIb4u/NDmo2yjKj+s+hQDTKYU6Fpn9NbhF3BQHU/rflYI/I P50GaodkGcEkWAt0byS+P8+T0YnCfltRo4h1YBkpEAJLycvkuii2Og1/YlQnUUJarj+P xtKNLwqQIafiYtB38rwenrnlM7/WzCGo/Hu9A13yLtyj66KAjB6SQmPhaDH2nwLjwhYh Qu9lEXal/ARClKSHZ9n6nMb4XNDVjLdhxc9gn+9nu4/7RI2BKY1dBw7/Z0gYFSaDP89Y wP3Zy60hNj1/F6xHVyDmLQ8dW6weDZ8ixlzETMdMuocHNS6PY1hUGM1kPjY6oxzfKH2j h52Q== X-Gm-Message-State: APjAAAXFIek83bYcdsqe/PdzQMibB+P/eRnn/BFkIgDrxTyEyyN4JbXH EnxqQou+zZtpIJWmSisj0cXVgtdm X-Google-Smtp-Source: APXvYqzoojUHDuC9rjABvmp3KaRO2665jshX+Oa5rd8xyqvP8yakjKDXlStb/Df9NaBEcNkcTBHmHg== X-Received: by 2002:a62:1cd6:: with SMTP id c205mr34760353pfc.179.1579144224025; Wed, 15 Jan 2020 19:10:24 -0800 (PST) Received: from [172.17.0.82] ([111.69.8.186]) by smtp.gmail.com with ESMTPSA id 12sm23770423pfn.177.2020.01.15.19.10.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 19:10:23 -0800 (PST) Subject: Re: [arch-d] Draft IAB conflict of interest policy To: Robert Raszuk , Toerless Eckert Cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Thu, 16 Jan 2020 16:10:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 03:10:27 -0000 On 16-Jan-20 14:15, Robert Raszuk wrote: >=20 >=20 > Toerless, >=20 > Considering that not that many of us are really good in predicting the = future you post a pretty tough question to answer ;) >=20 > Cheers, > R. >=20 > "Can the work of the IAB that you contribute to impact future > financial results of your employer / sponsor ?" I think that's easy. Read the arguments that you, as a candidate, made to= your employer to justify you spending time and travel budget on IAB memb= ership. If those arguments do not explain how IAB membership will positiv= ely affect your employer, answer "No". But in that case, I rather doubt t= hat your employer would have allowed you to accept the nomination. Mine c= ertainly wouldn't have. In other words, the only credible answer to this question is "Yes". =20 > If one would answer YES, does that constitute a COI ? Poetntially, yes. Even a self-employed engineer has this potential COI. I= t's something I lived with as a WG chair, IAB member, IESG member, ISOC B= oard member, and for that matter in completely other non-profit roles at = various times. =20 > If not, then what would be a good reference example for the most mi= nor COI > that one should be concerned about ? IMHO: arguing in a WG for a bit position when your company's running code= or hardware already assumes that bit position. Or arguing for a strange = new protocol feature that your company's business model relies on. That's= probably only happened a few hundred times in the IETF's history. There'= s nothing special about IAB (or even IESG) membership from this point of = view. It's potentially all of us. As long as it's argued in public, we ca= n resolve it. That's why I don't get the point of an IAB COI policy. We don't have an I= ETF COI policy, but I believe that's because the IETF process rules were = themselves designed around avoiding the standards process being damaged b= y COI. As long as the standards process is fully open, and HR and budget = COI is covered by IETF LLC rules, why bother? Regards Brian >=20 > Thanks > =C2=A0 =C2=A0 Toerless >=20 > > > >=C2=A0 =C2=A0 =C2=A0 Disclosure of Actual or Potential Conflicts > > > > The IAB requires that all Covered Individuals disclose their main= > > employment, sponsorship, consulting customer, or other sources of= income > > when joining the IAB or whenever there are updates. > > > > In addition, when a topic is discussed at the IAB, the Covered In= dividuals > > are required to promptly disclose if that topic constitutes a per= ceived or > > potential conflict of interest. Once disclosed, Covered Individua= ls may > > recuse from participation in discussions or decisions at their di= scretion. > > > > The specific conflicts that may cause a perceived or potential co= nflict of > > interest are matters for individual and IAB judgment, but general= ly come in > > the following forms: > > > >=C2=A0 * > > > >=C2=A0 =C2=A0 A personnel decision relates to the Covered Individu= al, a colleague > >=C2=A0 =C2=A0 that the Covered Individual's works closely with, or= a family > >=C2=A0 =C2=A0 member. For the purposes of this policy, a "person w= orking closely > >=C2=A0 =C2=A0 with" is someone working in the same team or project= , or a direct > >=C2=A0 =C2=A0 manager or employee of the Covered Individual. And "= family" means a > >=C2=A0 =C2=A0 spouse, domestic partner, child, sibling, parent, st= epchild, > >=C2=A0 =C2=A0 stepparent, and mother-, father-, son-, daughter-, b= rother-, or > >=C2=A0 =C2=A0 sister-in-law, and any other person living in the sa= me household, > >=C2=A0 =C2=A0 except tenants and household employees. > > > >=C2=A0 * > > > >=C2=A0 =C2=A0 A decision or output from the IAB impacts a contract= that the IETF > >=C2=A0 =C2=A0 enters into with a party, and that party relates to = the Covered > >=C2=A0 =C2=A0 Individual, a colleague that the Covered Individual'= s works closely > >=C2=A0 =C2=A0 with, or a family member. > > > >=C2=A0 * > > > >=C2=A0 =C2=A0 Activity on the IAB involves discussion and decision= s regarding > >=C2=A0 =C2=A0 technical matters, mainly related to IETF activities= =2E As an activity > >=C2=A0 =C2=A0 adjacent to a standardization process, it is often t= he case that > >=C2=A0 =C2=A0 Covered Individuals will have some (frequently non-f= inancial) stake > >=C2=A0 =C2=A0 in the outcome of discussions or decisions that rela= te to technical > >=C2=A0 =C2=A0 matters. This policy does not require that Covered I= ndividuals > >=C2=A0 =C2=A0 disclose such conflicts of interest as they relate t= o technical > >=C2=A0 =C2=A0 matters. However, Covered Individuals need to exerci= se their > >=C2=A0 =C2=A0 judgment and, in extraordinary cases be willing to d= isclose > >=C2=A0 =C2=A0 potential or perceived conflicts of interest even as= they relate to > >=C2=A0 =C2=A0 technical matters. For example, if a Covered Individ= ual's sponsor > >=C2=A0 =C2=A0 were in the process of entering a new market where t= here is an > >=C2=A0 =C2=A0 ongoing IAB discussion, then disclosure, or even rec= usal, might be > >=C2=A0 =C2=A0 appropriate, even if difficult. > > > > > >=C2=A0 =C2=A0 =C2=A0 Disclosure Transparency > > > > A person's recusal to participate in the discussion of a topic is= always > > noted in the public IAB minutes. In addition, the IAB will mainta= in a > > repository of all general disclosures of employment and other spo= nsorship. > > It is expected that much of this repository is public, but there = can be > > situations where some disclosures (such as customers of consultan= ts) are > > private. > > > > > > > >=C2=A0 > > > > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 > --=20 > --- > tte@cs.fau.de >=20 From nobody Wed Jan 15 20:31:21 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFD1120855; Wed, 15 Jan 2020 20:31:20 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvCFJaN7dlwb; Wed, 15 Jan 2020 20:31:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4B1FC120803; Wed, 15 Jan 2020 20:31:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1irwoO-0008TN-GC; Thu, 16 Jan 2020 04:31:16 +0000 Date: Wed, 15 Jan 2020 20:31:15 -0800 Message-ID: From: Randy Bush To: Brian E Carpenter Cc: IETF Rinse Repeat , architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:31:20 -0000 > I think that's easy. Read the arguments that you, as a candidate, made > to your employer to justify you spending time and travel budget on IAB > membership. If those arguments do not explain how IAB membership will > positively affect your employer, answer "No". But in that case, I > rather doubt that your employer would have allowed you to accept the > nomination. Mine certainly wouldn't have. > > In other words, the only credible answer to this question is "Yes". i know this is terribly old fashioned and silly of me. but some see roles as public service for the good of the internet. and some of us are spoiled brats whose employers support them willy nilly. randy From nobody Wed Jan 15 20:34:36 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51FF120889; Wed, 15 Jan 2020 20:34:34 -0800 (PST) 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, 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 tyaoKSFD_U2b; Wed, 15 Jan 2020 20:34:33 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B70712002F; Wed, 15 Jan 2020 20:34:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 6736B9BA3744; Wed, 15 Jan 2020 22:34:29 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B4PfFGSmPsr; Wed, 15 Jan 2020 22:34:28 -0600 (CST) Received: from [172.16.1.18] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id D61119BA373B; Wed, 15 Jan 2020 22:34:28 -0600 (CST) From: "Pete Resnick" To: gendispatch@ietf.org Cc: "IETF discussion list" Subject: Agenda items for gendispatch? Date: Wed, 15 Jan 2020 22:34:28 -0600 Reply-To: gendispatch@ietf.org X-Mailer: MailMate (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:34:35 -0000 Greetings, As the time quickly approaches for requesting a meeting for the March IETF, your gendispatch chairs wonder if there are agenda items for which we should schedule a meeting. Please let us know on the gendispatch list (the Reply-To on this message is set there) within the next two weeks if you have any potential agenda items so we can decide if a meeting is necessary. Thanks, Pete & Francesca From nobody Wed Jan 15 20:52:59 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245B21208AE; Wed, 15 Jan 2020 20:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 yJYfHiydNPoQ; Wed, 15 Jan 2020 20:52:50 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 BDBF31208AC; Wed, 15 Jan 2020 20:52:50 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 00G4nBGv004943; Thu, 16 Jan 2020 04:52:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cpPhLxS9ATT6Jr/rtGYFpEzQsSsCRJmZ5Z/vaO45E5s=; b=CX1nMr9Cue3EovBG5ldbwCjAB2fBWY2MVNdVr9waGBo0PAlVnZ/msNDXtV9wX/iiRljF MvT1i35pnso4vO2h/o4ze+m5D1lze/pHizURjEZZgzDs9HjhvFJkAJjGHU6N9E09ru4Z qiYgLcpXzPfD5jjPL6wYkHAza8yBDw9YToe68i/0dKbjpJdcTG1gJnMYhVk8puivkjpS yj/GpXjkxBlV9SQjXHWjtJJbbwqe8XvFS4iQkGO5d3MjV8FPRkpvg191ErIiHgQ4u5eP ShiXC3dgiEl3V7DMJ3yEHv4hRkA9AoJrmq9+BXltzKQJqC9UV7/KkuA/giyaybo4yObE nA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2xhpsn5nyb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 04:52:49 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00G4l21o023439; Wed, 15 Jan 2020 23:52:48 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2xfajyw0yu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 23:52:48 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 23:52:47 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 15 Jan 2020 23:52:47 -0500 From: "Salz, Rich" To: Randy Bush , Brian E Carpenter CC: IETF Rinse Repeat , "architecture-discuss@ietf.org" Subject: Re: [arch-d] Draft IAB conflict of interest policy Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfsqcaAgAAx24CAACA0gIAAFp2A//+yMQA= Date: Thu, 16 Jan 2020 04:52:46 +0000 Message-ID: <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.80.50] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-16_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=418 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001160038 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-16_02:2020-01-16, 2020-01-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 clxscore=1015 mlxlogscore=393 phishscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001160038 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:52:52 -0000 PiAgICBpIGtub3cgdGhpcyBpcyB0ZXJyaWJseSBvbGQgZmFzaGlvbmVkIGFuZCBzaWxseSBvZiBt ZS4gIGJ1dCBzb21lIHNlZQ0KICAgIHJvbGVzIGFzIHB1YmxpYyBzZXJ2aWNlIGZvciB0aGUgZ29v ZCBvZiB0aGUgaW50ZXJuZXQuICBhbmQgc29tZSBvZiB1cw0KICAgIGFyZSBzcG9pbGVkIGJyYXRz IHdob3NlIGVtcGxveWVycyBzdXBwb3J0IHRoZW0gd2lsbHkgbmlsbHkuDQogIA0KWWVzLCBidXQg dGhhdCB0ZW5kcyB0byBwZXJwZXR1YXRlIHRoZSBzaXR1YXRpb24gdGhhdCBvbmx5IGJpZ2dlciBv cmdhbml6YXRpb25zIGNhbiBhZmZvcmQgdG8gc3BvbnNvciBtb3N0IG9mIHRoZSBJRVRGIGxlYWRl cnNoaXAgcG9zaXRpb25zLiBNYW55IChwcm9iYWJseSBpbmNsdWRpbmcgUmFuZHkgYW5kIEJyaWFu KSBzZWUgdGhhdCBhcyBhIHByb2JsZW0uDQoNCg== From nobody Wed Jan 15 20:55:14 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18D6120899; Wed, 15 Jan 2020 20:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgKs08P-1fdS; Wed, 15 Jan 2020 20:55:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) (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 C6376120807; Wed, 15 Jan 2020 20:55:11 -0800 (PST) Received: from [198.180.150.2] (helo=mail.rg.net) by psg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1irxBW-000OkX-Fo; Thu, 16 Jan 2020 04:55:10 +0000 Received: from c-24-16-172-3.hsd1.wa.comcast.net ([24.16.172.3] helo=[192.168.0.157]) by mail.rg.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1irxBV-00055r-Ds; Thu, 16 Jan 2020 04:55:09 +0000 From: "Randy Bush" To: "Salz, Rich" Cc: "Brian E Carpenter" , "IETF Rinse Repeat" , architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy Date: Wed, 15 Jan 2020 20:55:06 -0800 X-Mailer: MailMate (1.13.1r5671) Message-ID: <343C5DC4-9B53-4E6A-BB17-1578E601B94C@psg.com> In-Reply-To: <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:55:13 -0000 >> i know this is terribly old fashioned and silly of me. but some see >> roles as public service for the good of the internet. and some >> of us are spoiled brats whose employers support them willy nilly. > Yes, but that tends to perpetuate the situation that only bigger > organizations can afford to sponsor most of the IETF leadership > positions. Many (probably including Randy and Brian) see that as a > problem. neither of my two full time jobs are for large corps. one is an isp research lab, and the other a startup routing stack dev. randy From nobody Wed Jan 15 21:02:57 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678671208AC; Wed, 15 Jan 2020 21:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=akamai.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 ns7su8bVOkyS; Wed, 15 Jan 2020 21:02:44 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2150912089D; Wed, 15 Jan 2020 21:02:44 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 00G4xT3H032074; Thu, 16 Jan 2020 05:02:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=eCAc2LTXBl3xh219Z8WM7+yArdpqDhZfwWX+F3AxRWU=; b=ZtSo0Of5ksMbVsUWwtuyUE9vrKnv8UKMe2yza33swkb081UBxymEcPSDoakUkh3ZTYqX QjnOdzsHORfqsA5SIzOq5W8LQzEmO6bIpnqR0bFutY3Iuw66xGld4SLCoE27XfYehvrd YbvbAoEvWKfB9I3K0VxMTft+DvsdTYvZTN+jAStZCXts30M9QhaSvo9MCRZMXpxGMzZo 47TSp0BX918RPsTGaBQz8VGwZKeoEQRsmmU3mzDpiWVgFLWRzR7JuNZW90NCyxovRnDH 50fz+wecEpwS5K1ShIoaFSu7CQyGGW102bgGVmwi+uK6tFT/t0zxTxhLJAELuBGOEcj3 Nw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2xhpsn5pt4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 05:02:41 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00G52fJB004763; Thu, 16 Jan 2020 00:02:41 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2xfak0n1ph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 00:02:40 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 00:02:39 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 16 Jan 2020 00:02:38 -0500 From: "Salz, Rich" To: Randy Bush CC: Brian E Carpenter , IETF Rinse Repeat , "architecture-discuss@ietf.org" Subject: Re: [arch-d] Draft IAB conflict of interest policy Thread-Topic: [arch-d] Draft IAB conflict of interest policy Thread-Index: AQHVxnmMup37bT2dZUClj9/F6vIplqfsqcaAgAAx24CAACA0gIAAFp2A//+yMQCAAFR5AP//rkkA Date: Thu, 16 Jan 2020 05:02:38 +0000 Message-ID: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> <343C5DC4-9B53-4E6A-BB17-1578E601B94C@psg.com> In-Reply-To: <343C5DC4-9B53-4E6A-BB17-1578E601B94C@psg.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.80.50] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-16_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=641 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001160041 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-16_02:2020-01-16, 2020-01-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 clxscore=1011 mlxlogscore=616 phishscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001160040 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 05:02:50 -0000 PiAgICBuZWl0aGVyIG9mIG15IHR3byBmdWxsIHRpbWUgam9icyBhcmUgZm9yIGxhcmdlIGNvcnBz LiAgb25lIGlzIGFuIGlzcA0KICAgIHJlc2VhcmNoIGxhYiwgYW5kIHRoZSBvdGhlciBhIHN0YXJ0 dXAgcm91dGluZyBzdGFjayBkZXYuDQogIA0KSSBzZW5kICIqdGVuZHMqIHRvIHBlcnBldHVhdGUu IiAgVGhlcmUncyBhbHdheXMgZXhjZXB0aW9uczsgZ2xhZCB5b3UncmUgb25lLg0KDQo= From nobody Thu Jan 16 00:18:36 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8E7120A07; Thu, 16 Jan 2020 00:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvQ7EkkaPAKC; Thu, 16 Jan 2020 00:18:29 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 ABC42120020; Thu, 16 Jan 2020 00:18:29 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id p8so17355849iln.12; Thu, 16 Jan 2020 00:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=I6ARyqBmmKTWayGUDcqgSe2XVQF33rNfMWebPhfc+tE=; b=MRqVx5N8qmSnkEWEDs3X1VpCTcSN/5CqiNM+xnImeLylRV4qwPTO0zAEdFZ3BSpfLF IqaX6baKi28VPdZ2KyQvtA6Lovm7WB6VIVoSFsRhlH8nYwZVfE3h7/1wN/tZgCNumWM/ R47eSIZEOkanTxpEjvanFri4bxLdRufKHCwuEQm9bTMOIzZhRajurg3Cb/JfsV00F+V5 XxhhsaKSJqDcmdh4n/RA4RE0jPlyoSAi1riC8KmGJGe9bCFEBekjdxpBBr6R8hA2M43Q wSk+vZlzsDeRP5QDnTZeEDuHK2K82o7ZSNeFAB76/Y3qtjJj8OCxNR41A3zcL/GpodRp 5fQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=I6ARyqBmmKTWayGUDcqgSe2XVQF33rNfMWebPhfc+tE=; b=pZUoz3I859fvs/TRNPIp5gRwylmWlHNdgc60l6GxQNkJLpEO8YARl711pfU6A5hoyN 0vymZEZcpt9HKaVMLD21v/FYxqVjzJilwDP8HEWKLmE4Yu2cIgBgmvAXZAJlKjm7NCqo 4hljcNAgTfLu/DoSTbjZ7T3K2XuoIFmpV/0rO8IGzIknedfdhxgVbIY+fH2tb7qrIUzF XzAUYMYBiQMHjzT+GMMQi4wp29DbfpiTvXIz/OfdB0rNHM7hFXPDV4esjfH/4KsG7ZnV 4xlq1p86IqNAB9+VWj2Tt0BvLYaSIDxq46rId6R6o47pSu6YXagZid3QetAfiofRVi7a qfjQ== X-Gm-Message-State: APjAAAW0e67ayQA10AGS2PNRLrS0sI9XVR45yhI0p63pSby1dsYvZFLY U97JTiA+jSK7vjG0gcMIjG43EBl53MIZGI+FrwtS+mYXEtg= X-Google-Smtp-Source: APXvYqwIVN4fq4brGebdTttqUGs5P4pjHSBCizbQ1oo0drboST+bhuYC49k3vqn81Px0C1u7ER/Z/rKA2bcM+v7A/rw= X-Received: by 2002:a92:dc91:: with SMTP id c17mr2619359iln.78.1579162708665; Thu, 16 Jan 2020 00:18:28 -0800 (PST) MIME-Version: 1.0 From: Gyan Mishra Date: Thu, 16 Jan 2020 03:17:34 -0500 Message-ID: Subject: [Gen-art] Genart last call review of draft-ietf-rmcat-wireless-tests-08 To: gen-art@ietf.org, ietf@ietf.org, rmcat@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="0000000000004aeb67059c3d78f0" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 08:18:35 -0000 --0000000000004aeb67059c3d78f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reviewer: Gyan Mishra Review result: Ready with Minor Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-rmcat-wireless-tests-08 Reviewer: Gyan Mishra Review Date: 2020-01-17 IETF LC End Date: 2020-01-21 IESG Telechat date: Not scheduled for a telechat Summary: Ready, but with nits and minor issues that should be addressed. Major issues: None Minor issues: This document describes test cases for evaluating performance of RTP congestion control algorithms over LTE & WIFI networks. Section 1 It is mentioned a number of instance where =E2=80=9Cwired=E2=80= =9D is mentioned where I believe =E2=80=9Cwireless=E2=80=9D or =E2=80=9CWIFI=E2=80=9D is wha= t is meant to be stated. Please check. I would recommend to use WIFI to refer to local LAN WIFI and use cellular to refer to a mobile handset, and not use the term =E2=80=9Cwireless=E2=80= =9D as that could be confusing. I would recommend not using LTE to refer to Cellular from a general mobile handset point of view, since LTE refers to 4G and Cellular could be any - 2G,3G,4G,5G etc Section 3 This section also mentioned =E2=80=9Cwired=E2=80=9D where I think= the goal of the document is test cases of WIFI & Cellular and adding in wired does confuse the reader as we are talking about quality degradation issues with wireless technologies - WIFI & Cellular. Please check the verbiage. Section 3 In this sentence you mention 3G support of high bandwidth. My experience with 3G has not been very slow page loading and that multimedia would suffer. Section 3 Bottom of page 5 it is mentioned that the combination of multiple access technologies such as one user has LTE connection and another has Wi-Fi connection is kept out of the scope of this document. Please explain why as the reader would believe it would be in scope as that is the main topic. Section 3 Top of page 6 - I am wondering if there is a better explanation of why you need a test simulator due to unpredictable nature or cellular other than underground mines. Section 3.1.1 Here the fixed user is on a wired LAN connected to mobile user. You mention wireless interface which makes me wonder is the fixed user actually a WIFI user connected to broadband WIFI router wired to the internet. See in quotes which makes me wonder "The fixed user is connected to the Internet via wired connection with sufficiently high bandwidth, for instance, 10 Gbps, so that the system is resource limited on the {wireless?} interface" Section 4.1 Please explain in why the home access link represents a bottleneck due to its bandwidth. It is not obvious as these days Gigabit and above broadband speeds are available at home. Nits/editorial comments: Draft Date should to be updated. Section 3.1.2 1-B Antenna- [2D, 3D] should be defined Section 3.1.2 RTT [40, 150] , should define a unit millisecond Section 3.1.2 4. User Intensity, should define what the values in brackets mean and unit of measure. Section 3.1.2 7.2.a Media direction: Uplink and Downlink, should define what is meant by Uplink and Downlink Section 4.2.3 g N=3D [4, 8, 12, 16, 20], should define what N is and any un= it of measure _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art --0000000000004aeb67059c3d78f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Reviewer: Gyan Mishra
Review result: Ready wit= h Minor Issues

I am the assigned Gen-ART reviewer for this draft. Th= e General Area
Review Team (Gen-ART) reviews all IETF documents being pr= ocessed
by the IESG for the IETF Chair.=C2=A0 Please treat these comment= s just
like any other last call comments.

For more information, p= lease see the FAQ at

<https://trac.ietf.org/t= rac/gen/wiki/GenArtfaq>.=C2=A0=C2=A0

Document: draft-ietf-rmc= at-wireless-tests-08
Reviewer: Gyan Mishra
Review Date: 2020-01-17IETF LC End Date: 2020-01-21
IESG Telechat date: Not scheduled for a te= lechat

Summary: Ready, but with nits and minor issues that should be= addressed.

Major issues: None

Minor issues: =C2=A0This docum= ent describes test cases for evaluating performance of RTP congestion contr= ol algorithms over LTE & WIFI networks. =C2=A0


Section 1 It= is mentioned a number of instance where =E2=80=9Cwired=E2=80=9D is mention= ed where I believe =E2=80=9Cwireless=E2=80=9D or =E2=80=9CWIFI=E2=80=9D is = what is meant to be stated.=C2=A0 Please check.

I would recom= mend =C2=A0to use WIFI to refer to local LAN WIFI and use cellular to refer= to a mobile handset, and not use the term =E2=80=9Cwireless=E2=80=9D as th= at could be confusing.=C2=A0=C2=A0

I would recomme= nd not using LTE to refer to Cellular from a general mobile handset point o= f view, since LTE refers to 4G and Cellular could be any - 2G,3G,4G,5G etc= =C2=A0

Section 3 This section also mentioned =E2=80=9Cwir= ed=E2=80=9D where I think the goal of the document is test cases of WIFI &a= mp; Cellular and adding in wired does confuse the reader=C2=A0
as= we are talking about quality degradation issues with wireless technologies= - WIFI & Cellular.=C2=A0 Please check the verbiage.

= Section 3 In this sentence you mention 3G support of high bandwidth.=C2=A0 = My experience with 3G has not been very slow page loading and that multimed= ia would suffer.

Section 3 Bottom of page 5 it is mention= ed that the combination of multiple access technologies such as one user ha= s LTE connection and another has=C2=A0
Wi-Fi connection is kept o= ut of the scope of this document.=C2=A0 Please explain why as the reader wo= uld believe it would be in scope as that is the main topic.

Section 3 Top of page 6 - I am wondering if there is a better explanatio= n of why you need a test simulator due to unpredictable nature or cellular = other than underground mines. =C2=A0

Section 3.1.1 Here t= he fixed user is on a wired LAN connected to mobile user.=C2=A0 You mention= wireless interface which makes me wonder is the fixed user actually a=C2= =A0
WIFI user connected to broadband WIFI router wired to the int= ernet. See in quotes which makes me wonder=C2=A0
"The fixed = user is connected to the Internet via wired connection with sufficiently hi= gh bandwidth, for instance,=C2=A0
10 Gbps, so that the system is = resource limited on the {wireless?} interface"=C2=A0=C2=A0
<= br>
Section 4.1 Please explain in why the home access link repres= ents a bottleneck due to its bandwidth. =C2=A0
It is not obvious = as these days Gigabit and above broadband speeds are available at home.
=
Nits/editorial comments:

Draft Date should to be updated.=

Section 3.1.2 =C2=A01-B Antenna- [2D, 3D] should be defined<= br>Section 3.1.2 RTT [40, 150] , should define a unit millisecond
Sectio= n 3.1.2 4. User Intensity, should define what the values in brackets mean a= nd unit of measure.
Section 3.1.2 7.2.a Media direction: Uplink and Down= link, =C2=A0should define what is meant by Uplink and Downlink
Section 4= .2.3 g N=3D [4, 8, 12, 16, 20], should define what N is and any unit of mea= sure

_______________________________________= ________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf= .org/mailman/listinfo/gen-art


--0000000000004aeb67059c3d78f0-- From nobody Thu Jan 16 01:50:39 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBD612001E; Thu, 16 Jan 2020 01:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=elandsys.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 us0Qa9-XXaxe; Thu, 16 Jan 2020 01:50:31 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 84CD6120019; Thu, 16 Jan 2020 01:50:31 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.166.51]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00G9oJsI025430 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2020 01:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579168230; x=1579254630; i=@elandsys.com; bh=bn9bZbUsz2eba4v9sEwtM94Groq9eEr/PpF2NLvdTaE=; h=Date:To:From:Subject:Cc; b=ePb4O2cNr/k4WVxhQP7/OzWhwYTpTkA2xkcrXbxpETrSGRHkuRo3ZE3xuOiLkVQ9l vyCTY5GPSWHDnE51CEkFp4nYxcNjlJQRdDjjdjmXGqYqy+HKSRyZYiZyEIURs3xP3o QrLr58KlJTct5BpNpyFFcO6pHPvM3Uu9roJn6QPI= Message-Id: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Jan 2020 01:48:34 -0800 To: trustees@ietf.org From: S Moonesamy Subject: Trust Financial Statements Cc: ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 09:50:38 -0000 Dear IETF Trust, I was browsing your web site and I noticed that the last monthly financial statements is dated August 2019. Could the statements after that month be published on the web site? I could not find the Disclosure Forms mentioned in one of your policies on your web site. I found that odd as the IETF Administration LLC publishes individual-level disclosures. Could the trustees consider publishing the Disclosure Forms? Regards, S. Moonesamy From nobody Thu Jan 16 01:58:29 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FB9120024; Thu, 16 Jan 2020 01:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbsVN6epC1Ev; Thu, 16 Jan 2020 01:58:25 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5871A120019; Thu, 16 Jan 2020 01:58:25 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7309E54804C; Thu, 16 Jan 2020 10:58:20 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6AD04440059; Thu, 16 Jan 2020 10:58:20 +0100 (CET) Date: Thu, 16 Jan 2020 10:58:20 +0100 From: Toerless Eckert To: Randy Bush Cc: Brian E Carpenter , IETF Rinse Repeat , architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy Message-ID: <20200116095820.GA20495@faui48f.informatik.uni-erlangen.de> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 09:58:27 -0000 On Wed, Jan 15, 2020 at 08:31:15PM -0800, Randy Bush wrote: > i know this is terribly old fashioned and silly of me. but some see > roles as public service for the good of the internet. and some of us > are spoiled brats whose employers support them willy nilly. My take: The only way to prove that there is no conflict of interest is when i can prove that i will harm my own interests through what i do. Maybe a reference to Exodus 22:28. That was fun. Now, can we move beyond sillyness ? I hope that most participants in IETF honestly think that what they work towards is not morally evil, but many of us hopefully are also aware that our work is in support of one of potentially multiple competing commercial options whose outcomes do impact revenue and market experience of different group of market participants. Politicians are regularily accused of COI when they change from/to a job in the industry that relates to their political work, so they do not even do both things in parallel like most of us do. Let me repeat my original question: I want user stories: What would be a good reference example for the most minor COI that one should be concerned about in an IAB candidate/member ? Toerless From nobody Thu Jan 16 02:06:11 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D7120024; Thu, 16 Jan 2020 02:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asLmaswWaav1; Thu, 16 Jan 2020 02:06:03 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FD9120019; Thu, 16 Jan 2020 02:06:02 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3748C54804C; Thu, 16 Jan 2020 11:05:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2E85D440059; Thu, 16 Jan 2020 11:05:54 +0100 (CET) Date: Thu, 16 Jan 2020 11:05:54 +0100 From: Toerless Eckert To: "Salz, Rich" Cc: Randy Bush , Brian E Carpenter , IETF Rinse Repeat , "architecture-discuss@ietf.org" Subject: Re: [arch-d] Draft IAB conflict of interest policy Message-ID: <20200116100554.GB20495@faui48f.informatik.uni-erlangen.de> References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <751BE0CC-99C6-442C-843E-97BE053D0B43@akamai.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 10:06:09 -0000 On Thu, Jan 16, 2020 at 04:52:46AM +0000, Salz, Rich wrote: > Yes, but that tends to perpetuate the situation that only bigger organizations can afford to sponsor most of the IETF leadership positions. Many (probably including Randy and Brian) see that as a problem. Does this include owners of one-man shops on contract by big organizations like governments or divisions thereof ? What is an actually small organization in your opinion ? (don't answer). I would say: Candidates supporting "well funded interests" (forget how the emoney flow is orchestrated). We had this discussion maybe even on this list in the past and i asked why ISOC is not providing funding for candidates to leadership positions, and that seemed to have all type of pitfalls too (not too persuading to me though..). Cheers Toerless From nobody Thu Jan 16 04:01:05 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D3A120033 for ; Thu, 16 Jan 2020 04:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou4zHgGPdXOm for ; Thu, 16 Jan 2020 04:00:56 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B1A12002E for ; Thu, 16 Jan 2020 04:00:56 -0800 (PST) Received: from [192.168.1.182] (162-17-148-121-static.hfc.comcastbusiness.net [162.17.148.121]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 855DE540142; Thu, 16 Jan 2020 07:00:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: Draft IAB conflict of interest policy From: Jared Mauch In-Reply-To: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> Date: Thu, 16 Jan 2020 07:00:54 -0500 Cc: ietf@ietf.org Message-Id: <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> To: Michael StJohns X-Mailer: iPhone Mail (17C54) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 12:01:03 -0000 > On Jan 13, 2020, at 2:23 PM, Michael StJohns wrote:= >=20 > Given that IAB is in the appeals chain for protocols standards and other i= tems, and has in the past dabbled with personnel decisions, focusing simply o= n finance and/or personnel seems short sighted.=20 I have several relationships with people that verge on various levels of "is= this something to disclose" Do I need to list all prior employers and standards activities? People I hav= e dated? Companies I have enable on their devices? Machines I have root on?=20= There is a concern here that disclosing everything would be harmful or limit= the people from section when we likely want diversity of opinions to partic= ipate.=20 It's quite a bit to disclose it all, I have old UUCP maps with my name on th= at, consider it disclosed :-) If you are concerned with the honestly of the individuals involved and selec= ted for the roles then is a good time to provide the feedback. I feel we hav= e a lot of process and chance for that at present, but the community consens= us is not always what is the most active thread.=20 I know I'll be disclosing a lot of information in the coming weeks.=20 *buckles in for the ride* - Jared =20= From nobody Thu Jan 16 06:52:30 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C0D12008A; Thu, 16 Jan 2020 06:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc7bvjgKdUR2; Thu, 16 Jan 2020 06:52:23 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B59120043; Thu, 16 Jan 2020 06:52:23 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id d62so19031080oia.11; Thu, 16 Jan 2020 06:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SKy4StY+ALUz8zbHBwzF804k+FO7PQ/ySTUtexBTip0=; b=dIM0Zh7tOnRgwjph+5tdxavKZbFWUsk/WxDsq3Tlvs/xcSkg85PJzxwCDoOSKrE4O7 1KL1WmveLtqNqLCd4LYU5frdAbmd01jTPPe6/kHc2+MzXsF45JJjDYaAG22GJnPp7tCr nTA7qQAdcj3RJlvoWn4dTL86Nr+SCsKIM2kKmksoimXT3XHfdBNeGdO5VfTG9OYkPrcQ qkOsF8TdAoiSOps1SfGKwMaeHmJIrCDSzssom6ryIQ62Ep7nOWLs6qkmit3T18zzGeuG Qij06M2PlwZJff3gWoAfJP86pdHN1/YC8b9n8qqTVbtqmKRjWZrr1m1cmvd95Xh4garg iI/w== 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=SKy4StY+ALUz8zbHBwzF804k+FO7PQ/ySTUtexBTip0=; b=FLoZOsHFmAiYiLUzPWVtCDR7LZ8fq9b5lLYJed7xGOHbTnNeP5/OwhMrf+Z/8Tpa6z 8d6+6wTPos/ECcogjDPSIYfTSUqwoU6CUflN/mBBMpV9GV4cuIhTG1DdDWhRAp9wZjZ3 1D3CIChH8MfNaJazt7zTIlA17UhfmKkvqxBtd33kXF9ChD9iJ29Ex3DJwCnAl+HcJ5U0 zz+ZSiV/UNpd2soyKdkywBPbd6xM7oD5H1sk8AFW+QGCka/VX5bdLTFi/SgrqGkMr1Ep QKf/Na8E33mgVAOzXiwGtE97sRcYrzbJ3Ri+iYeyv3w208UEFRrIbSpwuae7r0n8+9S/ Zbaw== X-Gm-Message-State: APjAAAWrZePCKWPKfBLVJ0CqSnwKFOqGzAolwpZMXNW613prtMNaavhf I2YilMaUPEgXgxtqBUo+y8unRImizqSVhZWP34+wROPV X-Google-Smtp-Source: APXvYqx1MDU3U4fpW5yye0iTJg6U4Grb3799WIj4qOR3QPeoVXm/XDjovXnK2Ijg7qcpQnRLmGNii/BFeCe+DBIHy5g= X-Received: by 2002:aca:4309:: with SMTP id q9mr4333143oia.158.1579186343069; Thu, 16 Jan 2020 06:52:23 -0800 (PST) MIME-Version: 1.0 References: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> From: Kathleen Moriarty Date: Thu, 16 Jan 2020 09:51:47 -0500 Message-ID: Subject: Re: [Trustees] Trust Financial Statements To: S Moonesamy Cc: Trustees Trustees , IETF Content-Type: multipart/alternative; boundary="000000000000034b52059c42f9a1" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 14:52:29 -0000 --000000000000034b52059c42f9a1 Content-Type: text/plain; charset="UTF-8" Hi SM, Thank you for your email. We'll look into the gap and appreciate you pointing it out. We do intend to keep what we can transparent, but as with life, some things fall int he cracks at times. We'll work to get this resolved in terms of the financial statements. As the treasurer, it's all been business as usual. You should just see a repeated pattern from month to month of expected expenses. We'll discuss the disclosures and get back to you as I don't want to respond for everyone until we have time to discuss. Best regards, Kathleen On Thu, Jan 16, 2020 at 4:50 AM S Moonesamy wrote: > Dear IETF Trust, > > I was browsing your web site and I noticed that the last monthly > financial statements is dated August 2019. Could the statements > after that month be published on the web site? > > I could not find the Disclosure Forms mentioned in one of your > policies on your web site. I found that odd as the IETF > Administration LLC publishes individual-level disclosures. Could the > trustees consider publishing the Disclosure Forms? > > Regards, > S. Moonesamy > > _______________________________________________ > Trustees mailing list > Trustees@ietf.org > https://www.ietf.org/mailman/listinfo/trustees > -- Best regards, Kathleen --000000000000034b52059c42f9a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi SM,

Thank you for=C2=A0your email.= =C2=A0 We'll look into the gap and appreciate you pointing it out.=C2= =A0 We do intend to keep what we can transparent, but as with life, some th= ings fall int he cracks at times.=C2=A0 We'll work to get this resolved= in terms of the financial statements.=C2=A0 As the treasurer, it's all= been business as usual.=C2=A0 You should just see a repeated pattern from = month to month of expected expenses.

We'll dis= cuss the disclosures and get back to you as I don't want to respond for= everyone until we have time to discuss.

Best rega= rds,
Kathleen

On Thu, Jan 16, 2020 at 4:50 AM S Moonesamy &= lt;sm+ietf@elandsys.com> w= rote:
Dear IETF = Trust,

I was browsing your web site and I noticed that the last monthly
financial statements is dated August 2019.=C2=A0 Could the statements
after that month be published on the web site?

I could not find the Disclosure Forms mentioned in one of your
policies on your web site.=C2=A0 =C2=A0 I found that odd as the IETF
Administration LLC publishes individual-level disclosures.=C2=A0 Could the =
trustees consider publishing the Disclosure Forms?

Regards,
S. Moonesamy

_______________________________________________
Trustees mailing list
Trustees@ietf.org
https://www.ietf.org/mailman/listinfo/trustees


--

Best regards,
Kathleen
--000000000000034b52059c42f9a1-- From nobody Thu Jan 16 09:00:40 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015C7120B02; Thu, 16 Jan 2020 09:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.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 uOZ3gzbRlfEI; Thu, 16 Jan 2020 09:00:30 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 F0B0A120AB7; Thu, 16 Jan 2020 09:00:29 -0800 (PST) Received: from pps.filterd (m0048276.ppops.net [127.0.0.1]) by m0048276.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 00GGxBSX008726; Thu, 16 Jan 2020 12:00:29 -0500 Received: from usaoamgip002.mail.tfayd.com ([173.213.212.136]) by m0048276.ppops.net-00176a04. with ESMTP id 2xf86262r4-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Thu, 16 Jan 2020 12:00:29 -0500 Received: from unknown (HELO ashemwp00016.mail.tfayd.com) ([10.40.78.204]) by usaoamgip002.mail.tfayd.com with ESMTP; 16 Jan 2020 11:51:46 -0500 Received: from ashemwp00005.mail.tfayd.com (100.126.24.29) by ashemwp00048.mail.tfayd.com (100.126.24.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 16 Jan 2020 12:00:25 -0500 Received: from ashemwp00009.mail.tfayd.com (100.126.24.33) by ashemwp00005.mail.tfayd.com (100.126.24.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 16 Jan 2020 12:00:24 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00009.mail.tfayd.com (100.126.24.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 16 Jan 2020 12:00:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TIVNn0YLTgeHU+v1AWAYuZzxCUXq+9eJ3b1RvbVHOy4yiv3ysKJ5I6ehFheDd8aOz8ZIV9lk+DVEt4XoZNPZft1FII9wKEru8zJ/fJnjAlmrM26MgBjTQpcG5gUGHXTmYUGrX8UQqjyxIDTNeVhIeCAIzoPCAhCjTuUN1ktTnGinS8XdAHs90plg44ahsAoCOjAZdsAK/vX8RSq69RNkVuCjmwqjXPK5vdK3cs8/DO9+ePxUx8L5V9giPadsMw3Q3oL1MCNY2F08JX6U4J1t0jNPu71g+EJAIPHUZCKbY8dd3pKVQ2Twrc0vtC5iQf7QpCgxPvZKnpjnYGybF0nO4A== 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=tq9nGEZWNjCEohedfVohvLpgZvwux53a2MqY/aNwPWk=; b=Sw+d1FAoV/I6+54m1MyU8y8ovdhp/NktDAi7/uiJY/UUH0dva6mjC3JQxHlkwM47MjTcGhEV02MulVCEeJ5F4kAMNSaf+8BLEgE11UJ6eOnGlmaAnMAm8zdaVTLqP34ZQexq9lSfMV4uENZuu1MBQQwWpcYdw2HXGBtbKSKx4kMyh/MjVMRm3+KilgB0c3HbVof71icYfvTU/b9jUykSRuQtd9+jb1BDMn3hmSEe9dMpsK/tsPsw4BmIQmhY5N0N157scLZu+9jPjiXL2QbW9xGPz0uFuTw3/04+iZlIvSe6Bl/qKFMoUIeZPcWVRcnXkCzkq4qn0SlREKHcjlc8TQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tq9nGEZWNjCEohedfVohvLpgZvwux53a2MqY/aNwPWk=; b=g+8QZJvg7EeL0GP3JVpUMnMNEIVSR/06WtyUx5e1819kdkjQDX5k+yTBhud4J2x7r1YQFRRYDA/gyDnI0Jq5LoMKhGTVp21tMtK4XLcu7gVUDBRr88QJEIwao8i1T2d0WNqfSoCixCcqoEgjgIszgv1t5pSBZR2q15wV2FmCvDg= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB3515.namprd14.prod.outlook.com (10.141.163.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Thu, 16 Jan 2020 17:00:24 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2644.021; Thu, 16 Jan 2020 17:00:24 +0000 From: "Deen, Glenn (NBCUniversal)" To: S Moonesamy , "trustees@ietf.org" CC: "ietf@ietf.org" , "Deen, Glenn (NBCUniversal)" Subject: Re: [EXTERNAL] [Trustees] Trust Financial Statements Thread-Topic: [EXTERNAL] [Trustees] Trust Financial Statements Thread-Index: AQHVzFJ2ny3aZ686Y0OE8WHdmacXWKfs/iCA Date: Thu, 16 Jan 2020 17:00:23 +0000 Message-ID: <5C1C71F3-EABC-4382-AAE7-596F95CFF5BF@nbcuni.com> References: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [108.185.101.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb73a821-e07f-47b2-467a-08d79aa59413 x-ms-traffictypediagnostic: DM6PR14MB3515: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(376002)(396003)(136003)(366004)(346002)(189003)(199004)(91956017)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007)(26005)(6506007)(316002)(2616005)(33656002)(186003)(110136005)(54906003)(8676002)(8936002)(71200400001)(36756003)(81156014)(81166006)(6486002)(6512007)(107886003)(5660300002)(2906002)(86362001)(478600001)(966005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB3515; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nGZYqiG7r0TMp/4/cqy4qK1JEGdzj2xb6ygdYoXOZR6XVoe6eJVxRW9yt/NiiQz8FhbCafVxrWdhmnmr74FN2wiqcYZX8/PJpl5JO9gxxYb27UP4CfArl2Vng60xJa7TK1soZTn1wCJLDJ25cQcjaswwB191z8dfuEOnnToE6eoKgzgmUKX8qER/Ms6fz1Tk0zFhlCPWSxXQwzm8pDgOLinQOJwyIkeRGK2pctMn6hDM/GNh7bg94g9WkVi/9K0U7K1QgFcGsmLmTu68Ud+iVyrcTMBbj2TVnvVcufkV2X/N1ejqNUUtbFMpwoUNPdO4IuyqhTuuxT1DCnIeJOj2x1CGcqYpN3az55X+2SPStX2NaSH72+4QclflfDDB9A4VC1UTXnXJgxmdnRNLrOKlvGmHfiubJ6z3t4dFdhSOmXsOzttB4cRuugtXlHpsAX3DdvHVNDFxl0Cww1Fm65Wkan/GHgfmJA4hNZwJYMu2a+c= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eb73a821-e07f-47b2-467a-08d79aa59413 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 17:00:24.0129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Z8qPJgngyaMxThlyEq1Q2/XYmyeAA5nkNCGqMPvbtuUjBh3aIYY1zGcm1AtvG7HYLKtzCcOkM8Vo4gjoHe8pOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB3515 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-16_05:2020-01-16, 2020-01-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 spamscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001160136 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 17:00:36 -0000 SGkgDQoNClRoZSBJRVRGIFRydXN0ZWVzIHdpbGwgY2VydGFpbmx5IGRpc2N1c3MgdGhlIHN1Z2dl c3Rpb24gb2YgdGhlIGluZGl2aWR1YWwtbGV2ZWwgZGlzY2xvc3VyZXMuICAgVGhvdWdoIEknZCBs aWtlIHRvIHNlZSB3aGVyZSB0aGUgY3VycmVudCBvdGhlciBkaXNjdXNzaW9ucyBlbmQgdXAgYmVm b3JlIHdlIHByb2NlZWQgdG9vIGZhciBhcyBJIGRvbid0IHdhbnQgdXMgdG8gZHVwbGljYXRlIGRp c2N1c3Npb25zIHRoYXQgYXJlIGFscmVhZHkgZ29pbmcgb24uICAgICANCg0KVGhlIElFVEYgVHJ1 c3RlZSByb2xlIGlzIGNlcnRhaW5seSBkaWZmZXJlbnQgdGhhbiB0aGUgb3RoZXJzIGJlaW5nIGRp c2N1c3NlZCBhcyBpdCBkb2Vzbid0IGhhdmUgYW55IGluZmx1ZW5jZSBvciBkZWNpc2lvbiBtYWtp bmcgb3ZlciB0ZWNobmljYWwgc3RhbmRhcmRzLCBvciBhcmNoaXRlY3R1cmFsIGlzc3VlLCBvciB3 aGF0IHRoZSBJRVRGIHdvdWxkIHdvcmsgb24uICBJdCBhbHNvIGRvZXNuJ3QgZW5nYWdlIGluIHRo ZSBmdW5kaW5nIGRlY2lzaW9ucyB0aGF0IHRoZSBJRVRGIExMQyBkb2VzLiAgICAgVGhlIFRydXN0 IGZvY3VzZWQgaXMgbGltaXRlZCB0byBtYW5hZ2luZyB0aGUgSUVURiBJUCdzIGFzc2V0cyAtIHRo ZSBjb3B5cmlnaHRzLCB0cmFkZW1hcmtzLCBhbmQgb3BlbiBzb3VyY2UgbGljZW5zZXMsIGFzIHdl bGwgYXMgdGhlIElBTkEgYXNzZXRzLg0KDQpTdGlsbCwgaXQgaXMgc29tZXRoaW5nIEkgYmVsaWV2 ZSB3ZSBzaG91bGQgZGlzY3VzcyBhbmQgY29uc2lkZXIgc28gdGhhdCB3ZSBkbyB3aGF0J3Mgcmln aHQgYW5kIHJlYXNvbmFibGUuDQogDQoNClJlZ2FyZHMNCkdsZW5uIERlZW4sIGFzIElFVEYgVHJ1 c3QgQ2hhaXINCg0KDQrvu79PbiAxLzE2LzIwLCAxOjUxIEFNLCAiVHJ1c3RlZXMgb24gYmVoYWxm IG9mIFMgTW9vbmVzYW15IiA8dHJ1c3RlZXMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg c20raWV0ZkBlbGFuZHN5cy5jb20+IHdyb3RlOg0KDQogICAgRGVhciBJRVRGIFRydXN0LA0KICAg IA0KICAgIEkgd2FzIGJyb3dzaW5nIHlvdXIgd2ViIHNpdGUgYW5kIEkgbm90aWNlZCB0aGF0IHRo ZSBsYXN0IG1vbnRobHkgDQogICAgZmluYW5jaWFsIHN0YXRlbWVudHMgaXMgZGF0ZWQgQXVndXN0 IDIwMTkuICBDb3VsZCB0aGUgc3RhdGVtZW50cyANCiAgICBhZnRlciB0aGF0IG1vbnRoIGJlIHB1 Ymxpc2hlZCBvbiB0aGUgd2ViIHNpdGU/DQogICAgDQogICAgSSBjb3VsZCBub3QgZmluZCB0aGUg RGlzY2xvc3VyZSBGb3JtcyBtZW50aW9uZWQgaW4gb25lIG9mIHlvdXIgDQogICAgcG9saWNpZXMg b24geW91ciB3ZWIgc2l0ZS4gICAgSSBmb3VuZCB0aGF0IG9kZCBhcyB0aGUgSUVURiANCiAgICBB ZG1pbmlzdHJhdGlvbiBMTEMgcHVibGlzaGVzIGluZGl2aWR1YWwtbGV2ZWwgZGlzY2xvc3VyZXMu ICBDb3VsZCB0aGUgDQogICAgdHJ1c3RlZXMgY29uc2lkZXIgcHVibGlzaGluZyB0aGUgRGlzY2xv c3VyZSBGb3Jtcz8NCiAgICANCiAgICBSZWdhcmRzLA0KICAgIFMuIE1vb25lc2FteQ0KICAgIA0K ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg VHJ1c3RlZXMgbWFpbGluZyBsaXN0DQogICAgVHJ1c3RlZXNAaWV0Zi5vcmcNCiAgICBodHRwczov L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cnVzdGVlc19fOyEhUElaZWVXNXdzY3luUlEhOXJPbEdWNENpWHJfb0FLZG1md09kTmJYUi0w Qlkwd3RWbWhuc2tSNVJacTVqQWxNS0J6RXByYk1GZ0FSSjZIbiQgDQogICAgDQoNCg== From nobody Thu Jan 16 09:48:40 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF57120861; Thu, 16 Jan 2020 09:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 noTe0UksW8nS; Thu, 16 Jan 2020 09:48:27 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C14E6120071; Thu, 16 Jan 2020 09:48:27 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.116.6]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00GHmC3P004514 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2020 09:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579196904; x=1579283304; i=@elandsys.com; bh=w70sMHRm7JKJhgQualKOZX1KVb6vf3xm538ugaRnrvs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Au+dza3K4UIlVlR11ivMu2cAxyO0dQPs/xQAm7s/RcZDeYYUVI6HW3pLWfKfHjs6L EMgTuWZbnpVoVr9FZje+qJ/4MZwwSRLz+YEsG4qwvKWoDjcnGUUnDU/9vtY23HRCda f7T8VLsqSwsU1ucDFbROmlkhV+xiiJor+jHZMHaM= Message-Id: <6.2.5.6.2.20200116093537.0d0568b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Jan 2020 09:47:35 -0800 To: "Deen, Glenn (NBCUniversal)" , trustees@ietf.org From: S Moonesamy Subject: Re: [EXTERNAL] [Trustees] Trust Financial Statements Cc: ietf@ietf.org In-Reply-To: <5C1C71F3-EABC-4382-AAE7-596F95CFF5BF@nbcuni.com> References: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> <5C1C71F3-EABC-4382-AAE7-596F95CFF5BF@nbcuni.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 17:48:34 -0000 Dear Glenn, Thank you for the feedback. In order to avoid any confusion I would like to clarify that my request was not related to the topic of having influence or decision making over technical standards, or architectural issue. Regards, S. Moonesamy From nobody Thu Jan 16 10:07:03 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96175120071; Thu, 16 Jan 2020 10:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.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 f5QQsKzO9UQN; Thu, 16 Jan 2020 10:06:52 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (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 4C90812009E; Thu, 16 Jan 2020 10:06:52 -0800 (PST) Received: from pps.filterd (m0048207.ppops.net [127.0.0.1]) by m0048207.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 00GHwf3Q017703; Thu, 16 Jan 2020 13:06:51 -0500 Received: from usaoamgip001.mail.tfayd.com ([173.213.212.135]) by m0048207.ppops.net-00176a04. with ESMTP id 2xfagke3xh-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Thu, 16 Jan 2020 13:06:51 -0500 Received: from unknown (HELO ashemwp00037.mail.tfayd.com) ([10.40.78.204]) by usaoamgip001.mail.tfayd.com with ESMTP; 16 Jan 2020 12:58:32 -0500 Received: from ashemwp00023.mail.tfayd.com (100.126.24.47) by ashemwp00009.mail.tfayd.com (100.126.24.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 16 Jan 2020 13:06:48 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00023.mail.tfayd.com (100.126.24.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 16 Jan 2020 13:06:47 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 16 Jan 2020 13:06:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d7UZ1srrHbTYZRLyaOWEfXGu08PLUZ24tZ5tQSzwh7enSJuZdxF14ugrnB4iA3u8er/yySCjU14Gn0gBiHCS1dvLltxEcEdVDSmBElgaH+gfUg6p3gvy5Qrp1lOlVXlkUV00z6vRCbtwVfoHGl7coEsah/sXzvQpARwbKSVnoZAu+1q32PFI1hNWtjMqYSwIDYRcheeIZtdH9K3MJKj5m50Cq1Inb5Ly/5YdrSBWmZ1/Sd4nvQ934T5ckwUA/XnllJ9hYFTkTFpu/Y4Tt9fCt2YIl0lSduiQHa9DKEeq5nHs/SM+lsQXkA4/ad5wjkoNttmdkdbh3Ye92JCyoSoH8A== 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=JN98Ywy0jb6F2/4CGy1zWPs2WmNrYNsLOhkg53LruTU=; b=KIUW6EXJLbg3BMb/2AnD5No5EGuwHFVbPia+h+VGoFSnuGi51yetcIeiDhZPTbuNMU61vNxQpruqK6QaJCdZOjF6Cn0CcR3nOOHekOsvU31yQIWr8BlYeZ6wa3nsT2m9p6pd+K/HGf0hIs0lfns39MM8lrOKMtUurT972T+n55MRK3bL6CsZZcO8s5jGVHxqZEO9/r+iJbj34kQJw8Zo9gsiQ3LT/TS3OHY/CXDncAYC1oMKVXMUfbSdw+6X+xKHmZtTe1Jd4NodjNCOiK2474mY8zys3oJtXZdGBqMi/PpiKqQoguoK/fd76C628oWdXea5RJ3IRXTMv732YCFZog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JN98Ywy0jb6F2/4CGy1zWPs2WmNrYNsLOhkg53LruTU=; b=R62t6IRtBptYxvpd3AED0WDjHtJNHsENgRQZiJ5CpYFMkLD3YrbUttYcsKsF2NyTDrBRW9qo3/bEyncuYMoibL1iYUUoJO0pmo61eis+f4CTMcx5RjurrpfHrEICd2G+I3sB4lyNxStX80lrbun3Zo/rH+owSUuNQnNXzb6EvNk= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB2297.namprd14.prod.outlook.com (20.176.92.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 16 Jan 2020 18:06:46 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2644.021; Thu, 16 Jan 2020 18:06:46 +0000 From: "Deen, Glenn (NBCUniversal)" To: S Moonesamy , "trustees@ietf.org" CC: "ietf@ietf.org" , "Deen, Glenn (NBCUniversal)" Subject: Re: [EXTERNAL] [Trustees] Trust Financial Statements Thread-Topic: [EXTERNAL] [Trustees] Trust Financial Statements Thread-Index: AQHVzFJ2ny3aZ686Y0OE8WHdmacXWKfs/iCAgACTTYD//38+gA== Date: Thu, 16 Jan 2020 18:06:46 +0000 Message-ID: <9ABA3A15-0FB9-445B-90FC-EB112BEEEF88@nbcuni.com> References: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> <5C1C71F3-EABC-4382-AAE7-596F95CFF5BF@nbcuni.com> <6.2.5.6.2.20200116093537.0d0568b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20200116093537.0d0568b8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [108.185.101.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fb345c47-8742-47bd-cf3d-08d79aaed9c1 x-ms-traffictypediagnostic: DM6PR14MB2297: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(346002)(39860400002)(376002)(136003)(396003)(189003)(199004)(71200400001)(2906002)(66476007)(76116006)(81166006)(107886003)(316002)(66946007)(8936002)(5660300002)(81156014)(8676002)(54906003)(66446008)(33656002)(64756008)(66556008)(6512007)(186003)(4326008)(36756003)(26005)(6486002)(110136005)(2616005)(478600001)(86362001)(6506007)(91956017)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB2297; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 64hDtxgoztfg/mgJ3lLbFT6DZQOjpNlVuqPrEKWCIGFCKoFkY7H9E495vhHANBDix8yw15KA6eB04d2r3oA2uU7FVl0XORT/rL05MKlLEA6t1q5vzNQ15eciQKIf9G8jiWkXvgVIlC7bKpGyOqTmSWP2z7Q2GemukHwiFl5pgXBZb2TMZsX5NiP+A2vhbdhHPfyuF+YUvTiHwi9Jalys0xNia5r2AeUZgH0taQH7/WG4dVXmlqjgjmUzaD7snFxEfjJVOykHEBTNi2y8Fl9BfVkTfUjeFMpudr5cgqeRuZQjZ8txE2x4SB6wyVcP8lhbrLxsR/hJuBt0+fL75EUxLdgwN8VSC3GdyVMoJ99quVbXv0gJDbEIb6bKms+8ZwGfMfscREGt3ozF6xvG88qGxK74phxcNSxPjjN8JY6ex7E3Dy1NxQKqQQIt5Tq8A02D Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fb345c47-8742-47bd-cf3d-08d79aaed9c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 18:06:46.2726 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Pp001xLe+Cti73SleHgA115cAUh3hoX+vZ73NXFCZGJXKCcFv+OSN+6ypl9YeH57z2hON+5qtzhkPiywKyxTew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB2297 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-16_05:2020-01-16, 2020-01-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 impostorscore=0 phishscore=0 spamscore=0 adultscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001160145 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 18:06:58 -0000 T24gMS8xNi8yMCwgOTo0OSBBTSwgIlMgTW9vbmVzYW15IiA8c20raWV0ZkBlbGFuZHN5cy5jb20+ IHdyb3RlOg0KDQogICAgRGVhciBHbGVubiwNCiAgICANCiAgICBUaGFuayB5b3UgZm9yIHRoZSBm ZWVkYmFjay4NCiAgICANCiAgICBJbiBvcmRlciB0byBhdm9pZCBhbnkgY29uZnVzaW9uIEkgd291 bGQgbGlrZSB0byBjbGFyaWZ5IHRoYXQgbXkgDQogICAgcmVxdWVzdCB3YXMgbm90IHJlbGF0ZWQg dG8gdGhlIHRvcGljIG9mIGhhdmluZyBpbmZsdWVuY2Ugb3IgZGVjaXNpb24gDQogICAgbWFraW5n IG92ZXIgdGVjaG5pY2FsIHN0YW5kYXJkcywgb3IgYXJjaGl0ZWN0dXJhbCBpc3N1ZS4NCg0KVW5k ZXJzdG9vZC4gIA0KDQpBdCB0aGUgaGVhcnQgb2YgZGlzY3Vzc2luZyBkaXNjbG9zdXJlIGEga2V5 IHF1ZXN0aW9uIGlzIHdoYXQgYXNwZWN0cyB3b3VsZCBwb3NzaWJseSBiZSBhIGNvbmZsaWN0IG9m IGludGVyZXN0IGZvciBhIFRydXN0ZWUgdGhhdCB3b3VsZCBiZSByZXZlYWxlZCB2aWEgdGhlIGRp c2Nsb3N1cmUuICAgVGhlIFRydXN0J3MgZm9jdXMgb24gSVAgYXNzZXQgbWFuYWdlbWVudCB3aGlj aCBtZWFucyBlbnN1cmluZyBsaWNlbnNlcyBhcmUgcHJvcGVybHkgZG9uZSwgd2hlcmUgbmVlZGVk IGRlZmVuc2l2ZSBwcm90ZWN0aXZlIGFjdGlvbnMgYXJlIHRha2VuLCBhbmQgdGhhdCBuZWVkZWQg bGVnYWwgcHJvY2Vzc2VzIGFyZSBwcm9wZXJseSBmb2xsb3dlZCBhbmQgdGltZWx5IG1ha2VzIHRo ZSBwb3RlbnRpYWwgY29uZmxpY3RzIHZlcnkgZGlmZmVyZW50IGFuZCB3aWxsIHJlcXVpcmUgc29t ZSBuZXcgdGhpbmtpbmcgdGhyb3VnaCB3aGF0IHdvdWxkIGNvbnN0aXR1dGUgYSBjb25mbGljdC4g IA0KDQpDbGVhcmx5IGEgVHJ1c3RlZSB0aGF0IGlzL3dhcyBhIHBsYWludGlmZiBvciBpcy9oYXMg YmVlbiBlbmdhZ2VkIG9uIHRoZSBzaWRlIG9mIGEgcGxhaW50aWZmIGluIGEgbGF3c3VpdCBhZ2Fp bnN0IHRoZSBJRVRGIExDQyBvciBJRVRGIFRydXN0IHdvdWxkIGJlIGEgY2xlYXIgY29uZmxpY3Qu ICAgQW5vdGhlciBpcyBhIHNpdHVhdGlvbiBvZiBhbiBhbnRpLUlQIGFjdGl2aXN0IHdobyBpcyBm dW5kYW1lbnRhbGx5IG9wcG9zZWQgdG8gdGhlIHJvbGUgb2YgdGhlIFRydXN0IG9yIHRoZSB3YXkg dGhhdCBJUCBhc3NldHMgYXJlIGxlZ2FsbHkgbWFuYWdlZCBhcyB0aGV5IG1heSBiZSB1bndpbGxp bmcgdG8gcGVyZm9ybSB0aGUgZHV0aWVzIG9mIGEgVHJ1c3RlZS4gICBXaGF0IG90aGVyIHNpdHVh dGlvbnMgdGhlcmUgbWlnaHQgYmUgd2lsbCBuZWVkIHRoaW5raW5nIHRocm91Z2gsIGFzIHdlbGwg YXMgdGhlIHF1ZXN0aW9uIG9mIHdoYXQgc3BlY2lmaWMgaW5mb3JtYXRpb24gZGlzY2xvc3VyZSB3 b3VsZCBpbiBmYWN0IGJlIGFza2VkIGJ5IFRydXN0ZWVzIHRvIGFkZHJlc3MgdGhlIHNjZW5hcmlv cy4gICANCg0KUmVnYXJkcw0KR2xlbm4NCg0KDQogICAgDQoNCg== From nobody Thu Jan 16 12:09:45 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074131200EF; Thu, 16 Jan 2020 12:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 MPD7SwzDvuAj; Thu, 16 Jan 2020 12:09:37 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7198F12008A; Thu, 16 Jan 2020 12:09:37 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.116.6]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00GK9MUB001295 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2020 12:09:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579205375; x=1579291775; i=@elandsys.com; bh=6x8Jp1ZfpUupcaZgVsZx8L/+TpCMHgVop+fBKCipCgw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sWw684frsnXFb0iiducTsS1mcjpyTCdtViVkyQmT8h9tSl7Zs/f901K9siZoste3E N4ymAHIOLAw5yTsLK0FyIAOa+gjUl0HpUgetXPLL0j8VZqxIThrZHI0wj8moU8evxB 7eEdAiNEqLyCRbL2R+QTWl+SQZVQ6uz0vtIhpr2E= Message-Id: <6.2.5.6.2.20200116103925.0ca66450@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Jan 2020 12:08:54 -0800 To: "Deen, Glenn (NBCUniversal)" , trustees@ietf.org From: S Moonesamy Subject: Re: [EXTERNAL] [Trustees] Trust Financial Statements Cc: ietf@ietf.org In-Reply-To: <9ABA3A15-0FB9-445B-90FC-EB112BEEEF88@nbcuni.com> References: <6.2.5.6.2.20200116011810.07e704b8@elandnews.com> <5C1C71F3-EABC-4382-AAE7-596F95CFF5BF@nbcuni.com> <6.2.5.6.2.20200116093537.0d0568b8@elandnews.com> <9ABA3A15-0FB9-445B-90FC-EB112BEEEF88@nbcuni.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 20:09:42 -0000 Dear Glenn, At 10:06 AM 16-01-2020, Deen, Glenn (NBCUniversal) wrote: >At the heart of discussing disclosure a key question is what aspects >would possibly be a conflict of interest for a Trustee that would be >revealed via the disclosure. The Trust's focus on IP asset >management which means ensuring licenses are properly done, where >needed defensive protective actions are taken, and that needed legal >processes are properly followed and timely makes the potential >conflicts very different and will require some new thinking through >what would constitute a conflict. Yes. >Clearly a Trustee that is/was a plaintiff or is/has been engaged on >the side of a plaintiff in a lawsuit against the IETF LCC or IETF >Trust would be a clear conflict. Another is a situation of an >anti-IP activist who is fundamentally opposed to the role of the >Trust or the way that IP assets are legally managed as they may be >unwilling to perform the duties of a Trustee. What other >situations there might be will need thinking through, as well as the >question of what specific information disclosure would in fact be >asked by Trustees to address the scenarios. One of the stated purposes of the IETF Trust is that it is for the advancement of education and public interest ... It is difficult to argue that the trustee is acting as a disinterested party when there is a conflict of interest. It also raises questions about whether the action was in the public interest or whether it was self-interest. I gather that a Trustee would understand that it is a bad idea to be affiliated with a party which files a lawsuit against the IETF Trust. As for the unwillingness of a Trustee to perform his/her duties, it would be good to understand what the problem is instead of reaching hasty conclusions. Regards, S. Moonesamy From nobody Thu Jan 16 13:41:29 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845D112004A for ; Thu, 16 Jan 2020 13:41:20 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK-3e2Kjkh9h for ; Thu, 16 Jan 2020 13:41:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2E23612004C for ; Thu, 16 Jan 2020 13:41:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1isCt8-0007St-GC for ietf@ietf.org; Thu, 16 Jan 2020 21:41:14 +0000 Date: Thu, 16 Jan 2020 13:41:14 -0800 Message-ID: From: Randy Bush To: IETF Rinse Repeat Subject: Re: Draft IAB conflict of interest policy In-Reply-To: <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 21:41:21 -0000 would being on the board of one or both pir and isoc, and be the exec dir if ietf (paid from pir money), be a conflict? would being on the board of of both isoc and pir be a conflict in this messy deal? asking for a friend randy From nobody Thu Jan 16 14:06:43 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB25212008A for ; Thu, 16 Jan 2020 14:06:41 -0800 (PST) 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, HTML_MESSAGE=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 h-a72xaaQsRW; Thu, 16 Jan 2020 14:06:40 -0800 (PST) Received: from macbook-pro.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id A8AA612004A; Thu, 16 Jan 2020 14:06:39 -0800 (PST) From: Jay Daley Message-Id: <4E1419BE-1EB3-40AD-A3F9-8D05EC5BFAF4@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B0F25BC-5BE8-4016-B6B4-58C15DBA2822" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: Draft IAB conflict of interest policy Date: Fri, 17 Jan 2020 11:06:37 +1300 In-Reply-To: Cc: IETF Discussion To: Randy Bush References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 22:06:42 -0000 --Apple-Mail=_8B0F25BC-5BE8-4016-B6B4-58C15DBA2822 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Randy > On 17/01/2020, at 10:41 AM, Randy Bush wrote: >=20 > would being on the board of one or both pir and isoc, and be the exec > dir if ietf (paid from pir money), be a conflict? Since you=E2=80=99re talking about me, though not to me, allow me to = respond. A conflict of interest comes about where someone is in a position to = influence something improperly. In the case of the PIR/ISOC/IETF = relationship, PIR provides money to ISOC following guidelines set by = ISOC and has no say at all in how that money is used by ISOC. To be = clear, PIR does not recommend to ISOC how the money is used, does not = put any restrictions on how the money is used, does not ask for any = reports on how the money is used and so on. So to describe it as "PIR = money" is incorrect, it is ISOC=E2=80=99s money and they do with it as = they wish. In that context, no there is no conflict of interest. =20 There are other ways in which it could be a conflict of interest, such = as if the LLC were to approach PIR directly for funding, in which case I = would recuse myself on both sides. > would being on the board of of both isoc and pir be a conflict in this > messy deal? The two boards have separate memberships. > asking for a friend If your friend would like to ask me questions like this directly, = privately or publicly, then they are welcome to do so. You may also = wish to point your friend at my published Conflict of Interest statement = [1] kind regards Jay [1] = https://ietf.org/media/documents/Daley_-_IETF_LLC_Conflict_of_Interest_For= m_-_v1_-_20191031.pdf >=20 > randy >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org +64 21 678840 --Apple-Mail=_8B0F25BC-5BE8-4016-B6B4-58C15DBA2822 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Randy

On 17/01/2020, at 10:41 AM, = Randy Bush <randy@psg.com> wrote:

would = being on the board of one or both pir and isoc, and be the exec
dir if ietf (paid from pir money), be a conflict?

Since = you=E2=80=99re talking about me, though not to me, allow me to = respond.

A conflict of interest = comes about where someone is in a position to influence something = improperly.  In the case of the PIR/ISOC/IETF relationship, PIR = provides money to ISOC following guidelines set by ISOC and has no say = at all in how that money is used by ISOC.  To be clear, PIR does = not recommend to ISOC how the money is used, does not put any = restrictions on how the money is used, does not ask for any reports on = how the money is used and so on.  So to describe it as "PIR money" = is incorrect, it is ISOC=E2=80=99s money and they do with it as they = wish.

In that context, no there is = no conflict of interest.  

There = are other ways in which it could be a conflict of interest, such as if = the LLC were to approach PIR directly for funding, in which case I would = recuse myself on both sides.

would being on the board of = of both isoc and pir be a conflict in this
messy deal?

The = two boards have separate memberships.

asking for a friend

If = your friend would like to ask me questions like this directly, privately = or publicly, then they are welcome to do so.  You may also wish to = point your friend at my published Conflict of Interest statement = [1]


kind = regards
Jay




randy


-- 
Jay Daley
IETF = Executive Director
jay@ietf.org
+64 21 678840

= --Apple-Mail=_8B0F25BC-5BE8-4016-B6B4-58C15DBA2822-- From nobody Thu Jan 16 14:35:31 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817C2120099 for ; Thu, 16 Jan 2020 14:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Cgjpf1dy; dkim=pass (1024-bit key) header.d=yitter.info header.b=eszEfHt8 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 tu2rL-AiqUHc for ; Thu, 16 Jan 2020 14:35:28 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359F812004A for ; Thu, 16 Jan 2020 14:35:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8A026BCBD4 for ; Thu, 16 Jan 2020 22:34:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1579214097; bh=TClM6neXuu1zBmORqa1cwbNgbw5uFye2Ox5i0QLTZfM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Cgjpf1dy8kBWxxs/ZOJ8Dfg9z22QiioT7yqOGWb6MQJ/rEFteJ9Yc+s1ly0vDTBM8 9tRqPLHCV9J7HFu/ZeQoDsK3pUyC5jrixd2+OXXNWXW2VpdrvftI7dC+Sm6rRv7Jjl yxbbVq6HtSBkaWfFY0pAc5CZUx+E2J6cG7QKmFu4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pHuJXfEA6ap for ; Thu, 16 Jan 2020 22:34:56 +0000 (UTC) Date: Thu, 16 Jan 2020 17:34:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1579214096; bh=TClM6neXuu1zBmORqa1cwbNgbw5uFye2Ox5i0QLTZfM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=eszEfHt8hN675E0QOEoUZAIupwnObY9hlONE3FMUfcRNJoPTpO/cSm+c0N6OhbtSo 5shy+RX88cQ1nS71lAHTv1jHcKWR0fd653U2M9nFzFqkg+VE9VDcL8ya/96w5sc+Pn d/oogo+9uKCGdbPimyZQ4lv4hyAgCH28kbH0XMjU= From: Andrew Sullivan To: ietf@ietf.org Subject: ISOC and PIR board analogies (Was Re: Draft IAB conflict of interest policy) Message-ID: <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 22:35:30 -0000 Hi, I'm speaking wearing my ISOC hat, and just for information so that people can evaluate the implicit analogy in Randy's question. On Thu, Jan 16, 2020 at 01:41:14PM -0800, Randy Bush wrote: > would being on the board of one or both pir and isoc, and be the exec > dir if ietf (paid from pir money), be a conflict? The conclusion in the reviews that the various boards made was that it was not a hard conflict under the rules. That is not to say everyone was completely comfortable and I don't know what would have happened had other events not been going on. Note that it is not the case that the IETF's money all comes from PIR. Not all of the ISOC funding comes from PIR (though of course most of it does), and the fact that the PIR money is filtered through an intermediate organization seems to make this strictly speaking ok under the existing conflict rules. > would being on the board of of both isoc and pir be a conflict in this > messy deal? It's hard to see exactly how, given that the PIR board is appointed and serves at the pleasure of the ISOC board, but it would certainly raise eyebrows. Fortunately, we don't have to deal with that because ISOC has not historically appointed a member of the ISOC Board of Trustees to the PIR Board. (I'm a liaison to the PIR Board but I have neither a vote on the PIR Board nor on the ISOC Board.) Best regards, A -- Andrew Sullivan President & CEO, Internet Society sullivan@isoc.org +1 416 731 1261 From nobody Thu Jan 16 15:10:02 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C82120099 for ; Thu, 16 Jan 2020 15:10:00 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YTh61gjSBPA for ; Thu, 16 Jan 2020 15:09:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 875F31200DB for ; Thu, 16 Jan 2020 15:09:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1isEGz-0000hn-Da; Thu, 16 Jan 2020 23:09:57 +0000 Date: Thu, 16 Jan 2020 15:09:56 -0800 Message-ID: From: Randy Bush To: Andrew Sullivan Cc: IETF Rinse Repeat Subject: Re: ISOC and PIR board analogies (Was Re: Draft IAB conflict of interest policy) In-Reply-To: <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 23:10:00 -0000 andrew and jay if i was looking at this from 10,000m, which i partially am, jay being anywhere near the pir decision making is a clear conflict of inbterest. that y'all don't see this says a lot about how the ietf/isoc culture sees conflict of interest; which was my point, not to pick on jay. i believe my friend who was asking will be in touch directly. but we suspect you will still be shoveling kitty litter over it qs fast as possible. qed randy From nobody Thu Jan 16 15:21:29 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC071200DE for ; Thu, 16 Jan 2020 15:21:23 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjkRmk8qDyhQ for ; Thu, 16 Jan 2020 15:21:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A27EB1200D7 for ; Thu, 16 Jan 2020 15:21:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1isES1-0000ty-AS; Thu, 16 Jan 2020 23:21:21 +0000 Date: Thu, 16 Jan 2020 15:21:20 -0800 Message-ID: From: Randy Bush To: Andrew Sullivan Cc: IETF Rinse Repeat Subject: Re: ISOC and PIR board analogies (Was Re: Draft IAB conflict of interest policy) In-Reply-To: <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 23:21:23 -0000 btw, to clarify. i do not have a dog in the pir sale fight. i would have to study up on far to much to have a serious clue. and i gave at the office. it is our lack of perception of conflict of interest which simply amazes me. randy From nobody Thu Jan 16 15:23:26 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E031200DF for ; Thu, 16 Jan 2020 15:23:23 -0800 (PST) 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, HTML_MESSAGE=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 wUVQoFTvFooh; Thu, 16 Jan 2020 15:23:22 -0800 (PST) Received: from macbook-pro.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 49DD51200DE; Thu, 16 Jan 2020 15:23:21 -0800 (PST) From: Jay Daley Message-Id: <3A3B8F8C-548C-40F2-9100-135B87E4B2A1@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D8BBE7F-7878-4C21-B5A3-637C5ED83793" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: ISOC and PIR board analogies (Was Re: Draft IAB conflict of interest policy) Date: Fri, 17 Jan 2020 12:23:19 +1300 In-Reply-To: Cc: Andrew Sullivan , IETF Discussion To: Randy Bush References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 23:23:23 -0000 --Apple-Mail=_9D8BBE7F-7878-4C21-B5A3-637C5ED83793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Randy > On 17/01/2020, at 12:09 PM, Randy Bush wrote: >=20 > andrew and jay >=20 > if i was looking at this from 10,000m, which i partially am, jay being > anywhere near the pir decision making is a clear conflict of = inbterest. > that y'all don't see this says a lot about how the ietf/isoc culture > sees conflict of interest; which was my point, not to pick on jay. If you would be good enough to explain what you see as the conflict of = interest (i.e. what opportunity is there for me to act improperly in = this situation?) then I and possibly others can take steps to mitigate = against that. kind regards Jay >=20 > i believe my friend who was asking will be in touch directly. but we > suspect you will still be shoveling kitty litter over it qs fast as > possible. >=20 > qed >=20 > randy >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org +64 21 678840 --Apple-Mail=_9D8BBE7F-7878-4C21-B5A3-637C5ED83793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Randy

On 17/01/2020, at 12:09 PM, = Randy Bush <randy@psg.com> wrote:

andrew= and jay

if i was looking at this from = 10,000m, which i partially am, jay being
anywhere near the = pir decision making is a clear conflict of inbterest.
that = y'all don't see this says a lot about how the ietf/isoc culture
sees conflict of interest; which was my point, not to pick on = jay.

If you would be good enough to explain what you = see as the conflict of interest (i.e. what opportunity is there for me = to act improperly in this situation?) then I and possibly others can = take steps to mitigate against that.

kind regards
Jay


i believe my friend who was asking will be in = touch directly.  but we
suspect you will still be = shoveling kitty litter over it qs fast as
possible.

qed

randy


-- 
Jay Daley
IETF = Executive Director
jay@ietf.org
+64 21 678840

= --Apple-Mail=_9D8BBE7F-7878-4C21-B5A3-637C5ED83793-- From nobody Thu Jan 16 15:59:14 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64A1200BA; Thu, 16 Jan 2020 15:59:13 -0800 (PST) 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, 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 M37_VzC7oCVh; Thu, 16 Jan 2020 15:59:11 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE773120059; Thu, 16 Jan 2020 15:59:10 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1isF2Z-000KdK-Qr; Thu, 16 Jan 2020 18:59:07 -0500 Date: Thu, 16 Jan 2020 18:59:02 -0500 From: John C Klensin To: Brian E Carpenter cc: IAB Chair , iab@iab.org, ietf@ietf.org, architecture-discuss@ietf.org Subject: Re: [arch-d] Draft IAB conflict of interest policy Message-ID: In-Reply-To: References: <4e888f0a-a1e8-df72-cbbc-9a2e2f0d0d05@iab.org> <20200115221637.GA32014@faui48f.informatik.uni-erlangen.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 23:59:14 -0000 --On Thursday, January 16, 2020 16:10 +1300 Brian E Carpenter wrote: >> "Can the work of the IAB that you contribute to impact >> future financial results of your employer / sponsor ?" > > I think that's easy. Read the arguments that you, as a > candidate, made to your employer to justify you spending time > and travel budget on IAB membership. If those arguments do not > explain how IAB membership will positively affect your > employer, answer "No". But in that case, I rather doubt that > your employer would have allowed you to accept the nomination. > Mine certainly wouldn't have. > > In other words, the only credible answer to this question is > "Yes". >> If one would answer YES, does that constitute a COI ? > > Poetntially, yes. Even a self-employed engineer has this > potential COI. It's something I lived with as a WG chair, IAB > member, IESG member, ISOC Board member, and for that matter in > completely other non-profit roles at various times. Brian, I think you are right, but I also have to agree with Randy. Someone working for an organization that is willing to have them participate in the IETF because of a commitment to the general health of the Internet and that is willing to accept their acting against the best short-term interests of the company's products is a rare situation, but one that several of us have been in at one time or another. In some ways, that is the ideal, at least as long as we don't increase costs of participation enough that only the largest organizations can play. But, even then, if the individual is nearly as opportunistic as some of the comments in this thread imply that a policy needs to look out for, then the individual might still reason that, if the company's products do well this year, then there will be bigger bonuses next year and therefore be biased toward those products. I stopped commenting several days ago because I tried to write an explanation of why someone with projects or clients that could not be made public might still be an appropriate participant in the IAB. I realized that the explanation is too complicated if the policies have to be simple. I also realized that, if I were working for a company whose primary business was the making of soap or breakfast cereal, it might be hard to identify conflicts of interest without an in-depth job and departmental description and companies often consider that sort of information (and organization charts beyond some level of detail) to be sensitive ... a situation not very different from a consulting contract that barred either party from disclosing the relationship without mutual agreement (and that might have been insisted on by the consultant rather than the company). FWIW, I have never had any trouble getting permission to disclose arrangements that are, formally, non-public or confidential to Nomcoms: but the rules and the culture there have seemed offer more than adequate protection of the information. Where this all leads me is back to a point that others have made in different ways. For the technical work of the IAB, we want and need as much diversity of opinions, technical expertise, and perspective as we can get. That is, as long as the people involved really are experts and their expertise includes knowing what they don't know. IAB members might be biased as much or more because of personal technical preferences than because of financial interests (however described or measured). If we decide the former are ok and the latter aren't, we are not only going to find ourselves splitting hairs and exploring rat holes, but do each other --and the IAB's historical core technical mission-- a disservice. As an extreme, and I hope silly, example, if the Nomcom, in its wisdom, decided to appoint someone to the IAB who was the main advocate of a protocol or device that claimed to make physical limits on IP based on the speed or protons or electrons in a vacuum irrelevant, in technical discussions, I'd want the IAB to hear and evaluate that perspective and to do so independent of whether the individual stood to make zillions of dollars if the protocol proved successful. I'd also want the IAB to hear from the members best equipped to explain why, for Internet purposes at least, protocols or devices that require trans-light speeds to work properly are not going anywhere, independent of what they might stand to gain from upholding those positions. If either or both of those types of positions should not be represented in IAB discussions, then we are a problem with the way nomcoms work or with that absence of an effective recall mechanism, neither of which will be helped by a complex and hair-splitting COI policy. If we need very different policies for the IAB's technical and architectural work than for its more administrative or representational functions, it is likely that there are different skill sets for those functions as well. And maybe someone who has real or imagined conflicts should be isolated from the latter even while being a valuable asset for the technical and architectural work. If that is the case, maybe it is time to reconsider the IAB and whether some of its functions belong somewhere else. The perceived need for a formalized COI policy may be another argument that it is time to rethink the IAB, but it is not a solution. I think the bottom line is that this policy, at least as currently written, is unlikely to be helpful in difficult cases and may easily be damaging. Nomcoms need to select IAB members who hold openness and transparency in sufficient respect, and who have a strong enough of personal ethics, that issues that might affect their judgment on technical issues will be disclosed to other IAB members and, if appropriate, the community and who are willing to keep in confidence anything that is told them in confidence. If Nomcoms can't be counted on to do that, probably nothing else matters because people with less integrity (a problem I don't think we have seen) can always lie about their conflict. If Nomcoms cannot do that reliably with the tools they have available, then we have a different kind of problem, but, again, complex COI policy statements are not going to fix it. And, again, if we have given the IAB responsibilities --financial, administrative, or otherwise and direct or indirect-- that do require this sort of statement, let's work at separating those responsibilities as incompatible with what I still believe is the IAB's primary role, rather than things it ended up with post-POISED because we didn't have a better plan and other non-architectural tasks that have accumulated since. regards, john From nobody Thu Jan 16 20:26:51 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61451200CD; Thu, 16 Jan 2020 20:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEDCJQui4_pC; Thu, 16 Jan 2020 20:26:47 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39C0120099; Thu, 16 Jan 2020 20:26:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1isJDZ-0000oC-Jx; Thu, 16 Jan 2020 23:26:45 -0500 Date: Thu, 16 Jan 2020 23:26:39 -0500 From: John C Klensin To: Jay Daley , Randy Bush cc: IETF Discussion , Andrew Sullivan Subject: Re: ISOC and PIR board analogies (Was Re: Draft IAB conflict of interest policy) Message-ID: <7BAB021A111B785D303816BC@PSB> In-Reply-To: <3A3B8F8C-548C-40F2-9100-135B87E4B2A1@ietf.org> References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> <3A3B8F8C-548C-40F2-9100-135B87E4B2A1@ietf.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 04:26:50 -0000 --On Friday, January 17, 2020 12:23 +1300 Jay Daley wrote: > Randy > >> On 17/01/2020, at 12:09 PM, Randy Bush wrote: >> >> andrew and jay >> >> if i was looking at this from 10,000m, which i partially am, >> jay being anywhere near the pir decision making is a clear >> conflict of inbterest. that y'all don't see this says a lot >> about how the ietf/isoc culture sees conflict of interest; >> which was my point, not to pick on jay. > > If you would be good enough to explain what you see as the > conflict of interest (i.e. what opportunity is there for me to > act improperly in this situation?) then I and possibly others > can take steps to mitigate against that. Jay, Since things that are obvious to Randy are sometimes less obvious to the rest of us (but with the understanding that, in my experience, when he thinks something is obvious, he is usually right), let me tell you where I would see a conflict: Suppose you are IETF Exec Dir and saw your role as protecting the IETF's revenue stream (I think that is a given with the IETF LLC and your job description, but reasonably people might disagree). Suppose you are also aware of the discussions at ICANN and associated ISOC presentations that led to ORG being transferred to PIR, an entity ISOC set up to receive it and about which some explicit (even if not legally binding) commitments were made about support for the IETF. Suppose that you also believe, by virtue of being an observant sort of human being, that, even with the IETF LLC arrangements and ISOC's strong and continuing commitment to supporting the IETF, that ISOC's ability to send money in the direction of the IETF depends on ISOC having the money. Nor suppose you looked, as an observant member of the community, at the PIR-ISOC-IETF cash flow and came to the same conclusion that many of us have, i.e., that there are real possibilities that the domain name marketing business is a bubble and that, sooner or later, the bottom will drop out of that market and that, while ORG will continue to be a valuable asset, the income flow from it might, at best, become a little unstable, especially relative to rosy predictions about continued growth. >From an ISOC and IETF standpoint and strictly looking at finances, that would make spinning off PIR in a way that turned the expectation of ongoing operating income for ISOC into either a single large capital payment or something else that was safe and not coupled to PIR's annual income into a huge win. And, as IETF Exec Dir, you would have some obligation to support such a move without regard to questions like "is this good for PIR?" or "is it good for registrants and/or users of names registered in ORG or that might be registered in ORG in the future?". However, if you were a PIR Director (or to a certain extent given whatever those old commitments to ICANN and its community are worth today, an ISOC Director), you would also, perhaps primarily, have obligations to consider what is good for PIR, for ORG, and for the ORG registrant and user communities. If any of the scary scenarios that have been circulating about the possible long-term consequences of turning PIR over to a for-profit entity that many in the community (and least seemingly-many loud ones) are even plausible, then there would be a conflict of interests and loyalties between the IETF LLC and ISOC or PIR Board responsibilities. There would even be an appearance of such a conflict if you had been a PIR Executive when the Ethos Capital deal germinated and you then took the IETF LLC role. Those conflicts, or appearance of conflicts, would exist whether there were any potential financial gain to you from either outcome. It has far more to do with questions that are usually addressed as "whose side are you on?" than about following the real or potential money, but they would be conflicts nonetheless. DISCLAIMER: None of the above depends on any internal or confidential information, in part because I don't have any. It is based purely on some ability to detect and read the writing on various walls, the ability to do certain kinds of arithmetic, and some paranoia-enhanced ability to look at particular situations and guess what might go wrong. best, john From nobody Thu Jan 16 21:20:00 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E276A1200CD for ; Thu, 16 Jan 2020 21:19:58 -0800 (PST) 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 oi9VGL6Etcye for ; Thu, 16 Jan 2020 21:19:57 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 3CEDA120099 for ; Thu, 16 Jan 2020 21:19:57 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id t2so20304599ilq.9 for ; Thu, 16 Jan 2020 21:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wH9LzPAdDt/K5MPJkQLjVesufyetMO9CgtdCWNy0Fjw=; b=jMHjQsfY9CogmT4P8ktCt+rgnq2m2wCHL/rqgWEzxoVjxl6j25UUZcOMsPXsIDXjw6 HYa3F7OprAUIppLIZ5a/NQZo+DIt2Z6Hp6qVvy7oUyzMlN87h9dEL9LWiyqEDCx0JB1+ G7NwW0qmS0wflFqk5lzAR8U53XSIeXzVRcYJ6wANqgM1saa6o1jWoaCMcmuuOL/ZdS0+ NNuWPsG81zutF63mYoZTBUijxhGoehB4O9p7c4QsW5ijAvFlRA720V9QeHn99BAcDFBS 9++QgquFyjghLY1dUTJcep/NY5UZ3VtZ2Wm8i6egNpGb2BNse2tHD/RjynBtr6L1+Pxh 4+kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wH9LzPAdDt/K5MPJkQLjVesufyetMO9CgtdCWNy0Fjw=; b=L3J83a+Fk2y4YGJoI0p5YAAJNhHm2rGKUSEfea1Q9/b4rb17XE/P0hyFPN+f3Ywonj J63oxY7MG/sWlNHsbIfvShzxZWuC9NBaQzu6qKxV8r4MASub9OoI936ULEjgQLIme9/i ohwxc9xCKn3H6QPEkObK+qEhc5jJUEKhWIf9Qu3uXFVR9w2EUk30tRZK1vcOnQ0SoelJ mn2oWGYFrHGbIXK6EBDaIF3dK48RAKS/u2s/KXkXzI40X8ZUbCjWlmWBLyMk6ZDmZ4z7 /FBceoacmd1BNTh5BGf+1RZ7VF5Z3Y9rTqe97AxUIgfkt4YfEzm4AAxarwpHDIVzjD6v sF1Q== X-Gm-Message-State: APjAAAXJkkxtfF5EsszpHDXHADPUgdTRvicb9UmTKV07Cylar1d17/Uv 9xiN5N9x4Tmer2JAQwB8AUiV5FOD0cmWqlRObunA6XFkhss= X-Google-Smtp-Source: APXvYqxRBqMAPQdgruqOvKaazPh6Te5gkXcebsdbsfH9ktzbOspMbOqYjgMd9/ydNMYKhdWKoZGfkHRRNb3Lnh5GXEc= X-Received: by 2002:a92:498d:: with SMTP id k13mr1621693ilg.254.1579238396137; Thu, 16 Jan 2020 21:19:56 -0800 (PST) MIME-Version: 1.0 From: Rob Sayre Date: Thu, 16 Jan 2020 21:19:45 -0800 Message-ID: Subject: .org sale - bidding process To: IETF discussion list , www-archive@w3.org, mgodwin@rstreet.org Content-Type: multipart/alternative; boundary="0000000000009e1657059c4f178e" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 05:19:59 -0000 --0000000000009e1657059c4f178e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, ISOC Board of Trustees member Mike Godwin wrote on twitter: "The biggest question about how to #SaveDotOrg is this: what is the path forward that doesn=E2=80=99t slowly (or quickly) starve .ORG to death?" [0] It's fair for the board to consider the sale of .org. What was the bidding process? I've looked, and haven't seen many details. thanks, Rob [0] https://twitter.com/sfmnemonic/status/1217976049134374912 --0000000000009e1657059c4f178e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

ISOC Board of Trustees member Mike = Godwin wrote on twitter:

"The biggest que= stion about how to #SaveDotOrg is this: what is the path forward that doesn= =E2=80=99t slowly (or quickly) starve .ORG to death?" [0]
It's fair for the board to consider the sale of .org.

What was the bidding process? I've looked, and hav= en't seen many details.

thanks,
Rob= =C2=A0

--0000000000009e1657059c4f178e-- From nobody Thu Jan 16 21:53:14 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20090120119 for ; Thu, 16 Jan 2020 21:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 3Sg2Dv-n-Q_w for ; Thu, 16 Jan 2020 21:53:10 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 00C5512012C for ; Thu, 16 Jan 2020 21:53:09 -0800 (PST) Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00H5lHEg105695 for ; Fri, 17 Jan 2020 00:53:08 -0500 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xk0qtruwy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 17 Jan 2020 00:53:08 -0500 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 00H5qMH1013877 for ; Fri, 17 Jan 2020 05:53:07 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma05wdc.us.ibm.com with ESMTP id 2xhjdvf479-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 17 Jan 2020 05:53:07 +0000 Received: from b03ledav003.gho.boulder.ibm.com (b03ledav003.gho.boulder.ibm.com [9.17.130.234]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 00H5r6eR49873184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 17 Jan 2020 05:53:06 GMT Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 61DF96A047 for ; Fri, 17 Jan 2020 05:53:06 +0000 (GMT) Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 435706A051 for ; Fri, 17 Jan 2020 05:53:06 +0000 (GMT) Received: from rotala.raleigh.ibm.com (unknown [9.27.200.19]) by b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTPS for ; Fri, 17 Jan 2020 05:53:06 +0000 (GMT) Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.15.2/8.15.2) with ESMTP id 00H5r4PH009543 for ; Fri, 17 Jan 2020 00:53:04 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.15.2/8.15.2/Submit) id 00H5r3Iq009479 for ietf@ietf.org; Fri, 17 Jan 2020 00:53:03 -0500 From: narten@us.ibm.com Message-Id: <202001170553.00H5r3Iq009479@rotala.raleigh.ibm.com> Date: Fri, 17 Jan 2020 00:53:03 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-16_06:2020-01-16, 2020-01-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 phishscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 spamscore=0 mlxscore=0 suspectscore=13 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001170045 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 05:53:13 -0000 Total of 43 messages in the last 7 days. script run at: Fri 17 Jan 2020 12:53:02 AM EST Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.63% | 5 | 6.62% | 39892 | randy@psg.com 4.65% | 2 | 10.12% | 61050 | elear@cisco.com 6.98% | 3 | 6.62% | 39901 | brian.e.carpenter@gmail.com 4.65% | 2 | 7.66% | 46201 | mstjohns@comcast.net 6.98% | 3 | 4.99% | 30111 | tte@cs.fau.de 6.98% | 3 | 4.29% | 25881 | sm+ietf@elandsys.com 4.65% | 2 | 5.23% | 31554 | glenn.deen@nbcuni.com 4.65% | 2 | 4.38% | 26418 | john-ietf@jck.com 4.65% | 2 | 4.22% | 25458 | jay@ietf.org 4.65% | 2 | 3.75% | 22592 | rsalz@akamai.com 4.65% | 2 | 3.06% | 18440 | resnick@episteme.net 2.33% | 1 | 5.12% | 30897 | roni.even@huawei.com 2.33% | 1 | 3.53% | 21267 | robert@raszuk.net 2.33% | 1 | 3.32% | 19989 | gsenopu@gmail.com 2.33% | 1 | 3.14% | 18953 | hayabusagsm@gmail.com 2.33% | 1 | 3.06% | 18441 | jmh@joelhalpern.com 2.33% | 1 | 2.76% | 16656 | huitema@huitema.net 2.33% | 1 | 2.75% | 16600 | stewart.bryant@gmail.com 2.33% | 1 | 2.34% | 14122 | bernard.aboba@gmail.com 2.33% | 1 | 2.29% | 13808 | chair@ietf.org 2.33% | 1 | 2.28% | 13721 | kathleen.moriarty.ietf@gmail.com 2.33% | 1 | 2.00% | 12032 | narten@us.ibm.com 2.33% | 1 | 1.88% | 11351 | sayrer@gmail.com 2.33% | 1 | 1.74% | 10499 | fluffy@iii.ca 2.33% | 1 | 1.47% | 8883 | jared@puck.nether.net 2.33% | 1 | 1.37% | 8260 | nomcom-chair-2019@ietf.org --------+------+--------+----------+------------------------ 100.00% | 43 |100.00% | 602977 | Total From nobody Fri Jan 17 09:45:44 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FB8120074 for ; Fri, 17 Jan 2020 09:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=AQkXXeyM; dkim=pass (1024-bit key) header.d=yitter.info header.b=Gs1yRdH1 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 6wUZFa9el4N8 for ; Fri, 17 Jan 2020 09:45:36 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10C8120043 for ; Fri, 17 Jan 2020 09:45:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 04D5CBCBD4; Fri, 17 Jan 2020 17:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1579283135; bh=usV93/BHYP7Fp/HMsyaK4kmgH0fvWSbJOrlLQvPS97w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AQkXXeyMShSbyXtZVcsnvXgOJJkufrKQvpAH5Jk7w1dCJnlVXJxb+jEjJ/XuBwBcl mCAERKC5xrAZ4UUBlAciCVwesjZRIahKV24+z8Al6B7JRSnMihb8zkc37A56lO2dqK 7sqE8kOpDgk3UkWqfkq3Qvg0tjo+wWdbIeYBctYU= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewRGFbbciXPZ; Fri, 17 Jan 2020 17:45:33 +0000 (UTC) Date: Fri, 17 Jan 2020 12:45:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1579283133; bh=usV93/BHYP7Fp/HMsyaK4kmgH0fvWSbJOrlLQvPS97w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gs1yRdH1Bv0pwoT6/PYCaPuqls9jKvg7A2RP3sRYp2Kp4fxli5wETGW8SrOj85O5f gpWZbpUBrR31gm4LmWASbFMSSCh6K9Yt85GFtOyVJhvheO4sPzJGmkj0eVR6b4Z4SS 0goa8ie6ngiTkB1Za6bC60Js4zZirOKkvDjAQDYI= From: Andrew Sullivan To: Rob Sayre Cc: IETF discussion list , www-archive@w3.org, mgodwin@rstreet.org Subject: Re: .org sale - bidding process Message-ID: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 17:45:41 -0000 Hi, (ISOC hat on.) I've said before that I don't think the IETF list is a good place to discuss the PIR transaction, and unless the Sergeants-at-Arms disagree with me I'm going to maintain that position. (I see even less reason for this to be on a W3C list.) I'll respond to this question off-list. Best regards, A On Thu, Jan 16, 2020 at 09:19:45PM -0800, Rob Sayre wrote: > Hi, > > ISOC Board of Trustees member Mike Godwin wrote on twitter: > > "The biggest question about how to #SaveDotOrg is this: what is the path > forward that doesn’t slowly (or quickly) starve .ORG to death?" [0] > > It's fair for the board to consider the sale of .org. > > What was the bidding process? I've looked, and haven't seen many details. > > thanks, > Rob > > [0] https://twitter.com/sfmnemonic/status/1217976049134374912 -- Andrew Sullivan President & CEO, Internet Society sullivan@isoc.org +1 416 731 1261 From nobody Fri Jan 17 10:00:07 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115BF120074; Fri, 17 Jan 2020 10:00:06 -0800 (PST) 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, HTML_MESSAGE=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 a-cn7lERD2WP; Fri, 17 Jan 2020 10:00:04 -0800 (PST) Received: from thornhill.mtv.corp.google.com (unknown [IPv6:2620:0:1000:1111:c03e:1e8:50bf:2fe4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 80198120043; Fri, 17 Jan 2020 10:00:04 -0800 (PST) To: ietf@ietf.org, rfc-interest@rfc-editor.org, iab@iab.org From: IAB Chair Subject: Call for nominations, RFC Editor model evolution program chairs Message-ID: Date: Fri, 17 Jan 2020 10:00:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C85A409FC8C67F695D524DB9" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:00:06 -0000 This is a multi-part message in MIME format. --------------C85A409FC8C67F695D524DB9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Colleagues, In response to the recent series of public meetings on the evolution of the RSE role, the IAB recently circulated a proposed charter for a program on evolving the RFC Editor model .  As that charter notes, the intent is for this program to be modeled on an IETF working group, using its mailing list to develop and validate consensus among the participants. While there will be an IAB program lead acting as a liaison to the IAB for logistical matters, the IAB is seeking chairs from outside the IAB.  These chairs will set the detailed agenda, manage the program, and call consensus among the participants.  The IAB currently expects to appoint two chairs, but may choose three if appropriate. If you are interested in serving in this role, please send a short email message to iab-chair@iab.org and execd@iab.org with your motivation and information concerning your familiarity with IETF working groups or similar processes.  The deadline for volunteering is Friday, 2020-02-07.  The IAB will then solicit public comments on the candidates. The IAB intends to make a decision on this appointment in time to have the program meet at IETF 107 with these chairs in place. regards, Ted Hardie For the IAB --------------C85A409FC8C67F695D524DB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear Colleagues,

In response to the recent series of public meetings on the evolution of the RSE role, the IAB recently circulated a proposed charter for a program on evolving the RFC Editor model .  As that charter notes, the intent is for this program to be modeled on an IETF working group, using its mailing list to develop and validate consensus among the participants. While there will be an IAB program lead acting as a liaison to the IAB for logistical matters, the IAB is seeking chairs from outside the IAB.  These chairs will set the detailed agenda, manage the program, and call consensus among the participants.  The IAB currently expects to appoint two chairs, but may choose three if appropriate.

If you are interested in serving in this role, please send a short email message to iab-chair@iab.org and execd@iab.org with your motivation and information concerning your familiarity with IETF working groups or similar processes.  The deadline for volunteering is Friday, 2020-02-07.  The IAB will then solicit public comments on the candidates. 

The IAB intends to make a decision on this appointment in time to have the program meet at IETF 107 with these chairs in place.

regards,
Ted Hardie
For the IAB
--------------C85A409FC8C67F695D524DB9-- From nobody Fri Jan 17 10:52:02 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723961200A4 for ; Fri, 17 Jan 2020 10:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZo09dVmGiH5 for ; Fri, 17 Jan 2020 10:51:54 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9274C1200B5 for ; Fri, 17 Jan 2020 10:51:54 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 0086042EC3; Fri, 17 Jan 2020 13:51:54 -0500 (EST) Date: Fri, 17 Jan 2020 13:51:53 -0500 From: Viktor Dukhovni To: ietf@ietf.org Subject: Re: .org sale - bidding process Message-ID: <20200117185153.GV73491@straasha.imrryr.org> Reply-To: ietf@ietf.org References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:52:01 -0000 On Fri, Jan 17, 2020 at 12:45:31PM -0500, Andrew Sullivan wrote: > (ISOC hat on.) > > I've said before that I don't think the IETF list is a good place to > discuss the PIR transaction, and unless the Sergeants-at-Arms disagree > with me I'm going to maintain that position. (I see even less reason > for this to be on a W3C list.) I'll respond to this question > off-list. Don't know about the SAs, but when I joined ISOC, so I could subscribe to the appropriate discussion lists, I could not find anything on the ISOC site that made it possible to find or join such a list. This topic being of broad interest to the Internet community, it does not seem too far fetched to touch on it here. -- Viktor. From nobody Fri Jan 17 11:08:14 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA02A1200B5 for ; Fri, 17 Jan 2020 11:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=hzQgbT5V; dkim=pass (2048-bit key) header.d=comcast.com header.b=oq9+f3GY; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=pXic/N8v 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 qjiIRaljb1YU for ; Fri, 17 Jan 2020 11:08:07 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 E13051200A4 for ; Fri, 17 Jan 2020 11:08:06 -0800 (PST) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00HJ6OHQ004079 for ; Fri, 17 Jan 2020 14:08:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=YRK5k771V+N+gtTRNjzgEM60DohVSvw4ubXE6vSlaIg=; b=hzQgbT5VRpk3C8dk9kLQSlkRP17EVID6ixUkMHi1hk8gca97ChQPEU5a1exXP5bxItuq IoJfuUVPufUr90iiXCbtNYdxxtcnCJ1htu2kPueM5ZUWCosauHe3tccl2uLNP7eWHlNZ UyflUqfp1U+xE5vxzkwzEE0XkMqRaib5/15Gxsh2NSa32MOqwQITI/HPPul1iPLoefsk F05YbMBvlRQG10TgpockP9ERffohOVgrjBeDLxOVqPsKlTapVByPDnM8j/QQDQTQN7Cu IU7okD1pHqz58AxEQO4yBcAqPzeav9HQBqPRFHi/n3hHqgmiw4ID/S8xuXTdk+Q9o/lt EA== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2xk0sw5w9s-128 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 17 Jan 2020 14:08:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1579288086; x=2443201686; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YRK5k771V+N+gtTRNjzgEM60DohVSvw4ubXE6vSlaIg=; b=oq9+f3GY1Rf4X6YQ94gl72RzcVj7wMEuxGNbQrd8WfIpcqxc80y5uO7b32pb2Ixi JaoekXU8rKW6tQklw9qf9Xve9ndlDF5FvNYyGUGMHmepTyhnf3ujp1KHNjwftdmQ NwCVxuPO40sn10qvH98ZQFAz3Ps6VunY9aYIuXhBgTLCISsfK2NLUpDuGHJiZOaA pd5aloj90Hk17uG0JCVklOtmWMRqFcO7HXVSP46Ucqs+Ym0apYicVxD2Q72Om0/J R5NZF2Q0TVOjcIDdeuQmbJYMeaXLnAwxZBT/OTr2wc4B1uEGJh3ORj+sxzqyKTVv jI6lEjrWEl7tbHEPjq6TpQ==; X-AuditID: 60729ed4-24fff7000000bc72-eb-5e2206166b60 Received: from copdcex55.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 73.B6.48242.616022E5; Fri, 17 Jan 2020 12:08:06 -0700 (MST) Received: from copdcexc45.cable.comcast.com (147.191.125.144) by copdcex55.cable.comcast.com (147.191.125.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 14:08:05 -0500 Received: from COPDCEX09.cable.comcast.com (147.191.124.140) by copdcexc45.cable.comcast.com (147.191.125.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 17 Jan 2020 12:08:03 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX09.cable.comcast.com (147.191.124.140) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 17 Jan 2020 12:08:04 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.176) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 14:07:54 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2276.namprd11.prod.outlook.com (10.174.239.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 17 Jan 2020 19:07:53 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.018; Fri, 17 Jan 2020 19:07:53 +0000 From: "Livingood, Jason" To: Randy Bush , Andrew Sullivan , "IETF Rinse Repeat" Subject: Re: ISOC and PIR board analogies (Was Re: Draft IAB conflict of interest policy) Thread-Topic: ISOC and PIR board analogies (Was Re: Draft IAB conflict of interest policy) Thread-Index: AQHVzL1fsk4kyAtQN0q8NnxxiGf98qft6qcAgAD64oA= Date: Fri, 17 Jan 2020 19:07:53 +0000 Message-ID: References: <89f2653c-4333-665b-51b3-c4a860a78288@comcast.net> <3AFAE1F0-B7DA-4D00-8FB5-39D9ECE41596@puck.nether.net> <20200116223454.yqfjrahykxcnbcfg@mx4.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2601:41:200:4600:12a:4c23:3303:4543] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4221f7e7-0435-4491-1457-08d79b808e08 x-ms-traffictypediagnostic: BN6PR1101MB2276: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(189003)(199004)(5660300002)(966005)(2906002)(2616005)(86362001)(66476007)(66446008)(76116006)(66946007)(64756008)(478600001)(186003)(66556008)(91956017)(81156014)(316002)(6486002)(6512007)(33656002)(81166006)(8676002)(110136005)(71200400001)(8936002)(53546011)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2276; H:BN6PR1101MB2195.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mRap1Hxittyxuq0D09oGYbBgOcVsn0nw/hDNbkPiQL1Kvt0DuJRsRfUkYSFmxwEogC9dPB7+Nmd8XubKInmwyCMImWT0ZW/Doc+QgufU3QV/szFCwPH9pIr32YAT6J94pgugH7UMXSnU/rm2b1itS2EaL61s5ZVl3vv9I3iFhhZUR+D7VQUNDicojX6n7E04iggm53xxAf4//eJNme3h33V6KRCS2JD1Tl51h9SuOkYqrj5gO8lVtsZK7onWOuGNSSOU8Aw9doNzfldMY8k3uIZCe+R1vCh1rg0ky/sWEveZo2ytKZCuHAYXdS4sMsRgGnMKZfCONDwol7WI3ExAm8bM4/vK/ANQSrRZQDCH3hxtV0DsG2qvQGtDbLrQTN7FE8o4ZpSPVHFHGbP2sK8cH/uafLGx0Z8ZrgsD+pLFKuyxeYbBm5KGyy9g7+ro5lkJac9QQwMkx1u50Moijh+HNt1tDQTmos8Ei8g2GJuJEbo= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FzUfpoeNGxM8CqcfNeElZ6G3DXT4TrncKzyPSkQPFqntZm8n+m73rX0qxKHaHBArlPBMnYbeb9d3y/1uc18CXWn3Eqcv26RIW05UshTOxEpVbpquTmfKe42LNXCpNd/e2h71rf70S+jDn58cHHHCVDiQ0PPatjf1s+1SsXIzgm3QRmgGU0ys0mhfgaE/dbkd7EXWFV+AsMhDHXzRJKHszS+b9MKdQ3wO6HoF/91gzx+r6ohqgrS2K2wkSkcgJr5rFVUMkugHBksm5CEUuIjI/qzH5M1Nvh/+ca8DZ9aQjSQQ2K/XK+78yfyOWN85Ix30KFxFikCiUCaY/M/YQp9f2w== 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=rSQ0gqRpQEHOo4WNiQ1iWX66eafhfV4u5nDPbuZmdH4=; b=QYb24WF1Bdrv1M6fGusbp+aw8T+m+kbUq1G73fB/HV0G80Vwns+DsoKaJCoMRDkACRnVFvcyYuj89/Pkf1NIOx3G7DdkxColoRXkZI+SM0JdWm0nL9oEfpaPPIdfIyFJXMj90y45vIYlsT6a18Q5FpJ+V4g8wyATrxC2CnaFU9OOmIiAZ07CW5IXFrfznkiRc/VNAyRUJljcCY/HKdLsl8ivllr1HjlL4Kg3OTEeNJl5OBZHV2wSS/9YSjWU0HL8+GCfvayoUrxojl5gLq+ac6RfJu1anrijMsd49Lt+lHWTknTSp0l9D0wQLb1Vp8fLv3cgvd6Di1VjYCLzy4fapg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rSQ0gqRpQEHOo4WNiQ1iWX66eafhfV4u5nDPbuZmdH4=; b=pXic/N8v7+kjtCC4zXXTqlTnxTqNC5bdWk7TDGjcuz/B2VgeVSp2xQOBcd1Zp5+PaJKqigKYUrfAI5NXmakzC60rpuEdNQnC6SQosVMkclb+vpM6uGTwSpfku8QYVquYYNTAXGgoPs+YeOJdZPcqbg8YNrAiqJ2CwSw/e6VIWvQ= x-ms-exchange-crosstenant-network-message-id: 4221f7e7-0435-4491-1457-08d79b808e08 x-ms-exchange-crosstenant-originalarrivaltime: 17 Jan 2020 19:07:53.6108 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: y0XBiAiVB4zTeR4OVveAbfuv8b7Vcd6CrhIPtLFkf6ikqbVhU8j8VuS8oJdjQgNurnCqh4pBdHRiVq5cXkLmHBH9TvE8OKz9bS/Z/7giKTI= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2276 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: cable.comcast.com X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmk+LIzCtJLcpLzFFi42JJKJozWVeMTSnOoHcen8WzjfNZLJ61vmSy uP5qB6sDs8eSJT+ZPF5Na2T1mDpzNmMAc1QDo01JRlFqYolLalpqXnGqHZcCBrBJSk3LL0p1 TSzKqQxKzUlNxK4MpDIlNSezLLVIH6sx+ljNSehiyjj/5iBTwRGpiua/E1kbGN9IdjFyckgI mEisbL3B1MXIxSEkcJhJYuPOBTAOo8SUlm1sEE4zk8Sec73MEM4dRolVH54zQjgnGSX6b/Sy QDjTmCQeXn0ENeARo8Tci8vZQNawCZhJ3F14hRnEFhHIkmg/OJUdxBYWiJaYPeU/C0Q8RmLO 5r1MELaVxMTn7awgNouAqsTsRysZQWxeAReJwxfmgtULCbxmlPjwIwvE5hTQkjhz4gVYDaOA mMT3U2vA5jALiEvcejKfCeJVAYkle84zQ9iiEi8f/wObLyqgL/Hs5g4WiN4UicVdi6DqzSVm /m6AsmUlLs3vZoSwfSU+tm9ihbB1JJbNOAY1M1/iRstZFghbXaLl4zyoGhmJPUdWQtV0sUi0 7lfoYuQAuj9L4u1VuwmMZrOQXDoLKMMsoCmxfpc+RNhDYtnB/4wQtqLElO6H7LPAASEocXLm E5YFjKyrGPkszfQMDU30DE0t9IwMjTYxgpPovCs7GC9P9zjEKMDBqMTDm/dWMU6INbGsuDL3 EKMEB7OSCO/dXqAQb0piZVVqUX58UWlOavEhRmkOFiVxXjbbX7FCAumJJanZqakFqUUwWSYO TqkGxtkmrJOyJHxLP+3nepq9/nz+vo8SLPwbI66mfQi5Pc83/K9wQ9Gq6Akain+ymu+dZle4 8EnvtN2WNZbtqhLH49LTlh6TW+a559pf6eW6nqLbLruVMsayC+7rYjt3cdb2pYcPGGy/s3Vi 5GNRtc03psnuSuPL3rN9qtvuZw/m/Ol6FiJd8nW2+wUlluKMREMt5qLiRADbx8Y+ngMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_05:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 19:08:12 -0000 T24gMS8xNi8yMCwgNjoxMCBQTSwgImlldGYgb24gYmVoYWxmIG9mIFJhbmR5IEJ1c2giIDxpZXRm LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KDQo+ ICAgIGlmIGkgd2FzIGxvb2tpbmcgYXQgdGhpcyBmcm9tIDEwLDAwMG0sIHdoaWNoIGkgcGFydGlh bGx5IGFtLCBqYXkgYmVpbmcNCiAgICBhbnl3aGVyZSBuZWFyIHRoZSBwaXIgZGVjaXNpb24gbWFr aW5nIGlzIGEgY2xlYXIgY29uZmxpY3Qgb2YgaW5idGVyZXN0Lg0KICAgIHRoYXQgeSdhbGwgZG9u J3Qgc2VlIHRoaXMgc2F5cyBhIGxvdCBhYm91dCBob3cgdGhlIGlldGYvaXNvYyBjdWx0dXJlDQog ICAgc2VlcyBjb25mbGljdCBvZiBpbnRlcmVzdDsgd2hpY2ggd2FzIG15IHBvaW50LCBub3QgdG8g cGljayBvbiBqYXkuDQoNCkhpIFJhbmR5IC0gQXMgbm90ZWQgaW4gYSByZXBseSBpbiBhbiBvZmYt bGlzdCB0aHJlYWQgdG8geW91LCBidXQgc2luY2UgeW91IGFza2VkIGhlcmUgYXMgd2VsbDoNCg0K MSAtIFdlIGVzdGFibGlzaGVkIHBvbGljaWVzIGZvciB0aGUgSUVURiBMTEMsIGluY2x1ZGluZyBD b25mbGljdCBvZiBJbnRlcmVzdCAoQ09JKSwgb24gNyBOb3ZlbWJlciAyMDE5IGFmdGVyIGEgbG9u ZyBjb25zdWx0YXRpb24gcHJvY2VzcyB3aXRoIHRoZSBJRVRGIGNvbW11bml0eS4gU2VlOg0KLSBo dHRwczovL3d3dy5pZXRmLm9yZy9hYm91dC9hZG1pbmlzdHJhdGlvbi9wb2xpY2llcy1wcm9jZWR1 cmVzL2NvbmZsaWN0LWludGVyZXN0Lw0KLSBodHRwczovL3d3dy5pZXRmLm9yZy9ibG9nL2lldGYt bGxjLXBvbGljaWVzLXB1Ymxpc2hlZC8NCi0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9pZXRmLWFubm91bmNlLzZpbHU2TnEtU1E1TnJ3cTVKMVNmZjF1eFM1TQ0KLSBodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lldGYtYW5ub3VuY2UvUldudkpHdWNu NG54NlZNM05YMjhmcE8zMS1rDQoNCjIgLSBEdXJpbmcgdGhlIGhpcmluZyBwcm9jZXNzIG9mIHRo ZSBJRVRGIEV4ZWN1dGl2ZSBEaXJlY3RvciwgdGhlIElFVEYgTExDIEJvYXJkIGFza2VkIG91ciBs ZWdhbCBjb3Vuc2VsIHRvIHBlcmZvcm0gYSBkZXRhaWxlZCBhc3Nlc3NtZW50IG9mIGFueSBwb3Rl bnRpYWwgZm9yIGNvbmZsaWN0cyBvZiBpbnRlcmVzdCByZWxhdGVkIHRvIEpheSB3aGVuIGhlIHdh cyBhIGZpbmFsaXN0IGNhbmRpZGF0ZS4gQXMgd2Ugbm90ZWQgaW4gdGhlIENPSSBtaXRpZ2F0aW9u IG1lbW8gb24gNyBOb3ZlbWJlciAyMDE5IGF0IGh0dHBzOi8vd3d3LmlldGYub3JnL21lZGlhL2Rv Y3VtZW50cy9Cb2FyZF9JRVRGX0VEX0NvSV9NaXRpZ2F0aW9uX01lbW9fLV8yMDE5MTEwNy5wZGY6 DQrigJxPbiBPY3RvYmVyIDcsIDIwMTksIGNvdW5zZWwgcHJvdmlkZWQgYSBtZW1vIHRvIHRoZSBC b2FyZCBvZiBEaXJlY3RvcnMgb2YgdGhlIElFVEYgTExDIHdpdGggdGhlaXIgYXNzZXNzbWVudCBv ZiBwb3RlbnRpYWwgY29uZmxpY3RzIG9mIGludGVyZXN0LiBDb3Vuc2VsIGFkdmlzZWQgdGhhdCB0 aGV5IGRpZCBub3QgYmVsaWV2ZSB0aGF0IHRoZSBJRVRGIEVE4oCZcyBjb250aW51ZWQgc2Vydmlj ZSBvbiB0aGUgUElSIGJvYXJkIHByZXNlbnRzIGEgY29uZmxpY3Qgb2YgaW50ZXJlc3QgdGhhdCB3 b3VsZCBpbXBlZGUgdGhlIGNhbmRpZGF0ZeKAmXMgYWJpbGl0eSB0byBwZXJmb3JtIHRoZSByb2xl IG9mIElFVEYgRUQgaW4gdGhlIGJlc3QgaW50ZXJlc3RzIG9mIHRoZSBJRVRGIExMQy4gVGhleSBk aWQsIGhvd2V2ZXIsIHJlY29tbWVuZCB0aGF0IHRoZSBwYXJ0aWVzIHRha2UgY2VydGFpbiBzdGVw cyB0byBtaXRpZ2F0ZSBhbmQgcHJldmVudCBhbnkgcG90ZW50aWFsLCBhY3R1YWwgb3IgcGVyY2Vp dmVkIGNvbmZsaWN0cyBvZiBpbnRlcmVzdC7igJ0NCg0KMyAtIEFsbCBib2FyZCBtZW1iZXJzIGFu ZCB0aGUgSUVURiBFeGVjdXRpdmUgRGlyZWN0b3IgbWFkZSBDT0kgZGlzY2xvc3VyZXMgb24gNyBO b3ZlbWJlciAyMDE5LiBTZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYWJvdXQvYWRtaW5pc3RyYXRp b24vcG9saWNpZXMtcHJvY2VkdXJlcy9jb25mbGljdC1pbnRlcmVzdC9jb2ktZGlzY2xvc3VyZXMv DQoNCldlIGRvIGNvdW50IG9uIGNvbW11bml0eSBpbnB1dCBhbmQgcGFydGljaXBhdGlvbiB0byBn ZXQgdGhlc2UgdGhpbmdzIHJpZ2h0IGFuZCB3aWxsIGNvbnRpbnVlIHRvIGNvbnN1bHQgY2xvc2Vs eSBhbmQgd2lkZWx5LiBJbiBwYXJ0aWN1bGFyLCBvdXIgQ09JIHBvbGljeSBpcyBicmFuZCBuZXcu IElmIHBlb3BsZSBiZWxpZXZlIHRoZXJlIGlzIGEgc2hvcnRjb21pbmcgaW4gdGhhdCBwb2xpY3kg b3IgdGhlIGRpc2Nsb3N1cmUgZm9ybSBpdHNlbGYsIHdlIHdlbGNvbWUgYW55IHN1Z2dlc3Rpb25z IG9uIGhvdyB0aG9zZSBtYXkgYmUgaW1wcm92ZWQuDQoNClRoYW5rcw0KSmFzb24gKG9uIGJlaGFs ZiBvZiB0aGUgSUVURiBMTEMgQm9hcmQpDQoNCg== From nobody Fri Jan 17 11:44:25 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5565F1200D6 for ; Fri, 17 Jan 2020 11:44:22 -0800 (PST) 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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-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 qyJxvbCuzL8g for ; Fri, 17 Jan 2020 11:44:18 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 5054E1200A4 for ; Fri, 17 Jan 2020 11:44:18 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id c16so27256650ioh.6 for ; Fri, 17 Jan 2020 11:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YhibBWd6xhvpCEhH/gyh6gG6PGHtm/75oLx/TnwVxww=; b=mYRQmvciTB2HMctO3BfGUbGNPrbUn3ExsI0pQoADowUQpIEsDysuA4qM1EgjxtI+6C lJ3gNaDOrPbxi4CCoaHfQEOW8PkQhJe+PwBMCrHKMSIju+LzsRHOFYEex84wMKnqxlaW +oygXaX4/WAU4N5HDZK2EyvTfl/D0xoenJ1lB/Geux9oo2Ba6ny0Wc3C7WEEQfFeMvVx YRbYaZD90+n8iLWvK/ZUAiAX6MFrHdjhTkC19ubyy02xHTQni5sgCYgZ9ceZCCf+dsgq T4IciFfBQz4VXBp9zK3CIyUm7fsiobAj/g0np1QEcWA2uEBfbIMTOkLB7eVLz1/X3lju MkUQ== 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=YhibBWd6xhvpCEhH/gyh6gG6PGHtm/75oLx/TnwVxww=; b=VplTJKwVbjSjrUyl4B4s1rxIsBjPYMwxDcEEY2+BgQD4AXOaqwkHFNGlc8Kup4hP+U ROBJPkVzSOOH5PrwDxXNRE0QycpzvPOlJ/LwxIKtsLq2VEgpU83jPMTXb7sHjmkAE0PC DY4oU9LvTvAW4t4GGnuLkKEfwSt7POpqBUjEzzFJyfLFAd6RlzogNyWVQ0S2i5S/ZHpC lin8LL7gS4OKGxVJ9jJXB10w08G/VuGwuSYlAlzmzgrKyrn8EulzOflhrNGG7ulUGJh5 KEkbXrhlHZzjnOpW0obuLbU9JElti1yIQ/xQrKt7TBhmIOXCUNomkSUk0mrAus3yWV1v 6PJA== X-Gm-Message-State: APjAAAWUUvJGbnid55t00vVAaydI+X069D4vJ1/Ws8GDJts0pGrozINI tVYk3zTMpvTsb3+BzycxBVkpMO6ATLPLohhfT6cIhQ== X-Google-Smtp-Source: APXvYqyAjVeXdq37MJJlkSQOuyVbKkx3HglfzeTp97xFvvvPSZBJa2sjtQKUApy6x+I4J7NiED7w4vAVhyFSxYPd5f4= X-Received: by 2002:a5e:940f:: with SMTP id q15mr30152547ioj.218.1579290257586; Fri, 17 Jan 2020 11:44:17 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> From: Tim Bray Date: Fri, 17 Jan 2020 11:44:06 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Andrew Sullivan Cc: Rob Sayre , www-archive@w3.org, IETF discussion list , mgodwin@rstreet.org Content-Type: multipart/alternative; boundary="000000000000cd1fa0059c5b2ae6" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 19:44:22 -0000 --000000000000cd1fa0059c5b2ae6 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 9:46 AM Andrew Sullivan wrote: > > I've said before that I don't think the IETF list is a good place to > discuss the PIR transaction, and unless the Sergeants-at-Arms disagree > with me I'm going to maintain that position. (I see even less reason > for this to be on a W3C list.) I'll respond to this question > I'm inclined to disagree - ietf@ feels like an appropriate place to discuss, since this is of substantial concern to the Internet-engineering community. But I might be wrong - is there another place that clearly is an appropriate home for this discussion? Thanks in advance. --000000000000cd1fa0059c5b2ae6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 17, 2020 at 9:46 AM Andrew Sullivan <= ;sullivan@isoc.org> wrote:
<= /div>

I've said before that I don't think the IETF list is a good place t= o
discuss the PIR transaction, and unless the Sergeants-at-Arms disagree
with me I'm going to maintain that position.=C2=A0 (I see even less rea= son
for this to be on a W3C list.)=C2=A0 I'll respond to this question
<= /blockquote>

I'm inclined to disagree - ietf@ feels like an appropriate = place to discuss, since this is of substantial concern to the Internet-engi= neering community.

B= ut I might be wrong - is there another place that clearly is an appropriate= home for this discussion?=C2=A0 Thanks in advance.


--000000000000cd1fa0059c5b2ae6-- From nobody Fri Jan 17 11:50:44 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DA1200CD for ; Fri, 17 Jan 2020 11:50:43 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=akamai.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 sVJ_wVcvRYh1 for ; Fri, 17 Jan 2020 11:50:40 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9C9A81200A4 for ; Fri, 17 Jan 2020 11:50:40 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 00HJWExf022979; Fri, 17 Jan 2020 19:50:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=BSBVLMMme72bWX0W7nCtlkMX0P0Z5pZ6TOUROFRO6Cc=; b=VddHeu7Fy8Ef3L/l2mt2H9b4aBWXrsOCQ8din3Cm9xsP65D75zfDA7C04MxY39uFcRdw KRKCXNKwuhmL6dfPOS3P0VWFu4fisvnKrg/wNPX0QEcnNXgAD/T//FV8E1s9jsPU0D3I iClkvP23VZk+hqkcH7s3UvgvR2FIfRDm44egImL6brBWvqVSE2X9VzmYasq45zswNNmb 1bKDXdsWfz/OlhoTZOUvYQiEUQeO1SDKvHUDOeJMKp6Qa47xH9TcHbLE2bvDnnjqz1f9 sBSvfCczOGpFSNpnrKclChkMUWXOE6ioYyl9U1OnlaluH5Zt8e7qeMLeMlciMWEKzZER 1A== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2xhptxvaty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 19:50:40 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00HJl6Vq023616; Fri, 17 Jan 2020 14:50:38 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint6.akamai.com with ESMTP id 2xfak0v1rn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 14:50:38 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 14:50:38 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 14:50:37 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Fri, 17 Jan 2020 14:50:37 -0500 From: "Salz, Rich" To: Tim Bray , Andrew Sullivan CC: "www-archive@w3.org" , IETF discussion list , "mgodwin@rstreet.org" Subject: Re: .org sale - bidding process Thread-Topic: .org sale - bidding process Thread-Index: AQHVzPXNP5ZvMjmR1U+ZKPFpseXvaKfvdbmAgAAhIQD//64BgA== Date: Fri, 17 Jan 2020 19:50:37 +0000 Message-ID: References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.16] Content-Type: multipart/alternative; boundary="_000_E48C5268DCC64B8D97054F0F702B8DB8akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-17_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=859 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001170150 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_05:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 priorityscore=1501 spamscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 adultscore=0 mlxlogscore=829 bulkscore=0 impostorscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001170149 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 19:50:43 -0000 --_000_E48C5268DCC64B8D97054F0F702B8DB8akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkJ1dCBJIG1pZ2h0IGJlIHdyb25nIC0gaXMgdGhlcmUgYW5vdGhlciBwbGFjZSB0aGF0IGNsZWFy bHkgaXMgYW4gYXBwcm9wcmlhdGUgaG9tZSBmb3IgdGhpcyBkaXNjdXNzaW9uPyAgVGhhbmtzIGlu IGFkdmFuY2UuDQoNCipQdWJsaWMqIGZvcnVtLCB0aGF0IGlzLg0K --_000_E48C5268DCC64B8D97054F0F702B8DB8akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7548BDFCAB568149B631825DDAE87ABE@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jmd0O0J1dCBJIG1pZ2h0IGJlIHdyb25nIC0gaXMgdGhlcmUgYW5vdGhlciBwbGFjZSB0 aGF0IGNsZWFybHkgaXMgYW4gYXBwcm9wcmlhdGUgaG9tZSBmb3IgdGhpcyBkaXNjdXNzaW9uPyZu YnNwOyBUaGFua3MgaW4gYWR2YW5jZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KjxiPlB1YmxpYzwvYj4qIGZvcnVtLCB0aGF0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_E48C5268DCC64B8D97054F0F702B8DB8akamaicom_-- From nobody Fri Jan 17 12:31:46 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2242C1200F3 for ; Fri, 17 Jan 2020 12:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 sUL-lEvIU5eC for ; Fri, 17 Jan 2020 12:31:40 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750053.outbound.protection.outlook.com [40.107.75.53]) (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 C08D61200E6 for ; Fri, 17 Jan 2020 12:31:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z1e2RjgEs55yVa+23t3Ngm0h60nhdA6LqiXZgRUlTp9WNSLXwsMZuURIcuJfsVznDi/bqNMTA0vIu6w+UnLdiU7DbGLJu3TyG8rKKg/eus+E8EPpdEHX0DLDtxPPNOZRJceV1dsp3/ZA7iFUaEy6hIzNYNrJlrgF/cBrZL9zTUQ5An0wun83uUB3VBnhEbavKByG/n0AevPZlT/0UfNXeNbNihEkAlQOKIIXWQlMRkpD/Uuyf5atfdqvqn/skjn5rahVtMBCOWQmiHwWngjxQveRZSSvgpUEIu6nOGvgQumBx4xqWl4Ccwj6TF6/H26n/XfcdcSYj8a1VvGZSanTFg== 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=HR9zTZoSeT4rghlcqFy0XXFdQTQwuLOPJwrhHKEfYZM=; b=mS0EdTvot7fCcuOcR7DahCRh1SwdX/nY9JyNwNil8/Z9CZPVvXQbW7odpwwG3y/WAfAw1e8hJ2VkNfzoCey3+swmZeVKGCrWI8jq1F6c8cq/86Bar0JVWUNQjFzh3pl3wySo7B4/GtvUdP/MKg6Oc5zD/8+sKR3l4Hi+YOA1ep4/1n/l48SEYNNuov36bwy8sa4AL/ixK+JyDb3wWtVpEcS5g7DPY38uokNV2PmDt6KOAROJHLqV7wJVe6wncPSPlNiLcR1/8wkkEeUs+FMR11hchkffQejYIm/2PaoZBD4VGh+KM66nLCHf4hPmSb1v67ToqwF+Ka5C2wgJUfOWEg== 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=HR9zTZoSeT4rghlcqFy0XXFdQTQwuLOPJwrhHKEfYZM=; b=Ht3N5pY9Npu/bqfgVvGH58ufS5F21tiq/KpONP1R6oyqUpzxNSG1qAgocBkKc4m886lP+J4kBdf/COD+qt87o6dZ2CXy/uuL3+ir1jhwj6cEPI2yY7M07C19XbS3SlJpIwaB6oA901G6P2WA7CeFFwskdu/lXdxmX+uzlIAAl4g= Received: from BYAPR06MB5175.namprd06.prod.outlook.com (20.178.50.13) by BYAPR06MB6056.namprd06.prod.outlook.com (20.178.50.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Fri, 17 Jan 2020 20:31:37 +0000 Received: from BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0]) by BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0%4]) with mapi id 15.20.2623.015; Fri, 17 Jan 2020 20:31:37 +0000 Received: from outlook.office365.com (2607:fea8:760:124:280e:1c6:e79d:7bcc) by YTOPR0101CA0020.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:15::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19 via Frontend Transport; Fri, 17 Jan 2020 20:31:37 +0000 From: Andrew Sullivan To: "ietf@ietf.org" Subject: Re: .org sale - bidding process Thread-Topic: .org sale - bidding process Thread-Index: AQHVzW6EC6mC/qqtJEGLFM/20TbNO6fvT1oA Date: Fri, 17 Jan 2020 20:31:37 +0000 Message-ID: <20200117203133.pmyh6fftylbdoonj@outlook.office365.com> References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: YTOPR0101CA0020.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:15::33) To BYAPR06MB5175.namprd06.prod.outlook.com (2603:10b6:a03:ca::13) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sullivan@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2607:fea8:760:124:280e:1c6:e79d:7bcc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0bdd9344-7744-41b8-5d5c-08d79b8c4070 x-ms-traffictypediagnostic: BYAPR06MB6056: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39850400004)(136003)(366004)(189003)(199004)(478600001)(316002)(6916009)(66574012)(1076003)(71200400001)(2906002)(86362001)(81156014)(55016002)(81166006)(9686003)(186003)(16526019)(66446008)(64756008)(66556008)(66476007)(66946007)(8676002)(8936002)(6506007)(5660300002)(52116002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB6056; H:BYAPR06MB5175.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: NJN++hpgbwaZoEz5//r4clBF91gM/4oS0b+6olZ4rrvXc0XkWCL8SywfRF1UlvlCWMu0ioBkeR6mth0F9n92brUmz50GB/RDbGysThRNQAy/8ZGcqo8DgxEieQ/yii096x0C3M9FRF18vWBldbd/9hJTBarHQR3pMGfzZnfqVUmQUituqenol1s5H5paXKXZzFFx2TzXHyBIAT75tzsp6my3G1sSU8F3HULvoXAZf3xnE6hGN1eQbqHlPCjlq1MdysASJcY2HB9+b1sHPK7+wlOCiymuc+v4FLJl72/c98Px2V4Uo1/gt02Zvn/xP3DJKZDUcJb3F+xs+FCQagbIn+xSAcFNYmZpqZpUkhtceZT9xmq6NnfJnb4fA4hMvbWjSqSlZZC6MD5Rn/wgfReQs7glzu8aDFsL5HMXfut0OnZUJvI8wFNB/PTDzpkxEwpt x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <6DC9DAFB883B0F4C8EDD0EC1CC59F514@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 0bdd9344-7744-41b8-5d5c-08d79b8c4070 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 20:31:37.6456 (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: YHI30ck7exDk6Fk3ET1SPNK45FBl6OS37njhx4x5884XPVfSM6c6hha0aNhSVxVbAHtDjt8bjyndhsrV+su+JA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB6056 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 20:31:45 -0000 Hi, (Lists trimmed. There is no way this is a W3C issue.) On Fri, Jan 17, 2020 at 11:44:06AM -0800, Tim Bray wrote: > I'm inclined to disagree - ietf@ feels like an appropriate place to > discuss, since this is of substantial concern to the Internet-engineering > community. That isn't a reason to hold the discussion on the IETF list. I mean, presumably the Internet-engineering community is concerned about the possibility of war between the United States and Iran, but I think that would also be off-topic on the IETF general list. =20 =20 > But I might be wrong - is there another place that clearly is an > appropriate home for this discussion? Thanks in advance. I've pointed to it before, but a lot of discussion is happening on the ISOC internet-policy list. You do need to have an ISOC member account and the archives are not open. This is the result of our understanding of how the GDPR affected our ability to have open archives of lists that were set up before we got everyone's assent to an open archive. Full disclosure: the user interface for some of this is not great. We're working on it. A --=20 Andrew Sullivan President & CEO, Internet Society sullivan@isoc.org +1 416 731 1261 From nobody Fri Jan 17 13:21:59 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E413A1200F7 for ; Fri, 17 Jan 2020 13:21:56 -0800 (PST) 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 BUWfYkU_ZyVO for ; Fri, 17 Jan 2020 13:21:55 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2082.outbound.protection.outlook.com [40.107.92.82]) (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 2727B1200F3 for ; Fri, 17 Jan 2020 13:21:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DQh+XXQIVLH3FdW6qYUJxxWiAouH1f6d95KbIIiubdEZWrykCc3i3sX0gC6eI5UnWM8MS09OXt+/w/dOQBITwsrcHm+FO3QZ+FiCaYa3LBVuotjTBmbJu8vW92DmZBSjRSvw3sl6fRTurz3X1mSri283NcLl/REV7VlOaQ33w6ZzdaLEGrjP+xy59kAMt99fxX1xvDr8US0SGKLBdg/Bzl1O2AEymTcqWxD3/X8mYunmVwpJbGeSZJGmJ0v+VaEsy/hS0rVQqf3kFnwxNhmNXPvHhg+V7NLJDUGpXGKi78uBaTLpTqniyBtwe29DHOJ1jgMHBP0rUQWgCUvxyVHRLw== 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=ssJK4x96fwo8Zu7inONaxbMYruAuu71nLslVia6e9rU=; b=lE39jUEo32H7fMF0jjuhsicFM0zfgD9csJrGxWzrLN1KegO6335UG4cJb5M4kR1PLN9aHaoeawqqZauvtFken5L9G5IzHuuCArehLi1OKbuqsNIC3gxuYOuIPtLeTjQhPphme2BNOGViRTYM7GfbPhYW6VZq2SZDrS3qPn2ZN1aNwcRBJ8wnIBzq+3/0C5ENVpL+H9HqQ5LCMzQTgwMwBE4FoyAdHl2FcPtrQig/dLIA72ODlKHpCqpNddyo5/aklj26EVkQKRi9WbGkXB4MMp4P4MQTITO54BxCMMf/0RVNXfVvk3Jm7KF/Kdt4ZQgSZTGjFtYlMJWCynwIHenmhQ== 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=ssJK4x96fwo8Zu7inONaxbMYruAuu71nLslVia6e9rU=; b=cE4BMfPRxE3A3wdHWuBRASLjSRLXt3rVyx/9A2ruyUvQQWVkt/5bMLSpiM50b1x0adGnHK/uPfSkJrQSm5B8jxQFt/ZWfuipRp6VF5CvqCtBYzthVz1LJzoiOtLuZF1vxVu/y4O8Ev/YD7Ji934/7ZOJ3kvcYmMgPaASz/Q4SIE= Received: from BYAPR06MB5175.namprd06.prod.outlook.com (20.178.50.13) by BYAPR06MB6023.namprd06.prod.outlook.com (20.179.158.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.23; Fri, 17 Jan 2020 21:21:52 +0000 Received: from BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0]) by BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0%4]) with mapi id 15.20.2623.015; Fri, 17 Jan 2020 21:21:52 +0000 Received: from outlook.office365.com (2607:fea8:760:124:280e:1c6:e79d:7bcc) by YTXPR0101CA0057.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:1::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18 via Frontend Transport; Fri, 17 Jan 2020 21:21:52 +0000 From: Andrew Sullivan To: "ietf@ietf.org" Subject: Re: .org sale - bidding process Thread-Topic: .org sale - bidding process Thread-Index: AQHVzW6EC6mC/qqtJEGLFM/20TbNO6fu+4eAgABh3YA= Date: Fri, 17 Jan 2020 21:21:52 +0000 Message-ID: <20200117212149.3h4ozdvsxnzwgjpi@outlook.office365.com> References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> <20200117203133.pmyh6fftylbdoonj@outlook.office365.com> In-Reply-To: <20200117203133.pmyh6fftylbdoonj@outlook.office365.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: YTXPR0101CA0057.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:1::34) To BYAPR06MB5175.namprd06.prod.outlook.com (2603:10b6:a03:ca::13) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sullivan@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2607:fea8:760:124:280e:1c6:e79d:7bcc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b68a614-15ba-486d-5ac5-08d79b9345a1 x-ms-traffictypediagnostic: BYAPR06MB6023: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39830400003)(189003)(199004)(71200400001)(966005)(316002)(81166006)(81156014)(6916009)(186003)(86362001)(8936002)(16526019)(52116002)(8676002)(7696005)(6506007)(2906002)(1076003)(55016002)(66446008)(64756008)(5660300002)(66476007)(478600001)(9686003)(4744005)(66574012)(66946007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB6023; H:BYAPR06MB5175.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: 6i6H7V/7sdJXOeMZif3s4kEx0kZ2DOpCqmWMtHcX2CKO6aYIwto6gGlIJOTgP5tnjXMbMnMbI/T8k2BZ4sEh8xEVS0P1V5NMhPeVLFkd4RtpR+9PG8b2ZaYmP5ywLx+Exr6n06gPeFH5OFQsnNyTP1ErZ18LvhUXK4K6e0ZivawCVWI8vq3sNq9o+PcslDRf9Ogyoi++CIE4bGBKhV+DVQHyQMmAkZTarGnM/lhi2iJ+yACer2XJjW0R3Nwxwj7HmDPTX8Uw9mjhdu+voeNjXpXsp4+Yg+FZM7Jf+oCRzeSolEkpP8anJUi3F9TtPP4vZcfIY79RzOWUTkXJiQpJfZJ3GebU9SH+Muzfs/lZmkZYTjYgnHbGkwUTKIqMC7ZCjKlAukhxk7vm8eVEn6hXAlZhIsZCe/MtHfG7JKjnOxI2wiT5YfBiwGFGE+v7blZmJTpvDKkvwYSKc/yy1gipfzQf400t2dPbG2nVEpvpJaE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <0EE04327480ECB478EFD45A576C4D605@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 2b68a614-15ba-486d-5ac5-08d79b9345a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 21:21:52.7724 (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: 5JuklfYarNl99JOJgMLPI+Wl+kmaPwvj52+fMKQ9pXyDkfAfmvxEaZ4mShrnggxU5MlsJKhbxefBiU+AZd32lA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB6023 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 21:21:57 -0000 Hi, ISOC hat still on. On Fri, Jan 17, 2020 at 03:31:33PM -0500, Andrew Sullivan wrote: > an open archive. Full disclosure: the user interface for some of this > is not great. We're working on it. I've had some questions about this. Here's how you sign up: 1. go here: https://portal.isoc.org/ 2. sign in (or sign up) 3. Click on the picture of you (or where one would be) in the upper-right c= orner and click on "Profile" 4. Click on "Preferences" tab. 5. Click on "edit" in the "EMAIL CONSENT AND GENERAL CHANNELS" section. 6. Select "internet policy" and save. Nobody is more irritated than I am about how hard that is, though I think I can safely say that many other people are as irritated as I am by it. It's on the TODO list. Best regards, A --=20 Andrew Sullivan President & CEO, Internet Society sullivan@isoc.org +1 416 731 1261 From nobody Fri Jan 17 14:02:47 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA66120091 for ; Fri, 17 Jan 2020 14:02:45 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkbRnXM62Lrz for ; Fri, 17 Jan 2020 14:02:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 46FF7120041 for ; Fri, 17 Jan 2020 14:02:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1isZhN-0001sT-Ta; Fri, 17 Jan 2020 22:02:38 +0000 Date: Fri, 17 Jan 2020 14:02:37 -0800 Message-ID: From: Randy Bush To: Andrew Sullivan Cc: IETF Rinse Repeat Subject: Re: .org sale - bidding process In-Reply-To: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:02:46 -0000 perhaps "I don't think the IETF list is a good place to discuss the PIR transactio" does not have the best cosmetics for a subject where folk have expressed concern of discussion suppression. randy From nobody Fri Jan 17 14:17:25 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BF5120041 for ; Fri, 17 Jan 2020 14:17:22 -0800 (PST) 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 bjJW5P_h_q1Y for ; Fri, 17 Jan 2020 14:17:20 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2067.outbound.protection.outlook.com [40.107.237.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8769C120026 for ; Fri, 17 Jan 2020 14:17:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NdNrVgoVyprkyeBWKs/zWyS1IP0OMRLcwMetnHHYbj2ySnTHCRY5BGzTINisXY+b+LeZh1EYz0RLvxcky24LP+g+Ac6o8RtEoCjj1o0Xw8W5JGazjSk4K98BMayXGJD2tFiCpHgLqf3P5+tDWP1boygjbJNoxn1HgQqqA6memOMjl9MmIfJLPtWAeE/xPXkV7kCWonTRFimOZPfhVlACVO34Qf/gCFlYCQt7e3SnVB74Jsw2s2hdC6fo6t43nr01cNOxFDwu3OgFFrw0PHn/6kM5i2SbZc2I1AX/xSJfvp1HsGjydeeI6Q6/xwp7lvfYgu1oZMUe3cXybyP+paVZpA== 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=YJeL8B22iPoClTQAMMBUdXJKZodo9+mD32iicR1YIuA=; b=fpLu3MNGoqHJusickHZz2E5DtLgbbbOdXPBNR66kjd/o57bjp1xhDPDMp289f6XNjI+am12p7jFwWTQ3UFh/+C2dAAJaa7NTbnGG57lj1b+JC9LEhn9xw0iSKKOfzhF5RKpScGJARIQUyvQ5+VkJTbzyzv7jocHqWuAXngfxSGGZsw84eGzxVaF9xoTAtrzDGK51+WFasLLybMOj6kvpQ+gb6kuwEI0kCciZTccogSJhK7xe+Sa8IN4xUK0/e2/yaTyoMojFZz6ibHNbOsC6nEI/beOOFc3Uw7YJ8T1WSeUTrAnHanoQ8escxH7ZyAVm8oG0OypvsF2UwL9ZxbsjVQ== 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=YJeL8B22iPoClTQAMMBUdXJKZodo9+mD32iicR1YIuA=; b=A/QgNN9otc4cSlv/zRj7Il91fAgFjGBNnFtSif66Op/pvGRhqnYsW809wXeIgim7F+T0B9trzDe8+UtS98c8W4mGgO6xjN/s3hmNaDYAitrKPbjRfNqsHDILd7rksuTQzNwL7Exh5RV6pzXJa8SxrRQZittnhic1IJ/pQ75G8aw= Received: from BYAPR06MB5175.namprd06.prod.outlook.com (20.178.50.13) by BYAPR06MB4693.namprd06.prod.outlook.com (52.135.241.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Fri, 17 Jan 2020 22:17:16 +0000 Received: from BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0]) by BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0%4]) with mapi id 15.20.2623.015; Fri, 17 Jan 2020 22:17:16 +0000 Received: from outlook.office365.com (2607:fea8:760:124:280e:1c6:e79d:7bcc) by YTXPR0101CA0049.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:1::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18 via Frontend Transport; Fri, 17 Jan 2020 22:17:16 +0000 From: Andrew Sullivan To: "ietf@ietf.org" Subject: Re: .org sale - bidding process Thread-Topic: .org sale - bidding process Thread-Index: AQHVzYHUC6mC/qqtJEGLFM/20TbNO6fvbLiA Date: Fri, 17 Jan 2020 22:17:16 +0000 Message-ID: <20200117221713.vt6bmjo2jd5bz3e2@outlook.office365.com> References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: YTXPR0101CA0049.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:1::26) To BYAPR06MB5175.namprd06.prod.outlook.com (2603:10b6:a03:ca::13) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sullivan@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2607:fea8:760:124:280e:1c6:e79d:7bcc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d4fc666-9e3d-4851-a941-08d79b9b02c5 x-ms-traffictypediagnostic: BYAPR06MB4693: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(136003)(366004)(376002)(396003)(199004)(189003)(66946007)(66556008)(64756008)(66446008)(52116002)(66476007)(7696005)(86362001)(71200400001)(6506007)(66574012)(1076003)(186003)(16526019)(316002)(2906002)(81156014)(55016002)(8936002)(6916009)(8676002)(81166006)(478600001)(9686003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB4693; H:BYAPR06MB5175.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: lMRHXKPOEnY1UOUkzp7eDn1isbaoj0+gub+FhWBpEkGeqVUHZJTaXRTiqYhIosTcWNUscXM1bh8bQnkGWOr5l7yN4KcSOV1JY0hLQGh9s5+sPL7lZ6BOfsg+T/t55Y5pt1Ts5ZJBue4eZzMHWLopHaYoSSjLPmhuPzSdMODPzszc63lCO/Zd3usxbUmWa2Vcl16hz6lSYyevHdWXfbyUXQNNIYTx5Dipx2VOten5UnfNYlz/uA88b1EYzOa9QIZc4SN5SfvEcqbLNK73z8MQyXYbQguwDlP7Pniw9GgtS8aNgd6vSKGiGl1nfLgCTeNKJ9OPExfFz2TcjzFs/SPTHyv0wxuZv3Nqpns4W5Nn0srNUMbmnGm8K+cuVCMGbe3mcNt31HkjeTQ3MkRJXP76XwBKTT1sLM/MwHUSBTn8VAyMjuOiAKP967Dfx/dPG6wy x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 1d4fc666-9e3d-4851-a941-08d79b9b02c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 22:17:16.6068 (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: Xa9VcKkGmQ2BcBKbneQlbtvTWWY+KyAlTQh8Q0LH2hHPNvAxlz4GdlGsO0DnzeSxC/rSphmHPkh+8lodk+7BTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4693 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:17:23 -0000 Hi, On Fri, Jan 17, 2020 at 02:02:37PM -0800, Randy Bush wrote: > perhaps "I don't think the IETF list is a good place to discuss the PIR > transactio" does not have the best cosmetics for a subject where folk > have expressed concern of discussion suppression. =20 Please let me be perfectly clear. I am not trying to suppress discussion in any way. But there are three factors at play here: 1. The IETF list is supposed to be a list about IETF and the topics of direct relevance to its work. I have said, here on this list, that ISOC's commitment to IETF funding is in no way diminished by this proposed transaction and will continue whatever the outcome. Other than that, there is literally nothing about this transaction that has any technical implications at all. The IETF list would be an inappropriate list to discuss the corporate owner of the operator of .nl or .ca or .us or .biz or .info or .com. For the same reason, I cannot see even a little bit an argument for how the PIR transaction is on topic here, and I don't wish to distract the IETF from the important work it does. 2. There is in fact a list that has had a lot of traffic, and that is open to anyone here who wants to subscribe, where the topic is being discussed. Just as people often frown on cross-posting or (worse) "WG shopping" in the IETF, I think adding another list where discussion goes on will not help. 3. This is perhaps a more pragmatic reason, but I have limited capacity to follow the IETF list with great diligence, and I have been trying very hard to answer questions people have about this proposed transaction. To my chagrin, I no longer contribute in anything like a meaningful way to the IETF (admittedly, there are likely those who will say I never did), so I really just cannot keep up with IETF list traffic. If people wish to discuss the topic here on the IETF list, what is most likely to happen is that I won't be able to answer their questions in reasonable time. Other ISOC personnel are engaged in working on ISOC's efforts to build, promote, and defend the Internet. That's what we exist for, and I am not willing to pull them out of those efforts in order to follow a discussion here in a venue where I think the topic is not appropriate anyway (for the above reasons). Obviously, I can't police what people might talk about on the IETF list, and if you want to talk about this here and the SAA is prepared to allow it, go ahead. But _I_ don't think it's appropriate and you'll get better service if you ask questions on a different list. I hope that helps make my view plainer. Best regards, A --=20 Andrew Sullivan President & CEO, Internet Society sullivan@isoc.org +1 416 731 1261 From nobody Fri Jan 17 14:36:11 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ABD120086 for ; Fri, 17 Jan 2020 14:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 6HAbZP9jQuWp for ; Fri, 17 Jan 2020 14:36:05 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FBE120026 for ; Fri, 17 Jan 2020 14:36:04 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q8so4240813ljj.11 for ; Fri, 17 Jan 2020 14:36:04 -0800 (PST) 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=C07RSUEzmz1e5pT80+JzYdlV1nDjKJFYqzxX3fkXirc=; b=hqan1L4a485PYrb+X7lbrn/NQeSnqxm+6T5I0jysmU9PqtQ2MWHtO48hyj+fOkkgVc rYytTSGXNzWr0aqm9QkOsQdpX3kgcoG9Orba06QR9Ldhu5JERoeVD8vpSi+zLnDVEktc c4i/OGOm0xrlv3LXdNCubiXaF7evyOE6txhOMnFYUzAG1dv8Nqi/fuEIRgIHUpKeRX7I GmmqQastrTbg/F7EHLaYPzJkmYhf3TwQSl5vMGG+5xElBHoTMQG3KXKcna8CAfam58CW +/VyQnVoJAuuBhJxoPxDC9feMuB9M1vmbl8qhAW6lOSHhmIwo1S6p+szD4TTbLR1kG0I hmgg== 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=C07RSUEzmz1e5pT80+JzYdlV1nDjKJFYqzxX3fkXirc=; b=rx6x1CbXCxmISnWtW6jZsUSTe37kWc90lB0/2q59gQYgiEFFW+UpDk+FsrUTnXD+uw /AKsQOMSleEKsy6X2O6sSvUOb+Bw/VGwmfDFCiZGJUTcJuuO1M3dsOSoTNL0fhF/Xt1u y3cF5qgHWydbP98KcnXykz1IccTHAVTuWo8BX3ib4/mc6FiVwCAJIyUqw0cjDmeQ5I83 F/5H4Ff63rxXKwGxEHeRP1SN8iO0Ex6o9ugMU7f7Gx7mg+b6a+MSy1vjgzzsL5o7njjv HOt0xwkDjqVHsClumlqPDDh7YclQ2z5xQF1CjU80qvEp0pQogRpQfAz2xF0eiOofugFw ICWA== X-Gm-Message-State: APjAAAUiOoYNAq4rFFKmg6qGFxYv3dsVSeMjlt9Acfwf0lD1vqiEeBwm zGIibqx+ftCCrNGDoyTZBdvNhJ6ZH0MsVOBRAtop3Q== X-Google-Smtp-Source: APXvYqw8Uj39ivVDBOz2U8Wcgo04VOKYaIxvYRthkK1PnfpbmHn7z+J3zw5OHoY66/hm0+cK2/ZeN0t+rddKlnqI5IU= X-Received: by 2002:a2e:9e43:: with SMTP id g3mr7020657ljk.37.1579300563146; Fri, 17 Jan 2020 14:36:03 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: From: Eric Rescorla Date: Fri, 17 Jan 2020 14:35:27 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Randy Bush Cc: Andrew Sullivan , IETF Rinse Repeat Content-Type: multipart/alternative; boundary="0000000000000f6c7f059c5d9110" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:36:09 -0000 --0000000000000f6c7f059c5d9110 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 2:03 PM Randy Bush wrote: > perhaps "I don't think the IETF list is a good place to discuss the PIR > transactio" does not have the best cosmetics for a subject where folk > have expressed concern of discussion suppression. > This seems like an argument that really proves too much. Suppose someone wanted to discuss the US presidential election on the IETF list and then expressed concern over discussion suppression, would that mean it was bad optics to suggest that the IETF list wasn't the best place? -Ekr > randy > > --0000000000000f6c7f059c5d9110 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 17, 2020 at 2:= 03 PM Randy Bush <randy@psg.com>= wrote:
perhaps = "I don't think the IETF list is a good place to discuss the PIR transactio" does not have the best cosmetics for a subject where folk<= br> have expressed concern of discussion suppression.

=
This seems like an argument that really proves too much. Suppose= someone wanted to discuss the US presidential election on the IETF list an= d then expressed concern over discussion suppression, would that mean it wa= s bad optics to suggest that the IETF list wasn't the best place?

-Ekr


randy

--0000000000000f6c7f059c5d9110-- From nobody Fri Jan 17 14:44:05 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EE812004C for ; Fri, 17 Jan 2020 14:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4yK1FtCohQ1 for ; Fri, 17 Jan 2020 14:44:01 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 B5164120026 for ; Fri, 17 Jan 2020 14:44:01 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id i11so27669212ioi.12 for ; Fri, 17 Jan 2020 14:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B0VcRYxZnc5JzioDZ8s+lZBAqwCN4Ltzrqoj7C6vch0=; b=Pkip2unF9ziCx3kmk6bvyc2+XksMcdo9HOP/uXhEFUoXlX1EDUuDkhRdWZA6sZaWTx U9yj5ok3rokv5SaVY5gSDpN8n6b3tgS9CVzfd4HV2VJ5eV2Pw58bCxAYlwHUEtZMwyVl 5BD0A0UxY+82m7PZ1B3eK/SsWod+qOk5GrPCDd6+OyHie/k/fXBn0IphexQBeO9gpc9L 1qvtD/GWkq5iefAlfSEXTzt0i8cGsbFZ1ZvcyfYfIW4TdozvD7/b4NJL8IiULa9PR87C KiU4uGJ8Epk9AZmS0LEKe5S9FORbCGEtv9JsxIayBdIHXDlqkhFfa8IZfWQ51q64uL1N X0Fg== 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=B0VcRYxZnc5JzioDZ8s+lZBAqwCN4Ltzrqoj7C6vch0=; b=hzl8NpX0+3h0Kr10blECnKLChcdCaGd2MVe2z/OPwG4b/6Hk5VfrXLtYmsf2TbU0aW QRJWAk17HtQF3e5Cadg/QYUCuWDEX1zpEJW94KdXfP5Xku8gEKTNjnoXff2a/sRl42MV Qc691SwMtvS5wQGqtXQAMlHLH+VC6W5pwZadaoRgO8ezCSdNiEF4lWl5Jd6HvKWPprAD yYt2BAuoNy6NIHeFF2AMXH39LOVGJzw4Dp2nYRoIxBJO1zrJqJkjZ//O3FRCEC0z6pQS EJEmYyW+1VzbbNvQw9FgdvyY+JvurpfHl/eP5kxBuACoweHVRzsg57z0ortLdf+hvLRT 26bg== X-Gm-Message-State: APjAAAUmJ6qiQJwl66PZze6cWEgbRp4ttlmVjj7gE6Fpysz7CPnFX0x/ eXEhZ1tFrcAfkrPE0C8FDkRIk1b1Dsy5xpJ55/M= X-Google-Smtp-Source: APXvYqzKB0DaBrHycvs5937Pc/WGxo/ua0mY/FWCtf+HoDl4SFuPd3e39YlFhvRZNpBh2F3oa9EzFGDvn1gtbotjUP4= X-Received: by 2002:a02:ba91:: with SMTP id g17mr36115958jao.106.1579301040903; Fri, 17 Jan 2020 14:44:00 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> <20200117203133.pmyh6fftylbdoonj@outlook.office365.com> In-Reply-To: <20200117203133.pmyh6fftylbdoonj@outlook.office365.com> From: Rob Sayre Date: Fri, 17 Jan 2020 14:43:49 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Andrew Sullivan Cc: "ietf@ietf.org" , www-archive@w3.org Content-Type: multipart/alternative; boundary="000000000000895a02059c5dad7a" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:44:03 -0000 --000000000000895a02059c5dad7a Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 12:32 PM Andrew Sullivan wrote: > Hi, > > (Lists trimmed. There is no way this is a W3C issue.) > The purpose www-archive is: "Miscellaneous. Mail-to-web gateway." > On Fri, Jan 17, 2020 at 11:44:06AM -0800, Tim Bray wrote: > > > I'm inclined to disagree - ietf@ feels like an appropriate place to > > discuss, since this is of substantial concern to the Internet-engineering > > community. > > That isn't a reason to hold the discussion on the IETF list. > The IETF list is actually pretty tightly moderated. I haven't heard of or gotten any objections about this topic from the moderators. So, what was the bidding process? Maybe a link to an ISOC web page about the process would be helpful. That's what I was looking for, not a discussion. thanks, Rob --000000000000895a02059c5dad7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 12:32 PM Andrew S= ullivan <sullivan@isoc.org> = wrote:
Hi,

(Lists trimmed.=C2=A0 There is no way this is a W3C issue.)

The purpose www-archive is: "Miscellaneous. Mail-= to-web gateway."
=C2=A0
On Fri, Jan 17, 2020 at 11:44:06AM -0800, Tim Bray wrote:

> I'm inclined to disagree - ietf@ feels like an appropriate place t= o
> discuss, since this is of substantial concern to the Internet-engineer= ing
> community.

That isn't a reason to hold the discussion on the IETF list.=C2=A0
<= /blockquote>

The IETF list is actually pretty tightly mo= derated. I haven't heard of or gotten any objections about this topic f= rom the moderators.

So, what was the bidding proce= ss? Maybe a link to an ISOC web page about the process would=C2=A0be helpfu= l. That's what I was looking for, not a discussion.

thanks,
Rob



=C2=A0
--000000000000895a02059c5dad7a-- From nobody Fri Jan 17 16:24:20 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4681200B4 for ; Fri, 17 Jan 2020 16:24:18 -0800 (PST) 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 EfzidFYVAYVV for ; Fri, 17 Jan 2020 16:24:17 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 2D15D120091 for ; Fri, 17 Jan 2020 16:24:17 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id d15so27967158iog.3 for ; Fri, 17 Jan 2020 16:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1SVF2/domdlytXZBbzemP4C1LqPsuwBfpEJ/YOJAL7Q=; b=iSTwwuTFd7CxmommMF2lYD/BaS7VGLcz+CelrQYUUkSYEv1AVFcpl970xHLJEI8TzN rVoZVYIGjHYTFv1A58af43qfspez7ZUraoWpNrTM58+d6OT0t+rZY0jpe/gBHPV89Xe4 Y3ozNHLKaAB/3E3bc4+QxB3jehvtqbicATTeCiU5mxg5J7TNj5ITT3cnw4Dc5nYFFfU0 sjyz72HoajCtx+rFaqhvvRf3LJGNN8qeLJ6e7YVC9gsX11EMd3f4NuQMRmjUiZp3hPpK QkwnuljWG52dTyD8IdPLN+clj6IaASS7FwBPlt909he26iLRb8S0s9x5zUnqlVTzTK9v CGPw== 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=1SVF2/domdlytXZBbzemP4C1LqPsuwBfpEJ/YOJAL7Q=; b=jvLFhJ60IP5umZQ5SAH2ri8M+5AzBqRgGyoq4euz/W3g7LzXLbTQ/Pdj6EKwyW/utR CqShbj61zYqcDKtGDU2DL7akWVBhsuBGTWRDAKOcUAHvr3CITvIyiM9d7KyQ4xkwy1XY pPuNEx908hsY3kNxswwyuANOLaeTjr63FNnK1FaO6TkDSMGV7Ybgj+L3TYq6w+Co3UBT M7QmlFwlQ2ylV2Fg2NtNOESi55box9g96Pr9h/30Rc00ZfLRaN80/QIQa/zLOxgibKL/ LWU40+VrGxYAeCajYzcQCEfBteocsm8xxwk3q8zQg1o0P+khGPe3M8ui+/An8jEL6/Wg U0XQ== X-Gm-Message-State: APjAAAXkWriCYv36WkKh6m47lZ4lAEgcgv3iE0FaAK9nyWmkcwnDdIhE 2b6F6nffVRgQ6KP7RddnPGCui36PNTxgnx9po9k= X-Google-Smtp-Source: APXvYqz3Zp6Rg0pBkfX+0DYzKWgF1T6i8p8a33kjfWj2Woi2uGSf5qYaR1UKQG2h7uOduiVjFvh56KgZKZjCc/+ZHhc= X-Received: by 2002:a05:6638:21a:: with SMTP id e26mr6123384jaq.53.1579307056380; Fri, 17 Jan 2020 16:24:16 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: From: Rob Sayre Date: Fri, 17 Jan 2020 16:24:05 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Eric Rescorla Cc: Randy Bush , IETF Rinse Repeat , Andrew Sullivan Content-Type: multipart/alternative; boundary="000000000000164651059c5f141c" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 00:24:19 -0000 --000000000000164651059c5f141c Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 2:36 PM Eric Rescorla wrote: > > > On Fri, Jan 17, 2020 at 2:03 PM Randy Bush wrote: > >> perhaps "I don't think the IETF list is a good place to discuss the PIR >> transactio" does not have the best cosmetics for a subject where folk >> have expressed concern of discussion suppression. >> > > This seems like an argument that really proves too much. Suppose someone > wanted to discuss the US presidential election on the IETF list and then > expressed concern over discussion suppression, would that mean it was bad > optics to suggest that the IETF list wasn't the best place? > Maybe a better argument is that 4 members of the ISOC board are appointed by the IETF. (https://www.internetsociety.org/board-of-trustees/) A public web page (n.b. not a "discussion") detailing the bidding process seems like something the IETF might reasonably expect from its board members. thanks, Rob --000000000000164651059c5f141c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 2:36 PM Eric Resc= orla <ekr@rtfm.com> wrote:


On Fri, Jan 17, 2020= at 2:03 PM Randy Bush <randy@psg.com> wrote:
perhaps "I don't think the IETF list is a good pla= ce to discuss the PIR
transactio" does not have the best cosmetics for a subject where folk<= br> have expressed concern of discussion suppression.

=
This seems like an argument that really proves too much. Suppose= someone wanted to discuss the US presidential election on the IETF list an= d then expressed concern over discussion suppression, would that mean it wa= s bad optics to suggest that the IETF list wasn't the best place?
=

Maybe a better argument is tha= t 4 members of the ISOC board are appointed by the IETF. (https://www.internetsociety.o= rg/board-of-trustees/)

A public web page (n.b.= not a "discussion") detailing the bidding process seems like som= ething the IETF might reasonably expect from its board members.
<= br>
thanks,
Rob
--000000000000164651059c5f141c-- From nobody Fri Jan 17 17:23:47 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BA81200B4 for ; Fri, 17 Jan 2020 17:23:45 -0800 (PST) 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 ARrK4V0G_LKI for ; Fri, 17 Jan 2020 17:23:44 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1B4120091 for ; Fri, 17 Jan 2020 17:23:44 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id c16so23923191oic.3 for ; Fri, 17 Jan 2020 17:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gytKvDbkUs8Ni6KnP+B/2wpAU333FrxzDzRqHBdFrRA=; b=CIdk/RpRQRyEw13whzbZB0FLEWBjZii5sIUvksitdVMxPPsaCr3TJBzNXInMHqG2Fn eC1pZjXm+DcQXvIAaBwtwVhABDDEBETmXk9VpwLVZxBHPL+OA0YcwPSKGbzdyA8fP8at BzhpgV9LYxCvUK8yORKMzhcXxR06R4WpF9d+knugYjVlI3uXKQhtbH3p4wkz46o85gKn JuhHGaiU9LElOe4brV66tWFBJh074qT76o/ekOWOMSr6aeyQIyF31qcdB5MEG/72jivc iEQgqthZZHKZmfEgoO/FuG4+ZVIP+lzK0x6edG0lpJYi3UuBgB0eIt8Koyf4w8h9XXi2 GuSg== 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=gytKvDbkUs8Ni6KnP+B/2wpAU333FrxzDzRqHBdFrRA=; b=OIO7WF3OIhHp+Jkfuy8hs2h0AML0+skB7Ggh9AKhtXj2+SDyf91b6juqjnJC0fSpTR nJrYVj/jY4bV+x8KxqgbTVQ+W4voPvvBGvVlH54iwk23FfA00cUTsFP/t9UIIMFHvTJS KSUK1vvPvRdcJHSfEBJge2L4taXotriBg+3ptDuM3FUQaNcnKUjKe6hrC07FDcZ89qlT MlrTQxLssoKk9YXvT4BVp+OJe6eqnBWiLsNCzCn7F3jvNqnMvtb9BfAvROC0LoXjqx2x c00yF/FCYJGidJgRTA2YmiEiHFuzQj1+eFE1hAjhAyg625Nkks2RONDC8fCSqfhqmqKx 4r1g== X-Gm-Message-State: APjAAAUIdgw3Ws1+4VfE0DnD6XlrAjEAyIPgDNDov2I9tLcagEbHlSut LD4jnpNyi4WCIme/X65QaUQtILywxWO+/Jp862A= X-Google-Smtp-Source: APXvYqyBDX+yHICRri6/ImcwfczxKcHlqp46bK5+XTBB/pzFreSiEQe43ioJ5vmBe2rA/+98/nCShl2ZtnZzdA9D1VU= X-Received: by 2002:aca:ba88:: with SMTP id k130mr5755909oif.167.1579310623316; Fri, 17 Jan 2020 17:23:43 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: From: Ted Hardie Date: Fri, 17 Jan 2020 17:23:17 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Rob Sayre Cc: Eric Rescorla , Andrew Sullivan , IETF Content-Type: multipart/alternative; boundary="000000000000b15e7b059c5fe8c9" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 01:23:46 -0000 --000000000000b15e7b059c5fe8c9 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 4:24 PM Rob Sayre wrote: Maybe a better argument is that 4 members of the ISOC board are appointed > by the IETF. (https://www.internetsociety.org/board-of-trustees/) > > A public web page (n.b. not a "discussion") detailing the bidding process > seems like something the IETF might reasonably expect from its board > members. > It's important to note that while different groups make appointments to the Board, Internet Society Trustees do not represent specific constituencies after elections. Each Trustees serves the organization as a whole. Whatever expectations you have of the board, you should have them of all of them, not simply those appointed by the IETF. I do note that Gonzalo, Richard, and Mike have each written about the sale: https://www.internetsociety.org/blog/2019/12/the-sale-of-pir-the-internet-society-board-perspective/ http://www.circleid.com/posts/20191127_why_i_voted_to_sell_org/ https://www.keypointsabout.org/blog/heres-how-we-can-truly-savedotorg In general, https://www.keypointsabout.org/ appears to be the web site you are looking for, as it describes the board and supporters position. regards, Ted Hardie (No hats being worn) > --000000000000b15e7b059c5fe8c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 4:24 PM Rob Sayre= <sayrer@gmail.com= > wrote:

Maybe a better argument is that 4 = members of the ISOC board are appointed by the IETF. (https://www.int= ernetsociety.org/board-of-trustees/)

A public = web page (n.b. not a "discussion") detailing the bidding process = seems like something the IETF might reasonably expect from its board member= s.

It's important to note that while different groups mak= e appointments to the Board, Internet Society Trustees do not represent spe= cific constituencies after elections.=C2=A0 Each Trustees serves the organi= zation as a whole.=C2=A0=C2=A0 Whatever expectations you have of the board,= you should have them of all of them, not simply those appointed by the IET= F.

I d= o note that Gonzalo, Richard, and Mike have each written about the sale:

https://www.internetsociet= y.org/blog/2019/12/the-sale-of-pir-the-internet-society-board-perspective/<= /a>

http://www.circleid.com/posts/20191127_why_i_voted_to_sell= _org/

https://www.keypointsabout.org/blog/heres-how-we-can-truly-saved= otorg

In general, https://www.keypointsabout.org/ appears to be the web site y= ou are looking for, as it describes the board and supporters position.

regards,

Ted Hardie
(No hats being worn)
--000000000000b15e7b059c5fe8c9-- From nobody Fri Jan 17 17:37:30 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81F31200B8 for ; Fri, 17 Jan 2020 17:37:28 -0800 (PST) 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 3FApi8VMUxjW for ; Fri, 17 Jan 2020 17:37:27 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 1A2B7120091 for ; Fri, 17 Jan 2020 17:37:27 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id n11so27996894iom.9 for ; Fri, 17 Jan 2020 17:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DGKP3i1kLlwtjwbjSdejZbfEk7obW6Obwc33PLej3Sc=; b=uEQIM4gtub/yxCh+cftj2g9KXyHOMJoLL9sR1YfosfOKZ7PSHCJ45XVW5eBaZ8IZT2 WZAmHu0UFz4rBXFGBnBf3SuxPeUGi5/A5xYTDhA9+P8mEMA9ef3JooSZQG7Wy9Y/XzEm 9nlmFH47yyW7+Mt0N5EqYqy3W8fEcBvqc92QqL+ompLU4UlshnadlRiTIJaQRB7Z0g69 dxpGjnZPueY7srm9yrCAM5iM699w2UETBvXJcyqgyfxkit6YkdZUe72E6z7k1sJVXmIO NR++NP8EHg0fF66OUqLkevB+axTBR32Fxt3/6jvdIh4pzTsZ2bUiAByURhDxup12Fo99 5Zvg== 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=DGKP3i1kLlwtjwbjSdejZbfEk7obW6Obwc33PLej3Sc=; b=pFYzDzAqZcvIiAv3rRJlHJyNG5jZbONaUKvmYADxX3JTrMRlYSr0dJh0MQCOGKHqkD IKoqXHmj1g2tYtUO6HL1J9wcexTFGEYk+WqvpoFmShXXsPZIlnIBZYqbHqoTXWpsodEk Pg2jy3s+C9SnEt51QLzggd+7TSY35b3xGCVDtnVh6ylZkmui67F+FKnM4xu5f3phhZ7B 8ZpKlMTYZOVsAOcY7RTAde8hfHXlsOWss5+zvN5SD6wcLvB2bP1gcpsanymVpY6JsFSp kfCtJc6iBgC43bd31NmbuJhXRq485XcXQHLHQ6LwCKVzgeFnQMbb6UEh4ADDOR4pl6t/ 3jYQ== X-Gm-Message-State: APjAAAU2OB7e6ZrrYGNZ1RBYg46ofuCXUZx5wQe2L2iS24/L1OFlyxm/ w+gy46Irh/Tsg/mZF1LaLNxeIi31IHJvZbJXw+0= X-Google-Smtp-Source: APXvYqzLN0Gce1l5cnf4H2yImAg+V66zyDPtLiRzt0MK8hSvd5jV3U+WExysKe6zfGpzPxhMgv0Htg0cLMetRCrrDPs= X-Received: by 2002:a6b:731a:: with SMTP id e26mr32641199ioh.254.1579311446149; Fri, 17 Jan 2020 17:37:26 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: From: Rob Sayre Date: Fri, 17 Jan 2020 17:37:14 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Ted Hardie Cc: Eric Rescorla , Andrew Sullivan , IETF Content-Type: multipart/alternative; boundary="000000000000bccfb1059c60195a" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 01:37:29 -0000 --000000000000bccfb1059c60195a Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie wrote: > > In general, https://www.keypointsabout.org/ appears to be the web site > you are looking for, as it describes the board and supporters position. > Not really. There is a bullet point on https://www.keypointsabout.org/facts that says: "The Internet Society did not believe that the other offers would have been advantageous to the Internet Society or its work, so as to merit serious consideration of a sale." But there's no indication that they actually publicly put .org up for sale. thanks, Rob --000000000000bccfb1059c60195a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 5:23 PM Ted Hardi= e <ted.ietf@gmail.com> wrot= e:

In general, = https://www.k= eypointsabout.org/ appears to be the web site you are looking for, as i= t describes the board and supporters position.

Not really. There is a bullet point on=C2=A0https://www.keypointsabout.org/facts = that says:

"The Internet Society did not beli= eve that the other offers would have been advantageous to the Internet Soci= ety or its work, so as to merit serious consideration of a sale."

But there's no indication that they actually publi= cly=C2=A0put .org up for=C2=A0sale.

thanks,
<= div>Rob

--000000000000bccfb1059c60195a-- From nobody Fri Jan 17 17:54:28 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1AF1200C1 for ; Fri, 17 Jan 2020 17:54:26 -0800 (PST) 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 raZ9zdYlHXNE for ; Fri, 17 Jan 2020 17:54:25 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 371C41200BA for ; Fri, 17 Jan 2020 17:54:25 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id p8so22825499iln.12 for ; Fri, 17 Jan 2020 17:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4fzX1KZ7OGXe5oFOFoezlZ3JOJ7BkOGSONv1demPElE=; b=VksjUMEq5Z46BrryIhc81AgdBMQUCtAlBJzZdx/bW/arNVRtU/EHOx090zOd5hg9W/ uXoLwnxroY1WoREKK5HfMeU40gDemajbVHJ/vZIMQwF03FFh40kyzcYo9hHTzZIOeGS6 zvtJjIb64oliL4r3Na3YjWCd+RIit39DXoRgQajjzDDJqJ2fa3XsZ9dk9W4TseQpmFK4 fLk6migg1gxy4M9VhixSIHropDXzeJGHjiVBIzLCSsuqkFjku1RipQzTq6CpESYhKcPT qc+KJGBaj9Ph2bZS930UGGI84UJg0ZtAjbCnSEVMRjAylpKFl47nrqJUnUxRNZN9A+u0 oJxw== 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=4fzX1KZ7OGXe5oFOFoezlZ3JOJ7BkOGSONv1demPElE=; b=rluSAW1+Dj0trzNl8HcryMVskIbhvxH7asHn17yPE1JJ1dCBBMX9KTR9+BWJN1KYwr zLqFFUEsTBMgnBbGIF7r//v0k+eCgwyrmMVDvjgj4ZX0bcPlMhCMnHjcTSjfzxYAKBWO xPktI5dfAnzkZmgPPe8LF5GNN8lvbRv+cblWgAj3i0pHX/4kUZLLT4EaWO9/1bsApIvI ZUJaukhscNSbvDPONo4kT63Z6WE9XCrsD1p3QLCFZBL43Mbun6UYu9B6as4aVmAi2g6E wJL82W5iXYysiKpQapoW5oQAcAMF2vtzwR+NAvibXdrJF/YlM+u1HRx9n+twY6YF8lt1 iubw== X-Gm-Message-State: APjAAAVP6uaWhpriDDCvAfzV+pr7CBZYm6uY57KbI4FMtPI6U4CRuR/t QWFn75ASKW0BJVcguJkFmdsxv1+eM2eLmTFc9kw= X-Google-Smtp-Source: APXvYqx4Z7udQwUZtwJ0OJ+aNhGHuZA2YoY2D2wvgzB8WHAtVjFxuve1cl2kkAoKEvWsOJhgu6o/hRtcR+4IVWEsO+o= X-Received: by 2002:a92:498d:: with SMTP id k13mr1338109ilg.254.1579312464413; Fri, 17 Jan 2020 17:54:24 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: From: Rob Sayre Date: Fri, 17 Jan 2020 17:54:13 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Ted Hardie Cc: Eric Rescorla , Andrew Sullivan , IETF Content-Type: multipart/alternative; boundary="0000000000006e4931059c605611" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 01:54:27 -0000 --0000000000006e4931059c605611 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 5:37 PM Rob Sayre wrote: > On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie wrote: > >> >> In general, https://www.keypointsabout.org/ appears to be the web site >> you are looking for, as it describes the board and supporters position. >> > > Not really. There is a bullet point on > https://www.keypointsabout.org/facts that says: > > "The Internet Society did not believe that the other offers would have > been advantageous to the Internet Society or its work, so as to merit > serious consideration of a sale." > > But there's no indication that they actually publicly put .org up for sale. > Ah, that's actually in there too. "When Ethos originally approached the Internet Society with its proposal, Ethos made it clear it was not interested in participating in a long drawn-out process, and requested that the Internet Society keep its proposal confidential." Seems totally normal. thanks, Rob --0000000000006e4931059c605611 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 17, 2020 at 5:37 PM Rob S= ayre <sayrer@gmail.com> wrote= :
On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie <ted.ietf@gmail.com>= wrote:

In gene= ral, https://= www.keypointsabout.org/ appears to be the web site you are looking for,= as it describes the board and supporters position.

Not really. There is a bullet point on=C2=A0https://www.keypoi= ntsabout.org/facts that says:

"The Intern= et Society did not believe that the other offers would have been advantageo= us to the Internet Society or its work, so as to merit serious consideratio= n of a sale."

But there's no indication t= hat they actually publicly=C2=A0put .org up for=C2=A0sale.

Ah, that's actually in there too.

"When Ethos originally approached the Internet S= ociety with its proposal, Ethos made it clear it was not interested in part= icipating in a long drawn-out process, and requested that the Internet Soci= ety keep its proposal confidential."

Seems to= tally normal.

thanks,
Rob
=C2= =A0
--0000000000006e4931059c605611-- From nobody Fri Jan 17 19:33:51 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0F61200FF for ; Fri, 17 Jan 2020 19:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx5L1O2w_pXk for ; Fri, 17 Jan 2020 19:33:43 -0800 (PST) Received: from mmiller-44677.local (c-24-8-164-51.hsd1.co.comcast.net [24.8.164.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id EBB17120041 for ; Fri, 17 Jan 2020 19:33:42 -0800 (PST) Subject: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] To: IETF discussion list References: From: Sergeant-at-Arms Message-ID: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> Date: Fri, 17 Jan 2020 20:33:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 03:33:50 -0000 Hi all, We wanted to let the list know that the sergeant-at-arms (SAA) team (described in more detail at [1]) consider this thread [2] to be more appropriate for the ISOC internet-policy[3][4]. And as per the IETF discussion list charter [5], we suggest that the discussions should be moved to the more specific forum identified. Thanks, Matthew Miller on behalf of the SAA team [1] https://www.ietf.org/how/lists/discussion/ [2] https://mailarchive.ietf.org/arch/msg/ietf/mgDAvVJ96bwvwCGz80Ww2eVunfI [3] https://portal.isoc.org [4] Instructions to join detailed in < https://mailarchive.ietf.org/arch/msg/ietf/tow2sscnj5bK5GKA97vv-rzu-CI > [5] https://tools.ietf.org/html/rfc3005 From nobody Fri Jan 17 20:33:55 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760831200BA for ; Fri, 17 Jan 2020 20:33:54 -0800 (PST) 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 OjJJ0kJez5Av for ; Fri, 17 Jan 2020 20:33:53 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 142F612004A for ; Fri, 17 Jan 2020 20:33:53 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id t8so23041593iln.4 for ; Fri, 17 Jan 2020 20:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YUXxXFVKMFdg3/qWga69gv8ObylUsh1ziChvidOmU1w=; b=eyPvEYkauwjxUzdnWENpwApWH+zTqXIj8ufsQF7SOsxiezwN3iVW+UEBwUOoNYOu0r 4dfaevThgkj0QDFTGang9XfK9F6V9sGLHMhbeU3GHepJ/uaOls0DK3wHeKCRb591JYva Tl/90wnVyiBYoSXqID6e3+de7qsH8AFgSovY5a/O5ID0FbhPWxjD9FbXVjKMluu2UcPi PJuk3Q47+YaegkDmfxehvVZwCVeTsGOyNiOJlwdTNHD5wjOqX/AceWx5o87wmz+7t1my bt3LtCI8Iz3dXlgi4CXaDwcmQhvnfp/Znfuwam3jmInPBcdQqBXeqWs98taFxR8Qspm6 BW3w== 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=YUXxXFVKMFdg3/qWga69gv8ObylUsh1ziChvidOmU1w=; b=Vw9/OCQhzAxLhRg+NMh8ivCh2ex3xfO2pZ7N7KF7bNkAyCWF6hT5hR6AwvqyQEFwNo gIWNrRoF0Sch3abh4fcQpaWT8u61PKe4BA2D9KyQeZSrhnIECQTi8MsLknmYHjGT/IeN 8JRYpc00gNUYFl0wHgc3dEnfTeo9thOx7LDpCMzUMVpOsRs/m116w4WsK1XrkPrVIOQM GXIUUIrVoF5Z6RW0oigCmdsShc3QO39mkWlpy0ZBn2qE9A22ubdurdSo4w1HWYXVfHft DvxUVZKiwYBTv37kMd2TFricOE1ORxJIS3fkhIDwkt5VLWt3Fvj89h4Sw0O4jfbe3zVE fGOQ== X-Gm-Message-State: APjAAAWempNucUMRW16vhFZVEILwEVURljQjzxn1MkhEWW0mACrULQv/ gbs2xnHCvFLC13MvCEfn+2KD4BR68LPIBdztOUg= X-Google-Smtp-Source: APXvYqz6ELKWdpfalrNUQw7GxqJ5lHE+6NTGkj5iHIXQeJuGFmoRxUEOgw3xUJnfdpn6gJYzgAk7ns5bQxGAnBo+bxU= X-Received: by 2002:a92:498d:: with SMTP id k13mr1698859ilg.254.1579322032292; Fri, 17 Jan 2020 20:33:52 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: From: Rob Sayre Date: Fri, 17 Jan 2020 20:33:40 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Ted Hardie Cc: Eric Rescorla , Andrew Sullivan , IETF Content-Type: multipart/alternative; boundary="000000000000b88932059c629096" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 04:33:55 -0000 --000000000000b88932059c629096 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie wrote: > > It's important to note that while different groups make appointments to > the Board, Internet Society Trustees do not represent specific > constituencies after elections. Each Trustees serves the organization as a > whole. Whatever expectations you have of the board, you should have them > of all of them, not simply those appointed by the IETF. > Thank you for your opinion. It seems a bit strained to insist that appointees don't represent those who appointed them, but I would like to know more about this view. thanks, Rob --000000000000b88932059c629096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 5:23 PM Ted Hardi= e <ted.ietf@gmail.com> wrot= e:
=
It's important to note that while = different groups make appointments to the Board, Internet Society Trustees = do not represent specific constituencies after elections.=C2=A0 Each Truste= es serves the organization as a whole.=C2=A0=C2=A0 Whatever expectations yo= u have of the board, you should have them of all of them, not simply those = appointed by the IETF.

Th= ank you for your opinion. It seems a bit strained to insist that appointees= don't represent those who appointed them, but I would like to know mor= e about this view.

thanks,
Rob=C2=A0
--000000000000b88932059c629096-- From nobody Fri Jan 17 22:11:26 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874551200B8 for ; Fri, 17 Jan 2020 22:11:25 -0800 (PST) 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 yR_Qe3s2FVg7 for ; Fri, 17 Jan 2020 22:11:23 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 A52E1120058 for ; Fri, 17 Jan 2020 22:11:23 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id r9so24469312otp.13 for ; Fri, 17 Jan 2020 22:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OyrJYTgipkHzdv9MN3uV3p2UnsJMa9/+Mpx/9HDf8Ow=; b=omXBu09IOM1h6R3+j513CZdE0hGXYGhVMltECQF9N1YKfk5Ohjdx4Xfd5xQ1fCSE0p IdWkIzaj3TjVsccO65nkoK9IEfnhUSsimH3dSFzg5fEu0JrA1dSXPrvaipAp+2/215Q7 juhPdCszRsn3GqfVwf48rsa6dnYFIVJBjrC0Hw6lFIsIQsSSwrjeJJwzKwkOTeNRVc7d ilSJvqMsHbF5FpwNE6iyVimSXoZAaQmlnHL/kWMjmGF/hEaoXTC6D4YYr/d8FlbbCoul cnV5DwL5/cx+qCkLIypFe8lOheVHMoeuHFM8mknBOpo+I+Pf3XN2EvxX4uIGM3chmRoh s5Tg== 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=OyrJYTgipkHzdv9MN3uV3p2UnsJMa9/+Mpx/9HDf8Ow=; b=H/lXvojz9zaoI8fdmnENPCWBrd5aDwN7a8pt4q2TP1/sWFlAOUe9H013CUqMgf2UVJ HNLW4G7EbOFKr7DJCZCqACFu3iTm1hDs5Sji3xIBksUfQTzEFzy2kQOhSk2A+MpcFhvf i7XzFN4MN+NG+w3LcyJM1pmZgTe5y2WGPSrGsWyzF4uvJkjlY4etp6VxSXfm9eTbnbZk dh+eKg0Kdi6TBV7deGOT7DjKla3E/6m5z9CefvKpRpH89LnruuPaNiXd6F4t5wlXOJPF jqbjr7T9sauARXNwV4oedGA5TL/kG4NAbQZ4A/9kPzmDXr4lzwU17aH7MYaoh+OBoYBv tObA== X-Gm-Message-State: APjAAAWjqBKqDA5+66m2rTDqphxBoy3cVOam2DgvQMR1nG3fErYHtIQ7 fff40jdcS1zZ0YPiDogDTAdyU3ZA8s70WlTAJUA= X-Google-Smtp-Source: APXvYqxhSUDrlKBOFtElIt0PTe59imdHUfYz1SWdDssKrGeJyKY8zUMfUv/pxLNlpthOtDLbCoLN3hG6Kos9u+kLf1k= X-Received: by 2002:a9d:6f0d:: with SMTP id n13mr9074490otq.165.1579327882882; Fri, 17 Jan 2020 22:11:22 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> In-Reply-To: From: Ted Hardie Date: Fri, 17 Jan 2020 22:10:52 -0800 Message-ID: Subject: Re: .org sale - bidding process To: Rob Sayre Cc: Eric Rescorla , Andrew Sullivan , IETF Content-Type: multipart/alternative; boundary="00000000000071726e059c63ed2a" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 06:11:26 -0000 --00000000000071726e059c63ed2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mobile, brief, on-line. On Fri, Jan 17, 2020, 8:33 PM Rob Sayre wrote: > On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie wrote: > >> >> It's important to note that while different groups make appointments to >> the Board, Internet Society Trustees do not represent specific >> constituencies after elections. Each Trustees serves the organization a= s a >> whole. Whatever expectations you have of the board, you should have th= em >> of all of them, not simply those appointed by the IETF. >> > > Thank you for your opinion. It seems a bit strained to insist that > appointees don't represent those who appointed them, but I would like to > know more about this view. > The bylaws make this clear in Section 2, before describing the selection processes: The affairs of the Society shall be directed by the Board of Trustees (the =E2=80=9CBoard=E2=80=9D). The Board shall consist of not fewer than three (= 3) and not more than fifteen (15) voting Trustees. Trustees serve in the interest of the Internet Society as a whole. With the exception of the President, all Trustees shall be elected or otherwise appointed as follows: > Regards, Ted > > thanks, > Rob > --00000000000071726e059c63ed2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mobile, brief, on-line.

On Fri, Jan 17, 2020, 8:33 PM R= ob Sayre <sayrer@gmail.com> w= rote:
On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie <ted.ietf@gmail.com&= gt; wrote:

It's important to note tha= t while different groups make appointments to the Board, Internet Society T= rustees do not represent specific constituencies after elections.=C2=A0 Eac= h Trustees serves the organization as a whole.=C2=A0=C2=A0 Whatever expecta= tions you have of the board, you should have them of all of them, not simpl= y those appointed by the IETF.

Thank you for your opinion. It seems a bit strained to insist that ap= pointees don't represent those who appointed them, but I would like to = know more about this view.
<= /div>

The bylaws make this cle= ar in Section 2, before describing the selection processes:

The affairs of the Society shall be directed by the B= oard of Trustees (the =E2=80=9CBoard=E2=80=9D). The Board shall consist of = not fewer than three (3) and not more than fifteen (15) voting Trustees.

Trustees serve = in the interest of the Internet Society as a whole. With the exception of t= he President, all Trustees shall be elected or otherwise appointed as follo= ws:

=


=

Regards,

Ted

thanks,
<= div>Rob=C2=A0
--00000000000071726e059c63ed2a-- From nobody Fri Jan 17 22:58:19 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96E1200C5 for ; Fri, 17 Jan 2020 22:58:17 -0800 (PST) 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 Nz0REJi733y1 for ; Fri, 17 Jan 2020 22:58:14 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 C6788120058 for ; Fri, 17 Jan 2020 22:58:14 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id x1so28399195iop.7 for ; Fri, 17 Jan 2020 22:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=axtGjxh4tbQyCZuUUMxrX9d/GMqZ/edTx4Kye9/DfCA=; b=Dl5M08U89U1SY4BTYhsu9LZXhxQhnCCbZWKGP7DSgpjxExE8Ri5WWG+q8S7ROrcwSH 3fDCodrUDMA2crjMXyrABomHJQEM4DEgFkmNRYhBSoD/5jAAj0BAXgEkY9xK3Dl8fxNx /3NpjZXpUiBimbbUIJ2qcSbTC4+nyMz+xOA1V5cFQhkuQDagu2TaO589W3lJnWGRFyea I4wW2bCXwvj/uhjW09SrvuPFQl8GGpytkItSwRKyQQsekhtSfaTl+PHa3ddo5jU+95+S HYqRHx96yBX0lPgyCSze6J7A9xVTpC0TjXz46XGBZIpAQMJvEaJtHloyioZyKed5s2+v zbow== 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; bh=axtGjxh4tbQyCZuUUMxrX9d/GMqZ/edTx4Kye9/DfCA=; b=A8nGbYl9ipuTPE/oYSu/Y0erQEoSQsGKT0vFNt4CMMkGHvhl4NP2KBJLHDHipFEqkt Uob0Ln5dmLq5Jj0+S+xl/4rO1+cuXOUWZWva+U24QQ7cKfYQ82A3FcwEiVUJEQg/Xykd j/+PdwEjfwjDCo4celva342DDnC23J8s6nm4EWGcJnzpgL5cGMob0ZfUA+FVCIV/xzKb nj6GMbq4CTs2Df8WARRmbp7JrKGWGLDVfxINxtZPh9cs5KQfL7/iT0PALe6MFTLeAhzn INPVOeUetnYtvACApVBMof4gtcx/f+48Xgy4Jky8T6dL3ghi74fRpbS6l63oThALCx3i XQeg== X-Gm-Message-State: APjAAAVhF6epzZuIrhr5PJc99GH1Zk4u9stnq7tnCupxVf4Ua1yAyaJe rmWhTemfiyogqMSVaL85Wiro3kd10hb277U/M3nMzGws X-Google-Smtp-Source: APXvYqyERFUP4b9cJhQXrzt6HNcO2rlV6BgvHTrbpMZpf51YzaI5gFs0Sf5W8bU83QfI3KBRWNZybh7SaLj0TMkmH98= X-Received: by 2002:a6b:ec08:: with SMTP id c8mr34134898ioh.257.1579330693725; Fri, 17 Jan 2020 22:58:13 -0800 (PST) MIME-Version: 1.0 References: <20200117174531.tzvaerhqtkwzkxhj@mx4.yitter.info> <5817ea6f-839c-a92b-26b6-83f96a665769@gmail.com> In-Reply-To: <5817ea6f-839c-a92b-26b6-83f96a665769@gmail.com> From: Rob Sayre Date: Fri, 17 Jan 2020 22:58:02 -0800 Message-ID: Subject: Fwd: .org sale - bidding process To: IETF discussion list Content-Type: multipart/alternative; boundary="000000000000fb8590059c64949c" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 06:58:18 -0000 --000000000000fb8590059c64949c Content-Type: text/plain; charset="UTF-8" [with permission to forward] ---------- Forwarded message --------- From: Brian E Carpenter Date: Fri, Jan 17, 2020 at 10:12 PM Subject: Re: .org sale - bidding process To: Rob Sayre , Ted Hardie Cc: Andrew Sullivan Off list, because not an IETF issue. On 18-Jan-20 17:33, Rob Sayre wrote: > On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie > wrote: > > > It's important to note that while different groups make appointments to the Board, Internet Society Trustees do not represent specific constituencies after elections. Each Trustees serves the organization as a whole. Whatever expectations you have of the board, you should have them of all of them, not simply those appointed by the IETF. > > > Thank you for your opinion. It seems a bit strained to insist that appointees don't represent those who appointed them, but I would like to know more about this view. It isn't in the least strained; it's Serving on a Non-Profit Board 101. Of course we're all human, and I worked for IBM when I was on the ISOC Board, so I'm sure that this influenced my point of view. But IBM's point of view in ISOC matters was conveyed by IBM's member of the ISOC Advisory Council, which was not me. In fact that is exactly why the Advisory Council was created - so that the Organizational Members, who paid substantial dues, had a formal (but *advisory*) role. As far as I can see that is still the case: https://www.internetsociety.org/about-internet-society/organization-members/omac/ At that time (before PIR existed), the organizational members were ISOC's only source of income**, but even so they had no votes on the Board. For the record, ISOC had no COI policy for Board members until sometime during my tenure as Board Chair. I was a bit shocked that it had been overlooked, but perhaps the world was a softer, kinder place then. ** At that time, too, individual members paid annual dues, but that cost more to administer than it yielded, so it was a dead loss. Regards Brian --000000000000fb8590059c64949c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

[with permission to forward]

---------- Forwar= ded message ---------
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Dat= e: Fri, Jan 17, 2020 at 10:12 PM
Subject: Re: .org sale - bidding proces= s
To: Rob Sayre <sayrer@gmail.com= >, Ted Hardie <ted.ietf@gma= il.com>
Cc: Andrew Sullivan <sullivan@isoc.org>


Off list, because not an IET= F issue.

On 18-Jan-20 17:33, Rob Sayre wrote:
> On Fri, Jan 17, 2020 at 5:23 PM Ted Hardie <ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>= > wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0It's important to note that while different gro= ups make appointments to the Board, Internet Society Trustees do not repres= ent specific constituencies after elections.=C2=A0 Each Trustees serves the= organization as a whole.=C2=A0=C2=A0 Whatever expectations you have of the= board, you should have them of all of them, not simply those appointed by = the IETF.
>
>
> Thank you for your opinion. It seems a bit strained to insist that app= ointees don't represent those who appointed them, but I would like to k= now more about this view.

It isn't in the least strained; it's Serving on a Non-Profit Board = 101. Of course we're all human, and I worked for IBM when I was on the = ISOC Board, so I'm sure that this influenced my point of view. But IBM&= #39;s point of view in ISOC matters was conveyed by IBM's member of the= ISOC Advisory Council, which was not me.

In fact that is exactly why the Advisory Council was created - so that the = Organizational Members, who paid substantial dues, had a formal (but *advis= ory*) role.

As far as I can see that is still the case:
https://www.interne= tsociety.org/about-internet-society/organization-members/omac/

At that time (before PIR existed), the organizational members were ISOC'= ;s only source of income**, but even so they had no votes on the Board.

For the record, ISOC had no COI policy for Board members until sometime dur= ing my tenure as Board Chair. I was a bit shocked that it had been overlook= ed, but perhaps the world was a softer, kinder place then.

** At that time, too, individual members paid annual dues, but that cost mo= re to administer than it yielded, so it was a dead loss.

Regards
=C2=A0 =C2=A0 Brian

--000000000000fb8590059c64949c-- From nobody Sat Jan 18 08:42:55 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E167012003E; Sat, 18 Jan 2020 08:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 iWW2557TXywU; Sat, 18 Jan 2020 08:42:50 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 9721412002F; Sat, 18 Jan 2020 08:42:50 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id c9so25501502wrw.8; Sat, 18 Jan 2020 08:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lkoutahEqMa5bKchdtTytiGOydT7bQl7aflcXKA0QwA=; b=Y9PjpFxyHhzFRauNZfeQmpw8Wq7mfZaOBX/x+5fgXjcqjTYclty+q6qEHU1a0l8Xgc tp3ooBpppHw18Ij0OD5N6sZTgSvPNfHEbckqRuraI0jMmNdBZPzejXgRn4OLb2kKDQ80 iYaCAaW4RK9oNBQ5mE9f5Z/X6G8btrfGIsgXo3Wwxz6lqXAzpAGS2qCWBRnuAel7qBmE TVg6xQo1PSUzQDFQGhyaVW7jaORctADvctSHFd5METB7cHyQPnu5gdC6QFAvg5gRuORN Tn7ALWACeX7MN5iav6JPqnKRBZ76mr6PFfFbhVDpv6nLHXp1/NrKMh85eogoYsJJl2ow ix6A== 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=lkoutahEqMa5bKchdtTytiGOydT7bQl7aflcXKA0QwA=; b=BqZpxLs3+N0fcDeLSvJv3ZPMsJeFN7r1WQd9n9zdrfgJw07zPkQapUC9SGPIlXUj9m m/Ou4LykjS1e/YkWvsrore+vvv3LvzA2+Zlae+9Yk56Qzmrw5+6U4msfx5ecXn7wJpqm kFjOXxJ6+dgzWuwJWM3ga7N5kHfJC8PzJrwWjHaJtnH54DuM4ds5PDh3CbBLEKm3lG4Q yZOK1MbmhGGJeVF4LpssChe7BEiz1/1Hcwaz4wNaxOmuNdN4fHkbZe34KpCyKq03kee1 1Iw/fQmd3XjaHyAkk1B7FWNTMlb5vWb9/xOh0GZYstZqTUsfp3bQZd9YW8Ad0ULV/nzq BG0A== X-Gm-Message-State: APjAAAWcqr1SpC/XP+uBW5Mz6CLQ1f3lfEdcCxIqTGU5UZMAiVG1m0tq TQuNy9N0elxwUa9XkmrhNbpDjdQN X-Google-Smtp-Source: APXvYqz1+A7Hwlgkm9NX+t16UbKzoO6Vr9J4CbkpJYuN2YF5XSRg7ZyVaJdQaxInwFDNTCW4Sa57ZQ== X-Received: by 2002:a5d:5592:: with SMTP id i18mr9772002wrv.55.1579365768255; Sat, 18 Jan 2020 08:42:48 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:3886:b6c2:d6dc:1014? ([2601:647:5a00:ef0b:3886:b6c2:d6dc:1014]) by smtp.gmail.com with ESMTPSA id i10sm39787918wru.16.2020.01.18.08.42.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 08:42:47 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_110624BC-43FA-4239-BBCB-CED89635E131"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] Date: Sat, 18 Jan 2020 08:42:42 -0800 In-Reply-To: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> Cc: Bob Hinden , IETF , Andrew Sullivan To: Sergeant-at-Arms References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 16:42:53 -0000 --Apple-Mail=_110624BC-43FA-4239-BBCB-CED89635E131 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OK, I followed the instructions and added internet-policy to my ISOC = profile. How do I see the discussion, get email, etc.? I am not = seeing anything, nor have received an email with instructions. Bob > On Jan 17, 2020, at 7:33 PM, Sergeant-at-Arms wrote: >=20 > Hi all, >=20 > We wanted to let the list know that the sergeant-at-arms (SAA) team > (described in more detail at [1]) consider this thread [2] to be more > appropriate for the ISOC internet-policy[3][4]. And as per the IETF > discussion list charter [5], we suggest that the discussions should be > moved to the more specific forum identified. >=20 > Thanks, > Matthew Miller on behalf of the SAA team >=20 > [1] https://www.ietf.org/how/lists/discussion/ > [2] = https://mailarchive.ietf.org/arch/msg/ietf/mgDAvVJ96bwvwCGz80Ww2eVunfI > [3] https://portal.isoc.org > [4] Instructions to join detailed in < > https://mailarchive.ietf.org/arch/msg/ietf/tow2sscnj5bK5GKA97vv-rzu-CI = > > [5] https://tools.ietf.org/html/rfc3005 >=20 --Apple-Mail=_110624BC-43FA-4239-BBCB-CED89635E131 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl4jNYIACgkQrut0EXfn u6ikPQgAtvWPB8hEatfGDYQJ+ffNbpUoWP0WcO593hi+9q5l9Ed26HzbOX81XwmB g7wAsHB8aH2W4EhB/Z0irKajaskQW39H92ejwr5Z7BcBGST9qKvix0M340CE1cEg 6QwQ3EYzOvX0c9oj2Dap79OoYY0wofbS1fhqNamYX1nUpbeBm8ZK+BB7DFUgzZh8 SO6YxStncyG2RZanm8YZe2ovBax5W99o76TGBuiFmbCzqIc2sW6H4P51VYwoGISu wUCQtbz1kwaIQlkjruVVvCPvtPgLFz7CMN6v932IpBhLkBqS5mzQgFxDOSUjoY9u G+vvdheGzy8nl569QhyLIfXZAPV9QA== =Bpo+ -----END PGP SIGNATURE----- --Apple-Mail=_110624BC-43FA-4239-BBCB-CED89635E131-- From nobody Sat Jan 18 09:33:08 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B5012003E for ; Sat, 18 Jan 2020 09:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 10wgKTBv0I5R for ; Sat, 18 Jan 2020 09:33:03 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750045.outbound.protection.outlook.com [40.107.75.45]) (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 E29E9120024 for ; Sat, 18 Jan 2020 09:33:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aFdhjW/ZWBB58NEIlsf5nPrV8ISIb/b/fuz4djkEym2f+IyQL3FTXv6AMzRCtmymVZod5ZvYnpZRINCs314Zd92yGxJCrQ4qKb79xyz70E5tXK+iRA1b+IVoVQUYQC7Kq8fVHZIEpyBgeRVcsTnvzJfJGX8B90MG6t0RQY5oqfGQFAaWMucvSol2T2E0alkAt7js5IqnJswx+lIvAJG5O5kGJAXjXtCivVgynyE3aDPNOZG5pqnAkc88VU8EacNa3qK5mTkmI+i3z6nCAnSnSAlVXVZJwe+Rq6HA45Q3cc04rMiuQIn+PhblKVK6Tij6h8poAj+vEF3wJiIM8I5Y+w== 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=QGCYHYG22dmC0pl/hfwEMqX5Y8wrIbuH/nbBl8tJTYA=; b=AymmIUq5fDI0YAG75ml5tHDtuC8jstOsO4y1OYhVmHFePOZFYX3zUr9MbUxC/SvAz1GBvCJQGErFyYRaIo04fgKfTBmuddaHMKPYfANhajJd4b3saa4atSQ8/yRTsZSflOEe8SK36BSpQQNHUBzb4Fr9/OrFKieCv/zDLahlswukiL0+RbVowTVD7lvY/TpGWP9uuC79PjlWNDsLopWwbWl5SB4WW4N46cvSfJ2PKAXQInLlwbLZIQHHThn/mjX9T4MpB6yoEiCl/Wfb3uz4WH8UAbVHOM3Lx8bpr+F9rQkEgqlf9jrRMaed0uLNPAss9u35gD/jCHPQh9hQ48iEQg== 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=QGCYHYG22dmC0pl/hfwEMqX5Y8wrIbuH/nbBl8tJTYA=; b=ZZIKU7vDII4TBhnoYZK9kwFdHDt+u4mubpsRkpwnkQDAOHIkglzzffIop/0naOOvD1P20ypiQPa/XyxRa/6CgrZ8RAaxLycfPI2FQCWYIlm0e23xvNTp7dTVe3VKAUXuKJnrnetUtqKg4BJWCh04uFh2xzoMjO6pxsS78QNhXPU= Received: from BYAPR06MB5175.namprd06.prod.outlook.com (20.178.50.13) by BYAPR06MB4919.namprd06.prod.outlook.com (20.177.127.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Sat, 18 Jan 2020 17:33:00 +0000 Received: from BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0]) by BYAPR06MB5175.namprd06.prod.outlook.com ([fe80::3898:8eab:76b:5fb0%4]) with mapi id 15.20.2644.024; Sat, 18 Jan 2020 17:33:00 +0000 Received: from outlook.office365.com (2607:fea8:760:124:280e:1c6:e79d:7bcc) by YTOPR0101CA0061.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:14::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19 via Frontend Transport; Sat, 18 Jan 2020 17:32:59 +0000 From: Andrew Sullivan To: Bob Hinden , IETF Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] Thread-Topic: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] Thread-Index: AQHVzh5S4n7DbjGNj06l+wmO9Xc656fwrmcA Date: Sat, 18 Jan 2020 17:33:00 +0000 Message-ID: <20200118173254.cebvnhc4kw5eyxcl@outlook.office365.com> References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: YTOPR0101CA0061.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:14::38) To BYAPR06MB5175.namprd06.prod.outlook.com (2603:10b6:a03:ca::13) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sullivan@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2607:fea8:760:124:280e:1c6:e79d:7bcc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ae657ac-da9e-433f-85a7-08d79c3c76b3 x-ms-traffictypediagnostic: BYAPR06MB4919: x-ld-processed: 89f84dfb-7285-4810-bc4d-8b9b5794554f,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(366004)(346002)(376002)(396003)(136003)(189003)(199004)(316002)(6506007)(86362001)(186003)(16526019)(64756008)(66946007)(66476007)(52116002)(110136005)(66446008)(7696005)(66556008)(5660300002)(55016002)(8676002)(9686003)(81156014)(4744005)(8936002)(66574012)(1076003)(71200400001)(6666004)(81166006)(478600001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR06MB4919; H:BYAPR06MB5175.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: Ceq8K3l39IVOKYbQ9CkiAJRCgoLrlBCiFZCdg7GXXWUKAQceQSr1wwwbTM1aOvY9K5RqPzukHPJ+0iGQGby4fYI6troMI7T1tekmfP0W+u9cylkrKRndeDl62rKjWGTzSG8u3ooX7D/mH3UsYp8hJ7K1KKM0gYT4Q+JNV0weWdJoQOx5ZPNd16vN+eZjUKbFA2C4wzCy6rnd0fSGRF4bxErzsbBkcnGVj+TECfTq+kHiWLiXd90r1bLz/1ydQeOQ5QyW6uVk/kD7o5DTS/iJ1qsYjGhQVwM891Zub2R27F3CrTeUUO/lWuJrM2Lzmkyo8bL0ZFr6uRYLGbdYQ60VLEGcm+G/j1KSVpNJvOXkgREmBrKNl8Nq3KJ/CvhlGrsFkNkEjL+0dVcobl+MqmFESHXKtgynDdYzR3uNRvghrRyqT1j41xh5PNwkElT4lZfb x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <654814D5BCE14043ACD1B63C96532CD5@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 9ae657ac-da9e-433f-85a7-08d79c3c76b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2020 17:33:00.1980 (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: C8r9trsc8yXTTKmvNf0WX8SomWADj6UKr/92sRI773XabE9xRgGMiffMD98wLQR3+rGYEKvnI4RwlnSYjb1QTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4919 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 17:33:06 -0000 ISOC hat on. Copying the ietf list because people were apparently relying on instructions I sent and the SAA referred to them. On Sat, Jan 18, 2020 at 08:42:42AM -0800, Bob Hinden wrote: > OK, I followed the instructions and added internet-policy to my ISOC prof= ile. How do I see the discussion, get email, etc.? I am not seeing anyth= ing, nor have received an email with instructions. >=20 If you have added that to your ISOC profile, then you will be subscribed to the list and in due time will see the messages. (One of the unsatisfactory parts of this system is its terrible integration with the actual mailing list manager, which means subscriptions are processed in bulk via cron job. Please don't mail me with your outrage. I know.) Best regards, A --=20 Andrew Sullivan President & CEO, Internet Society sullivan@isoc.org +1 416 731 1261 From nobody Sat Jan 18 11:17:43 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF1C12003E for ; Sat, 18 Jan 2020 11:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 zsZOT6ygXVcU for ; Sat, 18 Jan 2020 11:17:40 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 71BE8120019 for ; Sat, 18 Jan 2020 11:17:40 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id f129so10814441wmf.2 for ; Sat, 18 Jan 2020 11:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uJErRjRnVPNY1QuKbnYbzwGjxOWlGL4AsPYOLNZ6xuY=; b=EMDqGPcgcDdxzFK3jxETbD9tUWE2WqrB5XGj6UCfmp+GiafDJ0FCYpiXMsC7hVaD3S AlW90IUrVjoJSNmr8rigqDDJo102c3roO+culAObvnSzKwT6iCI5r/uisJE48Sm9+1ya oa1fYyxRbp+tEqDggSxl5MAZGN7Ogrqq8sWPS6e97XY1fVD3dvkufOUHyALR+OJcHG5J gq2m+3/R9x9myirk3zQhpxaw15/rnPWswc0F7TkTcR/wfIz8DYT81bSmHsDOUJpJlPpa n27fR8R9vD79P0K4n28R74alU6/FN+ov/uf0gESKeal1rl8qzHP//44j353QhXGLGSur DCcA== 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=uJErRjRnVPNY1QuKbnYbzwGjxOWlGL4AsPYOLNZ6xuY=; b=jX+xgLcENCpr8moznQ1790TdaRl2l8hsstE6eDU2ILFHvAyXJJKVl32PQLCRCQm7xn ul9QC8/PyN/fEzguUtXa5Gs4ZKeDtmCK3f4UXVgY5w5V5mJcVbJAbcg0D1soe6RanBN0 tQPca3rlY4vyqdSru2CX9wRzrl9rfGYyuCAUM4ajmmdGK91kZRAn0xqRnJfvBHU++gXz ahuTFwkjjjaaBOlKjWhNK3NU+pBopH5gzDybAt+hd+dmZpZ2RybLrwXRAe8YDM8Qer0L UU7A2TinxFMT9LEsIruliHHJmtgLvQNUNigoBz7JTtEK8fkFldLEHfExLUujMXSJzaUs d70g== X-Gm-Message-State: APjAAAX56GyIbnjzrRbud/xRCVQb/TbeNSg+uYq+syngaAsFb9qiP4jy tfyt4/Wq3T+UhRwyIUEU0Dk= X-Google-Smtp-Source: APXvYqx+TczCziNfYxcOqLo3o1QGR17jEU0f29qkfvtzYeS/oxuKXuBL7Xvu9OWPzgR3DpIKCCIB9g== X-Received: by 2002:a05:600c:298:: with SMTP id 24mr10696489wmk.141.1579375058996; Sat, 18 Jan 2020 11:17:38 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:3886:b6c2:d6dc:1014? ([2601:647:5a00:ef0b:3886:b6c2:d6dc:1014]) by smtp.gmail.com with ESMTPSA id r15sm6338330wmh.21.2020.01.18.11.17.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 11:17:38 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7221312B-C454-437A-BAC2-39C94D45EC75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] Date: Sat, 18 Jan 2020 11:17:35 -0800 In-Reply-To: <20200118173254.cebvnhc4kw5eyxcl@outlook.office365.com> Cc: Bob Hinden , IETF To: "sullivan@isoc.org" References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> <20200118173254.cebvnhc4kw5eyxcl@outlook.office365.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 19:17:42 -0000 --Apple-Mail=_7221312B-C454-437A-BAC2-39C94D45EC75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 18, 2020, at 9:33 AM, Andrew Sullivan = wrote: >=20 > ISOC hat on. Copying the ietf list because people were apparently > relying on instructions I sent and the SAA referred to them. >=20 > On Sat, Jan 18, 2020 at 08:42:42AM -0800, Bob Hinden wrote: >> OK, I followed the instructions and added internet-policy to my ISOC = profile. How do I see the discussion, get email, etc.? I am not = seeing anything, nor have received an email with instructions. >>=20 >=20 > If you have added that to your ISOC profile, then you will be > subscribed to the list and in due time will see the messages. (One of > the unsatisfactory parts of this system is its terrible integration > with the actual mailing list manager, which means subscriptions are > processed in bulk via cron job. Please don't mail me with your > outrage. I know.) I am now getting email from the list, but as far as I can tell, I never = got a =E2=80=9Cyou are subscribed email=E2=80=9D, nor any info on how to = access the archive. Bob --Apple-Mail=_7221312B-C454-437A-BAC2-39C94D45EC75 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl4jWc8ACgkQrut0EXfn u6ingAgAqMwnQ/o4vWW8lx0v2pcFMiUb7NAJGxRa5MOmnJwuByM7CVdlyLoPueJ1 6EuqdUCjOwjc8iQ59aWRbAFgfJdhK6qcu0O22vrnJwxSjfYSUPBfsfkpXmuxCXL5 G8sje1Orvz2Jh8oa9996Vupm7w3DzWgi3HGH2hRZ40EJTUnhx1OE2BCEXToIs6m8 LRVQvCDUeeKuEMCmD2Lnm/mB+OcjdyMGj5TlFonKJikS5/vzyhjz3fyfN/ax2ymg 5SLGv86Ikw/6F1/Q3TJWaWmMx+99Q69R9tYdaRPAb+gWrghVQ4thCLESGnGKlvTP 8e79yBx3UP/xQSp84de3BZPUtYpW0Q== =QixD -----END PGP SIGNATURE----- --Apple-Mail=_7221312B-C454-437A-BAC2-39C94D45EC75-- From nobody Sat Jan 18 11:25:30 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270312003E for ; Sat, 18 Jan 2020 11:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WtQrGBeEI7PL for ; Sat, 18 Jan 2020 11:25:27 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 59C86120019 for ; Sat, 18 Jan 2020 11:25:27 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id v201so20876822lfa.11 for ; Sat, 18 Jan 2020 11:25:27 -0800 (PST) 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=1mMp1tucQBLttlSq1Sv0bloHfsa6hdR4EseUxde0N+8=; b=zQWm2RLjtrN2ljv4wJZEkfaEGKp5pnRnwOtFeYAbnMMY93OwArJmcNqyc2ameYpf+2 mBIms6RXeydCxhRQowAWxBktKduAT+xLXHixT7J0pbXxB9r9inEaoZKlMdWHaqj402vO NwkcPUhoGX27EwpsBnlbClWj90jTV/Xh1kpQAU+95T5L/i8CbuYImUa+/gTHOCTCJgd7 +1MxNLAShoxQA/BxmIdH3jarIcj10CjphcnMrl0timssdrfAa0R+xf+UgxDqBlPUAztH ku98fg9+3M1x0nfsG/IGL+BK+h/Xm4B0HRh1knwrq7ErtP3R4/l5tnC9siJ5MQInDplY +v9A== 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=1mMp1tucQBLttlSq1Sv0bloHfsa6hdR4EseUxde0N+8=; b=mTtmlXTSQU8sG8Hz18fpNhDXXpaWpusgkxW0iEVUFS5NoRyp1i0F2heUmBeAJV33Wb YvKkuaZNz9zdROcB7BX96f/OIugeZOVl/C8NxN70/CCe3K8Bg9GR+RV+fVgTwB5fgVRW Ty9dJNnmWi8yhcWIYoIben/fxvKvA3HowO+gk8L8gZ9pT8PnySGWB/CDFY6AFWaN4juc lQXBynwyJDBaxH3zs+VwaQORCObePa4vOoQBID/FdsirrA+r7cVX1mkR/sz3Kq+4IQdP bt5QtsA1bLNKHl5GD73FxEW+hPwej/kjMogTKgOZNe9C09Vc0S7RLeuGpOHdjTwQ+rKw nZpg== X-Gm-Message-State: APjAAAXF4GRwQZBkHHUn5exdT3zKljj8eTcCb/74bxY8N9yCxurqB92v lc1s2ynAKhDbTGteyJXTv6+J0xwTqtIRAFoHuv5+Rg== X-Google-Smtp-Source: APXvYqxCxacV0GZumQvaGD+6fClfLIQfvDDmHT6C6ieeGx7g0VlmbesumR7693vZsyp510o1RqxMzIdw3tGaOYaI7aQ= X-Received: by 2002:a19:7502:: with SMTP id y2mr8881502lfe.55.1579375525640; Sat, 18 Jan 2020 11:25:25 -0800 (PST) MIME-Version: 1.0 References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> <20200118173254.cebvnhc4kw5eyxcl@outlook.office365.com> In-Reply-To: From: Eric Rescorla Date: Sat, 18 Jan 2020 11:24:49 -0800 Message-ID: Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] To: Bob Hinden Cc: "sullivan@isoc.org" , IETF Content-Type: multipart/alternative; boundary="0000000000002c7dc2059c6f0521" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 19:25:29 -0000 --0000000000002c7dc2059c6f0521 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Me neither On Sat, Jan 18, 2020 at 11:18 AM Bob Hinden wrote: > > > > On Jan 18, 2020, at 9:33 AM, Andrew Sullivan wrote: > > > > ISOC hat on. Copying the ietf list because people were apparently > > relying on instructions I sent and the SAA referred to them. > > > > On Sat, Jan 18, 2020 at 08:42:42AM -0800, Bob Hinden wrote: > >> OK, I followed the instructions and added internet-policy to my ISOC > profile. How do I see the discussion, get email, etc.? I am not seeing > anything, nor have received an email with instructions. > >> > > > > If you have added that to your ISOC profile, then you will be > > subscribed to the list and in due time will see the messages. (One of > > the unsatisfactory parts of this system is its terrible integration > > with the actual mailing list manager, which means subscriptions are > > processed in bulk via cron job. Please don't mail me with your > > outrage. I know.) > > I am now getting email from the list, but as far as I can tell, I never > got a =E2=80=9Cyou are subscribed email=E2=80=9D, nor any info on how to = access the archive. > > Bob > > > --0000000000002c7dc2059c6f0521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Me neither

On Sat, Jan 18, 2020 at 11:18 AM Bob Hinden = <bob.hinden@gmail.com> wr= ote:


> On Jan 18, 2020, at 9:33 AM, Andrew Sullivan <sullivan@isoc.org> wrote:
>
> ISOC hat on.=C2=A0 Copying the ietf list because people were apparentl= y
> relying on instructions I sent and the SAA referred to them.
>
> On Sat, Jan 18, 2020 at 08:42:42AM -0800, Bob Hinden wrote:
>> OK, I followed the instructions and added internet-policy to my IS= OC profile.=C2=A0 =C2=A0How do I see the discussion, get email, etc.?=C2=A0= I am not seeing anything, nor have received an email with instructions. >>
>
> If you have added that to your ISOC profile, then you will be
> subscribed to the list and in due time will see the messages.=C2=A0 (O= ne of
> the unsatisfactory parts of this system is its terrible integration > with the actual mailing list manager, which means subscriptions are > processed in bulk via cron job.=C2=A0 Please don't mail me with yo= ur
> outrage.=C2=A0 I know.)

I am now getting email from the list, but as far as I can tell, I never got= a =E2=80=9Cyou are subscribed email=E2=80=9D, nor any info on how to acces= s the archive.

Bob


--0000000000002c7dc2059c6f0521-- From nobody Sat Jan 18 11:52:47 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3176120043 for ; Sat, 18 Jan 2020 11:52:45 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl header.b=EqfXpQ8I; dkim=pass (1024-bit key) header.d=nlnetlabs.nl header.b=EnCSalDF 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 WzEXMdXGukss for ; Sat, 18 Jan 2020 11:52:44 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 92C45120019 for ; Sat, 18 Jan 2020 11:52:44 -0800 (PST) Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 03ABB19942; Sat, 18 Jan 2020 20:52:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1579377163; bh=phuYbikM3cLEoUS5LaP9hpPT9y7Yv7CqStijukL3Ywk=; h=To:cc:Subject:From:In-reply-to:References:Date; b=EqfXpQ8IcaHRQhI/UuxX3B19oRspKT1ifVBh0SmvsyI2RAP+uDqbznuiJXdA7h5QQ cBY5niZA3oWJ5tFbY69bSpqOtVjHy5rgptIpvpz5fKomcUxVWOCwUCjjnQqnbr5Yg2 ZgehN7b8Cd30uUL26U6OCQQb/0NhHVgxzIFmM4MU= Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id 8033D1993F; Sat, 18 Jan 2020 20:52:42 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=NLnetLabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=jaap@NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1579377162; bh=phuYbikM3cLEoUS5LaP9hpPT9y7Yv7CqStijukL3Ywk=; h=To:cc:Subject:From:In-reply-to:References:Date; b=EnCSalDF+opK6FOAwbz8BfhRtl3CLfzpHsvMcy6tNTqu58r61SftMoSmG++1Ls300 ldttJvRMfWvZredIjwE7QMJo4OrYupEp41rfzCYubTrB45UTtLpYbf2YJHlh6Q5ScG l004zg/u31M8d8sihvGyBUr3GPA+Hbo23xRO+1N0= Received: from bela.nlnetlabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.15.2/8.15.2) with ESMTPS id 00IJqfOU052608 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Jan 2020 20:52:42 +0100 (CET) (envelope-from jaap@NLnetLabs.nl) Received: from bela.nlnetlabs.nl (jaap@localhost) by bela.nlnetlabs.nl (8.15.2/8.15.2/Submit) with ESMTP id 00IJqf7t052605; Sat, 18 Jan 2020 20:52:41 +0100 (CET) (envelope-from jaap@NLnetLabs.nl) Message-Id: <202001181952.00IJqf7t052605@bela.nlnetlabs.nl> X-Authentication-Warning: bela.nlnetlabs.nl: jaap owned process doing -bs To: Bob Hinden cc: "sullivan@isoc.org" , IETF Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] From: Jaap Akkerhuis In-reply-to: References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> <20200118173254.cebvnhc4kw5eyxcl@outlook.office365.com> Comments: In-reply-to Bob Hinden message dated "Sat, 18 Jan 2020 11:17:35 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52603.1579377161.1@bela.nlnetlabs.nl> Date: Sat, 18 Jan 2020 20:52:41 +0100 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 19:52:46 -0000 Bob Hinden writes: > nor any info on how to access the archive. The usual way: https://elists.isoc.org/mailman/private/internetpolicy/ jaap From nobody Sat Jan 18 12:37:09 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E36120024 for ; Sat, 18 Jan 2020 12:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 8dlG8C36FClu for ; Sat, 18 Jan 2020 12:37:06 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995E8120019 for ; Sat, 18 Jan 2020 12:37:06 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id d15so4801817pjw.1 for ; Sat, 18 Jan 2020 12:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gSYCSYTUq55sS4f4BAmafNlCIcfRrx3MmlF0P+QX1H4=; b=tlZm33QGGJHysOMBzhcshiJmk5mykWFiylWFgNgpTQV5xHtENYL9KLuqUGInao4M/a h3dCa2z01q9aO9NTHSIxjqwqosDRRf2eViI82gTf8Kd4/wqci9t1jMmTexM6H5M32eU4 Dap5b0RdBOh+JtsMEaPjLXW7vxUdMAFKIFuX3Jx7t+kBw2aQmeo2w6TUGxcy6Qv7LGWa ORF7vtCSo/IPrACMAJJCe+jQRlrKjyBpiVdZaM8+EzhsUburBwNrUGQEw8Pt0jY/t94g 5dCfj/dN86FW2dltKvBmI/WQpvbdGne/NX52r0NtTl8e7/XldUy2mzaCve9GI4S3FJ16 OY4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gSYCSYTUq55sS4f4BAmafNlCIcfRrx3MmlF0P+QX1H4=; b=lnJDcdlRHuARQQ55LPum4bxJz6zQ4kFxxAzvMoStMmAOgHV9D3DhOXUlVp3eS5B/Rk Xx0cj9dvAWzUKMTzWyZZ0YyCEiaEdj3QKm8gcYHRJb6qvCTM/8HIpyxC/a5fbUB0Dhfm 6dwapZo+BgME0LgroO5IALy4rzllpQD9hBSrDeRfIaHikBgT6bmWuyMlRtTGYd1G0nNJ YhBbt0vnAsJ3CbSw88QSoqSKTEATo6lEU/S7Zehs5z0AJY+Mxw9sNdKyFqe6nQdMMH9f NBlFjFUjCQDODMt58iwNJUP6Ssu1mO7HcjSFrk2DHiaJX4wRUStKSQMF8QoKISUtSlug NBmg== X-Gm-Message-State: APjAAAW6GgnrflsL9aB+QVpfBptOoPVrGu6m6+KTVSxipNK10XBpjUdB iLnayV1AnKa1HwFFYKk8mng= X-Google-Smtp-Source: APXvYqxyLiNPcdYVAAJSjJL1kh11cP3+dqgCu2mYwOWbodrgMBx/R+04erdvM0xAZBytlm+DswKV/g== X-Received: by 2002:a17:902:74cc:: with SMTP id f12mr6638329plt.330.1579379826167; Sat, 18 Jan 2020 12:37:06 -0800 (PST) Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id 144sm35632206pfc.124.2020.01.18.12.37.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 12:37:05 -0800 (PST) Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] To: Jaap Akkerhuis , Bob Hinden Cc: IETF , "sullivan@isoc.org" References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> <20200118173254.cebvnhc4kw5eyxcl@outlook.office365.com> <202001181952.00IJqf7t052605@bela.nlnetlabs.nl> From: Brian E Carpenter Message-ID: <4c7638c8-d1c4-d195-589b-17930e5e0a93@gmail.com> Date: Sun, 19 Jan 2020 09:37:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <202001181952.00IJqf7t052605@bela.nlnetlabs.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 20:37:08 -0000 On 19-Jan-20 08:52, Jaap Akkerhuis wrote: > Bob Hinden writes: > > > nor any info on how to access the archive. > > The usual way: https://elists.isoc.org/mailman/private/internetpolicy/ You may need this too, to get your password: https://elists.isoc.org/mailman/options/internetpolicy Oh, and some people (including me) have been seeing DNS issues with resolving elists.isoc.org. That is under investigation. Brian From nobody Sat Jan 18 12:51:23 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C05E120024 for ; Sat, 18 Jan 2020 12:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 1QWOlJYXb4y0 for ; Sat, 18 Jan 2020 12:51:19 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450: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 9E2BE120019 for ; Sat, 18 Jan 2020 12:51:19 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id y17so25862787wrh.5 for ; Sat, 18 Jan 2020 12:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OnApnyp+ZOe8GPLXlfPoEIpNOXBcXFVEQOFu6UwPps8=; b=Fhicc5u9L/FmhizWeLlfgwFLlb3/JB+0N8ms7k8QXJ4pgj3Vug6qqXmrHPLtk8G6k1 96ojUd44VWKhlLnyD1tF6Sj5buJTfD8Q/+4GC1i6V/bSvT0g4KnKROI/UGgguv+2yFO2 5jaA43kU5UbGN4S5ZB83zas5dfy50TONK9wC/0SUGDeOttReBDw896pYw3UIprzrZUgy cAoweURa5XvdLYTHiOCCsD6rGkpnUcoDHKhSUW1MlhjGISXJi40BG965FsLOi1B3HvtW WfoT9nhBujEBcmahColpyu/KC86cMAYSddEfcQ7OfwGIPRrS7Ld/v31kuPE7VPP28Q/Q n6Xw== 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=OnApnyp+ZOe8GPLXlfPoEIpNOXBcXFVEQOFu6UwPps8=; b=bwb3Z0ZYm5nDImhfKBAPJ6wYO25kRWr1PJhoOEsxkF5jbTlWSuU7ACZVK2laQVrQfx faNMBuN5BkjPCPfHH85u9Aj1m686HAHOCrqwR4QSI76Xj01btyyM98iYZqkYoZB6Q6Nb qTmQS//Ehj52br2usxuL92MTfISxuoM9f3ID3RJZ7T8abRF2T5Pk/mBLkFDJ30Vbm9+c 6webz7ZIbDUO9hU/nLOdqIBASltULoxZuowRPexfdO+roIjCqSJ3vg2OhbCI7N9wk2vh 4MFw0AKTGCB/APabzOl4RJI4gu8XxGAwcHO0OL9q7tgRcWMok5os/UxioKco1unLmUN6 cxzw== X-Gm-Message-State: APjAAAV0pRPN1hviPR9nrMX3lrFa8Vc+GS8qoXEddSHnM3nkObGo0Woa RYQ7iY9sPpQMNmOHesTDhTs= X-Google-Smtp-Source: APXvYqxhDJo3EKifcG/vw+jrLniUdLg6cO50uv8bo4hG0qR5fvWqEDTNX6jOvIXf26I3tasSp6FEQw== X-Received: by 2002:adf:9427:: with SMTP id 36mr10532237wrq.166.1579380678186; Sat, 18 Jan 2020 12:51:18 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:3886:b6c2:d6dc:1014? ([2601:647:5a00:ef0b:3886:b6c2:d6dc:1014]) by smtp.gmail.com with ESMTPSA id c15sm39562404wrt.1.2020.01.18.12.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 12:51:16 -0800 (PST) From: Bob Hinden Message-Id: <3DD3FAEA-E797-4583-8BF7-A4A60FE467FB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D0544C27-15D4-4435-986B-E6B872B8FA27"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] Date: Sat, 18 Jan 2020 12:51:14 -0800 In-Reply-To: <4c7638c8-d1c4-d195-589b-17930e5e0a93@gmail.com> Cc: Bob Hinden , IETF , "sullivan@isoc.org" To: Brian Carpenter , Jaap Akkerhuis References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> <20200118173254.cebvnhc4kw5eyxcl@outlook.office365.com> <202001181952.00IJqf7t052605@bela.nlnetlabs.nl> <4c7638c8-d1c4-d195-589b-17930e5e0a93@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 20:51:22 -0000 --Apple-Mail=_D0544C27-15D4-4435-986B-E6B872B8FA27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the pointers, now I can see the archive. Bob > On Jan 18, 2020, at 12:37 PM, Brian E Carpenter = wrote: >=20 > On 19-Jan-20 08:52, Jaap Akkerhuis wrote: >> Bob Hinden writes: >>=20 >>> nor any info on how to access the archive. >>=20 >> The usual way: = https://elists.isoc.org/mailman/private/internetpolicy/ >=20 > You may need this too, to get your password: >=20 > https://elists.isoc.org/mailman/options/internetpolicy >=20 > Oh, and some people (including me) have been seeing DNS issues with = resolving elists.isoc.org. That is under investigation. >=20 > Brian --Apple-Mail=_D0544C27-15D4-4435-986B-E6B872B8FA27 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl4jb8IACgkQrut0EXfn u6jvgwgApw9l9oo2cd1cLSQ0NEkS+q2dtNPQUXqCgkGnvnSR6lmhhcsCmeKILi73 mE5kaMJBrmSa+VIu1HxoAjOTPAOslwxm5yxqLsiG2IsPJ2PtJLCTUkAG6AImSrsj q9DFyPG69cMd+FAvO/xCWgkwMYbNYryKzFFRRzVo+/XUUgZPhBj29136NaDP+aQ8 uVmEjak/QVDewN14bVPty5CQFY0WHhjI70DGn7YdZpxiXyreb3UjZNbNtAt8VFqw /WNyoEx/l+wbpHEO//9sRhoz29fsFqv+QbyFt8haQ0kRBWA7h3MPLNQoSMuqWipO tMFTVS3+QeOr5/RG3p2NOOgct1hyiA== =3MxT -----END PGP SIGNATURE----- --Apple-Mail=_D0544C27-15D4-4435-986B-E6B872B8FA27-- From nobody Sat Jan 18 14:18:15 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBF912007C; Sat, 18 Jan 2020 14:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 J6-VDhPqY751; Sat, 18 Jan 2020 14:18:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68370120043; Sat, 18 Jan 2020 14:18:10 -0800 (PST) Received: from Zephyrus.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 00IMI7st015117 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 18 Jan 2020 16:18:08 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1579385888; bh=4U+v20wNspCLP7uSaiN42N97zW7U3BZOqJVwmZcFM1s=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=AYIie5QpuZgySSN800tMxLTAcH2Gr1OP9S+dEqFcIbwZ0HOcY6jn5lzPbD5yBcHEA WynipjRJhBHXtZT3h7fyxAQkTGMmfhR/kIXhfAVbRm7FofgWQrDEU+WAnGpxciHJbC lEHNczaEHj0YosG/kq0/yVIb8B6abx2HLodItre8= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Zephyrus.local Subject: Re: Agenda items for gendispatch? To: gendispatch@ietf.org Cc: IETF discussion list References: From: Adam Roach Message-ID: <97866639-e9b5-89b8-ede2-b1abdc79fe5b@nostrum.com> Date: Sat, 18 Jan 2020 16:18:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 22:18:14 -0000 On 1/15/20 22:34, Pete Resnick wrote: > As the time quickly approaches for requesting a meeting for the March > IETF, your gendispatch chairs wonder if there are agenda items for > which we should schedule a meeting. Please let us know on the > gendispatch list (the Reply-To on this message is set there) within > the next two weeks if you have any potential agenda items so we can > decide if a meeting is necessary. GENDISPATCH chairs -- I'm planning to spin a new version of draft-roach-bis-documents in the next few weeks, based on the feedback that has been provided so far. I think this would be a candidate for discussion in GENDISPATCH. /a From nobody Sat Jan 18 14:49:40 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44C01200FA; Sat, 18 Jan 2020 14:49:38 -0800 (PST) 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 jIuZtogJevvj; Sat, 18 Jan 2020 14:49:37 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 14E1012007C; Sat, 18 Jan 2020 14:49:37 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id n21so29826040ioo.10; Sat, 18 Jan 2020 14:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OPwtHT9dEPJiejuG5tH3PjXmGZkMjYHFl34dQOhW0yE=; b=OAQdkm+WlAC1hFgSfrdMHAEQh4bwHdB4w3O0shgmiOJ2noS/hivXZLsD+qCt1s0UUH XS8nTDyTHSji2C1TydrQkibjz9q5IgHlK+AdZ/Por2pc6QrQ1EBS1qiJ9Im8tDtFzmtd Mke1ClefgzEORPpFSrunnJlENuJHfKvwkw9LMR6DnqpkU1sg3vVcE3y2ZJRxZlLfpQm+ pXFAhs+0ybuXGdTaa11hup1JZkGLKapO641NzAozUpcEf9WsOLJ1/5oZ0VkObjTFFcue BjpSNvcT178Cj96tLTWS5jlDGR49nbowV+sYD13reByUPAGnf7RqvRrFGIwH30cSBhzm uZMQ== 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=OPwtHT9dEPJiejuG5tH3PjXmGZkMjYHFl34dQOhW0yE=; b=pPxYGVrqn/+td4nwHpOKaqPbRggK9cT/Q1rL0W2sEjFjiu+4MVJZv9rSltU3mF4Ch6 vd7aje+S2xsToerm7mpChffhR8SZNT2Qoeg02n5//vrXsKesGPZQc+UCDDEee21gvdXq SwIAME55Br8fElIrz0P2Mc2BPxx1hab7Y6bdoqWeRMUqPbz2i6oPiJIzhKTowuOMUZTi qV4/0tm2ioJXAVF11ruWgetxS+W1Ittz5L6xppzY+7ODwagCQFplAWOf5ypQXPn72LYD xGPTEUh1tmioZzkJAhTt0MHqOXLyzHBoH85A7L4PjSM06PxvPDF2+hashwNi+AK4n6Ms UWdg== X-Gm-Message-State: APjAAAX/8l+KDSKl+mphHHTpjKrm3m25wvXGpgHmwiPX23uFa0M53ZJl 14oq+YoOHS2G7RF2hMFeUPoK3QaTjq+ARbD/K9u2iABUQ48= X-Google-Smtp-Source: APXvYqxLbGx8/ILNFwNWvnD25i0P9QO4AZLawnBUybZVhKmEEyJhvYEIMtv2ZLDRx9Y1gj/oIKMlPuP0NrlrrIq1d98= X-Received: by 2002:a6b:731a:: with SMTP id e26mr35317215ioh.254.1579387775729; Sat, 18 Jan 2020 14:49:35 -0800 (PST) MIME-Version: 1.0 References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> In-Reply-To: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> From: Rob Sayre Date: Sat, 18 Jan 2020 14:49:24 -0800 Message-ID: Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] To: Sergeant-at-Arms Cc: IETF discussion list Content-Type: multipart/alternative; boundary="00000000000055c4b2059c71df70" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 22:49:39 -0000 --00000000000055c4b2059c71df70 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 7:34 PM Sergeant-at-Arms wrote: > Hi all, > > We wanted to let the list know that the sergeant-at-arms (SAA) team > (described in more detail at [1]) consider this thread [2] to be more > appropriate for the ISOC internet-policy[3][4]. And as per the IETF > discussion list charter [5], we suggest that the discussions should be > moved to the more specific forum identified. > Thank you for your suggestion to redirect this discussion to a poorly-administrated, non-public mailing list. Joining such a list would consent to a lack of transparency, so I won't do so. thanks, Rob --00000000000055c4b2059c71df70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 7:34 PM Sergeant-= at-Arms <saa@ietf.org> wrote:
=
Hi all,

We wanted to let the list know that the sergeant-at-arms (SAA) team
(described in more detail at [1]) consider this thread [2] to be more
appropriate for the ISOC internet-policy[3][4]. And as per the IETF
discussion list charter [5], we suggest that the discussions should be
moved to the more specific forum identified.

Thank you for your suggestion to redirect this discussion to a poorly= -administrated, non-public mailing list.

Joining s= uch a list would=C2=A0consent to a lack of transparency, so I won't do = so.

thanks,
Rob

--00000000000055c4b2059c71df70-- From nobody Sun Jan 19 06:35:01 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC5120044 for ; Sun, 19 Jan 2020 06:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=messagingengine.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 0KKhb-AUFcwc for ; Sun, 19 Jan 2020 06:34:57 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1A912001B for ; Sun, 19 Jan 2020 06:34:56 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 430D421B82; Sun, 19 Jan 2020 09:34:56 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 19 Jan 2020 09:34:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=jTTw5FSqWyaqgGDq/i3lfFkh9bBuiWksfff7zaBHO gs=; b=uiDq4bw88/vHrp7xsjof0FLy+XgT1ZmCpbqnhPj6LQ/igBn0812sUHAYb br/z9CwN9wHF5RCF3Lvz77QjSdl+OfzOhl3sjhI7pK/E7SICkE3wUNLv15KiDtVK 5XA/nig/HGzp4cvGSMHH89l1BS8ZFITEx9PxAeBGQnNy39BMaNreSPyQarx7buar NgeuiCDVAXLVptnqZ/CXAYId2Gcw1WLd1VSMRecbHhQG5mZ682zzbjsd9Awlw5ub iLsEKJQ1yXk6xysPnn76s+RsGJvUhqV/wQqHX8dlh9s2wYSlcZ1l52ni1e0QXcdw WeV2QMab+Waa8LlljqMdWV3wOO8ew== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecukfhppedutdekrddvvddurddukedtrdduhe enucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgv thhitghsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 757333060B1E; Sun, 19 Jan 2020 09:34:55 -0500 (EST) Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] To: ietf@ietf.org References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> From: Keith Moore Message-ID: <503dd3a8-8659-7525-3b43-f9c1c5b4e3ae@network-heretics.com> Date: Sun, 19 Jan 2020 09:34:53 -0500 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: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 14:34:58 -0000 On 1/17/20 10:33 PM, Sergeant-at-Arms wrote: > And as per the IETF > discussion list charter [5], we suggest that the discussions should be > moved to the more specific forum identified. I don't think RFC 3005 was ever intended to be used as an excuse to move a discussion out of the IETF or to suppress discussion within IETF. Please reconsider. Keith From nobody Sun Jan 19 07:03:59 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0222912006B for ; Sun, 19 Jan 2020 07:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 r9EaFewMaoXL for ; Sun, 19 Jan 2020 07:03:55 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49DC120044 for ; Sun, 19 Jan 2020 07:03:54 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id l2so31179094lja.6 for ; Sun, 19 Jan 2020 07:03:54 -0800 (PST) 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=XB2uW2tq2Xb6Bmgv5ZIzvyaMOIjNhfKDilJXFI1vhgM=; b=ST9m8S7q6RH/pz5lzTSxE2PFmjiIkX8qKiXohhWVS9lJONujtKZ9a06nqTYeUkegCS Xl4FPVGnCvhUK+sL1ZKMvLrBHkRxKfNsPgqy2zCQA54PxZmEzLML/tMXX4L2MiIs4q1F zhIY7jUpHRloY8daxLYqfCDAqX/igxWUSO6lYPfYP3ODvdvjROFCsBALJAPXn4DmiYNf VUnVmlPQT/qNbzktF/xE9aDyqPllWxGj3DwH0oPw5vK4UC3JrsizA7INPhjA0l0IfN+R bqWAD4dGnO3jdfEuif9/NIDCmb4Dzt85lZup6FVM1Nv2dKvtt/y49DnaUUs+yOnUaFVk kDJA== 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=XB2uW2tq2Xb6Bmgv5ZIzvyaMOIjNhfKDilJXFI1vhgM=; b=XWw6D/StYp1vGuznxWm/HWb3TAgrVSwW4/J8MSPaOlmTyc+7n1EJEUSCkBzkAB1hyT nxvMcqC+TNbH+UQyKvowQK4VD9Q3tbsVAUTblW0yd3D7SFZCnrDLW8BeRJHSeI1SBEca YErL9SXsVgpuo8akR0h97URkcUjBI5ek5StcWQeNYASx679b0nYr9BM4dLmm8CWVAJxd 0ES863g6Yn85Bn7zgEhbR92TjkzdGV+fi/ZbQEfOknlmGudZuf6iau0BIziR7crYoFyr fFSYnfJqubCNYkdNj7k+f3/vctNU3hxgum8nqUcnVau5kSKrUOu1QnQ+UzPxf5EmhFfi rcwQ== X-Gm-Message-State: APjAAAVAMDQlj2qI56icyeP/SmoII3IHpQGD2X/2CS/0TQm8jNdRK3TY kwmiHbG2MhfY8vldTORTY+9fnP5KK2J/rHrOpBQQiHEC+wOLqQ== X-Google-Smtp-Source: APXvYqxWArXn+7rsmYcs5ic11KvpttjjzNHPaOsyRYE//1Hcugg1q/B4dlcvSp8rYzXIVVfKBksqBHY+BCb43Bh6wRI= X-Received: by 2002:a2e:9015:: with SMTP id h21mr11398432ljg.69.1579446233039; Sun, 19 Jan 2020 07:03:53 -0800 (PST) MIME-Version: 1.0 References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> <503dd3a8-8659-7525-3b43-f9c1c5b4e3ae@network-heretics.com> In-Reply-To: <503dd3a8-8659-7525-3b43-f9c1c5b4e3ae@network-heretics.com> From: Eric Rescorla Date: Sun, 19 Jan 2020 07:03:16 -0800 Message-ID: Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] To: Keith Moore Cc: IETF discussion list Content-Type: multipart/alternative; boundary="000000000000a9a3ae059c7f7b67" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 15:03:57 -0000 --000000000000a9a3ae059c7f7b67 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 19, 2020 at 6:35 AM Keith Moore wrote: > On 1/17/20 10:33 PM, Sergeant-at-Arms wrote: > > > And as per the IETF > > discussion list charter [5], we suggest that the discussions should be > > moved to the more specific forum identified. > > I don't think RFC 3005 was ever intended to be used as an excuse to move > a discussion out of the IETF or to suppress discussion within IETF. > This seems like a surprising claim given that RFC 3005 explicitly lists as inappropriate postings: "Discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns" I'm not taking a position on whether this subject is "unrelated to IETF..." but it seems pretty clear that RFC 3005 was in fact intended to allow for discussion to be moved off of the *IETF list* -Ekr > Please reconsider. > > Keith > > > > --000000000000a9a3ae059c7f7b67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 19, 2020 at 6:35 AM Keith= Moore <moore@network-here= tics.com> wrote:
On 1/17/20 10:33 PM, Sergeant-at-Arms wrote:

> And as per the IETF
> discussion list charter [5], we suggest that the discussions should be=
> moved to the more specific forum identified.

I don't think RFC 3005 was ever intended to be used as an excuse to mov= e
a discussion out of the IETF or to suppress discussion within IETF.

This seems like a surprising claim given that = RFC 3005 explicitly lists as inappropriate postings:

"Discussion of subjects unrelated to IETF policy, meetings, ac= tivities, or technical concerns"

I'm not = taking a position on whether this subject is "unrelated to IETF...&quo= t; but it seems pretty clear that RFC 3005 was in fact intended to allow fo= r discussion to be moved off of the *IETF list*

-Ekr

X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 15:08:31 -0000 This is a multi-part message in MIME format. --------------C8267EDF92C59790519EE8DB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/19/20 10:03 AM, Eric Rescorla wrote: > > I don't think RFC 3005 was ever intended to be used as an excuse > to move > a discussion out of the IETF or to suppress discussion within IETF. > > > This seems like a surprising claim given that RFC 3005 explicitly > lists as inappropriate postings: > > "Discussion of subjects unrelated to IETF policy, meetings, > activities, or technical concerns" > > I'm not taking a position on whether this subject is "unrelated to > IETF..." but it seems pretty clear that RFC 3005 was in fact intended > to allow for discussion to be moved off of the *IETF list* I don't think this discussion is unrelated to IETF.   Technical decisions made in IETF have often taken into account participants' perceptions of trustworthiness and risk associated with roles played by other organizations (including both governments and NGOs).   This discussion within IETF seems to be useful background for future technical decisions. So I suppose I could rephrase my statement as: I don't think RFC 3005 was ever intended to be used as an excuse to move a discussion of relevance to IETF's work, out of the IETF, or to suppress discussion of topics relevant to IETF's work within IETF. Keith --------------C8267EDF92C59790519EE8DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/19/20 10:03 AM, Eric Rescorla wrote:


I don't think RFC 3005 was ever intended to be used as an excuse to move
a discussion out of the IETF or to suppress discussion within IETF.

This seems like a surprising claim given that RFC 3005 explicitly lists as inappropriate postings:

"Discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns"

I'm not taking a position on whether this subject is "unrelated to IETF..." but it seems pretty clear that RFC 3005 was in fact intended to allow for discussion to be moved off of the *IETF list*

I don't think this discussion is unrelated to IETF.   Technical decisions made in IETF have often taken into account participants' perceptions of trustworthiness and risk associated with roles played by other organizations (including both governments and NGOs).   This discussion within IETF seems to be useful background for future technical decisions.

So I suppose I could rephrase my statement as:

I don't think RFC 3005 was ever intended to be used as an excuse to move a discussion of relevance to IETF's work, out of the IETF, or to suppress discussion of topics relevant to IETF's work within IETF.

Keith


--------------C8267EDF92C59790519EE8DB-- From nobody Sun Jan 19 13:32:07 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D411120033 for ; Sun, 19 Jan 2020 13:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd3h1xmjcfhi for ; Sun, 19 Jan 2020 13:32:04 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 3A83D12001E for ; Sun, 19 Jan 2020 13:32:04 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id c4so25709267ilo.7 for ; Sun, 19 Jan 2020 13:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J4c23Akf4gx5lw/x382BqBZTqzrAXOou5e/IZZ+IYgA=; b=LQQK4khUhNFUqLJ7vWU/ljlwtlJUTOs559wjLC5A2gFIXcCJPChDDeZitboCZEyj5H 0DxYKlkBc5BJWfHh7m2rEIgqJTmgd9ANm1hc0E/jekKcpqdAX7LcV4tsJ80UZam09Lbp 1Yc0PzCkXIJ58P/gm/8w6xWUY9vVyL5KS1nO/s9Gqr+cT11MGAT0Vd2EgOHzo7j9jRkQ c/UDAKtMOcZJw8tfHiEAUjavvLK2GbqsFkw8qTesGE1poGuBjNZ9PxF5YcnQ/ft2ROeW 8FJfD/OCH6trHS+Ff4zH6Jyw74Ta3h8KKcHi9HLQEoPzaf+V2QuTh7ufjSFJsKvcNOv1 MYNQ== 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=J4c23Akf4gx5lw/x382BqBZTqzrAXOou5e/IZZ+IYgA=; b=KdD5bfbu+yiNeyGjsoVUHZStazxGxaBcgBWWYkKER6D1HR3KUzWEOmTevBIp0DgOhU vuvBncKFKtMdMpYptP473lnxrQuVUx/TJ9DTcCycs9jECkOwS62raWy5XQrKtPJYqzqw wE6U4McyWG68H+lQr3d/gko+O/UL/hDJIxafy3sxF1u287jshXXqxI/E2eHgx+QjES0f mHFwxv+wojMD71r7D2FKHEvhK6PlPvjNg+1pYVUIJzwzNjGuNyZ41JIgUqKvlYKKR3si VdWtEdJ8peTlbpHR7IakonNrT6xdlHnu3ogHQ/OYxju6SKRe29bKi7pnDUdEcqqXW3TR SKlw== X-Gm-Message-State: APjAAAU3QZArssz6nASUErqrOIeE4uonwi78kKCgPnKuGM2E0NYBhaib EkkT6QpPorV+5Z0kXXE58q4DHxJGPZ4h5z2odXY= X-Google-Smtp-Source: APXvYqxF7Legvz6VaH7syxyJic2dPYP2Ljoa7MRtQMqtXfK0Suw+U1li5NMFdLPcQ+/0z38svM7PgRwkOf0bEZclqgo= X-Received: by 2002:a92:498d:: with SMTP id k13mr8020544ilg.254.1579469523403; Sun, 19 Jan 2020 13:32:03 -0800 (PST) MIME-Version: 1.0 References: <91b0323b-a2d3-a8e3-0bce-86a53c04fba2@ietf.org> <503dd3a8-8659-7525-3b43-f9c1c5b4e3ae@network-heretics.com> In-Reply-To: From: Rob Sayre Date: Sun, 19 Jan 2020 13:31:51 -0800 Message-ID: Subject: Re: Forum Suggestion from IETF SAA [RE: .org sale - bidding process] To: Eric Rescorla Cc: Keith Moore , IETF discussion list Content-Type: multipart/alternative; boundary="000000000000e04783059c84e76a" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 21:32:05 -0000 --000000000000e04783059c84e76a Content-Type: text/plain; charset="UTF-8" On Sun, Jan 19, 2020 at 7:04 AM Eric Rescorla wrote: > > I'm not taking a position on whether this subject is "unrelated to > IETF..." but it seems pretty clear that RFC 3005 was in fact intended to > allow for discussion to be moved off of the *IETF list* > It's true that RFC 3005 intended to move discussion off-list. I wish there were a better destination than ISOC's odd semi-private list. While it's important to heed the SAA's warning to move this discussion off of this list, I refuse to sign up for the ISOC list. thanks, Rob --000000000000e04783059c84e76a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 19, 2020 at 7:04 AM Eric Resc= orla <ekr@rtfm.com> wrote:

I'= m not taking a position on whether this subject is "unrelated to IETF.= .." but it seems pretty clear that RFC 3005 was in fact intended to al= low for discussion to be moved off of the *IETF list*

It's true that RFC 3005 intended to move d= iscussion off-list. I wish there were a better destination=C2=A0than ISOC&#= 39;s odd semi-private list. While it's important to heed the SAA's = warning to move this discussion off of this list, I refuse to sign up for t= he ISOC list.

thanks,
Rob
--000000000000e04783059c84e76a-- From nobody Tue Jan 21 15:55:10 2020 Return-Path: X-Original-To: ietf@ietf.org Delivered-To: ietf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8979F120018; Tue, 21 Jan 2020 15:55:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: NomCom Chair 2019 To: "IETF Announcement List" Cc: ietf@ietf.org Subject: NomCom 2019 Announcement of IETF Trust Selection X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <157965090852.28971.8034952121190539489.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2020 15:55:08 -0800 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 23:55:08 -0000 As chair of the 2019-2020 NomCom, it gives me great pleasure to announce the results of the NomCom selection process for the IETF Trust. The IETF Trust candidate noted below has been confirmed by the IESG. The selected candidate for the IETF Trust is: Glenn Deen, Comcast-NBCUniversal The resulting IETF Trust will consist of: Kathleen Moriarty Joel Halpern * Glenn Deen IESG Selection (current member Stephen Wenger) John Levine (ISOC BoT Selection) ( * ) Candidate has agreed to accept the role (3-year term) The members of the NomCom thank all of the members of the community who offered to serve on the IETF Trust. Additionally, our thanks go out to the many members of the community who have supported (and continue to support) the NomCom process. The NomCom 2019 team continues with the LLC and IESG selections still to be announced. Regards, Victor Kuarsingh 2019-2020 IETF NomCom Chair victor at jvknet dot com nomcom-chair-2019 at ietf dot org From nobody Tue Jan 21 16:03:55 2020 Return-Path: X-Original-To: ietf@ietf.org Delivered-To: ietf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0CA120018; Tue, 21 Jan 2020 16:03:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: NomCom Chair 2019 To: "IETF Announcement List" Cc: ietf@ietf.org Subject: NomCom 2019 Announcement of LLC Board Director selection X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <157965143304.28917.10103593181996340517.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2020 16:03:53 -0800 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 00:03:53 -0000 As chair of the 2019-20120 NomCom, it gives me great pleasure to announce the results of the NomCom selection process for the IETF LLC Board Director to serve on the LLC Board. The LLC Board Director candidate noted below has been confirmed by the IESG. The selected candidate for the LLC Board is: Peter Van Roste, CENTR The resulting LLC Board will consist of: Jason Livingood Maja Andjelkovic * Peter Van Roste Sean Turner (ISOC BoT Selection) Alissa Cooper (IESG Selection) ( * ) Candidate has agreed to accept the role (3-year term) The members of the NomCom thank all of the members of the community who offered to serve on the LLC Board. Additionally, our thanks go out to the many members of the community who have supported (and continue to support) the NomCom process. The NomCom 2019 team continues with the IESG selections still to be announced. Regards, Victor Kuarsingh 2019-2020 IETF NomCom Chair victor at jvknet dot com nomcom-chair-2019 at ietf dot org From nobody Wed Jan 22 23:01:33 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44F2120115; Wed, 22 Jan 2020 23:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 84268CMjklWS; Wed, 22 Jan 2020 23:01:16 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 5FAB712003F; Wed, 22 Jan 2020 23:01:16 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id n96so761399pjc.3; Wed, 22 Jan 2020 23:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=ao8auilzcKlNWvH4hRPLsyyEPUxMUUXZN0kOSFhnVfA=; b=I7FW3r/i1U//bRVAndHM8g01HGCzGgkxHBwQ+5IfCIi0Xu0pblrG6BFXWwAASOrDFa idmbzx95yWRLwuLh7a/ozSpUD9V02+0tp0TvzCI6iNaSX3Fy/+us0s2ozg+RRJAdnnSF ZkduUw9Wj6lKy4jAs9yeHXvf6uiiQRnultmdIoLEcF1DkS5XxokrJCGbO6LKbPcdRpwW n9OZuvwkRLYKDM1RuYJ+yYU351arUabR2nJ9GE3seuZZGoy/EWJ3KiNaUWUmefjj3YEo IQxxJ7UVzj1dgmlxI/0BtFruFZEGPrI7YyMifH/AB9l5elP3ZPN0Jwv1Cm9t5SK99Nkd C3mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=ao8auilzcKlNWvH4hRPLsyyEPUxMUUXZN0kOSFhnVfA=; b=Qy/U4RMUjyVYCHhhPy8oM7Mlv+ptpTbQcwu/gOxGj2HEusDF1PCB/ued/0yygwSooN Qm0sBHotGWDvV+zvw0dp4DdFU/4uHS2gww3XPPrj5VPl29PdK3OeOnYQoCTp7VOSh0A8 ozr9ABJ+zjlk29aAv9LOPO9F3GSShsoIYHJX1xiDIeIUq7OtLPO1QpSMheOwqU8hTl9g g5/4+qm2lC41NJPdswO7ZF8m307MRz5H+RVFNESBtyr60GPwOZ6vYteueG02+hPD4RfA u8XoIzCnoiFY85oSSz12VNL8fZNC7vwbXsAVE1kIkJSQaP5JuGA8NXKACGodU7Qr3XOY V83w== X-Gm-Message-State: APjAAAWKzqi8A+B9q+G+jOpqkYgXHKB2nh4XwJ9oca5Xjh0tJsEnJria G+DF8YZYX9gCy/vtqqWAdCwjUyqz X-Google-Smtp-Source: APXvYqzrzhl3xTlDwezd1UdJzIhU7neeB76tgPCayY2TjF97r8Jkl5XmJ3RuyhBkX+DA7hkzpsGDdA== X-Received: by 2002:a17:902:12d:: with SMTP id 42mr14604083plb.246.1579762875607; Wed, 22 Jan 2020 23:01:15 -0800 (PST) Received: from [172.20.7.143] ([12.199.201.12]) by smtp.gmail.com with ESMTPSA id d189sm1311504pga.70.2020.01.22.23.01.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 23:01:15 -0800 (PST) From: Suresh Krishnan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Call for feedback: IESG appointment to the IETF Trust Message-Id: <98AADE26-098B-46EC-BFC6-308611A275AD@gmail.com> Date: Thu, 23 Jan 2020 02:01:14 -0500 Cc: ietf To: IETF-Announce X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 07:01:25 -0000 The IESG is responsible for appointing one person to the IETF Trust for = a two-year term to begin in March 2020. A call for nominations was sent = out and the following candidates have accepted a nomination: o Stephan Wenger, currently serving as the IESG appointee on a one year = term o Hago Dafalla o Michael Richardson (We also had one more candidate, Glenn Deen, who had accepted a = nomination but has since been selected as the Nomcom appointee for the = IETF Trust) Please send feedback about these three candidates to = suresh.krishnan@gmail.com. This feedback will be held in confidence by = the IESG. Please provide the feedback by February 6, 2020. We thank you in advance for your help. =20 On behalf of the IESG, Suresh Krishnan Internet Area Director= From nobody Thu Jan 23 21:53:12 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30B0120041 for ; Thu, 23 Jan 2020 21:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i80SwBtU1T-v for ; Thu, 23 Jan 2020 21:53:08 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 0E88A120020 for ; Thu, 23 Jan 2020 21:53:07 -0800 (PST) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00O5lETN115608 for ; Fri, 24 Jan 2020 00:53:07 -0500 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0b-001b2d01.pphosted.com with ESMTP id 2xp9kj1v2y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 24 Jan 2020 00:53:07 -0500 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 00O5paWH010033 for ; Fri, 24 Jan 2020 05:53:06 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma01wdc.us.ibm.com with ESMTP id 2xp7x4wpt8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 24 Jan 2020 05:53:06 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 00O5r6Je32112926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 24 Jan 2020 05:53:06 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 111BDAC05B for ; Fri, 24 Jan 2020 05:53:06 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F1790AC062 for ; Fri, 24 Jan 2020 05:53:05 +0000 (GMT) Received: from rotala.raleigh.ibm.com (unknown [9.27.200.19]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTPS for ; Fri, 24 Jan 2020 05:53:05 +0000 (GMT) Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.15.2/8.15.2) with ESMTP id 00O5r4xA032500 for ; Fri, 24 Jan 2020 00:53:04 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.15.2/8.15.2/Submit) id 00O5r4Tj032428 for ietf@ietf.org; Fri, 24 Jan 2020 00:53:04 -0500 From: narten@us.ibm.com Message-Id: <202001240553.00O5r4Tj032428@rotala.raleigh.ibm.com> Date: Fri, 24 Jan 2020 00:53:04 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-24_01:2020-01-23, 2020-01-24 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 adultscore=0 clxscore=1015 suspectscore=13 mlxlogscore=570 malwarescore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001240047 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 05:53:10 -0000 Total of 38 messages in the last 7 days. script run at: Fri 24 Jan 2020 12:53:03 AM EST Messages | Bytes | Who --------+------+--------+----------+------------------------ 23.68% | 9 | 24.69% | 112222 | sayrer@gmail.com 13.16% | 5 | 14.64% | 66556 | sullivan@isoc.org 7.89% | 3 | 7.81% | 35485 | ekr@rtfm.com 7.89% | 3 | 7.76% | 35259 | bob.hinden@gmail.com 5.26% | 2 | 6.84% | 31071 | ted.ietf@gmail.com 5.26% | 2 | 5.13% | 23310 | moore@network-heretics.com 5.26% | 2 | 3.28% | 14927 | nomcom-chair-2019@ietf.org 2.63% | 1 | 4.73% | 21485 | jason_livingood@comcast.com 2.63% | 1 | 2.99% | 13598 | rsalz@akamai.com 2.63% | 1 | 2.66% | 12085 | iab-chair@iab.org 2.63% | 1 | 2.62% | 11895 | narten@us.ibm.com 2.63% | 1 | 2.52% | 11447 | tbray@textuality.com 2.63% | 1 | 2.43% | 11040 | brian.e.carpenter@gmail.com 2.63% | 1 | 2.22% | 10086 | jaap@nlnetlabs.nl 2.63% | 1 | 2.21% | 10036 | suresh.krishnan@gmail.com 2.63% | 1 | 2.09% | 9487 | saa@ietf.org 2.63% | 1 | 1.97% | 8931 | adam@nostrum.com 2.63% | 1 | 1.76% | 8010 | ietf-dane@dukhovni.org 2.63% | 1 | 1.67% | 7571 | randy@psg.com --------+------+--------+----------+------------------------ 100.00% | 38 |100.00% | 454501 | Total From nobody Fri Jan 24 07:14:48 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ECB120024; Fri, 24 Jan 2020 07:14:40 -0800 (PST) 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, HTML_MESSAGE=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 F3rwKqSjYmeh; Fri, 24 Jan 2020 07:14:36 -0800 (PST) Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 7EE4312006E; Fri, 24 Jan 2020 07:14:36 -0800 (PST) From: IETF Chair Content-Type: multipart/alternative; boundary="Apple-Mail=_66A52368-DCFF-4291-8986-2FFFA2DF3867" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: IETF 107 Birds of a Feather (BOF) proposals due in 2 weeks Message-Id: <05336E16-0540-4C9C-966E-F1820F226740@ietf.org> Date: Fri, 24 Jan 2020 10:14:34 -0500 To: IETF-Announce , IETF discussion list X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 15:14:41 -0000 --Apple-Mail=_66A52368-DCFF-4291-8986-2FFFA2DF3867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wanted to remind everyone that proposals for "Birds of a Feather=E2=80=9D= (BOF) sessions at IETF 107 are due no later than Friday, 7 February at = 23:59 UTC.=20 Instructions for submitting your proposal are available at:=20 https://www.ietf.org/how/bofs/bof-procedures/ = =20 Please also read RFC 5434 (https://tools.ietf.org/html/rfc5434 = ), Considerations for Having a = Successful Birds-of-a-Feather Session, if you are not familiar with it.=20= If you are working on a BOF request but you=E2=80=99re not quite ready = to submit it, please tell the IESG now by sending an email to = iesg@ietf.org to get advance help with the = request. We have a number of ways of bringing new work into the IETF and = BOFs are just one of them, so please talk to the IESG or an individual = Area Director (https://www.ietf.org/about/groups/iesg/members/ = ) about your idea if = you=E2=80=99re thinking about proposing a BOF. IETF 107 will take place March 21-27 in Vancouver. More information is = available at:=20 https://www.ietf.org/how/meetings/107/ = Thanks, Alissa Cooper IETF Chair= --Apple-Mail=_66A52368-DCFF-4291-8986-2FFFA2DF3867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = wanted to remind everyone that proposals for "Birds of a Feather=E2=80=9D = (BOF) sessions at IETF 107 are due no later than Friday, 7 February at = 23:59 UTC. 

Instructions for = submitting your proposal are available at: 

https://www.ietf.org/how/bofs/bof-procedures/ 

Please also read RFC 5434 (https://tools.ietf.org/html/rfc5434), Considerations for = Having a Successful Birds-of-a-Feather Session, if you are not familiar = with it. 

If you are working on a BOF = request but you=E2=80=99re not quite ready to submit it, please tell the = IESG now by sending an email to iesg@ietf.org to get advance help with the request. = We have a number of ways of bringing new work into the IETF and BOFs are = just one of them, so please talk to the IESG or an individual Area = Director (https://www.ietf.org/about/groups/iesg/members/) about = your idea if you=E2=80=99re thinking about proposing a BOF.

IETF 107 will take place March 21-27 in = Vancouver. More information is available at: 

https://www.ietf.org/how/meetings/107/

Thanks,
Alissa Cooper
IETF = Chair= --Apple-Mail=_66A52368-DCFF-4291-8986-2FFFA2DF3867-- From nobody Fri Jan 24 09:00:29 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BBE120AB3 for ; Fri, 24 Jan 2020 09:00:27 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=kumari-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 t58uwebOnBKs for ; Fri, 24 Jan 2020 09:00:25 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 64BF9120A20 for ; Fri, 24 Jan 2020 09:00:25 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id g6so915883qvy.5 for ; Fri, 24 Jan 2020 09:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=WYkJ442NNTLilzx38ySMxUobIVMei2Ctpbfct04Ruzo=; b=zRoANcgxBVAoGzwyjGABXzwl46iiw5xx6K74AODq7Ugy0EckGom585k9/GuvBKrf3X Wi2S/Npza0ILeowTLbbMEaxbskKps912HMGtB3qyICnyFATRoWV980e61ywo6vbC3F2s H+TMftYIq79bYUVGBzLYwA9rrYYFlkLabd5WwZOUfHpsYHDiVCESJQ6JMjCn08rBbJ+z 5/DmaJPGITZZgV6k5Bzihn5hTNu9JfYLea5S35JJVjGUHFfcmoanvSTUPISMZc8g1ROG L/GJe10y8UK/+GPdEz9HUTN2RBXA8LuBKtujXx8ETq0NhwvjIV8ulRrky+j4VVOll0DJ EKsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WYkJ442NNTLilzx38ySMxUobIVMei2Ctpbfct04Ruzo=; b=jpuvcqKxguZeIalZcsgr6MEqmIfu6m4z0PrpqsUfBJLxr66PBewQcn+mBCqdSA2Wcf zRNBonVSdxZ0rQz1gfW8LVfeM2/zo46ZI9wPLlVvzmLEFCjge4KuxGXUMdEWzrVcLGFW AucaZbPiUBWB7hebDKEGfWiGMNdTf7hR6fs0FjGJdLLoW6JcPvq5KfC41ckDw4BhbvFd ZV/bhP++DeuyTaiaQEEZN4r9PJ/I8Yq4dr6HYJT01SVA8s5XeBzAJx/Fbv+dU0aPcydk NhwAD//fExwQeo05vwyYBlFlst+DtCctihZMZcmiqljsMwSXxW0uTNLMxLRE0aIp/VaT 62jA== X-Gm-Message-State: APjAAAX17EPgFvntYauH6KEE+QDMNhuJfFtDySgGmdgQ2DNZM19yLGSG EgH/0yVjeNdOuY0d9ks82nnX9tZ+3caVQQv6yCjWpew2520= X-Google-Smtp-Source: APXvYqwzDcL3W1Au5pzS+Dn6cY84DFLtCgoqavgIscruglae7TW+29XxHmVj5aAdZgHT+4V6ZiF+QUudNQkuLvkNwss= X-Received: by 2002:a05:6214:1633:: with SMTP id e19mr3843167qvw.104.1579885224008; Fri, 24 Jan 2020 09:00:24 -0800 (PST) MIME-Version: 1.0 From: Warren Kumari Date: Fri, 24 Jan 2020 11:59:48 -0500 Message-ID: Subject: Calling pilots, sailors, runners and cyclists... and everyone else... To: IETF Discuss Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 17:00:28 -0000 Hi all, if you are planning on coming to IETF107 in Vancouver, you are probably coming by plane, boat, bicycle, or, if especially hardcore, running... Why not share your experiences with others who have similar interests? We have Affiliate Groups for ham radio operators, cyclists, runners, sailors, pilots, and scuba divers. We also have Community India (targeted to increasing participation from India), and a general discussion jabber room (hallway). More info here: https://ietf.org/about/groups/affiliate/ As always, if you are part of a community, and would like to form an affiliated group, let me know... W P.S: Yes, I realize that for *almost* everyone flying to Vancouver, suddenly finding yourself in the pilot's seat means that something just has, or is about to go *very* badly, but I needed it for the gag... -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sat Jan 25 19:12:03 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627CE12007C for ; Sat, 25 Jan 2020 19:12:01 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAm_eL4bluD3 for ; Sat, 25 Jan 2020 19:12:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 70D1312001E for ; Sat, 25 Jan 2020 19:12:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ivYL9-0001z2-0k for ietf@ietf.org; Sun, 26 Jan 2020 03:11:59 +0000 Date: Sat, 25 Jan 2020 19:11:58 -0800 Message-ID: From: Randy Bush To: IETF Rinse Repeat Subject: bill manning User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 03:12:01 -0000 we have lost another one From nobody Sat Jan 25 20:06:47 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9F5120044 for ; Sat, 25 Jan 2020 20:06:45 -0800 (PST) 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 KGqbxmDoHMtB for ; Sat, 25 Jan 2020 20:06:44 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 3B15712001B for ; Sat, 25 Jan 2020 20:06:44 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id b15so3934010lfc.4 for ; Sat, 25 Jan 2020 20:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8v5UcG1xQfgs2XkJ2TM21VPTA9ZEdRtCMT1Dwyzw5n4=; b=uPMaktQb+/k64WjQPh7CVlPSo5cdPm999cs0R3qdn/MRcma82xqUepaQwOoobAU/11 gBRQIcC0NM1xsHdsgyW0G+cLttR7+e3pwRZk1/I9e8WCHANAsIxbcr8FXF4diqoTpCYE YzB4n2FEnEgkDm0NBme/RAwELx/73VmBwCcpnlK9Wk9fshf2Wozbrg5VBFcHcvzwKuQ5 aNUhjgFSQEknLVzMEZ61a8+afMS9uHXuN/wBwQFY4/20uM5qUW7d3zBhrP1yVkRzhFIy UCPCkjzURUIcLr/3kwjFQGEQrUNShdb0Rlc5YxA7I7F+zJi18Bv4J00as8b0v5bMg0Lw GvsA== 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=8v5UcG1xQfgs2XkJ2TM21VPTA9ZEdRtCMT1Dwyzw5n4=; b=ib47UBJz6NrOYdEBXXmBTU5BtGQsTeFh0RRSGgypIDIpprcKO/4F8VIkfDIDJxDv5G lH4SXmTmtTrRAMKw+nArEWCcGETDIv1lG1DTEO1p5/aAsxBiSq443IwmIDloA+NG60wa xkz97MF8vucfX31+bm71qZ/ryo1mIb0RDJh/1o7SI3D1FfUBvcPqa3yhLo0IboKqEoHn L3zQFtQSJHrUhBnBVz98yIyc67lyd6Ru4XPDsYLW6N42pReHGO1z26Pwl8rpN5EFNBQH GWnwPsfv3jiqTtLFDiHACgesMNqI6lH1f6eIxjOhDC14cDPAecOWUW5yHQ2jhkAgLlDg 3PVQ== X-Gm-Message-State: APjAAAVmp7ZsgcNu0wM3C9nSNCel73EgrC5L+Oj+swHph38vxtI+HBpo vyJHKMGrOQayY9QWNtNg3UZa+dPY+uekcUBynv8= X-Google-Smtp-Source: APXvYqzHwnPG09o897BKCKx2t3sLYI762BQjuIgkvHbQdsbVjE786nv/JK2UnVb1Vw28W91r5UP1aQyJUGgwOjiFbok= X-Received: by 2002:a19:5212:: with SMTP id m18mr5045374lfb.7.1580011602401; Sat, 25 Jan 2020 20:06:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jorge Amodio Date: Sat, 25 Jan 2020 22:06:31 -0600 Message-ID: Subject: Re: bill manning To: Randy Bush Cc: IETF Rinse Repeat Content-Type: multipart/alternative; boundary="0000000000004d5fa9059d031eae" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 04:06:46 -0000 --0000000000004d5fa9059d031eae Content-Type: text/plain; charset="UTF-8" So sad :-( On Sat, Jan 25, 2020 at 9:12 PM Randy Bush wrote: > we have lost another one > > --0000000000004d5fa9059d031eae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So sad :-(

On Sat, Jan 25, 2020 at 9:12 PM R= andy Bush <randy@psg.com> wrote:=
we have lost an= other one

--0000000000004d5fa9059d031eae-- From nobody Sat Jan 25 20:34:28 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4679120045 for ; Sat, 25 Jan 2020 20:34:26 -0800 (PST) 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, 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=sfc.wide.ad.jp 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 sPPy8WiIGVOo for ; Sat, 25 Jan 2020 20:34:23 -0800 (PST) Received: from mail1.sfc.wide.ad.jp (mail1.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:133]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B314120044 for ; Sat, 25 Jan 2020 20:34:22 -0800 (PST) Received: from vanmetedneysmbp.fletsphone (3.193.13.160.dy.iij4u.or.jp [160.13.193.3]) (Authenticated sender: rdv) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id 31BD812DAB; Sun, 26 Jan 2020 13:34:21 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1580013261; bh=lBp6kAs9zI8QDJihOt4k+uqKv6Le1UlPbZ0jzI1BOWM=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ezeaxBMiybsED25ggCnwXJ4JNmEULzH0tssRbyhLeApdDX7RGitiRUjU8Mlt/r/m6 5Ti8guKZGa+OOqwOK567DP6Cm/v1uSuodeuE8KCyyzayYCEPEgoAqtILwwTlxyN0C6 W2HEpSnw4IxLAM+wbku+gPOvljy/Y8OeVgXn8wCPuTWCa6P5JibOkpo1urHS43YDdC YpC3R8pm+hJqsN9p51ITCLfrF8PeoJAjrvY44p8cVqrqH951iy1Ya/GfBYB/BThB/Y IJhd6uv7viC2Gs9u7LyRKz6Rqa3V8ENWelcRbB7fw1tb/ANxw8uA5v0bTwvepubwAv mHdHNGTcehcMQ== From: Rodney Van Meter Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A2A32987-AC6B-4BF6-B9F3-6784D7BEF1AF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: bill manning Date: Sun, 26 Jan 2020 13:34:20 +0900 In-Reply-To: Cc: Rodney Van Meter , Randy Bush , IETF Rinse Repeat To: Jorge Amodio References: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 04:34:27 -0000 --Apple-Mail=_A2A32987-AC6B-4BF6-B9F3-6784D7BEF1AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This morning I talked to Julie Manning, Bill's wife. Bill died early Saturday morning, at home in Oregon. Most of you know Bill was waiting for a new heart. He would perhaps have gotten one next month. I guess the old one just wouldn't hold out long enough. I first met Bill in about 1995, when I returned to ISI after my first stint in Japan. He had taken a position in the Los Nettos project at ISI, a regional network project in the days when Internet service and operations work was still heavily shared between business and academia. Bill brought an operator's eye to the project, often seeing things differently from the researchers in the group. Bill kept the most erratic hours of any non-student I've ever met. He might be in the office at 2am or at 2pm, either was equally likely. I'd ask, "Bill, what time did you come in?" He'd reply, "10am." "I was here before that, and you were already here, it must have been earlier." "Greenwich Mean Time." And in one phase of life, "Bill, where do you live?" "Seat 4A." He would speculate about his average altitude and speed over the previous month. And, like any good geek, Bill had a spectacular collection of tie-dye t-shirts. He came by the look honestly: growing up in the Bay Area, he had actually snuck into Grateful Dead rehearsals held in a barn, and had traveled as a deadhead for a while. At ISI, we called Bill "the bad idea fairy". He always brought a slightly-off-kilter view of technical problems, which triggered endless discussions of fascinating, if usually implausible, alternatives. He had the most broad-ranging musical tastes of anyone I knew, and would eat almost anything (though, like me, he didn't drink alcohol). I was often envious of his eating and musical experiences. He certainly lived life to its fullest. On one occasion, I recall, we were eating lunch in a Thai restaurant for the first time. Bill called for the food "the way you'd make it in Thailand". The waiter went back into the kitchen and came out with a few raw Thai chiles. Bill ate one whole, without even breaking a sweat. The owner of the restaurant immediately came out to see who was eating them. Pam became a friend to our group. On other occasions, when the waiter asked for his order, Bill would point to another person at the table, and say, "I'll have what she's having." "Well, what is she having?" "I don't know, I haven't heard her say." Once in a while, he would point to someone else in the restaurant and say, "I'll have what they are having." It was funny and sometimes disconcerting, which was very Bill, and it was also his way of making sure he himself was eating (and thinking and doing) as broadly as possible, without getting stale. Bill worked in a bakery before joining Texas Instruments and accidentally falling into computer networking. (When we first met, he was commuting between Houston and L.A.; Julie and the kids were still in Houston.) I believe he attended a series of colleges but never finished his bachelor's degree. Just a few years ago, however, Jun Murai convinced him to get a Ph.D.; this took clearing administrative hoops to demonstrate that Bill's life experience matched that of a bachelor's degree, which it certainly did. I was honored to be on his Ph.D. committee. I literally created a "trouble ticket" accounting scheme to track change requests for his thesis. Bill was a valued member of the WIDE Project here in Japan. He worked with the DNS root operations group here, and participated in as many WIDE meetings as he could. He also came to Keio University's Shonan Fujisawa Campus when he was in Japan, and one of the best things about Bill was how seriously he took the students and their work, treating them like adult colleagues. Bill had friends on all seven continents, and for all I know on the International Space Station, as well. He was loved by us all. Julie does not plan to have a funeral immediately, so there is no need for flowers or the like. The family may do a memorial service in Utah in the spring. He was a unique and wonderful human being. And a good friend. Rest in peace, Bill. =E2=80=94Rod Rodney Van Meter Professor, Faculty of Environment and Information Studies Keio University, Japan rdv@sfc.wide.ad.jp > On Jan 26, 2020, at 13:06, Jorge Amodio wrote: >=20 >=20 > So sad :-( >=20 > On Sat, Jan 25, 2020 at 9:12 PM Randy Bush > wrote: > we have lost another one >=20 --Apple-Mail=_A2A32987-AC6B-4BF6-B9F3-6784D7BEF1AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

This morning I talked to = Julie Manning, Bill's wife. Bill died early
Saturday = morning, at home in Oregon.  Most of you know Bill was
waiting for a new heart. He would perhaps have gotten one = next
month. I guess the old one just wouldn't hold = out long enough.

I first met Bill in about 1995, when I returned to ISI after = my first
stint in Japan.  He had taken a = position in the Los Nettos project at
ISI, a = regional network project in the days when Internet service and
operations work was still heavily shared between business = and
academia.  Bill brought an operator's eye = to the project, often seeing
things differently = from the researchers in the group.

Bill kept the most erratic hours of any = non-student I've ever met.  He
might be in the = office at 2am or at 2pm, either was equally likely.
I'd ask, "Bill, what time did you come in?" He'd reply, = "10am."  "I
was here before that, and you were = already here, it must have been
earlier." =  "Greenwich Mean Time."

And in one phase of life, "Bill, where = do you live?" "Seat 4A."  He
would speculate = about his average altitude and speed over the previous
month.

And, like any good geek, Bill had a spectacular collection of = tie-dye
t-shirts.  He came by the look = honestly: growing up in the Bay Area,
he had = actually snuck into Grateful Dead rehearsals held in a barn,
and had traveled as a deadhead for a while.

At ISI, we called Bill = "the bad idea fairy".  He always brought a
slightly-off-kilter view of technical problems, which = triggered
endless discussions of fascinating, if = usually implausible,
alternatives.

He had the most = broad-ranging musical tastes of anyone I knew, and
would eat almost anything (though, like me, he didn't drink = alcohol).
I was often envious of his eating and = musical experiences.  He
certainly lived life = to its fullest.

On one occasion, I recall, we were eating lunch in a Thai = restaurant
for the first time.  Bill called = for the food "the way you'd make it
in Thailand". =  The waiter went back into the kitchen and came out with
a few raw Thai chiles.  Bill ate one whole, without even = breaking a
sweat.  The owner of the restaurant = immediately came out to see who
was eating them. =  Pam became a friend to our group.

On other occasions, when the waiter = asked for his order, Bill would
point to another = person at the table, and say, "I'll have what she's
having."  "Well, what is she having?" "I don't know, I = haven't heard
her say."  Once in a while, he = would point to someone else in the
restaurant and = say, "I'll have what they are having."  It was funny
and sometimes disconcerting, which was very Bill, and it was = also his
way of making sure he himself was eating = (and thinking and doing) as
broadly as possible, = without getting stale.

Bill worked in a bakery before joining Texas Instruments = and
accidentally falling into computer networking. =  (When we first met, he
was commuting between = Houston and L.A.; Julie and the kids were still
in = Houston.)  I believe he attended a series of colleges but = never
finished his bachelor's degree.  Just a = few years ago, however, Jun
Murai convinced him to = get a Ph.D.; this took clearing administrative
hoops = to demonstrate that Bill's life experience matched that of a
bachelor's degree, which it certainly did.  I was = honored to be on his
Ph.D. committee.  I = literally created a "trouble ticket" accounting
scheme to track change requests for his thesis.

Bill was a valued member = of the WIDE Project here in Japan.  He worked
with the DNS root operations group here, and participated in = as many
WIDE meetings as he could.  He also = came to Keio University's Shonan
Fujisawa Campus = when he was in Japan, and one of the best things about
Bill was how seriously he took the students and their work, = treating
them like adult colleagues.

Bill had friends on all = seven continents, and for all I know on the
International Space Station, as well. He was loved by us = all.

Julie = does not plan to have a funeral immediately, so there is no = need
for flowers or the like. The family may do a = memorial service in Utah
in the spring.

He was a unique and = wonderful human being. And a good friend.
Rest in = peace, Bill.

=E2=80=94Rod

Rodney Van Meter
Professor, Faculty of Environment and = Information Studies
Keio University, Japan



On Jan 26, 2020, at 13:06, Jorge Amodio <jmamodio@gmail.com> = wrote:


So sad = :-(

On Sat, Jan 25, 2020 at 9:12 PM Randy Bush <randy@psg.com> wrote:
we have lost another one
=

= --Apple-Mail=_A2A32987-AC6B-4BF6-B9F3-6784D7BEF1AF-- From nobody Sat Jan 25 23:56:52 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB9112009C for ; Sat, 25 Jan 2020 23:56:50 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se 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 KmA573UvD-yc for ; Sat, 25 Jan 2020 23:56:49 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA3F12001B for ; Sat, 25 Jan 2020 23:56:48 -0800 (PST) Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:1c80:d260:ebe6:3320]) by mail.frobbit.se (Postfix) with ESMTPSA id 9778B26C70; Sun, 26 Jan 2020 08:56:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1580025406; bh=O1hA8H2WTyRBlUtWbE3dpkBnXihOHqNtNHrvrTzqcyY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m6nd+IEVLQlhWg1bQS1QnlyYIxQ9VTRW3DZopUpV/4GOTs1OooCerf6nvplfHeywO +qhniMWIioYIt0736npbHX4B77VUfO07jebADgYoV+193AQnjMn8kyEzxKmMN5onSH Df/9E3Q/DJyml+7f0an5+Jh6LEuu8Ftlhgno7pCE= From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Rodney Van Meter" Cc: "Jorge Amodio" , "IETF Rinse Repeat" Subject: Re: bill manning Date: Sun, 26 Jan 2020 08:56:42 +0100 X-Mailer: MailMate (1.13.1r5676) Message-ID: <9B963164-02E4-4028-A78E-7A08B58A4114@frobbit.se> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_B46EE702-21DA-4D6D-A4EC-8E5766B86AE5_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 07:56:51 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_B46EE702-21DA-4D6D-A4EC-8E5766B86AE5_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Rodney for this excellent story. An excellent description of th= e Bill we all knew. I can not describe it better myself. Only give anothe= r series of anecdotes. There where many. This is indeed a sad morning. Best, Patrik On 26 Jan 2020, at 5:34, Rodney Van Meter wrote: > This morning I talked to Julie Manning, Bill's wife. Bill died early Sa= turday morning, at home in Oregon. Most of you know Bill was waiting for= a new heart. He would perhaps have gotten one next month. I guess the ol= d one just wouldn't hold out long enough. > > I first met Bill in about 1995, when I returned to ISI after my first s= tint in Japan. He had taken a position in the Los Nettos project at ISI,= a regional network project in the days when Internet service and operati= ons work was still heavily shared between business and academia. Bill br= ought an operator's eye to the project, often seeing things differently f= rom the researchers in the group. > > Bill kept the most erratic hours of any non-student I've ever met. He = might be in the office at 2am or at 2pm, either was equally likely. > I'd ask, "Bill, what time did you come in?" He'd reply, "10am." "I was= here before that, and you were already here, it must have been earlier."= "Greenwich Mean Time." > > And in one phase of life, "Bill, where do you live?" "Seat 4A." He wou= ld speculate about his average altitude and speed over the previous month= =2E > > And, like any good geek, Bill had a spectacular collection of tie-dye t= -shirts. He came by the look honestly: growing up in the Bay Area, he ha= d actually snuck into Grateful Dead rehearsals held in a barn, and had tr= aveled as a deadhead for a while. > > At ISI, we called Bill "the bad idea fairy". He always brought a sligh= tly-off-kilter view of technical problems, which triggered endless discus= sions of fascinating, if usually implausible, > alternatives. > > He had the most broad-ranging musical tastes of anyone I knew, and woul= d eat almost anything (though, like me, he didn't drink alcohol). > I was often envious of his eating and musical experiences. He certainl= y lived life to its fullest. > > On one occasion, I recall, we were eating lunch in a Thai restaurant fo= r the first time. Bill called for the food "the way you'd make it in Tha= iland". The waiter went back into the kitchen and came out with a few ra= w Thai chiles. Bill ate one whole, without even breaking a sweat. The o= wner of the restaurant immediately came out to see who was eating them. = Pam became a friend to our group. > > On other occasions, when the waiter asked for his order, Bill would poi= nt to another person at the table, and say, "I'll have what she's having.= " "Well, what is she having?" "I don't know, I haven't heard her say." = Once in a while, he would point to someone else in the restaurant and say= , "I'll have what they are having." It was funny and sometimes disconcer= ting, which was very Bill, and it was also his way of making sure he hims= elf was eating (and thinking and doing) as broadly as possible, without g= etting stale. > > Bill worked in a bakery before joining Texas Instruments and accidental= ly falling into computer networking. (When we first met, he was commutin= g between Houston and L.A.; Julie and the kids were still in Houston.) I= believe he attended a series of colleges but never finished his bachelor= 's degree. Just a few years ago, however, Jun Murai convinced him to get= a Ph.D.; this took clearing administrative hoops to demonstrate that Bil= l's life experience matched that of a bachelor's degree, which it certain= ly did. I was honored to be on his Ph.D. committee. I literally created= a "trouble ticket" accounting scheme to track change requests for his th= esis. > > Bill was a valued member of the WIDE Project here in Japan. He worked = with the DNS root operations group here, and participated in as many WIDE= meetings as he could. He also came to Keio University's Shonan Fujisawa= Campus when he was in Japan, and one of the best things about Bill was h= ow seriously he took the students and their work, treating them like adul= t colleagues. > > Bill had friends on all seven continents, and for all I know on the Int= ernational Space Station, as well. He was loved by us all. > > Julie does not plan to have a funeral immediately, so there is no need = for flowers or the like. The family may do a memorial service in Utah in = the spring. > > He was a unique and wonderful human being. And a good friend. > Rest in peace, Bill. > > =E2=80=94Rod > > Rodney Van Meter > Professor, Faculty of Environment and Information Studies > Keio University, Japan > rdv@sfc.wide.ad.jp > > > >> On Jan 26, 2020, at 13:06, Jorge Amodio wrote: >> >> >> So sad :-( >> >> On Sat, Jan 25, 2020 at 9:12 PM Randy Bush > wrote: >> we have lost another one >> --=_MailMate_B46EE702-21DA-4D6D-A4EC-8E5766B86AE5_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCXi1GOg8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182GbgCghuHZz9zsDK0djQEQU6nfxeRChrUAni2lDIAV CBPQTOJC3CumJG/6GHid =x5+B -----END PGP SIGNATURE----- --=_MailMate_B46EE702-21DA-4D6D-A4EC-8E5766B86AE5_=-- From nobody Sun Jan 26 00:14:50 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CE812009E for ; Sun, 26 Jan 2020 00:14:48 -0800 (PST) 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 tOA8Ura0-Gvy for ; Sun, 26 Jan 2020 00:14:47 -0800 (PST) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF52012001B for ; Sun, 26 Jan 2020 00:14:46 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id k4so3884856oik.2 for ; Sun, 26 Jan 2020 00:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wUEciOxT5xwApnOp2jgD9+EbUJnlgtaYWNaSvUhTZRY=; b=mFMhMFiyBi7CsLvWLve6iWgJ7OVqi1Ea0x6NUA7J90TlKZHR5LDvZxRSqihOEYgwau 6erkilF7mLEyA2jv4lsfmarwxCp8HG2j2Mk1JkSm1FkXU7C2ykVjsLkw5KhEHaarJKLe ruPksc15uX5Ktuy3LCEGT6xJzSXzsmgCb05YtKeKlSSJrCnak5w7W7JJEQ1t8qGE0yvb PNg6cmsX5/IJDW9NA/mcyNITIiwxTvBz8Vp09N2YFXvN+VpL+l2CLtMVgjoxo91P/Oh2 Hwf9hqUeLjEPUWCXGsiMJQUIr4rrYp0EScUdotELTvTTpbnOQ0obv8qUgT+hlPkk/z3K seJg== 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=wUEciOxT5xwApnOp2jgD9+EbUJnlgtaYWNaSvUhTZRY=; b=KvI3LHJrEGQu7rjpQH+rjhUJA10xSVmQJL/0+AFstHKQLKmzV+SqNRflw4YagqxryF 0c139cqzr8Zh0BhIO6muN2gQ5PGK4dNxcdb07C08O5K36bZeEUBpTlhviYaDK6bV2VHF uNad2Xs95rL8O4R13fFx/uoHwy1chX5EltryimS9E87qwD3CwsXyKssxSzKF8+iIB6Pa aBnV5DrAUxGvq+D6aXcUpZj7Be/5v5ObDTxZIN/aHZBMaAs6wrEOIBnQJ88RQjPjDkii PU0R3gfJygUd98qrD1Vc9azclwj+jeaQ22QKQsSQd8Fbu84Rd05SOzQqdDGRo2+ZLMYu B3ig== X-Gm-Message-State: APjAAAUxS3nF85yJa9eaN31bSuAIOyEIMiYqiMXkrFpZHmeR6YxwMHXe jyAYGmRqv83puwJ2uVG2OEwn1yReYQwjo4YgGg== X-Google-Smtp-Source: APXvYqxxKN+hiStF+BLbXMPSLGnf1AxTadIgBygabfdJwy4ib90ZcgeNSSq4OXLTHCTvobyPnr1UKOgMZBw6AwT2x9c= X-Received: by 2002:a05:6808:4c2:: with SMTP id a2mr4129040oie.118.1580026486142; Sun, 26 Jan 2020 00:14:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Scott Brim Date: Sun, 26 Jan 2020 03:14:35 -0500 Message-ID: Subject: Re: bill manning To: Rodney Van Meter Cc: Jorge Amodio , IETF Rinse Repeat Content-Type: multipart/alternative; boundary="000000000000713c77059d0695a7" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 08:14:48 -0000 --000000000000713c77059d0695a7 Content-Type: text/plain; charset="UTF-8" Wow. On Friday he seemed optimistic about getting his heart sooner than later. I'm surprised and I'm missing him. --000000000000713c77059d0695a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wow. On Friday he seemed optimistic about getting his hea= rt sooner than later. I'm surprised and I'm missing him.=C2=A0 --000000000000713c77059d0695a7-- From nobody Sun Jan 26 06:53:47 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C1712007A for ; Sun, 26 Jan 2020 06:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 s8nLnMte2m7A for ; Sun, 26 Jan 2020 06:53:44 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 1A6D5120043 for ; Sun, 26 Jan 2020 06:53:44 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id t14so4207764wmi.5 for ; Sun, 26 Jan 2020 06:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3j0iYxuT3W4/klXJO8dURjqXe+C9PQ+dcYpSlSKBJcM=; b=n1buaHaw3YIClBL3n7IIMpaQ4vWmvRPWT4fqbkAwfWQ4soWxIVwGd7U2IsV8dlVNzL ABDi6I/F0C7QmgLcQJSXchw5BCznuP4VsDDNcZCiVKeMl6vL3IsUknLH0eUPs1lR5XYB uBZdUz48tp0lAFmcMbtbxY5KMrbjfW8APd1o2r9jOSyUd5bdUU3DB41kj6Q4KkxqTgi9 JTAsFSqJis584WFaGGvUyRUqteOjTbfKDnJdjMwnL3a4dg9YLn4LWuEDNhs2ddhTjhbO AGuOgWL7RS78Gj3vV9OVpOFK3gLgBSWQBlc5r5GADasl6I2PeIvrg2OCoKJMk+YZ2UAC vtKw== 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=3j0iYxuT3W4/klXJO8dURjqXe+C9PQ+dcYpSlSKBJcM=; b=ZoD3fe6urXXwZuK6CMnSdg23sIUd5ivnvmw7X8oqUNatclctAt4rGXko0gKOtDUC8j GxVJQBGmFKqp3SwF2rV7YBc5/TJ9+HRSBCdGsp6RK4/GX37ruAoZccdwLDi4oJQEMQ5A +WHm7kI4xMNNgG7Xs5IbhGd9Ww3AfCwiBuwgFC81tm4YEaLGFAxd+EM2PA+hF1U2E3G7 QrTvhdnLbm3oLOTT6EkE1WO5ID4y4GmJPTC3GQqnpGdSWXLEoxY3g22KGm+CFlphG6Uj n0wdHBsk0h4UHOi3hmDiTcKVzhww5rriWUQZzn3Y8+SwV1i/iR/NTz6wbplvRVqPuOoP hhKA== X-Gm-Message-State: APjAAAX7x25xtTabfGWwS0EFAS7axrXCXPMQZ3huF0HTqOWpb2bNqDcb GByFQuEJMEGW86VlJTObXvU= X-Google-Smtp-Source: APXvYqzZl48yaOe6NeYh2Knneg0nmnI7E9YvpLZ0YBvwFJXbjhJlqbqVLnZUmR7veCHunXkBnkbEKA== X-Received: by 2002:a1c:1b42:: with SMTP id b63mr9041559wmb.16.1580050422539; Sun, 26 Jan 2020 06:53:42 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:6c29:2058:98ba:d5a8? ([2601:647:5a00:ef0b:6c29:2058:98ba:d5a8]) by smtp.gmail.com with ESMTPSA id i16sm15603927wmb.36.2020.01.26.06.53.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jan 2020 06:53:41 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_86143923-EF61-47C8-9787-DAC214EE483E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: bill manning Date: Sun, 26 Jan 2020 06:53:38 -0800 In-Reply-To: Cc: Bob Hinden , IETF To: Rodney Van Meter References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 14:53:46 -0000 --Apple-Mail=_86143923-EF61-47C8-9787-DAC214EE483E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rod, Thanks for the very nice note about Bill. I too will miss him. Please express my condolences to Julie and the rest of his family. Bob > On Jan 25, 2020, at 8:34 PM, Rodney Van Meter = wrote: >=20 >=20 > This morning I talked to Julie Manning, Bill's wife. Bill died early > Saturday morning, at home in Oregon. Most of you know Bill was > waiting for a new heart. He would perhaps have gotten one next > month. I guess the old one just wouldn't hold out long enough. >=20 > I first met Bill in about 1995, when I returned to ISI after my first > stint in Japan. He had taken a position in the Los Nettos project at > ISI, a regional network project in the days when Internet service and > operations work was still heavily shared between business and > academia. Bill brought an operator's eye to the project, often seeing > things differently from the researchers in the group. >=20 > Bill kept the most erratic hours of any non-student I've ever met. He > might be in the office at 2am or at 2pm, either was equally likely. > I'd ask, "Bill, what time did you come in?" He'd reply, "10am." "I > was here before that, and you were already here, it must have been > earlier." "Greenwich Mean Time." >=20 > And in one phase of life, "Bill, where do you live?" "Seat 4A." He > would speculate about his average altitude and speed over the previous > month. >=20 > And, like any good geek, Bill had a spectacular collection of tie-dye > t-shirts. He came by the look honestly: growing up in the Bay Area, > he had actually snuck into Grateful Dead rehearsals held in a barn, > and had traveled as a deadhead for a while. >=20 > At ISI, we called Bill "the bad idea fairy". He always brought a > slightly-off-kilter view of technical problems, which triggered > endless discussions of fascinating, if usually implausible, > alternatives. >=20 > He had the most broad-ranging musical tastes of anyone I knew, and > would eat almost anything (though, like me, he didn't drink alcohol). > I was often envious of his eating and musical experiences. He > certainly lived life to its fullest. >=20 > On one occasion, I recall, we were eating lunch in a Thai restaurant > for the first time. Bill called for the food "the way you'd make it > in Thailand". The waiter went back into the kitchen and came out with > a few raw Thai chiles. Bill ate one whole, without even breaking a > sweat. The owner of the restaurant immediately came out to see who > was eating them. Pam became a friend to our group. >=20 > On other occasions, when the waiter asked for his order, Bill would > point to another person at the table, and say, "I'll have what she's > having." "Well, what is she having?" "I don't know, I haven't heard > her say." Once in a while, he would point to someone else in the > restaurant and say, "I'll have what they are having." It was funny > and sometimes disconcerting, which was very Bill, and it was also his > way of making sure he himself was eating (and thinking and doing) as > broadly as possible, without getting stale. >=20 > Bill worked in a bakery before joining Texas Instruments and > accidentally falling into computer networking. (When we first met, he > was commuting between Houston and L.A.; Julie and the kids were still > in Houston.) I believe he attended a series of colleges but never > finished his bachelor's degree. Just a few years ago, however, Jun > Murai convinced him to get a Ph.D.; this took clearing administrative > hoops to demonstrate that Bill's life experience matched that of a > bachelor's degree, which it certainly did. I was honored to be on his > Ph.D. committee. I literally created a "trouble ticket" accounting > scheme to track change requests for his thesis. >=20 > Bill was a valued member of the WIDE Project here in Japan. He worked > with the DNS root operations group here, and participated in as many > WIDE meetings as he could. He also came to Keio University's Shonan > Fujisawa Campus when he was in Japan, and one of the best things about > Bill was how seriously he took the students and their work, treating > them like adult colleagues. >=20 > Bill had friends on all seven continents, and for all I know on the > International Space Station, as well. He was loved by us all. >=20 > Julie does not plan to have a funeral immediately, so there is no need > for flowers or the like. The family may do a memorial service in Utah > in the spring. >=20 > He was a unique and wonderful human being. And a good friend. > Rest in peace, Bill. >=20 > =E2=80=94Rod >=20 > Rodney Van Meter > Professor, Faculty of Environment and Information Studies > Keio University, Japan > rdv@sfc.wide.ad.jp >=20 >=20 >=20 >> On Jan 26, 2020, at 13:06, Jorge Amodio wrote: >>=20 >>=20 >> So sad :-( >>=20 >> On Sat, Jan 25, 2020 at 9:12 PM Randy Bush wrote: >> we have lost another one >>=20 >=20 --Apple-Mail=_86143923-EF61-47C8-9787-DAC214EE483E 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl4tp/IACgkQrut0EXfn u6gC+wgAv9Oix88GkgSKFHW4fIjoW6PZscwkC/qLymoppyLl6/x2CfDHUZOWmx0c QZEFNGHp9pAWT0lW86/do1SNZCW4I1/4w2k5MYMsJEgwP/gfooLKyFWOOViSYM29 udKgEemCp4kU+ka9IkYyQPbfzO79+vCwXS/+5v+qXvcHqu9K//qwhUPPcBXgG5nw 4aX4k0xgpwGpRuHy1d5+izDoVe88S4ExTa0xcOIUNCSWgyvcfBiPS3fwJnj/XYGE it6JBYj2Frq1qqh1cbOMUy3lHgUntu5rVFwF/dbYmkFjXKf+44hIjuEL1Jk7m4Wl Rr8xafSjiCXpjOvGDRFbggwUPoL6pQ== =wMnz -----END PGP SIGNATURE----- --Apple-Mail=_86143923-EF61-47C8-9787-DAC214EE483E-- From nobody Sun Jan 26 13:57:21 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DBE1200B6 for ; Sun, 26 Jan 2020 13:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=academ-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 VBr8M2SzrRlQ for ; Sun, 26 Jan 2020 13:57:16 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 60D7F120052 for ; Sun, 26 Jan 2020 13:57:16 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id y19so4882793lfl.9 for ; Sun, 26 Jan 2020 13:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=academ-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EBKNAZbLib7krJkQwOdmavW0z0xOgT3aOn9/1kZ//Yg=; b=LfCYlT2IHaFmCOOlh8VJywhwx60WqNc/ZBUW4fZ928ODUC764USbWwEJhS+kYNROhh bM1fKrF3w6FJ3ctZQpRUbN0oG2+IvL3Y9lC/Dlo+C+XqB16E+k2YUU5fzRp2pa0CnXB5 G/NOC++wmAnHBHWU/HfrFGBcUwCoYJskNOVvi2ipl/Gupi/KV5xH8hC5QKMAyL/8f7QJ Ff81JWKE0SLaAz2hONQbJToQd3EP+ABeiJHk4QD1Y7mKUpPz/2BjQ/b+eA1Cs1RO1GWh cZUmkYoWSBbkacghz2jeSE2KlNodMvkDIhqYICYB5nQxVN8Witun0LTzomoUyVqmQGlr FIRw== 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=EBKNAZbLib7krJkQwOdmavW0z0xOgT3aOn9/1kZ//Yg=; b=Fh7tXRh5toDrshKxfan8GljpdseMVhosRknxUoNQO+iFJpCtnMOyowHGUQtqryWFXR 5shZ7Q1DvdNh0QjqkItpfo9XUUSq9KbB707aEZX/u5rjfGtgZczmK8E1gsojkfM0Yv9U mYWBv50FvfIXGpY5XWiu8tr1uDHmHP/yYnm2yIWMuHwZ7oye1vLMW5xJ2zfpPLtIKJox mGsgkelxin6ifTJ64ixkYnRBah6r/wKUxFXfoRWib+xD3cx2NYdNh4fIt8c7vhwKjf6P mmGWY8RnViFCJukNXC6VsFcJP/6IVdB/UCgFNS4m4AIRLFuvg2576ewRCuY0x+0ir1PK dDQg== X-Gm-Message-State: APjAAAXct9sxyppeWSfI2GAEqqSYHUDz57cOn+ouPksIjosRbYRezsJ3 TaHyvvKE1mR0JzHfp3yvtYi75aAft4qbiwg8n0MeRA== X-Google-Smtp-Source: APXvYqxJdok5AI72r0sQDHwyEAYrKsBiESUqBCEV35Aff8+1s7kVVu+xiG9vS/02tqPdaMjLdy+KoVCP6FcdUO88YGw= X-Received: by 2002:ac2:5f74:: with SMTP id c20mr6407203lfc.15.1580075834298; Sun, 26 Jan 2020 13:57:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stan Barber Date: Sun, 26 Jan 2020 13:57:03 -0800 Message-ID: Subject: Re: bill manning To: Bob Hinden Cc: IETF , Rodney Van Meter Content-Type: multipart/alternative; boundary="000000000000d2667a059d12129e" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 21:57:20 -0000 --000000000000d2667a059d12129e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I knew Bill early in my career while he was at Rice when Sesquinet was starting up. I worked for Sesquinet=E2=80=99s first customer, Baylor Colleg= e of Medicine, at the time, and worked him often as that effort was started. I offer condolences to his loved ones. I will always remember him fondly. On Sun, Jan 26, 2020 at 6:54 AM Bob Hinden wrote: > Rod, > > Thanks for the very nice note about Bill. I too will miss him. > > Please express my condolences to Julie and the rest of his family. > > Bob > > > > On Jan 25, 2020, at 8:34 PM, Rodney Van Meter 40sfc.wide.ad.jp@dmarc.ietf.org> wrote: > > > > > > This morning I talked to Julie Manning, Bill's wife. Bill died early > > Saturday morning, at home in Oregon. Most of you know Bill was > > waiting for a new heart. He would perhaps have gotten one next > > month. I guess the old one just wouldn't hold out long enough. > > > > I first met Bill in about 1995, when I returned to ISI after my first > > stint in Japan. He had taken a position in the Los Nettos project at > > ISI, a regional network project in the days when Internet service and > > operations work was still heavily shared between business and > > academia. Bill brought an operator's eye to the project, often seeing > > things differently from the researchers in the group. > > > > Bill kept the most erratic hours of any non-student I've ever met. He > > might be in the office at 2am or at 2pm, either was equally likely. > > I'd ask, "Bill, what time did you come in?" He'd reply, "10am." "I > > was here before that, and you were already here, it must have been > > earlier." "Greenwich Mean Time." > > > > And in one phase of life, "Bill, where do you live?" "Seat 4A." He > > would speculate about his average altitude and speed over the previous > > month. > > > > And, like any good geek, Bill had a spectacular collection of tie-dye > > t-shirts. He came by the look honestly: growing up in the Bay Area, > > he had actually snuck into Grateful Dead rehearsals held in a barn, > > and had traveled as a deadhead for a while. > > > > At ISI, we called Bill "the bad idea fairy". He always brought a > > slightly-off-kilter view of technical problems, which triggered > > endless discussions of fascinating, if usually implausible, > > alternatives. > > > > He had the most broad-ranging musical tastes of anyone I knew, and > > would eat almost anything (though, like me, he didn't drink alcohol). > > I was often envious of his eating and musical experiences. He > > certainly lived life to its fullest. > > > > On one occasion, I recall, we were eating lunch in a Thai restaurant > > for the first time. Bill called for the food "the way you'd make it > > in Thailand". The waiter went back into the kitchen and came out with > > a few raw Thai chiles. Bill ate one whole, without even breaking a > > sweat. The owner of the restaurant immediately came out to see who > > was eating them. Pam became a friend to our group. > > > > On other occasions, when the waiter asked for his order, Bill would > > point to another person at the table, and say, "I'll have what she's > > having." "Well, what is she having?" "I don't know, I haven't heard > > her say." Once in a while, he would point to someone else in the > > restaurant and say, "I'll have what they are having." It was funny > > and sometimes disconcerting, which was very Bill, and it was also his > > way of making sure he himself was eating (and thinking and doing) as > > broadly as possible, without getting stale. > > > > Bill worked in a bakery before joining Texas Instruments and > > accidentally falling into computer networking. (When we first met, he > > was commuting between Houston and L.A.; Julie and the kids were still > > in Houston.) I believe he attended a series of colleges but never > > finished his bachelor's degree. Just a few years ago, however, Jun > > Murai convinced him to get a Ph.D.; this took clearing administrative > > hoops to demonstrate that Bill's life experience matched that of a > > bachelor's degree, which it certainly did. I was honored to be on his > > Ph.D. committee. I literally created a "trouble ticket" accounting > > scheme to track change requests for his thesis. > > > > Bill was a valued member of the WIDE Project here in Japan. He worked > > with the DNS root operations group here, and participated in as many > > WIDE meetings as he could. He also came to Keio University's Shonan > > Fujisawa Campus when he was in Japan, and one of the best things about > > Bill was how seriously he took the students and their work, treating > > them like adult colleagues. > > > > Bill had friends on all seven continents, and for all I know on the > > International Space Station, as well. He was loved by us all. > > > > Julie does not plan to have a funeral immediately, so there is no need > > for flowers or the like. The family may do a memorial service in Utah > > in the spring. > > > > He was a unique and wonderful human being. And a good friend. > > Rest in peace, Bill. > > > > =E2=80=94Rod > > > > Rodney Van Meter > > Professor, Faculty of Environment and Information Studies > > Keio University, Japan > > rdv@sfc.wide.ad.jp > > > > > > > >> On Jan 26, 2020, at 13:06, Jorge Amodio wrote: > >> > >> > >> So sad :-( > >> > >> On Sat, Jan 25, 2020 at 9:12 PM Randy Bush wrote: > >> we have lost another one > >> > > > > --000000000000d2667a059d12129e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I knew Bill early in my career while = he was at Rice when Sesquinet was starting up. I worked for Sesquinet=E2=80= =99s first customer, Baylor College of Medicine, at the time, and worked hi= m often as that effort was started.

I offer condolences to his loved ones. I will always remember h= im fondly.

On Sun, Jan 26, 2020 at 6:54 AM Bob Hinden <bob.hinden@gmail.com> wrote:
Rod,

Thanks for the very nice note about Bill.=C2=A0 I too will miss him.

Please express my condolences to Julie and the rest of his family.

Bob


> On Jan 25, 2020, at 8:34 PM, Rodney Van Meter <rdv=3D40sfc.wide.ad.jp@dma= rc.ietf.org> wrote:
>
>
> This morning I talked to Julie Manning, Bill's wife. Bill died ear= ly
> Saturday morning, at home in Oregon.=C2=A0 Most of you know Bill was > waiting for a new heart. He would perhaps have gotten one next
> month. I guess the old one just wouldn't hold out long enough.
>
> I first met Bill in about 1995, when I returned to ISI after my first<= br> > stint in Japan.=C2=A0 He had taken a position in the Los Nettos projec= t at
> ISI, a regional network project in the days when Internet service and<= br> > operations work was still heavily shared between business and
> academia.=C2=A0 Bill brought an operator's eye to the project, oft= en seeing
> things differently from the researchers in the group.
>
> Bill kept the most erratic hours of any non-student I've ever met.= =C2=A0 He
> might be in the office at 2am or at 2pm, either was equally likely. > I'd ask, "Bill, what time did you come in?" He'd rep= ly, "10am."=C2=A0 "I
> was here before that, and you were already here, it must have been
> earlier."=C2=A0 "Greenwich Mean Time."
>
> And in one phase of life, "Bill, where do you live?" "S= eat 4A."=C2=A0 He
> would speculate about his average altitude and speed over the previous=
> month.
>
> And, like any good geek, Bill had a spectacular collection of tie-dye<= br> > t-shirts.=C2=A0 He came by the look honestly: growing up in the Bay Ar= ea,
> he had actually snuck into Grateful Dead rehearsals held in a barn, > and had traveled as a deadhead for a while.
>
> At ISI, we called Bill "the bad idea fairy".=C2=A0 He always= brought a
> slightly-off-kilter view of technical problems, which triggered
> endless discussions of fascinating, if usually implausible,
> alternatives.
>
> He had the most broad-ranging musical tastes of anyone I knew, and
> would eat almost anything (though, like me, he didn't drink alcoho= l).
> I was often envious of his eating and musical experiences.=C2=A0 He > certainly lived life to its fullest.
>
> On one occasion, I recall, we were eating lunch in a Thai restaurant > for the first time.=C2=A0 Bill called for the food "the way you&#= 39;d make it
> in Thailand".=C2=A0 The waiter went back into the kitchen and cam= e out with
> a few raw Thai chiles.=C2=A0 Bill ate one whole, without even breaking= a
> sweat.=C2=A0 The owner of the restaurant immediately came out to see w= ho
> was eating them.=C2=A0 Pam became a friend to our group.
>
> On other occasions, when the waiter asked for his order, Bill would > point to another person at the table, and say, "I'll have wha= t she's
> having."=C2=A0 "Well, what is she having?" "I don&= #39;t know, I haven't heard
> her say."=C2=A0 Once in a while, he would point to someone else i= n the
> restaurant and say, "I'll have what they are having."=C2= =A0 It was funny
> and sometimes disconcerting, which was very Bill, and it was also his<= br> > way of making sure he himself was eating (and thinking and doing) as > broadly as possible, without getting stale.
>
> Bill worked in a bakery before joining Texas Instruments and
> accidentally falling into computer networking.=C2=A0 (When we first me= t, he
> was commuting between Houston and L.A.; Julie and the kids were still<= br> > in Houston.)=C2=A0 I believe he attended a series of colleges but neve= r
> finished his bachelor's degree.=C2=A0 Just a few years ago, howeve= r, Jun
> Murai convinced him to get a Ph.D.; this took clearing administrative<= br> > hoops to demonstrate that Bill's life experience matched that of a=
> bachelor's degree, which it certainly did.=C2=A0 I was honored to = be on his
> Ph.D. committee.=C2=A0 I literally created a "trouble ticket"= ; accounting
> scheme to track change requests for his thesis.
>
> Bill was a valued member of the WIDE Project here in Japan.=C2=A0 He w= orked
> with the DNS root operations group here, and participated in as many > WIDE meetings as he could.=C2=A0 He also came to Keio University's= Shonan
> Fujisawa Campus when he was in Japan, and one of the best things about=
> Bill was how seriously he took the students and their work, treating > them like adult colleagues.
>
> Bill had friends on all seven continents, and for all I know on the > International Space Station, as well. He was loved by us all.
>
> Julie does not plan to have a funeral immediately, so there is no need=
> for flowers or the like. The family may do a memorial service in Utah<= br> > in the spring.
>
> He was a unique and wonderful human being. And a good friend.
> Rest in peace, Bill.
>
> =E2=80=94Rod
>
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies
> Keio University, Japan
> rdv@sfc.wide.a= d.jp
>
>
>
>> On Jan 26, 2020, at 13:06, Jorge Amodio <jmamodio@gmail.com> wrote:
>>
>>
>> So sad :-(
>>
>> On Sat, Jan 25, 2020 at 9:12 PM Randy Bush <randy@psg.com> wrote:
>> we have lost another one
>>
>

--000000000000d2667a059d12129e-- From nobody Mon Jan 27 07:42:22 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D5D12086F for ; Mon, 27 Jan 2020 07:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdBK-rifF7mP for ; Mon, 27 Jan 2020 07:42:14 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 26199120870 for ; Mon, 27 Jan 2020 07:42:14 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id q15so3570722qki.2 for ; Mon, 27 Jan 2020 07:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OeL1b1H6C2oe+HhPorA6DfJUDHbCI7CkBDxlfeh7YfE=; b=vDij3anaFxu/si652Tnzb+E7q1zVqcQAg+SxnEcU0HIpBDnV8xPO0fNUBGHZ9hdlaU d9Gx/rE0rPdkj0nbVN7CQ6JXGC9HGW33Cs95yL7W6IJJoXcYwJHybk+Nqpyif8gi/sQa 8VGt1LfzQQvx2PqlmL0P4ZXe1mJNpVxPuYu/FlUiJ4pNK9kVMCYRdyzGvw1lNsyH00Ah Rs96cesVqEqrnhThYpCme6O9NxAFLJyjtKff7/34s4oPSl+hkBnrovfMIKkq9rh79ems pO24HKZ+3DzgkjFgeygbP4+YoblJUcpA740AOfRjf1Fhf3ZrBtOOuu6xFscdtKuBuQru nLRw== 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=OeL1b1H6C2oe+HhPorA6DfJUDHbCI7CkBDxlfeh7YfE=; b=DNXBpZN4sNxtRp3tF0VHT9FvkuxnVG6gXPGm/47a2TeIcdJ5i6nKCzwlaqImaoQadq +WYSTyVKhP//Yju3LVkl5qGFexjg93i4DfsI0W5EGhBuKe32rboZaK3eCmjZHHF0JRRr EFZqbGRw5jbqULd4907cx4p5spRn+cFMus41C4nkmel2GTX03VD/UUuue9mQik3C188Q KlavsGU2ohvAJAaL7kDOHzeaslsHcltFN3310QqPeEVOhJdAgD0cdmXsqP35YszblZhw jBnBE9vX9MfR+r3qIOV7ARNCzc5W2aEFYKjMttmBwJWO9ewYi2n50TOKpJWqcu3PMzvO KzNA== X-Gm-Message-State: APjAAAU1StaznDDg3EvlQlFsnZX+XjTI2DbwuGv4ZgGU679OLfI1fW9E 1oAfpKbdmcNjLjAbdKB7J22j3A0f6WqffrL+x2c= X-Google-Smtp-Source: APXvYqzyc+MBHf5obO+N31QZS638ell3skR7qCuERu/nTa7sjE6toPaeq8K5wzL1BVdz5s2CE2F0aPLe6Cukc2QuAUE= X-Received: by 2002:a37:d94:: with SMTP id 142mr17289801qkn.143.1580139733303; Mon, 27 Jan 2020 07:42:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Davey Song Date: Mon, 27 Jan 2020 23:42:02 +0800 Message-ID: Subject: Re: bill manning To: Randy Bush Cc: IETF Rinse Repeat Content-Type: multipart/alternative; boundary="0000000000007fc59e059d20f308" Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 15:42:20 -0000 --0000000000007fc59e059d20f308 Content-Type: text/plain; charset="UTF-8" Bill is one of a few guys who guide me into the community. He teach me the difference between tactical thinking and strategical one. So Sad to hear his passing Davey On Sun, 26 Jan 2020 at 11:12, Randy Bush wrote: > we have lost another one > > --0000000000007fc59e059d20f308 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bill is one of a few guys who guide me into the commu= nity. He teach me the difference between tactical thinking and=C2=A0strateg= ical one.=C2=A0=C2=A0

So Sad to hear his passing= =C2=A0

Davey

On Sun, 26 Jan 2020 at 11:12= , Randy Bush <randy@psg.com> wro= te:
we have lost= another one

--0000000000007fc59e059d20f308-- From nobody Tue Jan 28 14:35:25 2020 Return-Path: X-Original-To: ietf@ietf.org Delivered-To: ietf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A62912004D; Tue, 28 Jan 2020 14:35:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: "IETF Announcement List" Cc: recentattendees@ietf.org, ietf@ietf.org, 107all@ietf.org Subject: REMINDER: Early Bird Cutoff is Monday, February 3rd at 23:59 X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: agenda@ietf.org Message-ID: <158025091551.4533.18398966038084784560.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2020 14:35:15 -0800 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 22:35:16 -0000 IETF 107 Vancouver, Canada March 21-27, 2020 Hosted By: Huawei IETF 107 Information: https://www.ietf.org/how/meetings/107/ Register online at: https://ietf.org/how/meetings/register/ 1. Registration 2. Visas & Letters of Invitation 3. Accommodations 4. Code Sprint 5. Hackathon 1. Registration: Early Bird Deadline: The early bird deadline for registration is Monday, February 3rd. Be sure to register and pay before the deadline passes! Register online at: https://www.ietf.org/how/meetings/register/ NOTE: If you have started the registration process but not completed payment, your registration record will be deleted at UTC 23:59 on February 3rd. After February 3rd at UTC 23:59 you will be required to re-enter your data and the registration fee will be $875 USD until the next registration deadline on March 9th, at which the registration fee will become $1,000 USD. 2. Visas & Letters of Invitation: NOTE: If you require a visa for IETF 107, please request a letter of invitation immediately and begin the application process. The IETF is providing the letter of invitation for IETF 107. If you experience issues using this letter to obtain a visa, please contact registrar@ietf.org immediately for assistance. If you’ve previously attended an IETF meeting, you can request a letter of invitation here: https://www.ietf.org/registration/letterofinvite/singleletter.py 3. Accommodations: NOTE: Daily Breakfast is NOT included with any IETF hotel rates below. 1. Hyatt Regency Vancouver - Meeting Venue (Headquarters Hotel, block of 450 rooms) Room Rate: $249 CAD (single/double) Room Rates DO NOT include daily breakfast. Room rate includes in-room high-speed Internet access and health club benefits. Taxes of 5% GST, 8% PST, 3% Occupancy, and 1.5% Destination Fee (subject to change) are excluded in the above rate. Taxes subject to change without notice. Reservation Cutoff Date: 02 March 2020 Cancel with No Penalty: 3 days prior to check-in/arrival Distance to Meeting Venue: N/A Reservations: https://tinyurl.com/107HYATT Overflow Hotel: 2. Sutton Place Hotel - (Overflow Hotel, block of 200 rooms) Room Rate: $230 CAD (single) $250 CAD (double) Room Rates DO NOT include daily breakfast. Room Rate includes in-room high-speed Internet access and complimentary access to in-house Business Center and Fitness Center. Lodging taxes of 12.5% and GST of 5% are not included in the above rate and are subject to change. Reservation Cutoff Date: 06 March 2020 Cancel with No Penalty: 72 hours prior to check-in/arrival Distance to Meeting Venue: 350 meters (5 minute walk) Reservations: https://tinyurl.com/107SUTTON 3. Metropolitan Hotel - (Overflow Hotel, block of 23 rooms) Room Rate: $229 CAD (single/double) Room Rates DO NOT include daily breakfast. Room Rate includes in-room high speed internet access and to Hotel Business Center, Fitness area, pools and saunas. Lodging rates of 11% and GST 5% (subject to change) are not included in the above rate. Reservation Cutoff Date: 26 February 2020 Cancel with No Penalty: 72 hours prior to check-in/arrival Distance to Meeting Venue: 350 meters (5 minute walk) Reservations: https://tinyurl.com/107METROPOLITAN 4. Coast Coal Harbour Hotel - (Overflow Hotel, block of 50 rooms) Room Rate: $195 CAD (single/double) Room Rates DO NOT include daily breakfast. Room Rate includes in-room high speed internet and access to Hotel Business Center, Fitness area, pools and whirlpool. Lodging taxes of 17.5% (subject to change) are not included in Room Rate. Reservation Cutoff Date: 26 February 2020 Cancel with No Penalty: 72 Hour prior to check in (Non-refundable 1 night deposit) Distance to Meeting Venue: 350 meters (5 minute walk) Reservations: https://tinyurl.com/107COASTCOAL 5. Fairmont Hotel Vancouver - (Overflow Hotel, Based on overall hotel availability) Room Rate: $249 CAD (single/double) Room Rates DO NOT include daily breakfast. Room Rate includes complimentary in-room internet. Municipal Hotel Tax 11%, GST 5% and Destination Marketing Fee Tax of 1.5% are not included in the above room rate. Taxes subject to change without notice. Reservation Cutoff Date: N/A Cancel with No Penalty: 48 Hour prior to check in/ arrival (Non-refundable 1 night deposit) Distance to Meeting Venue: 650 meters (9 minute walk) Reservations: https://tinyurl.com/107FAIRMONT More details at: https://www.ietf.org/how/meetings/107/hotel/ 4. Code Sprint The IETF 107 Code Sprint in Vancouver will, as always, let you work on fixing those things about the datatracker which you most urgently desire to do something about. When: Saturday, March 21 from 09:30 to 18:00 Where: Hyatt Regency Vancouver, Room TBD Signup: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF107SprintSignUp More information: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF107Sprint 5. Hackathon The IETF is holding a Hackathon at IETF 107 to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. When: Saturday March 21 and Sunday March 22 Where: Hyatt Regency Vancouver, Room TBD Signup for the Hackathon: https://www.ietf.org/registration/ietf107/hackathonregistration.py More information can be found here: https://www.ietf.org/how/runningcode/hackathons/107-hackathon/ Keep up to date by subscribing to: https://www.ietf.org/mailman/listinfo/hackathon The Hackathon is free to attend and open to all. Extend the invitation to colleagues outside the IETF! Descriptions and information regarding the technologies for the hackathon are located on the IETF 107 Meeting Wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/107hackathon Don’t see anything that interests you? Feel free to add your preferred technology to the list, sign up as its Champion and show up to work on it. Note: you must login to the wiki to add content. If you do add a new technology, we strongly suggest that you send an email to hackathon@ietf.org to let others know. You may generate interest in your technology, and find other people who want to contribute to it. From nobody Thu Jan 30 20:39:26 2020 Return-Path: X-Original-To: ietf@ietf.org Delivered-To: ietf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9846120044; Thu, 30 Jan 2020 20:39:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: NomCom Chair 2019 To: "IETF Announcement List" Cc: ietf@ietf.org Subject: NomCom 2019 Announcement of IESG selections X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <158044556379.4435.14118306726719300583.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2020 20:39:23 -0800 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 04:39:24 -0000 As chair of the 2019-2020 NomCom, it gives me great pleasure to announce the results of the NomCom selection process for the IESG positions to serve for the 2020-2022 cycle. All the IESG candidates noted below have been confirmed by the IAB. The selected candidates for the IESG are: Murray Kucherawy, Facebook, ART AD Erik Kline, Loon LLC, INT AD Robert Wilton, Cisco Systems, MGT AD Martin Vigoureux, Nokia, RTG AD Benjamin Kaduk, Akamai Technologies, SEC AD Martin Duke, F5 Networks Inc, TSV AD The resulting IESG will consist of: Alissa Cooper, Cisco, General Area Director / IETF Chair Murray Kucherawy, Facebook, Applications and Real-Time Area Director Barry Leiba, Futurewei Technologies, Applications and Real-Time Area Director Éric Vyncke, Cisco, Internet Area Director Erik Kline, Loon LLC, Internet Area Director Robert Wilton, Cisco, Operations and Management Area Director (Management) Warren Kumari, Google, Operations and Management Area Director (Operations) Alvaro Retana, Futurewei Technologies, Routing Area Director Deborah Brungard, AT&T, Routing Area Director Martin Vigoureux, Nokia, Routing Area Director Benjamin Kaduk, Akamai Technologies, Security Area Director Roman Danyliw, CERT/SEI, Security Area Director Magnus Westerlund, Ericsson, Transport Area Director Martin Duke, F5 Networks Inc, Transport Area Director The members of the NomCom thank all of the members of the community who offered to serve on the IESG. Additionally, our thanks go out to the many members of the community who have supported the NomCom process. With this announcement, the regular work of the 2019-2020 NonCom is complete. I wish to thank all the NomCom members who worked so hard this year and all the community members who put their name forth to volunteer for NomCom. Regards, Victor Kuarsingh 2019-2020 IETF NomCom Chair victor at jvknet dot com nomcom-chair-2019 at ietf dot org From nobody Thu Jan 30 21:53:13 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB37120255 for ; Thu, 30 Jan 2020 21:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 Fbg_qvmUytzY for ; Thu, 30 Jan 2020 21:53:11 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 64A2712001E for ; Thu, 30 Jan 2020 21:53:11 -0800 (PST) Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00V5mffU084568 for ; Fri, 31 Jan 2020 00:53:10 -0500 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com with ESMTP id 2xuvd6a01r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Jan 2020 00:53:10 -0500 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 00V5qXlo005618 for ; Fri, 31 Jan 2020 05:53:09 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma01dal.us.ibm.com with ESMTP id 2xrda7pk49-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Jan 2020 05:53:09 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 00V5r9am46203214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 31 Jan 2020 05:53:09 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E953BB2065 for ; Fri, 31 Jan 2020 05:53:08 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D37A9B205F for ; Fri, 31 Jan 2020 05:53:08 +0000 (GMT) Received: from rotala.raleigh.ibm.com (unknown [9.27.200.19]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTPS for ; Fri, 31 Jan 2020 05:53:08 +0000 (GMT) Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.15.2/8.15.2) with ESMTP id 00V5r6qL016761 for ; Fri, 31 Jan 2020 00:53:06 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.15.2/8.15.2/Submit) id 00V5r6Md016719 for ietf@ietf.org; Fri, 31 Jan 2020 00:53:06 -0500 From: narten@us.ibm.com Message-Id: <202001310553.00V5r6Md016719@rotala.raleigh.ibm.com> Date: Fri, 31 Jan 2020 00:53:05 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-31_01:2020-01-30, 2020-01-31 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 phishscore=0 suspectscore=13 impostorscore=0 bulkscore=0 mlxlogscore=550 spamscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2001310050 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 05:53:13 -0000 Total of 14 messages in the last 7 days. script run at: Fri 31 Jan 2020 12:53:05 AM EST Messages | Bytes | Who --------+------+--------+----------+------------------------ 7.14% | 1 | 12.13% | 22167 | sob@academ.com 7.14% | 1 | 11.54% | 21102 | rdv=40sfc.wide.ad.jp@dmarc.ietf.org 7.14% | 1 | 9.48% | 17329 | ietf-secretariat@ietf.org 7.14% | 1 | 8.61% | 15742 | bob.hinden@gmail.com 7.14% | 1 | 7.67% | 14019 | paf=40frobbit.se@dmarc.ietf.org 7.14% | 1 | 7.61% | 13913 | chair@ietf.org 7.14% | 1 | 6.34% | 11592 | sayrer@gmail.com 7.14% | 1 | 6.26% | 11446 | narten@us.ibm.com 7.14% | 1 | 5.65% | 10321 | warren@kumari.net 7.14% | 1 | 5.63% | 10295 | songlinjian@gmail.com 7.14% | 1 | 5.39% | 9854 | jmamodio@gmail.com 7.14% | 1 | 5.29% | 9672 | scott.brim@gmail.com 7.14% | 1 | 4.55% | 8320 | nomcom-chair-2019@ietf.org 7.14% | 1 | 3.85% | 7041 | randy@psg.com --------+------+--------+----------+------------------------ 100.00% | 14 |100.00% | 182813 | Total From nobody Fri Jan 31 10:12:33 2020 Return-Path: X-Original-To: ietf@ietf.org Delivered-To: ietf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3042212092D; Fri, 31 Jan 2020 10:12:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: "IETF Announcement List" Cc: recentattendees@ietf.org, ietf@ietf.org, 107all@ietf.org Subject: REMINDER: Early Bird Cutoff is Monday, February 3rd at 23:59 X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: agenda@ietf.org Message-ID: <158049434712.21235.12161160679865740891.idtracker@ietfa.amsl.com> Date: Fri, 31 Jan 2020 10:12:27 -0800 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 18:12:27 -0000 IETF 107 Vancouver, Canada March 21-27, 2020 Hosted By: Huawei IETF 107 Information: https://www.ietf.org/how/meetings/107/ Register online at: https://ietf.org/how/meetings/register/ 1. Registration 2. Visas & Letters of Invitation 3. Accommodations 4. Code Sprint 5. Hackathon 1. Registration: Early Bird Deadline The early bird deadline for registration is Monday, February 3rd. Be sure to register and pay before the deadline passes! Register online at: https://www.ietf.org/how/meetings/register/ NOTE: If you have started the registration process but not completed payment, your registration record will be deleted at UTC 23:59 on February 3rd. After February 3rd at UTC 23:59 you will be required to re-enter your data and the registration fee will be $875 USD until the next registration deadline on March 9th, at which the registration fee will become $1,000 USD. 2. Visas & Letters of Invitation: NOTE: If you require a visa for IETF 107, please request a letter of invitation immediately and begin the application process. The IETF is providing the letter of invitation for IETF 107. If you experience issues using this letter to obtain a visa, please contact registrar@ietf.org immediately for assistance. If you’ve previously attended an IETF meeting, you can request a letter of invitation here: https://www.ietf.org/registration/letterofinvite/singleletter.py 3. Accommodations: NOTE: Daily Breakfast is NOT included with any IETF hotel rates below. 1. Hyatt Regency Vancouver - Meeting Venue (Headquarters Hotel, block of 450 rooms) Room Rate: $249 CAD (single/double) Room Rates DO NOT include daily breakfast. Room rate includes in-room high-speed Internet access and health club benefits. Taxes of 5% GST, 8% PST, 3% Occupancy, and 1.5% Destination Fee (subject to change) are excluded in the above rate. Taxes subject to change without notice. Reservation Cutoff Date: 02 March 2020 Cancel with No Penalty: 3 days prior to check-in/arrival Distance to Meeting Venue: N/A Reservations: https://tinyurl.com/107HYATT Overflow Hotel: 2. Sutton Place Hotel - (Overflow Hotel, block of 200 rooms) Room Rate: $230 CAD (single) $250 CAD (double) Room Rates DO NOT include daily breakfast. Room Rate includes in-room high-speed Internet access and complimentary access to in-house Business Center and Fitness Center. Lodging taxes of 12.5% and GST of 5% are not included in the above rate and are subject to change. Reservation Cutoff Date: 06 March 2020 Cancel with No Penalty: 72 hours prior to check-in/arrival Distance to Meeting Venue: 350 meters (5 minute walk) Reservations: https://tinyurl.com/107SUTTON 3. Metropolitan Hotel - (Overflow Hotel, block of 23 rooms) Room Rate: $229 CAD (single/double) Room Rates DO NOT include daily breakfast. Room Rate includes in-room high speed internet access and to Hotel Business Center, Fitness area, pools and saunas. Lodging rates of 11% and GST 5% (subject to change) are not included in the above rate. Reservation Cutoff Date: 26 February 2020 Cancel with No Penalty: 72 hours prior to check-in/arrival Distance to Meeting Venue: 350 meters (5 minute walk) Reservations: https://tinyurl.com/107METROPOLITAN 4. Coast Coal Harbour Hotel - (Overflow Hotel, block of 50 rooms) Room Rate: $195 CAD (single/double) Room Rates DO NOT include daily breakfast. Room Rate includes in-room high speed internet and access to Hotel Business Center, Fitness area, pools and whirlpool. Lodging taxes of 17.5% (subject to change) are not included in Room Rate. Reservation Cutoff Date: 26 February 2020 Cancel with No Penalty: 72 Hour prior to check in (Non-refundable 1 night deposit) Distance to Meeting Venue: 350 meters (5 minute walk) Reservations: https://tinyurl.com/107COASTCOAL 5. Fairmont Hotel Vancouver - (Overflow Hotel, Based on overall hotel availability) Room Rate: $249 CAD (single/double) Room Rates DO NOT include daily breakfast. Room Rate includes complimentary in-room internet. Municipal Hotel Tax 11%, GST 5% and Destination Marketing Fee Tax of 1.5% are not included in the above room rate. Taxes subject to change without notice. Reservation Cutoff Date: N/A Cancel with No Penalty: 48 Hour prior to check in/ arrival (Non-refundable 1 night deposit) Distance to Meeting Venue: 650 meters (9 minute walk) Reservations: https://tinyurl.com/107FAIRMONT More details at: https://www.ietf.org/how/meetings/107/hotel/ 4. Code Sprint The IETF 107 Code Sprint in Vancouver will, as always, let you work on fixing those things about the datatracker which you most urgently desire to do something about. When: Saturday, March 21 from 09:30 to 18:00 Where: Hyatt Regency Vancouver, Room TBD Signup: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF107SprintSignUp More information: https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF107Sprint 5. Hackathon The IETF is holding a Hackathon at IETF 107 to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. When: Saturday March 21 and Sunday March 22 Where: Hyatt Regency Vancouver, Room TBD Signup for the Hackathon: https://www.ietf.org/registration/ietf107/hackathonregistration.py More information can be found here: https://www.ietf.org/how/runningcode/hackathons/107-hackathon/ Keep up to date by subscribing to: https://www.ietf.org/mailman/listinfo/hackathon The Hackathon is free to attend and open to all. Extend the invitation to colleagues outside the IETF! Descriptions and information regarding the technologies for the hackathon are located on the IETF 107 Meeting Wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/107hackathon Don’t see anything that interests you? Feel free to add your preferred technology to the list, sign up as its Champion and show up to work on it. Note: you must login to the wiki to add content. If you do add a new technology, we strongly suggest that you send an email to hackathon@ietf.org to let others know. You may generate interest in your technology, and find other people who want to contribute to it. From nobody Fri Jan 31 12:52:27 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737AD120041 for ; Fri, 31 Jan 2020 12:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4b_7aV52-rx for ; Fri, 31 Jan 2020 12:52:22 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 76EC7120020 for ; Fri, 31 Jan 2020 12:52:22 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id 185so3948621pfv.3 for ; Fri, 31 Jan 2020 12:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Za2IfvrFRCdxBtEaPc3feHbWCO6pucg7PrYneoLG2IM=; b=oFIzWGoLURXATj1jhDOXq3n0JMAxivkBH9jUFIKjH6AWc/qWB0VPh8TsHUTwjwm6vC 918j7sfZL420XHkWnWzCs7m/o1nIkx6XZw7N5/lHMYxSnm2HJdFCwcvlhxOOKkyLBbrF mDWnFHSrkb6kkhOXp0KLexzbJinnLbJ6S7EHiiNMLfuyhe1hZZnGQCJr9V1Cz60tfTdU HJRazMpqlTv2KyHOsAjRUt13z4lJcclXu86O9EVidwreNDItBjNPmkZXevc3ZFL7z1kB 0k18Oi4Z0x7S+T63sIfSDKzPf0WjDhmuZBaAmN9QJlvSE5PurchcAEkMhBAnsnh9F6lt l5fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Za2IfvrFRCdxBtEaPc3feHbWCO6pucg7PrYneoLG2IM=; b=cHRI4YAUbrvzLFwEz6zoWorqZ/tDMIL6FVKsC4ibd/smlkVw0Rgkj16aaQsAOnkZsc pb9QcMLnnW0LU0reTtwFOdaANzgk0snTFqh4kRF8YP582/D/P+hmM1FvVFjP7IgcK6ve z6Dc752Fbga8pNPX8yvTh4/Q8IAD8LcLBqqnYq22IJbX+n2mdeWl+3Jcwus8FfHm78Cg 8auV1sk2xD5koP5kcRakm3MzBpN1rOOvTtNRnuv1bCQxHvpGK7PVBGx4VLNC1TAfvZsZ KBxFerFR/pZIURMW9V/yBbSKlDntOw1ZbuWqgmi8Y0MQut4mlWH1cE6uqTs0Uheub4cB FymA== X-Gm-Message-State: APjAAAVZAiYg942PLcO/NC4RJygVJFx/ugwZ15MEhX4D6Xa6C6DIiRzZ llRzBXvzbLdPLFTUZn32uXoL+OrU X-Google-Smtp-Source: APXvYqyrDRyGhlSzEINmNdQjxtDnrBwJqTbsdGY0/T0+P1bXcD9ENHiSuijNIv4cODuq+1eK/koj9A== X-Received: by 2002:a62:e719:: with SMTP id s25mr10765763pfh.40.1580503941215; Fri, 31 Jan 2020 12:52:21 -0800 (PST) Received: from BGPMacBookPro.charter.com ([2600:6c50:7f:5954:6052:6198:1597:9860]) by smtp.gmail.com with ESMTPSA id g22sm10972698pgk.85.2020.01.31.12.52.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 12:52:20 -0800 (PST) Subject: Re: UUID version 6 proposal, initial feedback From: Brad Peabody To: IETF discussion list References: Message-ID: Date: Fri, 31 Jan 2020 12:52:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------618B58F24B549439FEBBCA60" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 20:52:26 -0000 This is a multi-part message in MIME format. --------------618B58F24B549439FEBBCA60 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I've given this UUID idea a lot more thought and had more discussion on it and I wanted to get feedback on these latest ideas.  To summarize: - Instead of making one single way to generate UUIDs, it should be a set of options which indicate a UUID with the features needed.  Properties like case-insensitivity, how much random data is included, time ordering with a timestamp, and others, can be highly application-specific.   Trying to specify one set that works for everyone is unrealistic and unnecessary. - There appear to be three main aspects to generating a UUID: timestamp, random data and the text encoding of it.  Most of the options are centered around these three aspects.  Examples: timestamps can be in second-precise ("ts"), millisecond-precise ("tms") and nanosecond-precise ("tns") forms.  Random data can be in various lengths "r64" for 8 bytes of random data might be okay for many applications, some might want "r128" for the additional uniqueness, others might only want "r32" where occasional duplication is not dire (example: a unique ID for an error message used for debugging) and it's better to have a shorter ID.  Various encoding forms like "b32", "b64" (and some alphabet variations on this) and "hex" can be used. These are "format options" and together they make a "format spec" - There's also an option for some static bytes to be appended - for example a machine ID in a cluster. Useful for fully guaranteeing uniqueness in cases where there's a controlled environment. - In practical terms and as an example, a format spec of "tns r64 b32" would result in a nanosecond-precise timestamp (64 bits) followed by 64 bits of random data, encoded in base32. Alternatively, if you want to save on text length a bit and case-insensitivity is not important for your application, use "tns r64 b64" instead. - UUIDs in text form are parseable if one knows the format spec used.  (This addresses the case of some applications needing to extract the timestamp, without over complicating the UUID text format by trying to somehow include the format spec in it.) Otherwise it can also of course be used as an opaque string. - The special format option "rfc4122" results in a timestamp in the format of that RFC, the number 6 in the version bit field, and the lower 64 bits filled with random data.   This addresses the backward compatibility concern while allowing newer applications to be more flexible (using other options instead). This is the document I've been putting together, it's still very rough, but has a fair amount of detail: https://docs.google.com/document/d/1bctTr14CrxzjHUIRAkT8jB46Jomr9aB2JQ9hDCh3cJg Any feedback on this would greatly appreciated.  Overall my plan is to complete the document above and then write an implementation in Go and in C (and maybe it's time to learn Rust, lol) to make sure it works in practice.  And then convert the document into an IETF draft and try for moving it toward becoming an RFC. Best, Brad On 7/4/18 1:44 AM, Brad Peabody wrote: > Thanks Martin, > > Those are really good points and I agree. > > I’m a bit concerned about moving entirely away from the existing > format, as I think there are some useful properties - particularly the > ability to extract the time stamp. Also by producing newer versions of > UUIDs that are the same size and layout a lot of existing software > will continue to work (for example, Cassandra understands UUIDs and > works with my prototype “version 6” UUIDs without any modification). > > But the points you bring up are quite relevant.  I’m not sure how to > address the clock skew leakage that might occur, but definitely the > counters and MAC address can go the way of the buffalo. Simply reading > from /dev/urandom, et al makes so much more sense these days. > > I think there is also real potential in the idea of making them > variable length.  If you need compatibility with existing UUID schemes > you can use the 128 bit length, but you can also go longer if you > require more guarantee of uniqueness or un-guess-ability. > > The only other thing that has me pondering on this is how important is > the property of being able to tell “is this a valid UUID, and if so > what type”.  If we don’t care about this, then it might make sense to > have two additional formats - a base64 which is as compact as > reasonably possible while still being ASCII, and a base32 which is > case-insensitive - they both have merit depending on the use case. >  But then add the fact that it’s variable length and it becomes > impossible to distinguish the format reliably (i.e you might read the > base32 value as base64 by accident).  I can think of some ways to work > around this in the format using specific characters in one and not the > other, but it starts to feel really hacky.  I’m just not sure if this > is actually important for real-world applications.  Many applications > just use the UUID opaquely, but not all.  And again, extracting the > timestamp can be useful - but then is it reasonable to also say “if > you want the time, you’ll need to know the format, you won’t be able > to automatically tell the difference between a base64 and base32 > UUID”.  One possible simple solution: put a period after the first 128 > bits > > Still not sure on this, input welcome. > > All that said, it seems to me we’re headed for a spec that has the > following properties: > > - Encodes timestamp > - Sorts correctly as raw bytes > - Has the version field in the same place for compatibility > - Supports the existing 128-bit hex representation > (NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN) for compatibility but also... > - Specifies alternative (url-safe) base64 encoding for compact string > representation while still sorting correctly; and also a base32 > encoding where case-insensitivity is required > - Instead of existing dangerous bits like counter and MAC address, use > secure random data available from OS > - Can be arbitrarily longer as needed, filled with additional random data. > > Does that seem about right? > > Also, when things settle in terms of the high level requirements, at > what point should I do a rough draft of the spec on this?  (And is > there some sort of outline I would follow?) > > -Brad > > >> On Jul 3, 2018, at 7:11 PM, Martin Thomson >> wrote: >> >> Nice presentation. >> >> I've always been skeptical of the value of UUIDs.  It's very easy to >> make a unique string.  Formatting it in a particular way, however, >> serves no real purpose and it might not be necessary for your use >> case. >> >> UUIDs (aside from v4) also have some nasty properties.  For instance, >> revealing a MAC address is now considered problematic.  As is exposing >> the output of a clock, which has been used in interesting ways to >> undermine privacy (clock skew can be used for de-anonymisation, even >> for determining CPU load).  Counters and timers also allow an observer >> to correlate the creation of different identifiers. >> >> Why not make a string with the properties you desire?  You might need >> more than 120 bits to achieve all that, but that's just another reason >> not to use UUIDs.  A library that provided these functions (maybe >> while addressing the above concerns), would be a valuable addition. >> On Wed, Jul 4, 2018 at 10:42 AM Brad Peabody >> wrote: >>> >>> I would like to get some initial feedback, and suggested next steps, >>> on the idea of making an RFC that covers a version 6 for UUIDs.  It >>> would have an embedded timestamp and sorting by its raw bytes >>> results in a sequence equivalent to sorting by time.  This is not >>> addressed by existing UUID types.  (The closest one is version 1, >>> but due to the byte encoding it does not sort correctly.) >>> >>> There is also seems to be some ambiguity in the existing RFC on when >>> to increment the counter field which I think can be clarified. >>> >>> I did a prototype implementation and basic write-up on the details >>> here: https://bradleypeabody.github.io/uuidv6/ >>> >>> I’m also thinking of covering the base64 encoding form which retains >>> the sorting properties but makes it human readable and is >>> significantly shorter than the long hex encoded form. >>> >>> Having these things is very useful when considering UUIDs as >>> database primary keys, which is becoming more and more common in >>> distributed systems; and indeed this is the main motivation. >>> >>> Any help or advice on moving forward with this would be appreciated. >>> >>> - Brad >>> > --------------618B58F24B549439FEBBCA60 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I've given this UUID idea a lot more thought and had more discussion on it and I wanted to get feedback on these latest ideas.  To summarize:

- Instead of making one single way to generate UUIDs, it should be a set of options which indicate a UUID with the features needed.  Properties like case-insensitivity, how much random data is included, time ordering with a timestamp, and others, can be highly application-specific.   Trying to specify one set that works for everyone is unrealistic and unnecessary.

- There appear to be three main aspects to generating a UUID: timestamp, random data and the text encoding of it.  Most of the options are centered around these three aspects.  Examples: timestamps can be in second-precise ("ts"), millisecond-precise ("tms") and nanosecond-precise ("tns") forms.  Random data can be in various lengths "r64" for 8 bytes of random data might be okay for many applications, some might want "r128" for the additional uniqueness, others might only want "r32" where occasional duplication is not dire (example: a unique ID for an error message used for debugging) and it's better to have a shorter ID.  Various encoding forms like "b32", "b64" (and some alphabet variations on this) and "hex" can be used. These are "format options" and together they make a "format spec"

- There's also an option for some static bytes to be appended - for example a machine ID in a cluster. Useful for fully guaranteeing uniqueness in cases where there's a controlled environment.

- In practical terms and as an example, a format spec of "tns r64 b32" would result in a nanosecond-precise timestamp (64 bits) followed by 64 bits of random data, encoded in base32.  Alternatively, if you want to save on text length a bit and case-insensitivity is not important for your application, use "tns r64 b64" instead.

- UUIDs in text form are parseable if one knows the format spec used.  (This addresses the case of some applications needing to extract the timestamp, without over complicating the UUID text format by trying to somehow include the format spec in it.)  Otherwise it can also of course be used as an opaque string.

- The special format option "rfc4122" results in a timestamp in the format of that RFC, the number 6 in the version bit field, and the lower 64 bits filled with random data.   This addresses the backward compatibility concern while allowing newer applications to be more flexible (using other options instead).

This is the document I've been putting together, it's still very rough, but has a fair amount of detail: https://docs.google.com/document/d/1bctTr14CrxzjHUIRAkT8jB46Jomr9aB2JQ9hDCh3cJg

Any feedback on this would greatly appreciated.  Overall my plan is to complete the document above and then write an implementation in Go and in C (and maybe it's time to learn Rust, lol) to make sure it works in practice.  And then convert the document into an IETF draft and try for moving it toward becoming an RFC.

Best, Brad


On 7/4/18 1:44 AM, Brad Peabody wrote:
Thanks Martin,

Those are really good points and I agree.

I’m a bit concerned about moving entirely away from the existing format, as I think there are some useful properties - particularly the ability to extract the time stamp. Also by producing newer versions of UUIDs that are the same size and layout a lot of existing software will continue to work (for example, Cassandra understands UUIDs and works with my prototype “version 6” UUIDs without any modification).

But the points you bring up are quite relevant.  I’m not sure how to address the clock skew leakage that might occur, but definitely the counters and MAC address can go the way of the buffalo. Simply reading from /dev/urandom, et al makes so much more sense these days.

I think there is also real potential in the idea of making them variable length.  If you need compatibility with existing UUID schemes you can use the 128 bit length, but you can also go longer if you require more guarantee of uniqueness or un-guess-ability.

The only other thing that has me pondering on this is how important is the property of being able to tell “is this a valid UUID, and if so what type”.  If we don’t care about this, then it might make sense to have two additional formats - a base64 which is as compact as reasonably possible while still being ASCII, and a base32 which is case-insensitive - they both have merit depending on the use case.  But then add the fact that it’s variable length and it becomes impossible to distinguish the format reliably (i.e you might read the base32 value as base64 by accident).  I can think of some ways to work around this in the format using specific characters in one and not the other, but it starts to feel really hacky.  I’m just not sure if this is actually important for real-world applications.  Many applications just use the UUID opaquely, but not all.  And again, extracting the timestamp can be useful - but then is it reasonable to also say “if you want the time, you’ll need to know the format, you won’t be able to automatically tell the difference between a base64 and base32 UUID”.  One possible simple solution: put a period after the first 128 bits

Still not sure on this, input welcome.

All that said, it seems to me we’re headed for a spec that has the following properties:

- Encodes timestamp
- Sorts correctly as raw bytes
- Has the version field in the same place for compatibility
- Supports the existing 128-bit hex representation (NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN) for compatibility but also...
- Specifies alternative (url-safe) base64 encoding for compact string representation while still sorting correctly; and also a base32 encoding where case-insensitivity is required
- Instead of existing dangerous bits like counter and MAC address, use secure random data available from OS
- Can be arbitrarily longer as needed, filled with additional random data.

Does that seem about right?

Also, when things settle in terms of the high level requirements, at what point should I do a rough draft of the spec on this?  (And is there some sort of outline I would follow?)

-Brad 


On Jul 3, 2018, at 7:11 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

Nice presentation.

I've always been skeptical of the value of UUIDs.  It's very easy to
make a unique string.  Formatting it in a particular way, however,
serves no real purpose and it might not be necessary for your use
case.

UUIDs (aside from v4) also have some nasty properties.  For instance,
revealing a MAC address is now considered problematic.  As is exposing
the output of a clock, which has been used in interesting ways to
undermine privacy (clock skew can be used for de-anonymisation, even
for determining CPU load).  Counters and timers also allow an observer
to correlate the creation of different identifiers.

Why not make a string with the properties you desire?  You might need
more than 120 bits to achieve all that, but that's just another reason
not to use UUIDs.  A library that provided these functions (maybe
while addressing the above concerns), would be a valuable addition.
On Wed, Jul 4, 2018 at 10:42 AM Brad Peabody <bradgareth@gmail.com> wrote:

I would like to get some initial feedback, and suggested next steps, on the idea of making an RFC that covers a version 6 for UUIDs.  It would have an embedded timestamp and sorting by its raw bytes results in a sequence equivalent to sorting by time.  This is not addressed by existing UUID types.  (The closest one is version 1, but due to the byte encoding it does not sort correctly.)

There is also seems to be some ambiguity in the existing RFC on when to increment the counter field which I think can be clarified.

I did a prototype implementation and basic write-up on the details here: https://bradleypeabody.github.io/uuidv6/

I’m also thinking of covering the base64 encoding form which retains the sorting properties but makes it human readable and is significantly shorter than the long hex encoded form.

Having these things is very useful when considering UUIDs as database primary keys, which is becoming more and more common in distributed systems; and indeed this is the main motivation.

Any help or advice on moving forward with this would be appreciated.

- Brad


--------------618B58F24B549439FEBBCA60-- From nobody Fri Jan 31 13:45:27 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A490120046 for ; Fri, 31 Jan 2020 13:45:23 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=akamai.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 vVrySXM5Es2b for ; Fri, 31 Jan 2020 13:45:20 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D833D120043 for ; Fri, 31 Jan 2020 13:45:19 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 00VLdNCu013863; Fri, 31 Jan 2020 21:45:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=sCiBKrNoo0gJavrSi5kQmgv9IAnBo/pbRvfAMbA8d1M=; b=VqVbWzvCW1i07UFZ6d9iqFBH2hHQypnBLFY4iNakTkvrPuXdQeMFlQP6lDlgEvM0aewx JCeSCJZ4jDdTjtoRol36ReKayaDy80VScNnkSzr7qEVmbIFkAj3ts2+TYpbT2+NNmWeC MYL/HhG+tXypzg7Mn4QmsYnjFJNl0n+NssKU1Vp+2sP/UenQxw3JdHXwjGavqHa8L+EX IPfIrbOanN7BBBX2YgBj35qYcnVs32jVr+NTX9N41p8BahJLoPpBHy7qmuCzySLr5qr7 ITAKwr0Sa7qzSDEoodglXqalOHagG1qZmzesor1LUUfyUCQzeps6F3YgHoI29GpyzFNG Ew== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2xuwxbke2f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 21:45:17 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00VLdpmr020041; Fri, 31 Jan 2020 16:45:16 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2xrhw1ywpb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 16:45:15 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 16:45:07 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Fri, 31 Jan 2020 16:45:07 -0500 From: "Salz, Rich" To: Brad Peabody , IETF discussion list Subject: Re: UUID version 6 proposal, initial feedback Thread-Topic: UUID version 6 proposal, initial feedback Thread-Index: AQHV2Hhgst2kZLm7HUCciPkYEwPu1agFTnYA Date: Fri, 31 Jan 2020 21:45:07 +0000 Message-ID: <6E165220-7D1F-4AD8-B4F3-DDCB8F1DA6E2@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.110] Content-Type: multipart/alternative; boundary="_000_6E1652207D1F4AD8B4F3DDCB8F1DA6E2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=978 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001310174 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-31_07:2020-01-31, 2020-01-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 impostorscore=0 malwarescore=0 adultscore=0 bulkscore=0 spamscore=0 clxscore=1011 phishscore=0 mlxlogscore=933 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2001310174 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 21:45:23 -0000 --_000_6E1652207D1F4AD8B4F3DDCB8F1DA6E2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgYWxsIHRoYXQgbWVjaGFuaXNtLiAg VVVJROKAmXMgYXJlIHN1cHBvc2VkIHRvIGJlIG9wYXF1ZSBpZGVudGlmaWVyczsgaWYgeW91IGlu dGVuZCBmb2xrcyB0byBsb29rIGluc2lkZSB0aGVtLCB0aGVuIHlvdSBzaG91bGQgbm90IGJlIHVz aW5nIFVVSUQsIHlvdSBzaG91bGQgYmUgdXNpbmcgc29tZXRoaW5nIGVsc2Ugd2hlcmUgdGhlIGlu c2lkZXMgYXJlIG9uIHRoZSBvdXRzaWRlLCBhcyBpdCB3ZXJlLg0KDQpVVUlE4oCZcyBhcmUgdmVy eSBvbGQsIHRoZXkgd2VyZSBmaXJzdCBwYXJ0IG9mIEFwb2xsb+KAmXMgTmV0d29yayBDb21wdXRp bmcgQXJjaGl0ZWN0dXJlIGluIHRoZSAxOTgw4oCZcy4gIElmIHdlIHdlcmUgcmVjcmVhdGluZyB0 aGVtIHRvZGF5LCB3ZeKAmWQganVzdCB1c2UgYSBjcnlwdG9ncmFwaGljIG5vbmNlLiAgSSBzdWdn ZXN0IHRoYXTigJlzIHdoYXQgeW91IGRvIGFzIHdlbGwuDQoNCg== --_000_6E1652207D1F4AD8B4F3DDCB8F1DA6E2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <29A8AB346F609D4098C60A611E8DF26E@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUg cHVycG9zZSBvZiBhbGwgdGhhdCBtZWNoYW5pc20uJm5ic3A7IFVVSUTigJlzIGFyZSBzdXBwb3Nl ZCB0byBiZSBvcGFxdWUgaWRlbnRpZmllcnM7IGlmIHlvdSBpbnRlbmQgZm9sa3MgdG8gbG9vayBp bnNpZGUgdGhlbSwgdGhlbiB5b3Ugc2hvdWxkIG5vdCBiZSB1c2luZyBVVUlELCB5b3Ugc2hvdWxk IGJlIHVzaW5nIHNvbWV0aGluZyBlbHNlIHdoZXJlIHRoZSBpbnNpZGVzIGFyZSBvbg0KIHRoZSBv dXRzaWRlLCBhcyBpdCB3ZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VVUlE4oCZcyBhcmUg dmVyeSBvbGQsIHRoZXkgd2VyZSBmaXJzdCBwYXJ0IG9mIEFwb2xsb+KAmXMgTmV0d29yayBDb21w dXRpbmcgQXJjaGl0ZWN0dXJlIGluIHRoZSAxOTgw4oCZcy4gJm5ic3A7SWYgd2Ugd2VyZSByZWNy ZWF0aW5nIHRoZW0gdG9kYXksIHdl4oCZZCBqdXN0IHVzZSBhIGNyeXB0b2dyYXBoaWMgbm9uY2Uu Jm5ic3A7IEkgc3VnZ2VzdCB0aGF04oCZcyB3aGF0IHlvdSBkbyBhcyB3ZWxsLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E1652207D1F4AD8B4F3DDCB8F1DA6E2akamaicom_-- From nobody Fri Jan 31 14:07:06 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9632512004F for ; Fri, 31 Jan 2020 14:07:04 -0800 (PST) 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 q4RLToLNeNpn for ; Fri, 31 Jan 2020 14:07:01 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 D631712002E for ; Fri, 31 Jan 2020 14:07:01 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id q8so4039628pfh.7 for ; Fri, 31 Jan 2020 14:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=zVfSveSMITm2fpknmbMCxsmAUivoQqeME3sIKgoOGw0=; b=PSOvBSfuzZqxclXnD1rHVImsiFSaZJCm2/vWk7+qPR8XcTNlwrJJGfoHTqbHocgzY+ drSut2uyRG0qgYKrKstxcCiZP05g8eAxq3RY/qT9RFrYbvreUVc844tewclUDn8yTNaB yVIC/quQVpWYIvhVpYVVXxE7w83wbBp/nKIzkow9kS0VQyKxkxBRE1+bKPYCHNr9mT7N Sa3fnsp2btsjZKcboEnOYKsUyuAKOxQzSOsghi21P+g9B1+jJcEAp6JMBqo1kTnp4ETF cDysachW1MKz1lxi4wEiz9pCe3LsklK/Uw04Ef6SfdQGb2OlRb5O+TVVZDyoAkAZsn5G Xw7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=zVfSveSMITm2fpknmbMCxsmAUivoQqeME3sIKgoOGw0=; b=aSfWNHtoFH2oVa5J1IBPvIji87nr4uf0VSb7fzsz04OxKj4n2L2FIdZe+tXydbmeGi RnfPn6EpQBI3adh5bW7xJZX9VV1JGTV2oaiayMZOO4PU9J9urex0XviJjg3gl0Vs2VES +cYzj4L0ZHiU8Rr27cMOI8ov0NKDD7KkiR+l0vGcf7dVGhO44DLEiToMhKzlYmYxJgB9 ZvmkoXDXuURYBhNj+UnfInVf3zDxJXPkgELv6SRiVpTd2Tz/DAiHWrNRt18X7BNbn+nI PsfqIh5+mbp6ZFrue4zKwOX/82z+I81lXP7g5Swzu7uLrmmy5rQKxX3Mo8ZD2iwaGew4 Jmgg== X-Gm-Message-State: APjAAAWD0xOH1l1mYzWgyVvVqS6CN9E5IgXJFHOH19Wa8mxO6mxHKJ12 WBzvvmxIzzLqTNTVeFXhSlIAjqgA X-Google-Smtp-Source: APXvYqzkOQMcDNF8oquzUjUGscPrJmVUtS0a/ahg/+QawaAi+FFIafP/prAu1YhMWbwDjKrHpr7naw== X-Received: by 2002:aa7:914b:: with SMTP id 11mr12991705pfi.69.1580508420913; Fri, 31 Jan 2020 14:07:00 -0800 (PST) Received: from BGPMacBookPro.charter.com ([2600:6c50:7f:5954:6052:6198:1597:9860]) by smtp.gmail.com with ESMTPSA id d24sm12470526pfq.75.2020.01.31.14.06.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jan 2020 14:06:59 -0800 (PST) Subject: Re: UUID version 6 proposal, initial feedback To: "Salz, Rich" , IETF discussion list References: <6E165220-7D1F-4AD8-B4F3-DDCB8F1DA6E2@akamai.com> From: Brad Peabody Message-ID: Date: Fri, 31 Jan 2020 14:06:58 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <6E165220-7D1F-4AD8-B4F3-DDCB8F1DA6E2@akamai.com> Content-Type: multipart/alternative; boundary="------------6F345E340AF322A4AA68222F" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 22:07:05 -0000 This is a multi-part message in MIME format. --------------6F345E340AF322A4AA68222F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I get where you're coming coming.  The issue is there are common use cases where just using cryptographic nonce does not work well. Random UUIDs as primary keys in databases have bad write amplification properties.  (example: https://github.com/uuidjs/uuid/issues/303#issuecomment-575992079) A timestamp provides locality in database indexes as well as a useful natural order in the database. The text format of a UUID is generally not the best way to store it in memory.  So after an identifier (timestamp or not) has been created there is the issue of how you show it to humans vs its binary form, and there are tradeoffs with different formats (size, case-insensitivity, backward compatibility). What I laid out is essentially a collection of options that seem to come up time and again dealing with unique identifiers.  I think there is benefit in standardizing it.  The list of open source projects that each have their own way of creating unique identifiers is quite long and the wheel is reinvented often. (Some examples: https://github.com/segmentio/ksuid https://github.com/rs/xid https://github.com/kjk/betterguid https://github.com/sony/sonyflake https://github.com/oklog/ulid https://github.com/chilts/sid ) I agree this is not a terribly complex problem and some applications can just read from /dev/urandom and be done with it. But I also believe the above concerns are real and affect a lot of real-world applications. On 1/31/20 1:45 PM, Salz, Rich wrote: > > I don’t understand the purpose of all that mechanism.  UUID’s are > supposed to be opaque identifiers; if you intend folks to look inside > them, then you should not be using UUID, you should be using something > else where the insides are on the outside, as it were. > > UUID’s are very old, they were first part of Apollo’s Network > Computing Architecture in the 1980’s.  If we were recreating them > today, we’d just use a cryptographic nonce.  I suggest that’s what you > do as well. > --------------6F345E340AF322A4AA68222F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I get where you're coming coming.  The issue is there are common use cases where just using cryptographic nonce does not work well.

Random UUIDs as primary keys in databases have bad write amplification properties.  (example: https://github.com/uuidjs/uuid/issues/303#issuecomment-575992079)  A timestamp provides locality in database indexes as well as a useful natural order in the database.

The text format of a UUID is generally not the best way to store it in memory.  So after an identifier (timestamp or not) has been created there is the issue of how you show it to humans vs its binary form, and there are tradeoffs with different formats (size, case-insensitivity, backward compatibility).

What I laid out is essentially a collection of options that seem to come up time and again dealing with unique identifiers.  I think there is benefit in standardizing it.  The list of open source projects that each have their own way of creating unique identifiers is quite long and the wheel is reinvented often.  (Some examples: https://github.com/segmentio/ksuid https://github.com/rs/xid https://github.com/kjk/betterguid https://github.com/sony/sonyflake https://github.com/oklog/ulid https://github.com/chilts/sid )

I agree this is not a terribly complex problem and some applications can just read from /dev/urandom and be done with it.  But I also believe the above concerns are real and affect a lot of real-world applications.


On 1/31/20 1:45 PM, Salz, Rich wrote:

I don’t understand the purpose of all that mechanism.  UUID’s are supposed to be opaque identifiers; if you intend folks to look inside them, then you should not be using UUID, you should be using something else where the insides are on the outside, as it were.

 

UUID’s are very old, they were first part of Apollo’s Network Computing Architecture in the 1980’s.  If we were recreating them today, we’d just use a cryptographic nonce.  I suggest that’s what you do as well.

 

--------------6F345E340AF322A4AA68222F-- From nobody Fri Jan 31 18:41:18 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D861120047 for ; Fri, 31 Jan 2020 18:41:17 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=akamai.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 AQ8L_lIq-R8Q for ; Fri, 31 Jan 2020 18:41:16 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 19A97120024 for ; Fri, 31 Jan 2020 18:41:16 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0112dnHe014045; Sat, 1 Feb 2020 02:41:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=HJzvlWKeYo0gXX/fBx4zCcfe8hemd0ZOzEvTQwgy1Ns=; b=C/cKTQ/1R4qVpdbtDznpI9mXBiuQFV/b6f4HqQ5zUOY5TOzhV1CV7ug3gK9KI32ebdpR EZOf2+diHM6lb4NR0/aincbPem3HsLQrhE1wepBvMepiPBDl8iFp148LLwGntlpYSks0 EU8zQzD0i4doynyaA49bM9uB4QC7E2nH+fXYCrPVZzP/fzkVHU4mhIARppPlEFNib2jS iVwcoh/pTDqNxSBwAOP9NXk8o5+KRaSf+uO653XyDQ7eKiXB7jHtW9AdUp8ceY7PZ/jY jo+LI+adU9aZ1a8Zx1aHP4yMYe/3m5nCR1qa9KNtUDNbgHuYo6elyYDuiLjDcM6j6wbZ Jg== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2xuxpg8r0t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 01 Feb 2020 02:41:14 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 0112WdhG026341; Fri, 31 Jan 2020 18:41:13 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xrmhc8g9a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 18:41:13 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 21:41:12 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Fri, 31 Jan 2020 21:41:12 -0500 From: "Salz, Rich" To: Brad Peabody , IETF discussion list Subject: Re: UUID version 6 proposal, initial feedback Thread-Topic: UUID version 6 proposal, initial feedback Thread-Index: AQHV2Hhgst2kZLm7HUCciPkYEwPu1agFTnYAgABZ7QD///jNAA== Date: Sat, 1 Feb 2020 02:41:12 +0000 Message-ID: References: <6E165220-7D1F-4AD8-B4F3-DDCB8F1DA6E2@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.251] Content-Type: multipart/alternative; boundary="_000_E49706DE5A3A44039A0BF9F4804CFEA1akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=928 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002010013 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-31_07:2020-01-31, 2020-01-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=900 spamscore=0 phishscore=0 mlxscore=0 bulkscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1911200001 definitions=main-2002010014 Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 02:41:17 -0000 --_000_E49706DE5A3A44039A0BF9F4804CFEA1akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2hhdCBJIGxhaWQgb3V0IGlzIGVzc2VudGlhbGx5IGEgY29sbGVjdGlvbiBvZiBvcHRp b25zIHRoYXQgc2VlbSB0byBjb21lIHVwIHRpbWUgYW5kIGFnYWluIGRlYWxpbmcgd2l0aCB1bmlx dWUgaWRlbnRpZmllcnMuICBJIHRoaW5rIHRoZXJlIGlzIGJlbmVmaXQgaW4gc3RhbmRhcmRpemlu ZyBpdC4NCg0KQ29uc2lkZXJhdGlvbnMgaW4gZGVzaWduaW5nIHVuaXF1ZSBpZGVudGlmaWVycyBz b3VuZHMgbGlrZSBpdCBjb3VsZCBiZSBhIHdvcnRod2hpbGUgUkZDLiBJIGp1c3QgZG9u4oCZdCB0 aGluayB0aGV54oCZcmUgVVVJROKAmXMuDQoNCj4gc29tZSBhcHBsaWNhdGlvbnMgY2FuIGp1c3Qg cmVhZCBmcm9tIC9kZXYvdXJhbmRvbSBhbmQgYmUgZG9uZSB3aXRoIGl0Lg0KDQpUaGF0IGlzIGZy YXVnaHQgd2l0aCBkYW5nZXIsIG5vdCBnb2luZyB0byBnZXQgaW50byBpdCBvbiB0aGlzIGdlbmVy YWwgcHVibGljIGxpc3QuDQoNCg== --_000_E49706DE5A3A44039A0BF9F4804CFEA1akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <99DFF67E1DAD074B8E1905240FD7BF25@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDc5Njg4MjMyOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM5ODk1NjYgMjAwOTM0MTY2NCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGli cmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgc3R5bGU9Im1z by1saXN0OmwwIGxldmVsMSBsZm8xIj5XaGF0IEkgbGFpZCBvdXQgaXMgZXNzZW50aWFsbHkgYSBj b2xsZWN0aW9uIG9mIG9wdGlvbnMgdGhhdCBzZWVtIHRvIGNvbWUgdXAgdGltZSBhbmQgYWdhaW4g ZGVhbGluZyB3aXRoIHVuaXF1ZSBpZGVudGlmaWVycy4mbmJzcDsgSSB0aGluayB0aGVyZSBpcyBi ZW5lZml0IGluIHN0YW5kYXJkaXppbmcgaXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cD5Db25z aWRlcmF0aW9ucyBpbiBkZXNpZ25pbmcgdW5pcXVlIGlkZW50aWZpZXJzIHNvdW5kcyBsaWtlIGl0 IGNvdWxkIGJlIGEgd29ydGh3aGlsZSBSRkMuIEkganVzdCBkb27igJl0IHRoaW5rIHRoZXnigJly ZSBVVUlE4oCZcy48bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgc29tZSBhcHBsaWNhdGlvbnMgY2Fu IGp1c3QgcmVhZCBmcm9tIC9kZXYvdXJhbmRvbSBhbmQgYmUgZG9uZSB3aXRoIGl0LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHA+VGhhdCBpcyBmcmF1Z2h0IHdpdGggZGFuZ2VyLCBub3QgZ29pbmcg dG8gZ2V0IGludG8gaXQgb24gdGhpcyBnZW5lcmFsIHB1YmxpYyBsaXN0LjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E49706DE5A3A44039A0BF9F4804CFEA1akamaicom_-- From nobody Fri Jan 31 19:03:24 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6FA12004C for ; Fri, 31 Jan 2020 19:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 OCZ1GdtnaDg4 for ; Fri, 31 Jan 2020 19:03:21 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFB9120018 for ; Fri, 31 Jan 2020 19:03:21 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C63C95F3; Fri, 31 Jan 2020 22:03:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 31 Jan 2020 22:03:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Q25Qf5 u+7lJqWGqRrC/qk+LlJNYaEdM1tdscRbw+lkU=; b=B2qCzuOYII0dCNskIHF7mO o/yuMdxtlveTa7AEvZnb6nyTRm48J+WhUWumMLPEDPDRx2n/gHRYYHPbt6nqjpcq ZRjpeTRS4ZIU/zXAOXbxYUoqnSGam3nbkb1Ao1P3VWltwTe6D8vHzy3bF5i8lKu8 K996RCM9F55XvqeRhIWlUBrVmSV3UNvrLaslgMrMukVQ+lqnIfZjfsOz2i3u10KO rIhgfxZIZ9yYowkeA/rn2zhvsdWAveJvp2CL50ZsChXEivOWWznSquRt6K13f65F LCZujxGtkTQth2a7Aq9Q2G5K7lEizwt0XBgFNpYI4+4YH3g+JeUoUrK2bGaNhwdQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgedugdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucfkphepuddtkedrvddvuddrudektddrudehne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhr vgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B7210328005D; Fri, 31 Jan 2020 22:03:19 -0500 (EST) Subject: Re: UUID version 6 proposal, initial feedback To: ietf@ietf.org References: <6E165220-7D1F-4AD8-B4F3-DDCB8F1DA6E2@akamai.com> From: Keith Moore Message-ID: Date: Fri, 31 Jan 2020 22:03:18 -0500 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: Content-Type: multipart/alternative; boundary="------------3290C7960B43EAD830D6482A" Content-Language: en-US Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 03:03:23 -0000 This is a multi-part message in MIME format. --------------3290C7960B43EAD830D6482A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/31/20 9:41 PM, Salz, Rich wrote: > * What I laid out is essentially a collection of options that seem > to come up time and again dealing with unique identifiers.  I > think there is benefit in standardizing it. > > Considerations in designing unique identifiers sounds like it could be > a worthwhile RFC. I just don’t think they’re UUID’s. > I concur.   I think it would be a better proposal if they were called something else. Keith --------------3290C7960B43EAD830D6482A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 1/31/20 9:41 PM, Salz, Rich wrote:

  • What I laid out is essentially a collection of options that seem to come up time and again dealing with unique identifiers.  I think there is benefit in standardizing it.

Considerations in designing unique identifiers sounds like it could be a worthwhile RFC. I just don’t think they’re UUID’s.

I concur.   I think it would be a better proposal if they were called something else.

Keith


--------------3290C7960B43EAD830D6482A-- From nobody Fri Jan 31 22:07:44 2020 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F862120048 for ; Fri, 31 Jan 2020 22:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GhKO-UWhNS9 for ; Fri, 31 Jan 2020 22:07:40 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6677A120018 for ; Fri, 31 Jan 2020 22:07:40 -0800 (PST) Received: from callcc.thunk.org (guestnat-104-133-9-100.corp.google.com [104.133.9.100] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01167XjV022176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 1 Feb 2020 01:07:35 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 64884420324; Sat, 1 Feb 2020 01:07:33 -0500 (EST) Date: Sat, 1 Feb 2020 01:07:33 -0500 From: "Theodore Y. Ts'o" To: Brad Peabody Cc: "Salz, Rich" , IETF discussion list Subject: Re: UUID version 6 proposal, initial feedback Message-ID: <20200201060733.GD454818@mit.edu> References: <6E165220-7D1F-4AD8-B4F3-DDCB8F1DA6E2@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 06:07:42 -0000 On Fri, Jan 31, 2020 at 02:06:58PM -0800, Brad Peabody wrote: > I get where you're coming coming. The issue is there are common use cases > where just using cryptographic nonce does not work well. > > Random UUIDs as primary keys in databases have bad write amplification > properties. (example: > https://github.com/uuidjs/uuid/issues/303#issuecomment-575992079) A > timestamp provides locality in database indexes as well as a useful natural > order in the database. As as you point at in [1], it's trivial to covert between your "version 6" and the V1 UUID --- it's just a matter of swapping the bytes. [1] http://gh.peabody.io/uuidv6/ As it happens, I'm aware of at least one large enterprise application which swaps the bytes before storing a UUID into a database, because it uses the UUID's for keys in its system. In fact, it's *because* of this application that the Linux implementation of libuuid has an optional-to-run uuidd helper daemon: The uuidd daemon is used by the UUID library to generate universally unique identifiers (UUIDs), especially time- based UUIDs, in a secure and guaranteed-unique fashion, even in the face of large numbers of threads running on different CPUs trying to grab UUIDs. This was implemented in 2007 because this particular large enterprise application (used in many Fortune 100 companies) needs a *huge* number of UUID when doing its initial database setup. But the point is they did this as a storage issue --- it's how they fold, spindle, and mutilate the UUID before they store it into the database and use it as a key. There is no need to define a new UUID version for this hack, since it's so easy to transform a v1 UUID into a more database-friendly format and back again. You can just treat it as an internal implementation detail of how the UUID is stored and lookups performed in the database. > I agree this is not a terribly complex problem and some applications can > just read from /dev/urandom and be done with it. But I also believe the > above concerns are real and affect a lot of real-world applications. /dev/urandom is a Linux specific thing. The better choice is libuuid. The libuuid library is installed on all Linux systems, so they can just link with -luuid and use uuid_generate(). It's also installed on MacOS systems (I changed the license to make it more accepted for MacOS) and since it is required by GNOME, it's generally available on all of the *BSD ports. So for most applications, the best way to go is to use uuid_generate() and link with -luuid. That's going to be more portable and more secure. - Ted